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

From ReactOS Wiki
Jump to: navigation, search
m (Protected "Google Summer of Code 2014 Ideas" (‎[edit=sysop] (indefinite) ‎[move=sysop] (indefinite)))
 
(17 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 
This page lists all project ideas for our Google Summer of Code 2014 application. Students should also visit our [[Google Summer of Code 2014|general GSoC 2014 page]] for more information including a Student Guide.
 
This page lists all project ideas for our Google Summer of Code 2014 application. Students should also visit our [[Google Summer of Code 2014|general GSoC 2014 page]] for more information including a Student Guide.
  
= Hardware Compatibility =
+
== Hardware Compatibility ==
 
+
=== Plug and Play (PnP) Storage Stack ===
== Plug and Play (PnP) Storage Stack ==
 
 
Right now, PnP support in the storage stack is close to be there. mountmgr.sys has already been implemented, and recent tests show that plugging USB sticks work. However, "traditional" storage stack is not PnP-aware, meaning that hot-plugging SATA or SCSI device is not possible.
 
Right now, PnP support in the storage stack is close to be there. mountmgr.sys has already been implemented, and recent tests show that plugging USB sticks work. However, "traditional" storage stack is not PnP-aware, meaning that hot-plugging SATA or SCSI device is not possible.
 
Alleviating PnP support in scsiport would be the first task of this project. Then, turning uniata into a PnP-aware driver would permit SATA devices hot-plugging. Finally, PnP-aware "cdrom_new" and "disk_new" drivers can be activated.
 
Alleviating PnP support in scsiport would be the first task of this project. Then, turning uniata into a PnP-aware driver would permit SATA devices hot-plugging. Finally, PnP-aware "cdrom_new" and "disk_new" drivers can be activated.
  
 
;References:
 
;References:
: SCSI Port API: http://msdn.microsoft.com/en-us/library/windows/hardware/ff565353(v=vs.85).aspx
+
* [http://msdn.microsoft.com/en-us/library/windows/hardware/ff565353(v=vs.85).aspx SCSI Port API]
: Universal ATA driver with PATA/SATA/AHCI support (opensource): http://alter.org.ua/soft/win/uni_ata/
+
* [http://alter.org.ua/soft/win/uni_ata/ Universal ATA driver with PATA/SATA/AHCI support (opensource)]
  
 
;Skills needed
 
;Skills needed
: Kernel-mode development experience.
+
* Kernel-mode development experience.
: SCSI Port APIs familiarity.
+
* SCSI Port APIs familiarity.
  
== EFI Support ==
+
=== EFI Support ===
 
Support running and booting of ReactOS on EFI systems instead of BIOS systems. This would allow running ReactOS natively on newer computers that do not use BIOS. Support must be added to freeloader and the ReactOS HAL.  Support for GPT is already present in the kernel but the disk.sys driver does not know how to handle it.  Furthermore, freeloader is unable to boot from GPT partitions due to limitations in Arc name handling.  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 natively on newer computers that do not use BIOS. Support must be added to freeloader and the ReactOS HAL.  Support for GPT is already present in the kernel but the disk.sys driver does not know how to handle it.  Furthermore, freeloader is unable to boot from GPT partitions due to limitations in Arc name handling.  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.
  
 
The installer must also be modified so that it can write the boot record in a place where UEFI can find it.
 
The installer must also be modified so that it can write the boot record in a place where UEFI can find it.
 +
 
;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.
 +
 
;References
 
;References
: Unified Extensible Firmware Interface specifications: http://www.uefi.org/specs/ (or http://www.intel.com/technology/efi/)
+
* [http://www.uefi.org/specs/ Unified Extensible Firmware Interface specifications] (or http://www.intel.com/technology/efi/)
: UEFI SDK and test images: http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome
+
* [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome UEFI SDK and test images]
 +
 
 
;Skills Needed
 
;Skills Needed
: Kernel, driver development experience.
+
* Kernel, driver development experience.
: Experience writing UEFI applications.
+
* Experience writing UEFI applications.
 +
 
 +
=== Intel High Definition Audio Bus Driver ===
 +
Implement support for the Intel High Definition Audio specification for sound cards. Modern audio cards use the Intel High Definition Audio specification, therefore they rely on a bus driver to communicate with the audio hardware. The goal is to write a bus driver which supports those new cards.
 +
 
 +
The HD Audio bus driver implements the HD Audio device driver interface which kernel-mode audio and modem drivers use to communicate with hardware codecs that are attached to the HD Audio controller. It exposes the HD Audio driver interface to its children which are instances of the audio and modem drivers that manage the codecs. The bus driver needs to work on a Microsoft NT system and with ReactOS.
  
== Intel High Definition Audio Bus Driver ==
 
Implement support for the Intel High Definition Audio specification for sound cards.
 
 
;Benefits
 
;Benefits
: Modern audio cards use the Intel High Definition Audio specification. Therefore they rely on a bus driver to communicate with the audio hardware. The goal is to write a bus driver which supports those new cards. The bus driver needs to work on a Microsoft NT system and with ReactOS.
+
* Given the ubiquity of the HDA codec in motherboard integrated sound cards, such a driver would bring sound support to ReactOS on a huge number of systems.
  
 
;References
 
;References
: HD Audio Device Driver Interface whitepaper: http://msdn.microsoft.com/en-us/windows/hardware/gg462966
+
* [http://msdn.microsoft.com/en-us/windows/hardware/gg462966 HD Audio Device Driver Interface whitepaper]
: Programming the HD Audio DDI: http://msdn.microsoft.com/en-us/library/ff536442%28v=vs.85%29.aspx
+
* [http://msdn.microsoft.com/en-us/library/ff536442%28v=vs.85%29.aspx Programming the HD Audio DDI]
: HD Audio Bus Drivers: http://msdn.microsoft.com/en-us/library/ff536434%28v=vs.85%29.aspx
+
* [http://msdn.microsoft.com/en-us/library/ff536434%28v=vs.85%29.aspx HD Audio Bus Drivers]
 +
* CMI driver present in ReactOS codebase.
  
 
;Skills Needed
 
;Skills Needed
: Kernel driver programming experience
+
* Kernel driver programming experience
: Bus driver programming experience
+
* Bus driver programming experience
: Familiarity with Intel HD Audio specification
+
* Familiarity with Intel HD Audio specification
: Audio kernel streaming
+
* Audio kernel streaming
  
== Interface Driver Stack ==
+
=== Interface Driver Stack ===
 
Implement support for the protocols such as Bluetooth or Firewire to allow ReactOS to communicate with compatible devices. Requirements would be a working set of device drivers and providing the corresponding API, with potential supplemental work including development of control panel applets or applications to expose the new functionality.
 
Implement support for the protocols such as Bluetooth or Firewire to allow ReactOS to communicate with compatible devices. Requirements would be a working set of device drivers and providing the corresponding API, with potential supplemental work including development of control panel applets or applications to expose the new functionality.
 
;Benefits
 
;Benefits
Line 50: Line 56:
 
 
 
;References:
 
;References:
: Bluetooth specifications https://www.bluetooth.org/Technical/Specifications/adopted.htm
+
* [https://www.bluetooth.org/Technical/Specifications/adopted.htm Bluetooth specifications]
: Firewire specifications http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=4659231
+
* [http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=4659231 Firewire specifications]
: Microsoft Bluetooth API documentation: http://msdn.microsoft.com/en-us/library/aa362932(v=vs.85).aspx
+
* [http://msdn.microsoft.com/en-us/library/aa362932(v=vs.85).aspx Microsoft Bluetooth API documentation]
  
 
; Skills Needed
 
; Skills Needed
: Familiarity with kernel development and Windows sockets
+
* Familiarity with kernel development and Windows sockets
  
== USB 3.0 Support ==
+
=== USB 3.0 Support ===
USB 3.0 (Also known as XHCI) is increasingly present these days. Having a USB 3.0 stack would make ReactOS available to the newest external device interface among others.
+
USB 3.0 (Also known as eXtensible Host Controller Interface or xHCI) is a computer interface specification that defines a register-level description of a Host Controller for Universal Serial bus (USB) which is capable of interfacing to USB 1.x, 2.0, and 3.0 compatible devices. It's increasingly present these days. Having a USB 3.0 stack would make ReactOS available to the newest external device interface among others.
  
 
; References
 
; References
: https://en.wikipedia.org/wiki/EXtensible_Host_Controller_Interface_%28xHCI%29 has links to the required specifications
+
* [[wikipedia:Extensible Host Controller Interface]] has links to the required specifications
: Current OHCI, UHCI and OHCI implementations.
+
* Current OHCI, UHCI and OHCI implementations.
  
 
; Needed Skills
 
; Needed Skills
: Kernel driver programming experience.
+
* Kernel driver programming experience.
: Bus driver programming experience.
+
* Bus driver programming experience.
: Familiarity with USB 3.0 specification.
+
* Familiarity with USB 3.0 specification.
  
= Networking =
+
== Networking ==
== Internet Protocol Helper ==
+
=== Internet Protocol Helper ===
Implement the Internet Protocol Helper API for manipulating network interfaces.
+
Implement the Internet Protocol Helper API for manipulating network interfaces. The Internet Protocol Helper (IP Helper) API enables the retrieval and modification of network configuration settings for the local computer. It's applicable in any computing environment where programmatically manipulating network and TCP/IP configuration is useful. Typical features used by applications include IP routing protocols and Simple Network Management Protocol (SNMP) agents.
  
 
;Benefits:  
 
;Benefits:  
: Internet Protocol Helper API allows for retrieval and modification of network configuration settings. As well as notification to applications when network configuration is changed. This is important to allow network administration of the local computer.
+
: The Internet Protocol Helper API provides much of the functionality used by network utilities and other programs to query and configure network devices. While ReactOS currently supports both wired and wireless network interface cards, the graphical utilities users tend to rely on for things like connecting to a wireless network or checking what their IP address is are lacking or outright absent. Implementing IPHAPI, or at least an appropriate subset, would provide the necessary infrastructure to support these utilities, making it easier to interact with network devices.
  
 
;References:   
 
;References:   
: http://msdn.microsoft.com/en-us/library/aa366071(v=vs.85).aspx
+
* [http://msdn.microsoft.com/en-us/library/aa366071(v=vs.85).aspx A list of all the functions that need to be implemented.]
  
 
;Skills Needed:  
 
;Skills Needed:  
: Familiar with windows network and TCP/IP networking.
+
* Familiarity with Windows networking and TCP/IP networking.
  
== SSH Service ==
+
=== SSH Service ===
 
Implement a native Windows service for accepting SSH connections and authenticating with Windows accounts to allow the user to interact with Windows through the command prompt should they not need access to the GUI shell.  Once authenticated, any commands passed through SSH are executed using the user's credentials to prevent abuse of the service's privileges.  And as the user is not technically logged in, there are no restrictions with respect to how many connections are permitted except as system resources allow.
 
Implement a native Windows service for accepting SSH connections and authenticating with Windows accounts to allow the user to interact with Windows through the command prompt should they not need access to the GUI shell.  Once authenticated, any commands passed through SSH are executed using the user's credentials to prevent abuse of the service's privileges.  And as the user is not technically logged in, there are no restrictions with respect to how many connections are permitted except as system resources allow.
 +
 
;Benefits
 
;Benefits
: Besides cygwin, few options are available for users who wish to remote into a Windows machine for simple commandline access.  Cygwin is also horrendously intrusive on Windows systems.  This implementation would provide a free SSH server implementation for Windows that was designed to integrate cleanly and present users with access to the Windows command shell, not try and lie to the user and pretend they are in a Unix environment.  As a remote administration tool, this opens Windows systems to considerably more flexibility for connecting to and managing them.  Administrators on Linux systems will also not need to relax security settings on Windows in order to use Linux RDP clients.
+
: Besides cygwin, few options are available for users who wish to remote into a Windows machine for simple command line access.  Cygwin is also horrendously intrusive on Windows systems.  This implementation would provide a free SSH server implementation for Windows that was designed to integrate cleanly and present users with access to the Windows command shell, not try and lie to the user and pretend they are in a Unix environment.  As a remote administration tool, this opens Windows systems to considerably more flexibility for connecting to and managing them.  Administrators on Linux systems will also not need to relax security settings on Windows in order to use Linux RDP clients.
  
 
;Skills Needed
 
;Skills Needed
: Network development experience.
+
* Network development experience.
: Knowledge/familiarity with SSH protocol.
+
* Knowledge/familiarity with SSH protocol.
  
== Terminal Services ==
+
=== Terminal Services ===
 
Implement support for terminal services, allowing inbound remote desktop connections to ReactOS. This encompasses implementation of input and video drivers to handle output over the network.
 
Implement support for terminal services, allowing inbound remote desktop connections to ReactOS. This encompasses implementation of input and video drivers to handle output over the network.
 +
 +
The terminal services system provides functionality for securely connecting remote clients and servers, for channeling communication between components of remote clients and servers, and for managing servers. It implements the Remote Desktop Protocol (RDP) which is a multi- channel protocol that allows users of a remote client to connect to a server over a network.
  
 
;Benefits
 
;Benefits
Line 98: Line 107:
  
 
;References
 
;References
: http://www.reactos.org/wiki/ReactOS_Terminal_Services
+
* [[ReactOS Terminal Services]]
  
 
;Skills Needed
 
;Skills Needed
: Network development experience.
+
* Network development experience.
: Driver development experience.
+
* Driver development experience.
: Knowledge/familiarity with RDP protocol.
+
* Knowledge/familiarity with RDP protocol.
  
= System Enhancements =
+
== System Enhancements ==
== Audio Mixer ==
+
=== Audio Mixer ===
 
Implement support for mixing of audio streams.
 
Implement support for mixing of audio streams.
 
;Benefits
 
;Benefits
Line 112: Line 121:
  
 
;References
 
;References
: Audio Mixer Reference: http://msdn.microsoft.com/en-us/library/ms705739(v=vs.85).aspx
+
* [http://msdn.microsoft.com/en-us/library/ms705739(v=vs.85).aspx Audio Mixer Reference]
: DirectKS Sample Application download: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=D7667686-8467-4B10-8713-BF0281536320&amp%3Bdisplaylang=en
+
* [http://www.microsoft.com/downloads/en/details.aspx?FamilyID=D7667686-8467-4B10-8713-BF0281536320&amp%3Bdisplaylang=en DirectKS Sample Application download]
: Programming Services: http://msdn.microsoft.com/en-us/library/ms685967%28v=VS.85%29.aspx
+
* [http://msdn.microsoft.com/en-us/library/ms685967%28v=VS.85%29.aspx Programming Services]
: "Secret Rabbit Code" (SRC) Sample Rate Converter: http://www.mega-nerd.com/SRC/
+
* "Secret Rabbit Code" (SRC) [http://www.mega-nerd.com/SRC/ Sample Rate Converter] aka libsamplerate
  
 
;Skills Needed
 
;Skills Needed
: Windows Services familiarity
+
* Windows Services familiarity
: Basic Audio file format familiarity
+
* Basic Audio file format familiarity
: Audio mixing algorithms / libraries familiarity
+
* Audio mixing algorithms / libraries familiarity
: Basic kernel streaming familiarity
+
* Basic kernel streaming familiarity
  
== 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.
 +
 
 
;References
 
;References
: Installable File System Design Guide: http://msdn.microsoft.com/en-us/library/ff548143(v=VS.85).aspx
+
* [http://msdn.microsoft.com/en-us/library/ff548143(v=VS.85).aspx Installable File System Design Guide]
: Installable File System Kit Samples: http://msdn.microsoft.com/en-us/library/ff548099(v=VS.85).aspx
+
* [http://msdn.microsoft.com/en-us/library/ff548099(v=VS.85).aspx Installable File System Kit Samples]
: NTFS-3G driver & library: http://www.tuxera.com/community/ntfs-3g-download/
+
* [http://www.tuxera.com/community/ntfs-3g-download/ NTFS-3G driver & library]
  
 
;Skills Needed
 
;Skills Needed
: Driver development experience.
+
* Driver development experience.
: Filesystem development experience.
+
* Filesystem development experience.
  
== Performance Data Registry ==
+
=== 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.  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.
  
Line 144: Line 154:
  
 
;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
  
 
;Skills Needed
 
;Skills Needed
: Registry API familiarity.
+
* Registry API familiarity.
: Performance registry structure familiarity.
+
* Performance registry structure familiarity.
: Performance counter familiarity.
+
* Performance counter familiarity.
== Security Controls ==
 
Implement support for user permissions based on Access Control Lists.
 
;Benefits
 
: This will allow separation of users into groups and better control over user privileges in ReactOS.  Security controls will then allow supporting multiple users on the same system.
 
  
;Skills Needed
+
=== Management Console ===
: Familiarity with Windows security and permissions models.
+
Implement Microsoft Management Console (MMC). The MMC provides an interface for various management tools, both from Microsoft and third parties, called snap-ins. These snap-ins are standalone programs dynamically loaded into an MMC console to perform a specific configuration task, such as configuring a network or managing disk drives.
  
== Management Console ==
 
Implement Microsoft Management Console (MMC). The MMC provides an interface for various management tools, both from Microsoft and third parties, called snap-ins. These snap-ins are standalone programs dynamically loaded into an MMC console to perform a specific configuration task, such as configuring a network or managing disk drives.
 
 
;Benefits
 
;Benefits
: Easier snap-ins development.
+
* Easier snap-ins development.
: Consistent user interface of management tools.
+
* Consistent user interface of management tools.
: One configurable place to access key management and configuration apps.
+
* One configurable place to access key management and configuration apps.
  
 
;References
 
;References
: What is MMC: http://msdn.microsoft.com/en-us/library/bb756943.aspx
+
* [http://msdn.microsoft.com/en-us/library/bb756943.aspx What is MMC]
: Developing for MMC 3.0: http://msdn.microsoft.com/en-US/library/bb756923.aspx
+
* [http://msdn.microsoft.com/en-US/library/bb756923.aspx Developing for MMC 3.0]
  
 
;Skills Needed
 
;Skills Needed
: Basic Windows development experience.
+
* Basic Windows development experience.
: Knowledge of COM.
+
* Knowledge of COM.
  
== NT "Wine audio" driver ==
+
=== NT "Wine audio" driver ===
 
Currently, ReactOS imports mmdevapi DLL from Wine, but it doesn't have a "driver" for it. In Wine, the driver is an implementation of various COM interfaces on top of libraries such as ALSA or OSS. However, it is perfectly possible to implement such a driver for Windows NT (preferably Vista+) using audio IOCTL to directly talk to the windows device.
 
Currently, ReactOS imports mmdevapi DLL from Wine, but it doesn't have a "driver" for it. In Wine, the driver is an implementation of various COM interfaces on top of libraries such as ALSA or OSS. However, it is perfectly possible to implement such a driver for Windows NT (preferably Vista+) using audio IOCTL to directly talk to the windows device.
 +
 
;Benefits
 
;Benefits
: Vista+ compatible sound stack (our portcls.sys is already there)
+
* Vista+ compatible sound stack (our portcls.sys is already there)
: Importing the latest Wine audio related libraries becomes possible (winmm, mmdevapi, dsound, etc.)
+
* Importing the latest Wine audio related libraries becomes possible (winmm, mmdevapi, dsound, etc.)
: One place to rule them all: the only direct interface between user mode and driver.
+
* One place to rule them all: the only direct interface between user mode and driver.
  
 
;References
 
;References
: Core Audio: http://msdn.microsoft.com/en-us/library/windows/desktop/dd370802%28v=vs.85%29.aspx
+
* [http://msdn.microsoft.com/en-us/library/windows/desktop/dd370802%28v=vs.85%29.aspx Core Audio]
: Wine implementation on top of alsa: http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winealsa.drv/mmdevdrv.c
+
* [http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winealsa.drv/mmdevdrv.c Wine implementation on top of alsa]
  
 
;Needed Skills
 
;Needed Skills
: Windows Audio Stack knowledge
+
* Windows Audio Stack knowledge
: COM knowledge
+
* COM knowledge
  
= UI Enhancement =
+
== UI Enhancement ==
== Finish shell32 Implementation ==
+
=== Finish shell32 Implementation ===
The old explorer implementation is an aging C++ codebase which is more a combination of the explorer shell and the shell32 library. This project is to finish the new shell32 library to allow for use of explorer_new in ReactOS, a requirement for the 0.4.0 release (http://www.reactos.org/wiki/Roadmap). The project will consist of getting the new explorer running in ReactOS.
+
The old explorer implementation is an aging C++ codebase which is more a combination of the explorer shell and the shell32 library. This project is to finish the new shell32 library to allow for use of explorer_new in ReactOS, a requirement for the 0.4.0 release ([[Roadmap]]). The project will consist of getting the new explorer running in ReactOS.
  
 
;Skills Needed
 
;Skills Needed
: COM knowledge
+
* COM knowledge
: Shell32 knowledge
+
* Shell32 knowledge
: Win32 API familiarity
+
* Win32 API familiarity
  
== GUI 1st Stage Installer ==
+
=== GUI 1st Stage Installer ===
 
To make ReactOS more user friendly for installation, a [[First_Stage_GUI_Setup|GUI installation]] instead of a rather limited text-mode installer is needed.  This could be run off of the [[LiveCD]] and act as a frontend to the disk formatter and installer we already have implemented.
 
To make ReactOS more user friendly for installation, a [[First_Stage_GUI_Setup|GUI installation]] instead of a rather limited text-mode installer is needed.  This could be run off of the [[LiveCD]] and act as a frontend to the disk formatter and installer we already have implemented.
 +
 
;Benefits
 
;Benefits
 
: Having a [[First_Stage_GUI_Setup|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 [[First_Stage_GUI_Setup|GUI installer]] would also be less intimidating to new users, especially those used to Vista or 7's installer.
 
: Having a [[First_Stage_GUI_Setup|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 [[First_Stage_GUI_Setup|GUI installer]] would also be less intimidating to new users, especially those used to Vista or 7's installer.
  
 
;Skills Needed
 
;Skills Needed
: Win32 API familiarity.
+
* Win32 API familiarity.
: Partitioning and setup experience.
+
* Partitioning and setup experience.
  
= Win32 Subsystem =
+
== Win32 Subsystem ==
== Implement metafile support ==
+
=== Implement metafile support ===
 
While wine has this part of GDI32 fully implemented, the code cannot easily be reused. The task would be to analyze the wine code and design a solution that makes use of existing wine code as much as reasonable and implement the missing parts.
 
While wine has this part of GDI32 fully implemented, the code cannot easily be reused. The task would be to analyze the wine code and design a solution that makes use of existing wine code as much as reasonable and implement the missing parts.
  
 
; Skills Needed
 
; Skills Needed
: Basic knowledge of the win32 graphics interface (GDI)
+
* Basic knowledge of the win32 graphics interface (GDI)
: Basic knowledge of (enhanced) metafiles at API level
+
* Basic knowledge of (enhanced) metafiles at API level
: Capabilities to analyze existing code and design architecturally complex solutions
+
* Capabilities to analyze existing code and design architecturally complex solutions
  
== Rewrite win32k line drawing functions ==
+
=== Rewrite win32k line drawing functions ===
 
The low level line drawing functions in win32k are insufficient in features, not conforming to Windows requirements and lacking in code correctness aspects.
 
The low level line drawing functions in win32k are insufficient in features, not conforming to Windows requirements and lacking in code correctness aspects.
 
The task is to write a new set of low level line drawing functions, with focus on graphical correctness, safety and performance where reasonable. The functionality is described in MSDN and in DDK sample source code. The latter can be used as reference and to a certain extent possibly as direct source of code (Windows XP DDK license allows reuse under GPL)
 
The task is to write a new set of low level line drawing functions, with focus on graphical correctness, safety and performance where reasonable. The functionality is described in MSDN and in DDK sample source code. The latter can be used as reference and to a certain extent possibly as direct source of code (Windows XP DDK license allows reuse under GPL)
  
 
; Skills Needed
 
; Skills Needed
: Knowledge in basic graphics algorithms (Bresenham, ...)
+
* Knowledge in basic graphics algorithms (Bresenham, ...)
: Skills in developing algorithms
+
* Skills in developing algorithms
: Basic knowledge of the win32 graphics interface (GDI)
+
* Basic knowledge of the win32 graphics interface (GDI)
: Beneficial, but not required: knowledge of the windows display driver interface (DDI)
+
* Beneficial, but not required: knowledge of the windows display driver interface (DDI)
  
== Layered Windows Support ==
+
=== Layered Windows Support ===
 
Implement support for layered windows.  Drawing operations to layered windows are redirected to a bitmap residing in memory.  When a window needs to be repainted, the bitmap is copied onto the screen.
 
Implement support for layered windows.  Drawing operations to layered windows are redirected to a bitmap residing in memory.  When a window needs to be repainted, the bitmap is copied onto the screen.
 +
 
;Benefits
 
;Benefits
: Layered windows provide an efficient way to achieve complex effects like shadows.  The stock menus provided to all applications use layered Windows to achieve the shadowing effect one sees and the current iteration of Windows Live Messenger relies on layered windows to achieve partial transparency.
+
* Layered windows provide an efficient way to achieve complex effects like shadows.  The stock menus provided to all applications use layered Windows to achieve the shadowing effect one sees. Many Windows applications rely on layered windows.
  
 
;References
 
;References
: http://msdn.microsoft.com/en-us/library/ms997507.aspx
+
* http://msdn.microsoft.com/en-us/library/ms997507.aspx
: http://blogs.msdn.com/b/dwayneneed/archive/2008/09/08/transparent-windows-in-wpf.aspx
+
* http://blogs.msdn.com/b/dwayneneed/archive/2008/09/08/transparent-windows-in-wpf.aspx
  
 
;Skills Needed
 
;Skills Needed
: Windows display driver development experience.
+
* Windows display driver development experience.
 +
 
 +
=== Multi-Monitor Support ===
 +
The implementation of multi-monitor support is until now almost inexistent. Display Device Drivers exposes them thanks to the HwVidGetVideoChildDescriptor callback, which videoprt.sys uses to enumerate monitors attached to it to then pass the information to win32k.sys. It is then the role of win32k.sys to make the link between the two (or more) monitors, either cloning or extending the desktop and exposing the relevant features to client applications.
  
== Multi-Monitor Support ==
 
Implementation of multi monitor support into ReactOS.
 
 
;Benefits
 
;Benefits
: Working with multi monitor support would be very nice for presentations into public events which would be much more convincing.
+
* Multi-monitor support would bring ReactOS into a serious player in professional desktop applications, given the increasing number of double-screen installations present in modern open-spaces. Document comparison, permanently visible e-mail reader or presentation applications are just a few benefits professionals get when using multiple monitor.l
: Moreover, this would increase driver compatibility as this feature would require a solid code base in win32k.
+
* Multi-Monitor support would also find its place in the casual computing experience. Writing e-mails while watching a movie, or chatting with friends about current football play is the things people do in XXIst century!
 +
* From a technical stance, properly supporting this feature would increase driver support, and WIN32 application compatibility regarding APIs such as EnumDisplaySettings.
  
 
;References
 
;References
: http://msdn.microsoft.com/en-us/library/ff569172%28v=VS.85%29.aspx
+
* http://msdn.microsoft.com/en-us/library/windows/desktop/dd145071%28v=vs.85%29.aspx
: http://www.vesa.org/
+
* http://msdn.microsoft.com/en-us/library/ff569172%28v=VS.85%29.aspx
 +
* http://www.vesa.org/
 +
* [https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/WINNT/Graphics/Video/mp/xpdm/VBoxMPDriver.cpp Virtualbox video driver source]
  
 
;Skills Needed
 
;Skills Needed
: Experience with Windows display drivers.
+
* Experience with Windows display drivers.
: Experience with WINAPI, especially gdi32/user32.: Experience with PNP, as this feature would require detection of connected monitors: Experience with EDID/VESA standards.
+
* Experience with WINAPI, especially gdi32/user32.: Experience with PNP, as this feature would require detection of connected monitors: Experience with EDID/VESA standards.
  
== Wine-based Win32 subsystem (Arwinss) ==
+
=== Wine-based Win32 subsystem (Arwinss) ===
 
There is a proof of concept done which shows the possibility to reuse majority of Wine code for implementing user32.dll, gdi32.dll and win32k.sys, which would be binary compatible enough to ultimately work even in native Windows.
 
There is a proof of concept done which shows the possibility to reuse majority of Wine code for implementing user32.dll, gdi32.dll and win32k.sys, which would be binary compatible enough to ultimately work even in native Windows.
However, the Arwinss branch is based on an now old Wine architecture and old ReactOS GDI code. The goal of this task would be to "update" Arwinss branch to the newest Wine 1.4 architecture (including DIB engine and other changes), bring in changes from ReactOS win32k graphic code which happened after Arwinss was last updated, find the source and fix a well defined set of Arwinss-specific bugs, conduct a performance review and estimate performance improvements strategies (optional, if time allows).
+
However, the Arwinss branch is based on an now old Wine architecture and old ReactOS GDI code. The goal of this task would be to "update" Arwinss branch to the newest Wine 1.7 architecture (including DIB engine and other changes), bring in changes from ReactOS win32k graphic code which happened after Arwinss was last updated, find the source and fix a well defined set of Arwinss-specific bugs, conduct a performance review and estimate performance improvements strategies (optional, if time allows).
 +
 
 
; Benefits
 
; Benefits
: Greatly superior application compatibility level
+
* Greatly superior application compatibility level
: Improved usability
+
* Improved usability
  
 
; References
 
; References
: http://www.reactos.org/wiki/Arwinss
+
* [[Arwinss]]
  
 
; Skills Needed
 
; Skills Needed
: Good knowledge of C language
+
* Good knowledge of C language
: Familiarity with Win32 and GDI APIs
+
* Familiarity with Win32 and GDI APIs
: Generic knowledge of Windows NT architecture
+
* Generic knowledge of Windows NT architecture
: Knowledge of core principles of Wine architecture
+
* Knowledge of core principles of Wine architecture
  
= Durability =
+
== Durability ==
 
+
=== Kernel mode test suite ===
== Kernel mode test suite ==
+
Improve our existing kernel mode test suite by adding comprehensive new tests in areas previously untouched by the test suite like the kernel caching APIs and PnP. The goal is to extensively test Native API functions exported by the kernel. Reference behavior could be checked by running the test suite on original Windows operating system.
Improve our existing kernel mode test suite by adding comprehensive new tests in areas previously untouched by the test suite like the kernel caching APIs and PnP. The goal is to extensively test Native API functions exported by the kernel. Reference behaviour could be checked by running the test suite on original Windows operating system.
 
  
 
;Benefits
 
;Benefits
: Improved system stability.
+
* Improved system stability.
: More information about undocumented behaviour.
+
* More information about undocumented behavior.
: Improved compatibility with third party drivers.
+
* Improved compatibility with third party drivers.
  
 
;Skills Needed
 
;Skills Needed
: Native API knowledge
+
* Native API knowledge
: NT driver development skills
+
* NT driver development skills
  
== Win32k test suite ==
+
=== Win32k test suite ===
 
Right now we have basically no tests that cover the win32k module. As win32k is the cornerstone of the interface between the Win32 Subsystem and the display drivers, lack of tests leads to inconsistency, guess work and frustration when it comes to improving driver compatibility.
 
Right now we have basically no tests that cover the win32k module. As win32k is the cornerstone of the interface between the Win32 Subsystem and the display drivers, lack of tests leads to inconsistency, guess work and frustration when it comes to improving driver compatibility.
 
A virtual display driver (à la kmtest.sys) allows us to test the functionality and behavior of win32k. If time permits, it would also be possible to add a mechanism to test videoprt.sys functionality, and the relationship between a display driver and its miniport counterpart.
 
A virtual display driver (à la kmtest.sys) allows us to test the functionality and behavior of win32k. If time permits, it would also be possible to add a mechanism to test videoprt.sys functionality, and the relationship between a display driver and its miniport counterpart.
  
 
;References
 
;References
: Windows 2000 display driver model reference: http://msdn.microsoft.com/en-us/library/windows/hardware/ff570585%28v=vs.85%29.aspx
+
* [http://msdn.microsoft.com/en-us/library/windows/hardware/ff570585%28v=vs.85%29.aspx Windows 2000 display driver model reference]
  
 
;Benefits
 
;Benefits
: Improved stability.
+
* Improved stability.
: More information about undocumented behavior.
+
* More information about undocumented behavior.
: Improved compatibility with third party drivers.
+
* Improved compatibility with third party drivers.
  
 
; Needed skills
 
; Needed skills
: Display drivers development experience
+
* Display drivers development experience
: Win32 API knowledge
+
* Win32 API knowledge
  
= Project Tools =
+
== Project Tools ==
== Implement Configuration Reload in rosev_ircsystem ==
+
=== Implement Configuration Reload in rosev_ircsystem ===
 
The ReactOS Project is backed by a non-profit organization called ReactOS Deutschland e.V. operating under German law. As such, it holds regular General Assemblies over IRC. An IRC Server System called "rosev_ircsystem" has been written from scratch, which is easy to set up and combines proper identification and voting to comply with all regulations for General Assemblies.
 
The ReactOS Project is backed by a non-profit organization called ReactOS Deutschland e.V. operating under German law. As such, it holds regular General Assemblies over IRC. An IRC Server System called "rosev_ircsystem" has been written from scratch, which is easy to set up and combines proper identification and voting to comply with all regulations for General Assemblies.
  
 
What's missing is a feature to reload the configuration after the server has already been started. Doing this properly includes subsequent tasks like kicking out old users/channels that aren't part of the new configuration anymore. It may require refactoring the existing code in several places.
 
What's missing is a feature to reload the configuration after the server has already been started. Doing this properly includes subsequent tasks like kicking out old users/channels that aren't part of the new configuration anymore. It may require refactoring the existing code in several places.
 
  
 
;References
 
;References
: rosev_ircsystem code: http://svn.reactos.org/svn/project-tools/trunk/rosev_ircsystem/
+
* [http://svn.reactos.org/svn/project-tools/trunk/rosev_ircsystem/ rosev_ircsystem code]
  
 
;Benefits
 
;Benefits
: Improved usability of this IRC Server System
+
* Improved usability of this IRC Server System
: Also makes the software more attractive to other organizations operating under similar laws
+
* Also makes the software more attractive to other organizations operating under similar laws
  
 
;Needed skills
 
;Needed skills
: C++ and Boost knowledge
+
* C++ and Boost knowledge
: Basic networking skills
+
* Basic networking skills
 
 
  
 
[[Category:Google_Summer_of_Code]]
 
[[Category:Google_Summer_of_Code]]

Latest revision as of 08:56, 15 February 2014

This page lists all project ideas for our Google Summer of Code 2014 application. Students should also visit our general GSoC 2014 page for more information including a Student Guide.

Hardware Compatibility

Plug and Play (PnP) Storage Stack

Right now, PnP support in the storage stack is close to be there. mountmgr.sys has already been implemented, and recent tests show that plugging USB sticks work. However, "traditional" storage stack is not PnP-aware, meaning that hot-plugging SATA or SCSI device is not possible. Alleviating PnP support in scsiport would be the first task of this project. Then, turning uniata into a PnP-aware driver would permit SATA devices hot-plugging. Finally, PnP-aware "cdrom_new" and "disk_new" drivers can be activated.

References
Skills needed
  • Kernel-mode development experience.
  • SCSI Port APIs familiarity.

EFI Support

Support running and booting of ReactOS on EFI systems instead of BIOS systems. This would allow running ReactOS natively on newer computers that do not use BIOS. Support must be added to freeloader and the ReactOS HAL. Support for GPT is already present in the kernel but the disk.sys driver does not know how to handle it. Furthermore, freeloader is unable to boot from GPT partitions due to limitations in Arc name handling. 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.

The installer must also be modified so that it can write the boot record in a place where UEFI can find it.

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.
References
Skills Needed
  • Kernel, driver development experience.
  • Experience writing UEFI applications.

Intel High Definition Audio Bus Driver

Implement support for the Intel High Definition Audio specification for sound cards. Modern audio cards use the Intel High Definition Audio specification, therefore they rely on a bus driver to communicate with the audio hardware. The goal is to write a bus driver which supports those new cards.

The HD Audio bus driver implements the HD Audio device driver interface which kernel-mode audio and modem drivers use to communicate with hardware codecs that are attached to the HD Audio controller. It exposes the HD Audio driver interface to its children which are instances of the audio and modem drivers that manage the codecs. The bus driver needs to work on a Microsoft NT system and with ReactOS.

Benefits
  • Given the ubiquity of the HDA codec in motherboard integrated sound cards, such a driver would bring sound support to ReactOS on a huge number of systems.
References
Skills Needed
  • Kernel driver programming experience
  • Bus driver programming experience
  • Familiarity with Intel HD Audio specification
  • Audio kernel streaming

Interface Driver Stack

Implement support for the protocols such as Bluetooth or Firewire to allow ReactOS to communicate with compatible devices. Requirements would be a working set of device drivers and providing the corresponding API, with potential supplemental work including development of control panel applets or applications to expose the new functionality.

Benefits

This would open up possibilities such as data transfer to/from mobile devices, internet-over-cellphone scenarios or alternative input devices.

References
Skills Needed
  • Familiarity with kernel development and Windows sockets

USB 3.0 Support

USB 3.0 (Also known as eXtensible Host Controller Interface or xHCI) is a computer interface specification that defines a register-level description of a Host Controller for Universal Serial bus (USB) which is capable of interfacing to USB 1.x, 2.0, and 3.0 compatible devices. It's increasingly present these days. Having a USB 3.0 stack would make ReactOS available to the newest external device interface among others.

References
Needed Skills
  • Kernel driver programming experience.
  • Bus driver programming experience.
  • Familiarity with USB 3.0 specification.

Networking

Internet Protocol Helper

Implement the Internet Protocol Helper API for manipulating network interfaces. The Internet Protocol Helper (IP Helper) API enables the retrieval and modification of network configuration settings for the local computer. It's applicable in any computing environment where programmatically manipulating network and TCP/IP configuration is useful. Typical features used by applications include IP routing protocols and Simple Network Management Protocol (SNMP) agents.

Benefits
The Internet Protocol Helper API provides much of the functionality used by network utilities and other programs to query and configure network devices. While ReactOS currently supports both wired and wireless network interface cards, the graphical utilities users tend to rely on for things like connecting to a wireless network or checking what their IP address is are lacking or outright absent. Implementing IPHAPI, or at least an appropriate subset, would provide the necessary infrastructure to support these utilities, making it easier to interact with network devices.
References
Skills Needed
  • Familiarity with Windows networking and TCP/IP networking.

SSH Service

Implement a native Windows service for accepting SSH connections and authenticating with Windows accounts to allow the user to interact with Windows through the command prompt should they not need access to the GUI shell. Once authenticated, any commands passed through SSH are executed using the user's credentials to prevent abuse of the service's privileges. And as the user is not technically logged in, there are no restrictions with respect to how many connections are permitted except as system resources allow.

Benefits
Besides cygwin, few options are available for users who wish to remote into a Windows machine for simple command line access. Cygwin is also horrendously intrusive on Windows systems. This implementation would provide a free SSH server implementation for Windows that was designed to integrate cleanly and present users with access to the Windows command shell, not try and lie to the user and pretend they are in a Unix environment. As a remote administration tool, this opens Windows systems to considerably more flexibility for connecting to and managing them. Administrators on Linux systems will also not need to relax security settings on Windows in order to use Linux RDP clients.
Skills Needed
  • Network development experience.
  • Knowledge/familiarity with SSH protocol.

Terminal Services

Implement support for terminal services, allowing inbound remote desktop connections to ReactOS. This encompasses implementation of input and video drivers to handle output over the network.

The terminal services system provides functionality for securely connecting remote clients and servers, for channeling communication between components of remote clients and servers, and for managing servers. It implements the Remote Desktop Protocol (RDP) which is a multi- channel protocol that allows users of a remote client to connect to a server over a network.

Benefits
Terminal services support would allow ReactOS to service as a terminal server/thin client server. Organizations that wish to provide a shared workstation with Windows would have a free alternative that does not have complex licensing terms covering multi-session usage. The display driver for terminal services can also be used to support fast user-switching and even possibly multi-monitor support.
References
Skills Needed
  • Network development experience.
  • Driver development experience.
  • Knowledge/familiarity with RDP protocol.

System Enhancements

Audio Mixer

Implement support for mixing of audio streams.

Benefits
Audio mixer is responsible for routing of multiple audio streams. This would be very beneficial to ReactOS as audio driver support has improved yet the use of these drivers is limited by the lack of an Audio Mixer. In the end of the project multiple audio streams should be able to be played at the same time.
References
Skills Needed
  • Windows Services familiarity
  • Basic Audio file format familiarity
  • Audio mixing algorithms / libraries familiarity
  • Basic kernel streaming familiarity

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.
References
Skills Needed
  • Driver development experience.
  • Filesystem development experience.

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. 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.
References
Skills Needed
  • Registry API familiarity.
  • Performance registry structure familiarity.
  • Performance counter familiarity.

Management Console

Implement Microsoft Management Console (MMC). The MMC provides an interface for various management tools, both from Microsoft and third parties, called snap-ins. These snap-ins are standalone programs dynamically loaded into an MMC console to perform a specific configuration task, such as configuring a network or managing disk drives.

Benefits
  • Easier snap-ins development.
  • Consistent user interface of management tools.
  • One configurable place to access key management and configuration apps.
References
Skills Needed
  • Basic Windows development experience.
  • Knowledge of COM.

NT "Wine audio" driver

Currently, ReactOS imports mmdevapi DLL from Wine, but it doesn't have a "driver" for it. In Wine, the driver is an implementation of various COM interfaces on top of libraries such as ALSA or OSS. However, it is perfectly possible to implement such a driver for Windows NT (preferably Vista+) using audio IOCTL to directly talk to the windows device.

Benefits
  • Vista+ compatible sound stack (our portcls.sys is already there)
  • Importing the latest Wine audio related libraries becomes possible (winmm, mmdevapi, dsound, etc.)
  • One place to rule them all: the only direct interface between user mode and driver.
References
Needed Skills
  • Windows Audio Stack knowledge
  • COM knowledge

UI Enhancement

Finish shell32 Implementation

The old explorer implementation is an aging C++ codebase which is more a combination of the explorer shell and the shell32 library. This project is to finish the new shell32 library to allow for use of explorer_new in ReactOS, a requirement for the 0.4.0 release (Roadmap). The project will consist of getting the new explorer running in ReactOS.

Skills Needed
  • COM knowledge
  • Shell32 knowledge
  • Win32 API familiarity

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 LiveCD 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.
Skills Needed
  • Win32 API familiarity.
  • Partitioning and setup experience.

Win32 Subsystem

Implement metafile support

While wine has this part of GDI32 fully implemented, the code cannot easily be reused. The task would be to analyze the wine code and design a solution that makes use of existing wine code as much as reasonable and implement the missing parts.

Skills Needed
  • Basic knowledge of the win32 graphics interface (GDI)
  • Basic knowledge of (enhanced) metafiles at API level
  • Capabilities to analyze existing code and design architecturally complex solutions

Rewrite win32k line drawing functions

The low level line drawing functions in win32k are insufficient in features, not conforming to Windows requirements and lacking in code correctness aspects. The task is to write a new set of low level line drawing functions, with focus on graphical correctness, safety and performance where reasonable. The functionality is described in MSDN and in DDK sample source code. The latter can be used as reference and to a certain extent possibly as direct source of code (Windows XP DDK license allows reuse under GPL)

Skills Needed
  • Knowledge in basic graphics algorithms (Bresenham, ...)
  • Skills in developing algorithms
  • Basic knowledge of the win32 graphics interface (GDI)
  • Beneficial, but not required: knowledge of the windows display driver interface (DDI)

Layered Windows Support

Implement support for layered windows. Drawing operations to layered windows are redirected to a bitmap residing in memory. When a window needs to be repainted, the bitmap is copied onto the screen.

Benefits
  • Layered windows provide an efficient way to achieve complex effects like shadows. The stock menus provided to all applications use layered Windows to achieve the shadowing effect one sees. Many Windows applications rely on layered windows.
References
Skills Needed
  • Windows display driver development experience.

Multi-Monitor Support

The implementation of multi-monitor support is until now almost inexistent. Display Device Drivers exposes them thanks to the HwVidGetVideoChildDescriptor callback, which videoprt.sys uses to enumerate monitors attached to it to then pass the information to win32k.sys. It is then the role of win32k.sys to make the link between the two (or more) monitors, either cloning or extending the desktop and exposing the relevant features to client applications.

Benefits
  • Multi-monitor support would bring ReactOS into a serious player in professional desktop applications, given the increasing number of double-screen installations present in modern open-spaces. Document comparison, permanently visible e-mail reader or presentation applications are just a few benefits professionals get when using multiple monitor.l
  • Multi-Monitor support would also find its place in the casual computing experience. Writing e-mails while watching a movie, or chatting with friends about current football play is the things people do in XXIst century!
  • From a technical stance, properly supporting this feature would increase driver support, and WIN32 application compatibility regarding APIs such as EnumDisplaySettings.
References
Skills Needed
  • Experience with Windows display drivers.
  • Experience with WINAPI, especially gdi32/user32.: Experience with PNP, as this feature would require detection of connected monitors: Experience with EDID/VESA standards.

Wine-based Win32 subsystem (Arwinss)

There is a proof of concept done which shows the possibility to reuse majority of Wine code for implementing user32.dll, gdi32.dll and win32k.sys, which would be binary compatible enough to ultimately work even in native Windows. However, the Arwinss branch is based on an now old Wine architecture and old ReactOS GDI code. The goal of this task would be to "update" Arwinss branch to the newest Wine 1.7 architecture (including DIB engine and other changes), bring in changes from ReactOS win32k graphic code which happened after Arwinss was last updated, find the source and fix a well defined set of Arwinss-specific bugs, conduct a performance review and estimate performance improvements strategies (optional, if time allows).

Benefits
  • Greatly superior application compatibility level
  • Improved usability
References
Skills Needed
  • Good knowledge of C language
  • Familiarity with Win32 and GDI APIs
  • Generic knowledge of Windows NT architecture
  • Knowledge of core principles of Wine architecture

Durability

Kernel mode test suite

Improve our existing kernel mode test suite by adding comprehensive new tests in areas previously untouched by the test suite like the kernel caching APIs and PnP. The goal is to extensively test Native API functions exported by the kernel. Reference behavior could be checked by running the test suite on original Windows operating system.

Benefits
  • Improved system stability.
  • More information about undocumented behavior.
  • Improved compatibility with third party drivers.
Skills Needed
  • Native API knowledge
  • NT driver development skills

Win32k test suite

Right now we have basically no tests that cover the win32k module. As win32k is the cornerstone of the interface between the Win32 Subsystem and the display drivers, lack of tests leads to inconsistency, guess work and frustration when it comes to improving driver compatibility. A virtual display driver (à la kmtest.sys) allows us to test the functionality and behavior of win32k. If time permits, it would also be possible to add a mechanism to test videoprt.sys functionality, and the relationship between a display driver and its miniport counterpart.

References
Benefits
  • Improved stability.
  • More information about undocumented behavior.
  • Improved compatibility with third party drivers.
Needed skills
  • Display drivers development experience
  • Win32 API knowledge

Project Tools

Implement Configuration Reload in rosev_ircsystem

The ReactOS Project is backed by a non-profit organization called ReactOS Deutschland e.V. operating under German law. As such, it holds regular General Assemblies over IRC. An IRC Server System called "rosev_ircsystem" has been written from scratch, which is easy to set up and combines proper identification and voting to comply with all regulations for General Assemblies.

What's missing is a feature to reload the configuration after the server has already been started. Doing this properly includes subsequent tasks like kicking out old users/channels that aren't part of the new configuration anymore. It may require refactoring the existing code in several places.

References
Benefits
  • Improved usability of this IRC Server System
  • Also makes the software more attractive to other organizations operating under similar laws
Needed skills
  • C++ and Boost knowledge
  • Basic networking skills