Difference between revisions of "Google Summer of Code 2011 Ideas"

From ReactOS Wiki
Jump to: navigation, search
Line 1: Line 1:
== Project Suggestions ==
+
== IFS Wrapper Driver ==
 
 
=== IFS Wrapper Driver ===
 
 
NT IFS drivers for alternate filesystems are relatively scarce, due partially to the complexity of the IFS interface and the lack of documentation for several years.  A FUSE implementation for Windows is also not ideal compared to a genuine kernel mode IFS driver.  A kernel mode wrapper IFS driver can however considerably ease development of filesystem drivers on Windows. A demonstration implementation using code derived from NTFS-3G would provide the foundation for future drivers for other non-Windows filesystems and also a testbench for ReactOS’ own filesystem library interface.
 
NT IFS drivers for alternate filesystems are relatively scarce, due partially to the complexity of the IFS interface and the lack of documentation for several years.  A FUSE implementation for Windows is also not ideal compared to a genuine kernel mode IFS driver.  A kernel mode wrapper IFS driver can however considerably ease development of filesystem drivers on Windows. A demonstration implementation using code derived from NTFS-3G would provide the foundation for future drivers for other non-Windows filesystems and also a testbench for ReactOS’ own filesystem library interface.
  
==== Benefits ====
+
=== Benefits ===
 
Future efforts to allow Windows NT to read/write to other filesystems such as ZFS would be considerably eased with a wrapper driver.
 
Future efforts to allow Windows NT to read/write to other filesystems such as ZFS would be considerably eased with a wrapper driver.
  
==== Milestones ====
+
=== Milestones ===
 
* Implementation of generic wrapper driver.
 
* Implementation of generic wrapper driver.
 
* Implementation of FAT driver based on wrapper driver using FullFAT library as a basis.
 
* Implementation of FAT driver based on wrapper driver using FullFAT library as a basis.
 
* Implementation of NTFS driver based on wrapper driver using NTFS-3G as a basis.
 
* Implementation of NTFS driver based on wrapper driver using NTFS-3G as a basis.
  
=== Performance Data Registry ===
+
== Performance Data Registry ==
==== Proposal ====
+
=== Proposal ===
 
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.  Many of the performance values provided through the performance data registry is not available in any other form.  The absence of support for performance counters renders many diagnostic utilities from Microsoft broken and is also an impediment to application compatibility.  Condor is an example of a third party application that uses the performance data registry for process and resource usage tracking.
 
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.  Many of the performance values provided through the performance data registry is not available in any other form.  The absence of support for performance counters renders many diagnostic utilities from Microsoft broken and is also an impediment to application compatibility.  Condor is an example of a third party application that uses the performance data registry for process and resource usage tracking.
  
==== Benefits ====
+
=== Benefits ===
 
Besides application compatibility, the performance data registry is one of the most difficult to use public interfaces in Windows.  The layout of its data structures makes querying and accessing values a highly manual process.  Documentation produced from this effort would provide better guidelines for third parties to access the performance data registry and better use the information published by the system and Microsoft's own applications such as the .NET runtime or the IIS service.
 
Besides application compatibility, the performance data registry is one of the most difficult to use public interfaces in Windows.  The layout of its data structures makes querying and accessing values a highly manual process.  Documentation produced from this effort would provide better guidelines for third parties to access the performance data registry and better use the information published by the system and Microsoft's own applications such as the .NET runtime or the IIS service.
  
==== Milestones ====
+
=== Milestones ===
 
* Centralized exporting of system data (counters) meant for the performance data hive by declaring in-memory structures for storing values from the scheduler, memory manager, and I/O manager.
 
* Centralized exporting of system data (counters) meant for the performance data hive by declaring in-memory structures for storing values from the scheduler, memory manager, and I/O manager.
 
* Tracking system for application performance counters.  Allow applications to register the presence of a performance counter DLL through the HKLM hive and use the DLL to read the performance data.
 
* Tracking system for application performance counters.  Allow applications to register the presence of a performance counter DLL through the HKLM hive and use the DLL to read the performance data.
 
* Implement querying of performance counter data through the registry API.
 
* Implement querying of performance counter data through the registry API.
==== Potential Milestones ====
+
=== Potential Milestones ===
 
* A wrapper API was released in Vista that abstracts away the need to use the registry API to access performance counter data.  Implementing this would considerably ease access to the performance data hive in ReactOS.
 
* A wrapper API was released in Vista that abstracts away the need to use the registry API to access performance counter data.  Implementing this would considerably ease access to the performance data hive in ReactOS.
==== References ====
+
=== References ===
 
* Description of performance counters and types in Windows 2003: http://technet.microsoft.com/en-us/library/cc776490%28WS.10%29.aspx
 
* 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
 
* 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
 
* Example code for accessing performance data through registry: http://msdn.microsoft.com/en-us/library/aa373219%28v=VS.85%29.aspx
  
=== Font Driver ===
+
== 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.
 
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 ===
+
== 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.
 
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.
==== Benefits ====
+
=== Benefits ===
 
Implementing the theme service would allow greater customization of ReactOS' user interface and open the OS up to interface designers that wish to experiment on Windows but do not have access to a Windows license.  The work would also benefit Wine by providing another testbench against which our respective theme implementations could be compared against.
 
Implementing the theme service would allow greater customization of ReactOS' user interface and open the OS up to interface designers that wish to experiment on Windows but do not have access to a Windows license.  The work would also benefit Wine by providing another testbench against which our respective theme implementations could be compared against.
  
==== Milestones ====
+
=== Milestones ===
 
* Implement the ability to register a library with every application running in a session.  Theme support requires that the uxtheme library be injected into applications.
 
* Implement the ability to register a library with every application running in a session.  Theme support requires that the uxtheme library be injected into applications.
 
* Implement the system 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.
 
* Implement the system 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.
Line 44: Line 42:
 
* Modify the uxtheme library to correctly paint non-client areas of Windows and also remove the ability to load themes.  This responsibility should be left to the theme service.
 
* Modify the uxtheme library to correctly paint non-client areas of Windows and also remove the ability to load themes.  This responsibility should be left to the theme service.
  
=== Font Driver Implementation ===
+
== Font Driver Implementation ==
 
Implement the Adobe Type Manager Font driver for text rendering using the freetype library as a basis.  The atmf driver is responsible for loading fonts and providing the outline of each glyph needed to render to the screen.
 
Implement the Adobe Type Manager Font driver for text rendering using the freetype library as a basis.  The atmf driver is responsible for loading fonts and providing the outline of each glyph needed to render to the screen.
==== Benefits ====
+
=== Benefits ===
 
This driver will be developed against Windows 2003 and when completed will also serve as a testbench against the win32k interface for font drivers in ReactOS.
 
This driver will be developed against Windows 2003 and when completed will also serve as a testbench against the win32k interface for font drivers in ReactOS.
  
==== Milestones ====
+
=== Milestones ===
  
=== Serial Over USB ===
+
== Serial Over USB ==
 
Implement a driver for USB/serial debugging support.  With the decreasing number of systems with a serial port, another mechanism for outputting debug information is needed.  A low level USB driver that can output in serial format would help expand the number of platforms that can be used test ReactOS on.  USB to serial adapters are quite prevalent, but outputting debug information out a USB port requires bypassing the need for traditional drivers or even a USB stack.  This driver will serve a similar role as the current KDCOM driver.
 
Implement a driver for USB/serial debugging support.  With the decreasing number of systems with a serial port, another mechanism for outputting debug information is needed.  A low level USB driver that can output in serial format would help expand the number of platforms that can be used test ReactOS on.  USB to serial adapters are quite prevalent, but outputting debug information out a USB port requires bypassing the need for traditional drivers or even a USB stack.  This driver will serve a similar role as the current KDCOM driver.
  
=== EFI Support ===
+
== EFI Support ==
 
Support running and booting of ReactOS on EFI systems instead of BIOS systems.  This would allow running ReactOS on Intel Macs and other systems that do not use BIOS.  Support must be added to freeloader and the ReactOS HAL.  Lack of the VGA BIOS must be addressed as the ReactOS boot process relies heavily on one being present for display during the boot process.
 
Support running and booting of ReactOS on EFI systems instead of BIOS systems.  This would allow running ReactOS on Intel Macs and other systems that do not use BIOS.  Support must be added to freeloader and the ReactOS HAL.  Lack of the VGA BIOS must be addressed as the ReactOS boot process relies heavily on one being present for display during the boot process.
  
==== Benefits ====
+
=== Benefits ===
 
Ability to boot natively on Intel Macs would provide ReactOS with a relatively stable hardware platform for testing purposes thanks to Apple's hardware design philosophy.  It would also present Mac users with another alternative to running Windows applications.
 
Ability to boot natively on Intel Macs would provide ReactOS with a relatively stable hardware platform for testing purposes thanks to Apple's hardware design philosophy.  It would also present Mac users with another alternative to running Windows applications.
  
==== Milestones ====
+
=== Milestones ===
 
* Modification of freeloader to be able to interface with EFI.
 
* Modification of freeloader to be able to interface with EFI.
 
* Modification of HAL to be able to interface with EFI.
 
* Modification of HAL to be able to interface with EFI.
Line 66: Line 64:
 
* Boot ReactOS to a working desktop.
 
* Boot ReactOS to a working desktop.
  
=== ACPI HAL ===
+
== ACPI HAL ==
 
Implementation of a Hardware Abstraction Layer that can interact with the ACPI interface for power management and device configuration.
 
Implementation of a Hardware Abstraction Layer that can interact with the ACPI interface for power management and device configuration.
  
==== Benefits ====
+
=== Benefits ===
 
Most modern motherboards possess ACPI support.  ReactOS’ system components are ACPI aware but cannot truly use ACPI until the hardware abstraction layer supports the specification.  Proper power management would require that the OS support ACPI and until the entire hardware interface stack in ReactOS has support implemented, ReactOS will be limited to running in a compatibility mode.
 
Most modern motherboards possess ACPI support.  ReactOS’ system components are ACPI aware but cannot truly use ACPI until the hardware abstraction layer supports the specification.  Proper power management would require that the OS support ACPI and until the entire hardware interface stack in ReactOS has support implemented, ReactOS will be limited to running in a compatibility mode.
  
==== Milestones ====
+
=== Milestones ===
 
* Be able to enumerate all ACPI-enabled devices and interfaces on a system.
 
* Be able to enumerate all ACPI-enabled devices and interfaces on a system.
 
* Be able to shut down the computer through ACPI.
 
* Be able to shut down the computer through ACPI.
  
=== GUI 1st Stage Installer ===
+
== GUI 1st Stage Installer ==
 
To make ReactOS more user friendly for installation, a GUI installation instead of a rather limited text-mode installer is needed.  This could be run off of the live CD and act as a frontend to the disk formatter and installer we already have implemented.
 
To make ReactOS more user friendly for installation, a GUI installation instead of a rather limited text-mode installer is needed.  This could be run off of the live CD and act as a frontend to the disk formatter and installer we already have implemented.
==== Benefits ====
+
=== Benefits ===
 
Having a GUI installer would allow the project to merge the bootcd and livecd and ensure that the livecd gets more testing to make sure it is not broken and simply neglected.  A GUI installer would also be less intimidating to new users, especially those used to Vista or 7's installer.
 
Having a GUI installer would allow the project to merge the bootcd and livecd and ensure that the livecd gets more testing to make sure it is not broken and simply neglected.  A GUI installer would also be less intimidating to new users, especially those used to Vista or 7's installer.
==== Milestones ====
+
=== Milestones ===
* Complete the formatting functions that need to be exported for use by an installer.
+
* Complete the disk formatting functions that need to be exported for use by an installer.
 
* Create a Windows application that can install ReactOS.
 
* Create a Windows application that can install ReactOS.

Revision as of 02:19, 4 March 2011

IFS Wrapper Driver

NT IFS drivers for alternate filesystems are relatively scarce, due partially to the complexity of the IFS interface and the lack of documentation for several years. A FUSE implementation for Windows is also not ideal compared to a genuine kernel mode IFS driver. A kernel mode wrapper IFS driver can however considerably ease development of filesystem drivers on Windows. A demonstration implementation using code derived from NTFS-3G would provide the foundation for future drivers for other non-Windows filesystems and also a testbench for ReactOS’ own filesystem library interface.

Benefits

Future efforts to allow Windows NT to read/write to other filesystems such as ZFS would be considerably eased with a wrapper driver.

Milestones

  • Implementation of generic wrapper driver.
  • Implementation of FAT driver based on wrapper driver using FullFAT library as a basis.
  • Implementation of NTFS driver based on wrapper driver using NTFS-3G as a basis.

Performance Data Registry

Proposal

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. Many of the performance values provided through the performance data registry is not available in any other form. The absence of support for performance counters renders many diagnostic utilities from Microsoft broken and is also an impediment to application compatibility. Condor is an example of a third party application that uses the performance data registry for process and resource usage tracking.

Benefits

Besides application compatibility, the performance data registry is one of the most difficult to use public interfaces in Windows. The layout of its data structures makes querying and accessing values a highly manual process. Documentation produced from this effort would provide better guidelines for third parties to access the performance data registry and better use the information published by the system and Microsoft's own applications such as the .NET runtime or the IIS service.

Milestones

  • Centralized exporting of system data (counters) meant for the performance data hive by declaring in-memory structures for storing values from the scheduler, memory manager, and I/O manager.
  • Tracking system for application performance counters. Allow applications to register the presence of a performance counter DLL through the HKLM hive and use the DLL to read the performance data.
  • Implement querying of performance counter data through the registry API.

Potential Milestones

  • A wrapper API was released in Vista that abstracts away the need to use the registry API to access performance counter data. Implementing this would considerably ease access to the performance data hive in ReactOS.

References

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.

Benefits

Implementing the theme service would allow greater customization of ReactOS' user interface and open the OS up to interface designers that wish to experiment on Windows but do not have access to a Windows license. The work would also benefit Wine by providing another testbench against which our respective theme implementations could be compared against.

Milestones

  • Implement the ability to register a library with every application running in a session. Theme support requires that the uxtheme library be injected into applications.
  • Implement the system 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 be extended to notify the theme service of user logins.
  • Modify the uxtheme library to correctly paint non-client areas of Windows and also remove the ability to load themes. This responsibility should be left to the theme service.

Font Driver Implementation

Implement the Adobe Type Manager Font driver for text rendering using the freetype library as a basis. The atmf driver is responsible for loading fonts and providing the outline of each glyph needed to render to the screen.

Benefits

This driver will be developed against Windows 2003 and when completed will also serve as a testbench against the win32k interface for font drivers in ReactOS.

Milestones

Serial Over USB

Implement a driver for USB/serial debugging support. With the decreasing number of systems with a serial port, another mechanism for outputting debug information is needed. A low level USB driver that can output in serial format would help expand the number of platforms that can be used test ReactOS on. USB to serial adapters are quite prevalent, but outputting debug information out a USB port requires bypassing the need for traditional drivers or even a USB stack. This driver will serve a similar role as the current KDCOM driver.

EFI Support

Support running and booting of ReactOS on EFI systems instead of BIOS systems. This would allow running ReactOS on Intel Macs and other systems that do not use BIOS. Support must be added to freeloader and the ReactOS HAL. Lack of the VGA BIOS must be addressed as the ReactOS boot process relies heavily on one being present for display during the boot process.

Benefits

Ability to boot natively on Intel Macs would provide ReactOS with a relatively stable hardware platform for testing purposes thanks to Apple's hardware design philosophy. It would also present Mac users with another alternative to running Windows applications.

Milestones

  • Modification of freeloader to be able to interface with EFI.
  • Modification of HAL to be able to interface with EFI.
  • Modify boot video driver to work without VGA BIOS.
  • Boot ReactOS to a working desktop.

ACPI HAL

Implementation of a Hardware Abstraction Layer that can interact with the ACPI interface for power management and device configuration.

Benefits

Most modern motherboards possess ACPI support. ReactOS’ system components are ACPI aware but cannot truly use ACPI until the hardware abstraction layer supports the specification. Proper power management would require that the OS support ACPI and until the entire hardware interface stack in ReactOS has support implemented, ReactOS will be limited to running in a compatibility mode.

Milestones

  • Be able to enumerate all ACPI-enabled devices and interfaces on a system.
  • Be able to shut down the computer through ACPI.

GUI 1st Stage Installer

To make ReactOS more user friendly for installation, a GUI installation instead of a rather limited text-mode installer is needed. This could be run off of the live CD and act as a frontend to the disk formatter and installer we already have implemented.

Benefits

Having a GUI installer would allow the project to merge the bootcd and livecd and ensure that the livecd gets more testing to make sure it is not broken and simply neglected. A GUI installer would also be less intimidating to new users, especially those used to Vista or 7's installer.

Milestones

  • Complete the disk formatting functions that need to be exported for use by an installer.
  • Create a Windows application that can install ReactOS.