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

From ReactOS Wiki
Jump to: navigation, search
m
 
(13 intermediate revisions by 3 users not shown)
Line 1: Line 1:
The ReactOS Project seeks to participate in the 2011 Google Summer of Code not only to improve ReactOS but also to help increase the pool of developers knowledgeable about Windows system development and interoperability.  Unlike platforms like Linux and BSD, Windows is not open to easy experimentation and exploration, resulting in a decreased number of developers familiar with its internals.  This often results in complications for open source projects that wish to provide Windows versions of their software due to a lack of expertise on the Windows NT architecture.  By providing an open source implementation of the Windows NT family, ReactOS hopes to provide an environment that promotes experimentation and collaboration in Windows system development, thus helping developers from all backgrounds better understand the NT system and adopt better practices for software development targeting Windows.
+
This page lists all project ideas for our Google Summer of Code 2011 application. Students should also visit our [[Google Summer of Code 2011|general GSoC 2011 page]] for more information including a Student Guide.
 
 
= Student Guide =
 
 
 
Every student new to ReactOS should begin by obtaining the code through our Subversion repository and performing a first build using our ReactOS Build Environment. This environment ensures consistent build results, eliminates the need to setup your own toolchain and makes ReactOS one of the easiest operating systems to build. These first steps are also exemplified in this video.
 
Also every student should subscribe to the ros-dev mailing list and optionally could join the #reactos channel on Freenode’s IRC network for a live discussion with developers.
 
 
 
By default, students will receive a branch in SVN to work on their code. If you prefer a different version control system like Git or Mercurial, please contact our Summer of Code administrator [[Ged Murphy]].
 
 
 
MSDN and plenty of available Windows publications serve as the primary reference for functionality ReactOS seeks to implement.  However, there are parts of Windows that are poorly documented or completely undocumented.  In these instances, the ReactOS Techwiki may possess descriptions of the data structures or interfaces.  The student may have to conduct some research, following project guidelines on respecting intellectual property, and write some documentation of their own if none exists however, though mentors will try to help with any missing gaps.
 
 
 
== ReactOS GSoC Adminstrators ==
 
* [[Ged Murphy]]
 
* [[Aleksey Bragin]]
 
 
 
== ReactOS GSoC Mentor Candidates ==
 
* [[Aleksey Bragin]]
 
* [[Art Yerkes]]
 
* [[Colin Finck]]
 
* [[Ged Murphy]]
 
* [[Giannis Adamopoulos]]
 
* [[Hervé Poussineau]]
 
* [[Jérôme Gardou]]
 
* [[Johannes Anderwald]]
 
* [[Kamil Hornicek]]
 
* [[Roel Messiant]]
 
* [[Sylvain Petreolle]]
 
* [[Timo Kreuzer]]
 
 
 
== Student Application Form ==
 
=== General Information ===
 
;Full Name
 
;Languages You Speak
 
;Timezone
 
;myReactOS Account Name
 
;IRC Nickname on Freenode
 
 
 
=== Time Commitment ===
 
Please outline any additional obligations you may have during the summer and how much of your time you will be able to commit to your GSoC project.
 
 
 
=== Optional ===
 
;Proposed Project
 
Please provide a brief description of, or a link to, the project you are interested in
 
 
 
;Proposed Milestones
 
For projects that are relatively easy to quantify, please propose milestones that can be used to gauge progress on the project.
 
 
 
;Legal Requirements
 
Students are required to affirm that the following is true.
 
I hereby swear that I have not used nor seen the source code to any version of the Windows operating system nor any Microsoft product that may be related to the proposed project that is under a license incompatible with contribution to ReactOS, including but not limited to the leaked Windows 2000 source code and the Windows Research Kernel.
 
 
 
= Application Form =
 
 
 
;Organization Name
 
ReactOS
 
 
 
;Description
 
The ReactOS Project develops an open source operating system which closely follows the Windows NT architecture and is binary compatible with its applications and drivers.
 
Home page
 
 
 
http://www.reactos.org
 
 
 
;Main Organization License
 
 
 
GNU General Public License (GPL)
 
 
 
== Why is your organization applying to participate in GSoC 2011? What do you hope to gain by participating? ==
 
We seek to improve the state of open source software in the Windows community, both in awareness and overall code quality.  By providing an open source implementation of Windows, we provide a first level example of what open source development can achieve in the Windows world.  Participating in the Google Summer of Code 2011 presents us with an opportunity to engage with students worldwide who may have an interest in Windows development and potentially increase the number of open source developers that will possess Windows expertise.
 
 
 
== If accepted, would this be your first year participating in GSoC? ==
 
 
 
No
 
 
 
== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.  ==
 
 
 
In 2006, ReactOS was accepted as a mentoring organisation. A total of (4) students participated for “Remote Desktop client application and ActiveX Control”, “ReactOS Print Spooler Service”, “Login System” and “Clipboard Server API Implementation”.
 
 
 
The Remote Desktop client application and the Clipboard Server API Implementation projects have been completed successfully.
 
 
 
For the Print Spooler Service project, Google considered the work on this project to be unsatisfactory and unlisted it. The student stated that he was unable to meet the target goals due to unforeseen problems though he wished to continue with the project. As of today, we still have no Print Spooler Service.
 
 
 
The “Login System” was considered abandoned but the project itself was continued by one of our developers after GSoC ended. Attempts to contact the student failed, so we were not able to rectify the situation.
 
 
 
== If your organization participated in past GSoCs, please let us know the ratio of students passing to students allocated, e.g. 2006: 3/6 for 3 out of 6 students passed in 2006. ==
 
 
 
2006 : 2 out of 4 students passed
 
 
 
== What is the URL for your ideas page? ==
 
 
 
[[Google Summer of Code 2011]]
 
 
 
== What is the main development mailing list for your organization? This question will be shown to students who would like to get more information about applying to your organization for GSoC 2011. If your organization uses more than one list, please make sure to include a description of the list so students know which to use. ==
 
 
 
ros-dev@reactos.org (see http://www.reactos.org/mailman/listinfo/ros-dev)
 
 
 
== What is the main IRC channel for your organization? ==
 
 
 
#reactos on Freenode
 
 
 
== Does your organization have an application template you would like to see students use? If so, please provide it now. Please note that it is a very good idea to ask students to provide you with their contact information as part of your template. Their contact details will not be shared with you automatically via the GSoC 2011 site. ==
 
 
 
=== Student Application Form ===
 
==== General Information ====
 
;Full Name
 
;Languages You Speak
 
;Timezone
 
;myReactOS Account Name
 
;IRC Nickname on Freenode
 
 
 
==== Time Commitment ====
 
Please outline any additional obligations you may have during the summer and how much of your time you will be able to commit to your GSoC project.
 
 
 
==== Optional ====
 
;Proposed Project
 
Please provide a brief description of, or a link to, the project you are interested in
 
 
 
;Proposed Milestones
 
For projects that are relatively easy to quantify, please propose milestones that can be used to gauge progress on the project.
 
 
 
;Legal Requirements
 
Students are required to affirm that the following is true.
 
I hereby swear that I have not used nor seen the source code to any version of the Windows operating system nor any Microsoft product that may be related to the proposed project that is under a license incompatible with contribution to ReactOS, including but not limited to the leaked Windows 2000 source code and the Windows Research Kernel.
 
 
 
== What criteria did you use to select the individuals who will act as mentors for your organization? Please be as specific as possible. ==
 
 
 
Our mentors were selected based on availability and familiarity with various parts of the Windows NT architecture, including but not limited to networking, filesystems, graphics, the registry, and hardware interfaces.  In addition we place emphasis on the ability of a developer to act in a teaching role, who know how to guide students but provide enough freedom to allow the student to explore and learn how to achieve their goals through their own efforts.  We will also encourage our mentors to be available to not just their assigned students, but also other students that have projects under ReactOS.  Many of our mentor candidates are knowledgeable about a wide range of Windows NT technologies and can provide advice for topics beyond their assigned student’s project.
 
 
 
== What is your plan for dealing with disappearing students? ==
 
 
 
While every effort will be made to select students who are unlikely to disappear, we recognize that unpredictable circumstances are always possible.  As such, we will require that all students provide backup contact information that we will verify as a failsafe in case students drop out of contact and are unable to inform us directly. Based on the situation, we will try to work with the student to accommodate any special circumstances that arise to ensure a project’s success, but if a student is unable to complete their project we will contact the GSoC team to consider any necessary actions, including marking a project as failed.
 
 
 
== What is your plan for dealing with disappearing mentors? ==
 
 
 
While the mentor candidates we have selected are considered highly reliable, we again recognize that life can result in unexpected circumstances.  As noted above, the mentor candidates we have selected are knowledgeable in more than just one specific part of Windows NT, and we will encourage students to consult with not just their assigned mentor but also others taking part in the GSoC program.  As such, students will always have advisers available to them even if their assigned mentor is unable to continue with the project.
 
 
 
== What steps will you take to encourage students to interact with your project's community before, during and after the program? ==
 
 
 
Students whose projects are selected will be introduced to the greater ReactOS community by their mentors.  They will also be put in touch with several community members that are actively engaged in regression and feature testing, whom will be invaluable in helping students find a wider audience for testing their code.  Students will also be encouraged to provide status updates to the community, which will provide opportunities for feedback and further engagement.  Even after a project is completed, a student will have learned a great deal about Windows development and will know that the ReactOS project is available as a resource for any future development work they may pursue on Windows.
 
 
 
== If you are a small or new organization applying to GSoC, please list a larger, established GSoC organization or a Googler that can vouch for you here. ==
 
 
 
During a brief conversation between Aleksey Bragin and Chris DiBona at the IT-Spring 2009 Conference in Moscow, Mr. DiBona was rather surprised ReactOS was not taking advantage of the Google Summer Of Code program and suggested we do our best to participate.
 
 
 
== If you are a large organization who is vouching for a small organization applying to GSoC for their first time this year, please list their name and why you think they'd be good candidates for GSoC here: ==
 
 
 
N/A
 
 
 
== Anything else you'd like to tell us? ==
 
We would like to thank Google for sponsoring the Summer of Code program, as it provides an entry to students to the open source world.
 
 
 
We would also like to thank our friends at Haiku, especially Matt Madia and Urias McCullough, for their help in putting together this year’s GSoC proposal.  Collaboration between our respective projects has slowly grown over the years and we greatly appreciate their advice and guidance for the application.
 
 
 
== Backup Admin (Link ID): ==
 
 
 
[[Aleksey Bragin]]
 
  
 
= Hardware Compatibility =
 
= Hardware Compatibility =
Line 163: Line 9:
 
: 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.
  
;References  
+
;References
 
: ACPI specification: http://www.acpi.info/spec.htm
 
: ACPI specification: http://www.acpi.info/spec.htm
 
: The ACPI Component Architecture documentation: http://www.acpica.org/documentation/
 
: The ACPI Component Architecture documentation: http://www.acpica.org/documentation/
Line 208: Line 54:
 
: Familiarity with Intel HD Audio specification
 
: Familiarity with Intel HD Audio specification
 
: Audio kernel streaming
 
: 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:
 +
: Bluetooth specifications https://www.bluetooth.org/Technical/Specifications/adopted.htm
 +
: Firewire specifications http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=4659231
 +
: Microsoft Bluetooth API documentation: http://msdn.microsoft.com/en-us/library/aa362932(v=vs.85).aspx
 +
 +
; Skills Needed
 +
: Familiarity with kernel development and Windows sockets
  
 
= Networking =
 
= Networking =
 +
== Internet Protocol Helper ==
 +
Implement the Internet Protocol Helper API for manipulating network interfaces.
 +
 +
;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.
 +
 +
;References:
 +
: http://msdn.microsoft.com/en-us/library/aa366071(v=vs.85).aspx
 +
 +
;Skills Needed:
 +
: Familiar with windows network 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.
Line 296: Line 167:
 
;Skills Needed
 
;Skills Needed
 
: Familiarity with Windows security and permissions models.
 
: Familiarity with Windows security and permissions models.
 +
 +
== 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
 +
: What is MMC: http://msdn.microsoft.com/en-us/library/bb756943.aspx
 +
: Developing for MMC 3.0: http://msdn.microsoft.com/en-US/library/bb756923.aspx
 +
 +
;Skills Needed
 +
: Basic Windows development experience.
 +
: Knowledge of COM.
 +
 
= UI Enhancement =
 
= UI Enhancement =
 
== Font Driver ==
 
== Font Driver ==
Line 309: Line 196:
 
: Font technology familiarity.
 
: Font technology familiarity.
 
: Windows display driver development experience.
 
: Windows display driver development experience.
 +
 +
== 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.
 +
 +
;Skills Needed
 +
: Win32 API familiarity.
 +
: Partitioning and setup experience.
 +
 +
== Layered Windows ==
 +
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 and the current iteration of Windows Live Messenger relies on layered windows to achieve partial transparency.
 +
 +
;References
 +
: http://msdn.microsoft.com/en-us/library/ms997507.aspx
 +
: http://blogs.msdn.com/b/dwayneneed/archive/2008/09/08/transparent-windows-in-wpf.aspx
 +
 +
;Skills Needed
 +
: Windows display driver development experience.
 +
 
== 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.
Line 318: Line 227:
 
: Win32 drawing familiarity.
 
: Win32 drawing familiarity.
  
== GUI 1st Stage Installer ==
+
= Durability =
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.
+
 
 +
== Kernel mode test suite ==
 +
Develop a kernel mode test suite, consisting of a framework and actual modularized tests. 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
: 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.
+
: Improved system stability.
 +
: More information about undocumented behaviour.
 +
: Improved compatibility with third party drivers.
  
 
;Skills Needed
 
;Skills Needed
: Win32 API familiarity.
+
: Native API knowledge
: Partitioning and setup experience.
+
: NT driver development skills
= Mentor Candidates =
+
 
* Aleksey Bragin
+
[[Category:Google Summer of Code]]
* Art Yerkes
 
* Colin Finck
 
* Ged Murphy
 
* Giannis Adamopoulos
 
* Hervé Poussineau
 
* Jérôme Gardou
 
* Johannes Anderwald
 
* Kamil Hornicek
 
* Roel Messiant
 
* Sylvain Petreolle
 
* Timo Kreuzer
 

Latest revision as of 09:23, 14 May 2014

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

Hardware Compatibility

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.
References
ACPI specification: http://www.acpi.info/spec.htm
The ACPI Component Architecture documentation: http://www.acpica.org/documentation/
Skills Needed
Kernel, driver development experience.

Debugging over a USB to Serial adapter

Implement a KD driver for debugging over a USB to Serial adapter. 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 expanding the number of platforms that can be used to 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.

References
USB Open Host Controller Interface specification: ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf
USB Universal Host Controller Interface specification: http://download.intel.com/technology/usb/UHCI11D.pdf
FTDI FT232R datasheet: http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232R.pdf
Prolific PL2303 datasheet: http://www.prolific.com.tw/eng/downloads.asp?ID=23
VirtualKD, another KD driver for outputting debug information from a virtual machine: http://virtualkd.sysprogs.org/
Techwiki:Kd
Skills Needed
Kernel, driver development experience.

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. 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.

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
Unified Extensible Firmware Interface specifications: http://www.uefi.org/specs/ (or http://www.intel.com/technology/efi/)
Skills Needed
Kernel, driver development experience.

Intel High Definition Audio Bus Driver

Implement support for the Intel High Definition Audio specification for sound cards.

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.
References
HD Audio Device Driver Interface whitepaper: http://msdn.microsoft.com/en-us/windows/hardware/gg462966
Programming the HD Audio DDI: http://msdn.microsoft.com/en-us/library/ff536442%28v=vs.85%29.aspx
HD Audio Bus Drivers: http://msdn.microsoft.com/en-us/library/ff536434%28v=vs.85%29.aspx
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
Bluetooth specifications https://www.bluetooth.org/Technical/Specifications/adopted.htm
Firewire specifications http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=4659231
Microsoft Bluetooth API documentation: http://msdn.microsoft.com/en-us/library/aa362932(v=vs.85).aspx
Skills Needed
Familiarity with kernel development and Windows sockets

Networking

Internet Protocol Helper

Implement the Internet Protocol Helper API for manipulating network interfaces.

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.
References
http://msdn.microsoft.com/en-us/library/aa366071(v=vs.85).aspx
Skills Needed
Familiar with windows network 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 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.
Skills Needed
Network development experience.
Knowledge/familiarity with SSH protocol.

TCP/IP Driver Replacement Using lwIP

Implement a new TCP/IP driver using lwIP to handle the needed protocols to replace the current one in ReactOS that is using oskit.

Benefits
lwIP is a compact and highly stand-alone library implementing various network protocols. Due to its portability, it can be easily integrated into third party products such as a driver without complicating future updates.
References
Learning About Protocol Drivers: http://msdn.microsoft.com/en-us/library/ff557050(v=vs.85).aspx
lwIP home page: http://savannah.nongnu.org/projects/lwip/
Skills Needed
Experience with windows driver framework and ndis protocol specific dispatch functions.

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.

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.
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
Audio Mixer Reference: http://msdn.microsoft.com/en-us/library/ms705739(v=vs.85).aspx
DirectKS Sample Application download: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=D7667686-8467-4B10-8713-BF0281536320&amp%3Bdisplaylang=en
Programming Services: http://msdn.microsoft.com/en-us/library/ms685967%28v=VS.85%29.aspx
"Secret Rabbit Code" (SRC) Sample Rate Converter: http://www.mega-nerd.com/SRC/
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
Installable File System Design Guide: http://msdn.microsoft.com/en-us/library/ff548143(v=VS.85).aspx
Installable File System Kit Samples: http://msdn.microsoft.com/en-us/library/ff548099(v=VS.85).aspx
NTFS-3G driver & library: http://www.tuxera.com/community/ntfs-3g-download/
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
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
Skills Needed
Registry API familiarity.
Performance registry structure 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
Familiarity with Windows security and permissions models.

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
What is MMC: http://msdn.microsoft.com/en-us/library/bb756943.aspx
Developing for MMC 3.0: http://msdn.microsoft.com/en-US/library/bb756923.aspx
Skills Needed
Basic Windows development experience.
Knowledge of COM.

UI Enhancement

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. A display driver implements several GDI functions for loading and correctly drawing text based on their glyphs.

Benefits
The Win32 architecture provides an interface in which display drivers of various types can implement support for various rendering styles. A font driver would provide a testbench against that interface, which can then be fixed to add support for not only conventional display drivers for video output but also print drivers that may support special formats not supported by the baseline Win32.
References
GDI functions implemented by printer and display drivers: http://msdn.microsoft.com/en-us/library/ff566549%28VS.85%29.aspx
Skills Needed
Font technology familiarity.
Windows display driver development experience.

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

Layered Windows

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 and the current iteration of Windows Live Messenger relies on layered windows to achieve partial transparency.
References
http://msdn.microsoft.com/en-us/library/ms997507.aspx
http://blogs.msdn.com/b/dwayneneed/archive/2008/09/08/transparent-windows-in-wpf.aspx
Skills Needed
Windows display driver development experience.

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.
Skills Needed
Windows service API familiarity.
Win32 drawing familiarity.

Durability

Kernel mode test suite

Develop a kernel mode test suite, consisting of a framework and actual modularized tests. 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
Improved system stability.
More information about undocumented behaviour.
Improved compatibility with third party drivers.
Skills Needed
Native API knowledge
NT driver development skills