Google Summer of Code 2011 Ideas

Project Suggestions

BFS Installable Filesystem Driver for NT

Objective: Create a filesystem driver permitting read and write access for the BFS filesystem. As BFS possesses a rather rich set of metadata functionality, it serves as a workable placeholder for NTFS. A BFS filesystem driver would serve as a testbench against future development of the filesystem runtime library and common cache on ReactOS. In addition, the driver would allow a certain amount of interoperability with the likes of Haiku.

Goals: Working BFS driver that runs in Windows XP or later.

• Milestone 1: Ability to mount and read BFS partitions.
• Milestone 2: Ability to write to BFS partitions without extensive metadata attributes.
• Milestone 3: Ability to write and edit BFS metadata attributes.

Performance Data Registry

Access to performance data on Windows is done primarily through the registry API, accessing something known as the performance data hive. This hive does not exist as a genuine file but is in reality a collection of data exported by various OS components, drivers, services, and even applications. The Windows Task Manager is an example of an application that queries the performance data hive. Condor is another application that uses the performance data hive.

Missing Functionality:

• Centralized exporting of data (counters) meant for the performance data hive. Currently information from the memory manager, scheduler, and I/O manager are all scattered across multiple data structures or locations. These should be more concentrated so that reading and writing these values do not require jumping around random places in memory. This data is also not shared and will likely require placement in shared, non-paged memory.
• Tracking system for performance counters. Publishing of performance counters can be done by many different components and applications. A mechanism must be implemented that keeps track of who is publishing this data, where the data is, and what kind of data is being published.
• The registry functions used to access the performance data hive must be extended to deal with the data structures in the performance data hive. The layout is very different and for all intents and purposes does not match the regular registry's hierarchy at all.
• A wrapper API was released in Vista that abstracts away the need to use the registry API to access performance counter data.

References:

• Description of performance counters and types in Windows 2003: http://technet.microsoft.com/en-us/library/cc776490%28WS.10%29.aspx
• Performance counter data structures: http://msdn.microsoft.com/en-us/library/aa373093%28v=VS.85%29.aspx
• Example code for accessing performance data through registry: http://msdn.microsoft.com/en-us/library/aa373219%28v=VS.85%29.aspx

Font Driver

Implement the Adobe Type Manager Font (atmf) driver for text rendering. Currently text rendering is done by copying glyphs onto bitmaps verbatim instead of using the information provided by font glyphs to properly draw them. The data structures that hold the extra information provided by glyphs must be implemented and the drawing functions must then be extended to consume the data structures.

Theme Service

Implement support for loading and applying global themes. The current support provided for themes is incomplete and does not follow the design in Windows to begin with. The classic Windows 2000 theme does not rely on theme support and is in fact a "default" look for when no themes are present.

Missing Functionality:

• Ability to register a library with every running application in a particular session. Theme support requires that the uxtheme library be registered.
• Theme service that handles loading and parsing of themes and providing uxtheme with the bitmaps and configurations of a theme. The theme service must also be able to create remote threads into the winlogin process when a user logs in. This is due to the theme service running in session 0. While in XP and below the first user that is logged in is also in session 0, additional users logging in will be put into a separate session. On Vista and higher, all user logins are given a separate session from session 0. The remote thread started by the theme service facilitates transfer of theme information to the uxtheme for applications of each session.
• The GINA library used for user login must notify the theme service of user logins.
• The current uxtheme in ReactOS is borrowed from Wine but will have to be forked to work with the theme service. At the moment uxtheme handles the loading of themes. This responsibility will be shifted to the theme service. Painting of the non-client area of Windows must also be implemented.