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

From ReactOS Wiki
Jump to: navigation, search
(Import even more ideas from the 2014 page)
(Integrating SMB into ReactOS)
 
(25 intermediate revisions by 7 users not shown)
Line 1: Line 1:
This page lists all project ideas for our Google Summer of Code 2016 application. Students should also visit our [[Google Summer of Code 2016|general GSoC 2016 page]] for more information including a Student Guide.
+
This page lists all project ideas for our Google Summer of Code 2016 application. Students should also visit our [[Google Summer of Code 2016|general GSoC 2016 page]] for more information including a Student Guide and our contact information.
  
 
== Your idea! ==
 
== Your idea! ==
 +
We are eager to hear about your proposal to improve either ReactOS or its infrastructure. Come and propose your project on ReactOS developers mailing-list or on IRC, to get feedback about its feasibility. If your project is doable, we will be glad to provide you a mentor so that you can succeed in your project.
  
We are eager to hear about your proposal to improve either ReactOS or its infrastructure. Come and propose your project on ReactOS developers mailing-list or on IRC, to get a feedback about its feasability. If your project is doable, we will be glad to provide you a mentor so that you can succeed in your project.
+
Don't forget that ReactOS is a big project and application fields are wide. You can choose between user-mode, kernel-mode development. But also between application, or dll/driver development. Or between working on ReactOS itself or on extra tools used by developers for their daily work on ReactOS. And in the end, if all you prefer is web development, we also have needs there.  
 
 
Don't forget that ReactOS is a big project and application fields are wide. You can choose between user-mode, kernel-mode developer. But also between application, or dll/driver developer. Or between working on ReactOS itself or on extra tools used by developers for their daily work on ReactOS. And in the end, if all you prefer is web development, we also have needs there.  
 
  
 
; Skills needed
 
; Skills needed
* Yours
+
: Yours
  
 
; Difficulty
 
; Difficulty
Line 17: Line 16:
  
 
== Drivers ==
 
== Drivers ==
 +
=== AHCI SATA Storage Driver ===
 +
Implement a Windows-compatible AHCI driver (msahci.sys) for the NT 5.2 architecture. This driver would be unique in that it would bring a feature of Vista back to prior Windows versions and could be used both in ReactOS and Windows. Nearly all new machines feature AHCI controllers exclusively and the ability to fallback to IDE emulation will likely disappear over the coming years. Therefore, an AHCI driver is necessary for the project to ensure it can run on real machines in the present and future. This driver would be able to provide AHCI support for Windows versions before Vista like 2000, XP, 2003, and obviously ReactOS. This driver would also provide a fantastic test case for our SCSI Port driver which has nothing testing its PnP path as of now.
  
=== TCP/IP Driver ===
+
;References:
 +
: SCSI Port API: http://msdn.microsoft.com/en-us/library/windows/hardware/ff565353(v=vs.85).aspx
 +
: AHCI specification: http://www.intel.com/content/www/us/en/io/serial-ata/ahci.html
 +
: Universal ATA driver with PATA/SATA/AHCI support (opensource): http://alter.org.ua/soft/win/uni_ata/
  
'''Useful for:''' End-users
+
;Skills needed
 +
: Kernel-mode development
 +
: Familiarity with SCSI Port APIs
  
Currently, ReactOS implements TCP/IP driver using lwIP library. However, having an own TCP/IP implementation which does not rely on "heaps of hacks" around existing implementation/libraries would be of great benefit. The new driver needs to be developed as drop in replacement for Windows tcpip.sys which would allow to thoroughly test the implementation in a running Windows environment and fix possible compatibility issues in ReactOS.
 
  
 +
=== Intel High Definition Audio Bus Driver ===
 +
Implement support for the Intel High Definition Audio specification for sound cards.
 
;Benefits
 
;Benefits
* Get rid of thirdparty library dependency
+
: 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.
* Better source code
 
* Better compatibility and/or performace
 
  
 
;References
 
;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
 +
 +
 +
=== Fully Integrate lwIP ===
 +
'''Useful for:''' End-users
 +
 +
Currently ReactOS uses two entirely separate code bases for its network operations, UDP utilizes lwIP while TCP uses much older code. While UDP runs well albeit slowly, TCP is a minor mess and has major bugs that prevent applications like Chrome from working. lwIP has a working TCP stack, along with support for a few other network interfaces that we either have poor or non-existent support for. Fully integrating lwIP into ReactOS, especially the newer versions which have support for things like multithreading, would significantly improve ReactOS' usability.
 +
 +
;Benefits
 +
: Better source code
 +
: Better compatibility and/or performance
  
 
;Needed Skills
 
;Needed Skills
* Windows Networking stack knowledge
+
: Windows Networking stack knowledge
* TCP/IP protocol tech knowledge
+
: TCP/IP protocol tech knowledge
 +
 
 +
;Resources
 +
: VM image for Windows 2003 to test code on: https://www.microsoft.com/en-us/download/details.aspx?id=19727
  
 
;Extra
 
;Extra
Line 39: Line 66:
  
 
=== NT "Wine audio" driver ===
 
=== NT "Wine audio" driver ===
 
 
'''Useful for:''' End-users
 
'''Useful for:''' End-users
  
Line 45: Line 71:
  
 
;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
* [https://wiki.winehq.org/Sound WINE documentation about its Sound System]
+
: [https://wiki.winehq.org/Sound WINE documentation about its Sound System]
* [http://msdn.microsoft.com/en-us/library/windows/desktop/dd370802%28v=vs.85%29.aspx Core Audio]
+
: [http://msdn.microsoft.com/en-us/library/windows/desktop/dd370802%28v=vs.85%29.aspx Core Audio]
* [http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winealsa.drv/mmdevdrv.c Wine implementation on top of alsa]
+
: [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
 +
 
  
 
=== NTFS driver improvements ===
 
=== NTFS driver improvements ===
Line 64: Line 91:
  
 
;Benefits
 
;Benefits
* Allowing ReactOS to interact with volumes managed in recent Windows
+
: Allowing ReactOS to interact with volumes managed in recent Windows
* Perhaps allowing ReactOS to have a journaled system
+
: Perhaps allowing ReactOS to have a journaled system
  
 
;References
 
;References
* Various documents on the Internet (including MSDN)
+
: Various documents on the Internet (including MSDN)
* Windows Internals books
+
: Windows Internals books
* NTFS-3G FUSE driver
+
: NTFS-3G FUSE driver
  
 
;Needed Skills
 
;Needed Skills
* Kernel world knowledge
+
: Kernel world knowledge
* FUSE dev knowledge might be a plus
+
: FUSE dev knowledge might be a plus
  
  
Line 82: Line 109:
  
 
;References
 
;References
* [http://msdn.microsoft.com/en-us/library/windows/hardware/ff565353(v=vs.85).aspx SCSI Port API]
+
: [http://msdn.microsoft.com/en-us/library/windows/hardware/ff565353(v=vs.85).aspx SCSI Port API]
* [https://github.com/Microsoft/Windows-driver-samples/tree/master/storage Windows Open-Source Storage Driver Samples based on the PnP Storage Stack]
+
: [https://github.com/Microsoft/Windows-driver-samples/tree/master/storage Windows Open-Source Storage Driver Samples based on the PnP Storage Stack]
* [http://alter.org.ua/soft/win/uni_ata/ Universal ATA driver with PATA/SATA/AHCI support (opensource)]
+
: [http://alter.org.ua/soft/win/uni_ata/ Universal ATA driver with PATA/SATA/AHCI support (opensource)]
  
 
;Skills needed
 
;Skills needed
* Software Development in C and under Windows
+
: Software Development in C and under Windows
* Experience with developing low-level Kernel-Mode hardware drivers
+
: Experience with developing low-level Kernel-Mode hardware drivers
* Previous experience with Windows Storage APIs would be a huge plus
+
: Previous experience with Windows Storage APIs would be a huge plus
 +
 
  
 +
=== USB Stack ===
 +
The USB stack on ReactOS suffers from a variety of issues. Support for hub devices and USB 3.0 (xHCI) is missing completely; implementation of the UHCI protocol used by Intel/VIA USB 1.1 controllers is much less complete than OHCI/EHCI. Additionally, day to day operations are complicated because of missing support for the various behaviors displayed by different hardware, and many smaller bugs that can cause timing issues, random failures and crashes, and incompatibilities with other devices and controllers.
  
=== USB 3.0 Support ===
+
Students are not expected to fix all of these issues, but may choose a subset based on their preference and experience (e.g. support for hubs is definitely worth a project to itself). It is also worth noting that many issues encountered when using USB devices in ReactOS lie with the kernel, not the USB stack. Venturing into these issues is possible, but not recommended due to the difficulty of estimating the scope of such projects.
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
* [[wikipedia:Extensible Host Controller Interface]] has links to the required specifications
+
: [https://jira.reactos.org/issues/?filter=13702 Open USB issues in Jira]
* Current OHCI and EHCI implementations
+
: [[wikipedia:Extensible Host Controller Interface]] has links to the required specifications
 +
: Current OHCI and EHCI implementations (exercise: find them in the ReactOS source tree)
 +
: Haiku, Linux, and XNU USB stack implementations
  
 
;Needed Skills
 
;Needed Skills
* Software Development in C and under Windows
+
: Software Development in C and under Windows
* Experience with developing low-level Kernel-Mode hardware drivers
+
: Experience with developing low-level Kernel-Mode hardware drivers
* Previous experience with USB-related development would be a huge plus
+
: Previous experience with USB-related development would be a huge plus
 +
 
 +
== Networking ==
 +
=== BITS ===
 +
'''Useful for:''' Developers
 +
 
 +
The Background Intelligent Transfer Service is a mechanism used to managed downloads without tying up a user application. The code to perform these transfers has been implemented by WINE but the the service itself is missing in ReactOS. One will be needed if we are to actually provide BITS functionality to applications.
  
 +
; References
 +
: [https://msdn.microsoft.com/en-us/library/bb968799%28v=vs.85%29.aspx MSDN Documentation on BITS]
  
== Networking ==
+
; Needed Skills
 +
: Software Development in C/C++ and under Windows
 +
: Familiarity with Win32 APIs and COM
  
 
=== Integrating SMB into ReactOS ===
 
=== Integrating SMB into ReactOS ===
Line 118: Line 159:
  
 
; References
 
; References
* [https://wiki.samba.org/index.php/Main_Page Samba Wiki]
+
: [https://wiki.samba.org/index.php/Main_Page Samba Wiki]
* [https://msdn.microsoft.com/en-us/library/cc246231.aspx MS-SMB Server Message Block (SMB) Protocol Open Specification] (and related ones on this site)
+
: [https://msdn.microsoft.com/en-us/library/cc246231.aspx MS-SMB Server Message Block (SMB) Protocol Open Specification] (and related ones on this site)
 +
: [http://freecode.com/projects/samba-tng Samba-TNG] was an effort to rewrite unix samba libraries into a more NT like architecture. They already work in Windows/ReactOS, archival copies are available here [http://encodedpr.com/files/reactos/source%20code/samba-tng-0.5-rc1.zip source] and [http://encodedpr.com/files/reactos/tools/samba-tng-0.5-rc1_bin.zip binaries]. There is even a [https://www.youtube.com/watch?v=UhFIgSIKPOU video] of how to use it.
  
 
; Needed Skills
 
; Needed Skills
* Software Development in C and under Windows
+
: Software Development in C and under Windows
* Familiarity with Win32 APIs and Networking
+
: Familiarity with Win32 APIs and Networking
* Experience with glueing code of different projects together
+
: Experience with gluing code of different projects together
 
 
  
 
=== SSH Service ===
 
=== SSH Service ===
 
 
'''Useful for:''' End-users and developers
 
'''Useful for:''' End-users and developers
  
Line 137: Line 177:
  
 
;Skills Needed
 
;Skills Needed
* Network development experience.
+
: Network development experience.
* Knowledge/familiarity with SSH protocol.
+
: Knowledge/familiarity with SSH protocol.
  
  
 
=== Terminal Services ===
 
=== Terminal Services ===
 
 
'''Useful for:''' End-users and developers
 
'''Useful for:''' End-users and developers
  
Line 153: Line 192:
  
 
;References
 
;References
* [[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.
  
[[Category:Google Summer of Code]]
 
  
 
== Durability ==
 
== Durability ==
 
=== Kernel mode test suite ===
 
=== Kernel mode test suite ===
 
 
'''Useful for:''' Developers
 
'''Useful for:''' Developers
  
Line 170: Line 207:
  
 
;Benefits
 
;Benefits
* Improved system stability.
+
: Improved system stability.
* More information about undocumented behavior.
+
: 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 ===
 
 
'''Useful for:''' Developers
 
'''Useful for:''' Developers
  
Line 186: Line 223:
  
 
;References
 
;References
* [http://msdn.microsoft.com/en-us/library/windows/hardware/ff570585%28v=vs.85%29.aspx Windows 2000 display driver model reference]
+
: [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
 +
 
  
 
== System Enhancements ==
 
== 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
 +
: [http://msdn.microsoft.com/en-us/library/ms705739(v=vs.85).aspx Audio Mixer Reference]
 +
: [http://www.microsoft.com/downloads/en/details.aspx?FamilyID=D7667686-8467-4B10-8713-BF0281536320&amp%3Bdisplaylang=en DirectKS Sample Application download]
 +
: [http://msdn.microsoft.com/en-us/library/ms685967%28v=VS.85%29.aspx Programming Services]
 +
: "Secret Rabbit Code" (SRC) [http://www.mega-nerd.com/SRC/ Sample Rate Converter] aka libsamplerate
 +
 +
;Skills Needed
 +
: Windows Services familiarity
 +
: Basic Audio file format familiarity
 +
: Audio mixing algorithms / libraries familiarity
 +
: Basic kernel streaming familiarity
 +
 +
 +
=== Search Band in Explorer ===
 +
Our current Explorer still lacks a shell search band on the left. It would make the user able to search files, documents, or objects just like Windows does. It must be implemented compatible to the Windows Explorer interfaces to maintain compatibility with existing applications and existing search providers relying on it.
 +
 +
Filling the gaps in our shellbrowser implementation to allow Windows search band to be able to search elements in our explorer would be a great improvement for compatibility. If time permits, it would be possible to implement a search band and associated folder view and making it able to work under Windows explorer.
 +
 +
;Benefits
 +
: This would make our explorer feel closer to like the original one, and be an user improvement
 +
: Great compatibility test for our browseui/explorer infrastucture.
 +
 +
;Skills Needed
 +
: Development in C/C++ and under Windows
 +
: Knowledge of COM, ATL, and shell APIs would be a plus.
 +
: Able to work without documentation, and only with debugging traces, WinDbg/API monitor
  
 
=== Performance Data Registry ===
 
=== Performance Data Registry ===
Line 206: Line 275:
  
 
;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.
  
  
Line 220: Line 289:
  
 
;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
* [http://msdn.microsoft.com/en-us/library/bb756943.aspx What is MMC]
+
: [http://msdn.microsoft.com/en-us/library/bb756943.aspx What is MMC]
* [http://msdn.microsoft.com/en-US/library/bb756923.aspx Developing for MMC 3.0]
+
: [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.
  
  
Line 239: Line 308:
  
 
A list of features to be implemented:
 
A list of features to be implemented:
* Adding command line parameters support to RAPPS. For example: "rapps install chrome" (just like your favourite Linux distro package manager) or "rapps remove msvc2010_redist"
+
 
* Separate download and install, so that a user could choose just to download the apps into a local cache and later install some or all of them (just like Steam does Download, then it asks to Install, or NVidia driver updaters for example)
+
* Mainly:
* Automatically "install" simple apps by unpacking the archive they come in and execute a script inside it (if any) which creates shortcuts on the desktop
+
 
 +
  - https://docs.google.com/document/d/1_SVqMk1VU75tjAnnE5oz20iU8fy5fQpPf5vwTf3bnEk/edit?usp=sharing
 +
 
 +
* Optionally:
 +
  - Adding command line parameters support to RAPPS. For example: "rapps install chrome" (just like your favourite Linux distro package manager) or "rapps remove msvc2010_redist"
 +
  - Separate download and install, so that a user could choose just to download the apps into a local cache and later install some or all of them (just like Steam does Download, then it asks to Install, or NVidia driver updaters for example)
 +
  - Automatically "install" simple apps by unpacking the archive they come in and execute a script inside it (if any) which creates shortcuts on the desktop
  
 
; Skills needed
 
; Skills needed
* WinAPI
+
: WinAPI
* C language
+
: C/C++
  
 
; Difficulty
 
; Difficulty
Line 252: Line 327:
 
; Extras
 
; Extras
 
A chance to work on an app potentially used by many people throughout the world
 
A chance to work on an app potentially used by many people throughout the world
 
  
 
=== GUI 1st Stage Installer ===
 
=== GUI 1st Stage Installer ===
Line 263: Line 337:
  
 
;Skills Needed
 
;Skills Needed
* Win32 API familiarity.
+
: Win32 API familiarity.
* Partitioning and setup experience.
+
: Partitioning and setup experience.
 +
 
 +
== Win32 Subsystem ==
 +
 
 +
=== 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
 +
: http://msdn.microsoft.com/en-us/library/windows/desktop/dd145071%28v=vs.85%29.aspx
 +
: 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
 +
: 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.
 +
 
  
 
== Enhancing web presence of ReactOS ==
 
== Enhancing web presence of ReactOS ==
 +
 
=== Implement a REST API in testman ===
 
=== Implement a REST API in testman ===
 
 
'''Useful for:''' Developers
 
'''Useful for:''' Developers
  
Line 276: Line 371:
  
 
; Skills needed
 
; Skills needed
* PHP/MySQL development
+
: PHP/MySQL development
* REST API development
+
: REST API development
  
 
; Difficulty
 
; Difficulty
Line 284: Line 379:
 
; Extras
 
; Extras
 
If the student goes fast enough, we will be able to extend this project, by for instance looking at how to develop a skeleton application to make use of the API. Or to directly develop a complete application to evaluate the performances of the tests over time.
 
If the student goes fast enough, we will be able to extend this project, by for instance looking at how to develop a skeleton application to make use of the API. Or to directly develop a complete application to evaluate the performances of the tests over time.
 +
 +
 +
[[Category:Google Summer of Code]]

Latest revision as of 16:15, 25 March 2016

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

Your idea!

We are eager to hear about your proposal to improve either ReactOS or its infrastructure. Come and propose your project on ReactOS developers mailing-list or on IRC, to get feedback about its feasibility. If your project is doable, we will be glad to provide you a mentor so that you can succeed in your project.

Don't forget that ReactOS is a big project and application fields are wide. You can choose between user-mode, kernel-mode development. But also between application, or dll/driver development. Or between working on ReactOS itself or on extra tools used by developers for their daily work on ReactOS. And in the end, if all you prefer is web development, we also have needs there.

Skills needed
Yours
Difficulty

The one you'll have set

Extras

You'll be working on your own project and be able to choose its direction along with your mentor :-).

Drivers

AHCI SATA Storage Driver

Implement a Windows-compatible AHCI driver (msahci.sys) for the NT 5.2 architecture. This driver would be unique in that it would bring a feature of Vista back to prior Windows versions and could be used both in ReactOS and Windows. Nearly all new machines feature AHCI controllers exclusively and the ability to fallback to IDE emulation will likely disappear over the coming years. Therefore, an AHCI driver is necessary for the project to ensure it can run on real machines in the present and future. This driver would be able to provide AHCI support for Windows versions before Vista like 2000, XP, 2003, and obviously ReactOS. This driver would also provide a fantastic test case for our SCSI Port driver which has nothing testing its PnP path as of now.

References
SCSI Port API: http://msdn.microsoft.com/en-us/library/windows/hardware/ff565353(v=vs.85).aspx
AHCI specification: http://www.intel.com/content/www/us/en/io/serial-ata/ahci.html
Universal ATA driver with PATA/SATA/AHCI support (opensource): http://alter.org.ua/soft/win/uni_ata/
Skills needed
Kernel-mode development
Familiarity with SCSI Port APIs


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


Fully Integrate lwIP

Useful for: End-users

Currently ReactOS uses two entirely separate code bases for its network operations, UDP utilizes lwIP while TCP uses much older code. While UDP runs well albeit slowly, TCP is a minor mess and has major bugs that prevent applications like Chrome from working. lwIP has a working TCP stack, along with support for a few other network interfaces that we either have poor or non-existent support for. Fully integrating lwIP into ReactOS, especially the newer versions which have support for things like multithreading, would significantly improve ReactOS' usability.

Benefits
Better source code
Better compatibility and/or performance
Needed Skills
Windows Networking stack knowledge
TCP/IP protocol tech knowledge
Resources
VM image for Windows 2003 to test code on: https://www.microsoft.com/en-us/download/details.aspx?id=19727
Extra

Make the performance of a new tcpip.sys in Windows better than its native driver. Ambitious, but fun.

NT "Wine audio" driver

Useful for: End-users

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
WINE documentation about its Sound System
Core Audio
Wine implementation on top of alsa
Needed Skills
Windows Audio Stack knowledge
COM knowledge


NTFS driver improvements

Useful for: End-users and developers

During the last spring, NTFS support was finally added in ReactOS. If it was a major step forward, it still requires huge amount of work. It was implemented without caching support, and some features of NTFS are also totally ignored. We are looking for students willing to discover one of the most used file system and to improve its supports in ReactOS. There are various options offered to students: either work on improvements for RO support and/or start implementing RW features.

Benefits
Allowing ReactOS to interact with volumes managed in recent Windows
Perhaps allowing ReactOS to have a journaled system
References
Various documents on the Internet (including MSDN)
Windows Internals books
NTFS-3G FUSE driver
Needed Skills
Kernel world knowledge
FUSE dev knowledge might be a plus


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
SCSI Port API
Windows Open-Source Storage Driver Samples based on the PnP Storage Stack
Universal ATA driver with PATA/SATA/AHCI support (opensource)
Skills needed
Software Development in C and under Windows
Experience with developing low-level Kernel-Mode hardware drivers
Previous experience with Windows Storage APIs would be a huge plus


USB Stack

The USB stack on ReactOS suffers from a variety of issues. Support for hub devices and USB 3.0 (xHCI) is missing completely; implementation of the UHCI protocol used by Intel/VIA USB 1.1 controllers is much less complete than OHCI/EHCI. Additionally, day to day operations are complicated because of missing support for the various behaviors displayed by different hardware, and many smaller bugs that can cause timing issues, random failures and crashes, and incompatibilities with other devices and controllers.

Students are not expected to fix all of these issues, but may choose a subset based on their preference and experience (e.g. support for hubs is definitely worth a project to itself). It is also worth noting that many issues encountered when using USB devices in ReactOS lie with the kernel, not the USB stack. Venturing into these issues is possible, but not recommended due to the difficulty of estimating the scope of such projects.

References
Open USB issues in Jira
wikipedia:Extensible Host Controller Interface has links to the required specifications
Current OHCI and EHCI implementations (exercise: find them in the ReactOS source tree)
Haiku, Linux, and XNU USB stack implementations
Needed Skills
Software Development in C and under Windows
Experience with developing low-level Kernel-Mode hardware drivers
Previous experience with USB-related development would be a huge plus

Networking

BITS

Useful for: Developers

The Background Intelligent Transfer Service is a mechanism used to managed downloads without tying up a user application. The code to perform these transfers has been implemented by WINE but the the service itself is missing in ReactOS. One will be needed if we are to actually provide BITS functionality to applications.

References
MSDN Documentation on BITS
Needed Skills
Software Development in C/C++ and under Windows
Familiarity with Win32 APIs and COM

Integrating SMB into ReactOS

Useful for: End-users and developers

SMB/CIFS is omnipresent for file sharing under Windows. It's one of the features new users to ReactOS always expect and then cannot find anywhere.

As such, ReactOS finally needs an implementation of SMB properly integrated into the operating system. SMB heavily relies on RPC and UNC pathes and previous work in both areas exists. A potential developer should base the work on the mature Samba Open-Source implementation of SMB. However, Samba is developed for UNIX systems and therefore parts of its code require careful porting to create a native implementation for ReactOS.

Benefits

Having SMB would highly improve ReactOS' abilities to transfer files over the network, both for users and developers! It would also lay the ground for other Windows network services such as Printer Sharing.

References
Samba Wiki
MS-SMB Server Message Block (SMB) Protocol Open Specification (and related ones on this site)
Samba-TNG was an effort to rewrite unix samba libraries into a more NT like architecture. They already work in Windows/ReactOS, archival copies are available here source and binaries. There is even a video of how to use it.
Needed Skills
Software Development in C and under Windows
Familiarity with Win32 APIs and Networking
Experience with gluing code of different projects together

SSH Service

Useful for: End-users and developers

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

Useful for: End-users and developers

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
ReactOS Terminal Services
Skills Needed
Network development experience.
Driver development experience.
Knowledge/familiarity with RDP protocol.


Durability

Kernel mode test suite

Useful for: Developers

Improve our existing kernel mode test suite (created by a previous successful GSoC student) 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

Useful for: Developers

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
Windows 2000 display driver model reference
Benefits
Improved stability.
More information about undocumented behavior.
Improved compatibility with third party drivers.
Needed skills
Display drivers development experience
Win32 API knowledge


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
DirectKS Sample Application download
Programming Services
"Secret Rabbit Code" (SRC) Sample Rate Converter aka libsamplerate
Skills Needed
Windows Services familiarity
Basic Audio file format familiarity
Audio mixing algorithms / libraries familiarity
Basic kernel streaming familiarity


Search Band in Explorer

Our current Explorer still lacks a shell search band on the left. It would make the user able to search files, documents, or objects just like Windows does. It must be implemented compatible to the Windows Explorer interfaces to maintain compatibility with existing applications and existing search providers relying on it.

Filling the gaps in our shellbrowser implementation to allow Windows search band to be able to search elements in our explorer would be a great improvement for compatibility. If time permits, it would be possible to implement a search band and associated folder view and making it able to work under Windows explorer.

Benefits
This would make our explorer feel closer to like the original one, and be an user improvement
Great compatibility test for our browseui/explorer infrastucture.
Skills Needed
Development in C/C++ and under Windows
Knowledge of COM, ATL, and shell APIs would be a plus.
Able to work without documentation, and only with debugging traces, WinDbg/API monitor

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.


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
Developing for MMC 3.0
Skills Needed
Basic Windows development experience.
Knowledge of COM.


Applications Manager Rapps

Useful for: End-users

RAPPS is a lightweight GUI utility which downloads and installs various popular apps and redistributable packages in Windows and ReactOS. It can be significantly improved to become a really useful tool for not only for ReactOS but for Windows users also who want to manage their installed applications like Steam manages games installation/updating.

A list of features to be implemented:

  • Mainly:
 - https://docs.google.com/document/d/1_SVqMk1VU75tjAnnE5oz20iU8fy5fQpPf5vwTf3bnEk/edit?usp=sharing
  • Optionally:
 - Adding command line parameters support to RAPPS. For example: "rapps install chrome" (just like your favourite Linux distro package manager) or "rapps remove msvc2010_redist"
 - Separate download and install, so that a user could choose just to download the apps into a local cache and later install some or all of them (just like Steam does Download, then it asks to Install, or NVidia driver updaters for example)
 - Automatically "install" simple apps by unpacking the archive they come in and execute a script inside it (if any) which creates shortcuts on the desktop
Skills needed
WinAPI
C/C++
Difficulty

Medium

Extras

A chance to work on an app potentially used by many people throughout the world

GUI 1st Stage Installer

Useful for: End-users

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

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
http://msdn.microsoft.com/en-us/library/windows/desktop/dd145071%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/ff569172%28v=VS.85%29.aspx
http://www.vesa.org/
Virtualbox video driver source
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.


Enhancing web presence of ReactOS

Implement a REST API in testman

Useful for: Developers

For its development, ReactOS project has been using with success for years a complete tools set. Each time a commit is made to our trunk, our buildbot infrastructure (https://build.reactos.org) is in charge of rebuilding trunk and starting a bunch of tests (circa 10M tests) on it to make sure not regressions came in. When these tests are done, they are uploaded to testman (https://www.reactos.org/testman), which makes them properly readable and usable for developers. Over years, the question of being able to catch more or less automatically regressions patterns was raised. Also, regtests provide a good performance indicator for ReactOS and evaluating their performances over commits can be critical as well.

There is then a need to be able to directly query Testman via an API to gather the raw data (tests, time to perform then) so that more tools can make use of these results. The student would then have the responsibility to implement such an API into testman directly.

Skills needed
PHP/MySQL development
REST API development
Difficulty

The project in itself shouldn't be difficult. Testman is a well-known product develop in-house. But a deep attention will have to be set on security and the performances of the API.

Extras

If the student goes fast enough, we will be able to extend this project, by for instance looking at how to develop a skeleton application to make use of the API. Or to directly develop a complete application to evaluate the performances of the tests over time.