Difference between revisions of "Google Summer of Code 2017 Ideas"
Colin Finck (talk | contribs) (Remove the ideas that were done last year) |
Colin Finck (talk | contribs) (→Win32 Subsystem) |
||
(15 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
− | This page lists all project ideas for our Google Summer of Code 2017 application. Students should also visit our [[Google Summer of Code 2017|general GSoC 2017 page]] for more information including a Student Guide and our contact information. | + | This page lists all the project ideas for our Google Summer of Code 2017 application. Students should also visit our [[Google Summer of Code 2017|general GSoC 2017 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 | + | We are eager to hear about your proposal to improve either ReactOS or its infrastructure. Come and propose your project on the 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 with a mentor so 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 | + | Don't forget that ReactOS is a big project and application fields are wide. You can choose between user-mode or kernel-mode development, 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. Also if all you prefer is web development, we also have needs there. |
− | ; Skills needed | + | ;Skills needed |
: Yours | : Yours | ||
− | ; Difficulty | + | ;Difficulty |
− | The one you'll have set | + | : The one you'll have set |
− | ; Extras | + | ;Extras |
− | You'll be working on your own project and be able to choose its direction along with your mentor :-). | + | : You'll be working on your own project and be able to choose its direction along with your mentor :-). |
== Drivers == | == Drivers == | ||
Line 26: | Line 26: | ||
: HD Audio Bus Drivers: http://msdn.microsoft.com/en-us/library/ff536434%28v=vs.85%29.aspx | : HD Audio Bus Drivers: http://msdn.microsoft.com/en-us/library/ff536434%28v=vs.85%29.aspx | ||
− | ;Skills | + | ;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 | ||
+ | |||
+ | === Fundamental WiFi components === | ||
+ | ReactOS already supports the majority of drivers for cabled Ethernet controllers. | ||
+ | Supporting wireless WiFi controllers requires additional components for enumerating networks, handling a connection and encrypting the communication. | ||
+ | These are almost non-existing in ReactOS right now, and WPA encryption is entirely unsupported. | ||
+ | Having WiFi components would greatly improve the ReactOS experience on mobile computers. | ||
+ | |||
+ | The student should implement the basic components for WiFi connections found in modern Windows versions (NT6 and later). The components should support connecting to unencrypted and encrypted WEP/WPA/WPA2 networks. | ||
+ | We're deliberately not targeting WinXP (NT5) here, because of major architectural changes in the WiFi components since then. | ||
+ | If there is still time left, adequate GUI applications for connecting to WiFi networks and checking the status can be implemented. | ||
+ | |||
+ | ;References | ||
+ | : [https://technet.microsoft.com/de-de/library/cc766215(v=ws.10).aspx#BKMK_AppndxB Windows Vista DLLs and function descriptions] | ||
+ | : [https://msdn.microsoft.com/en-us/library/windows/hardware/ff543936(v=vs.85).aspx 802.11 Wireless LAN Objects] | ||
+ | : [https://msdn.microsoft.com/en-us/library/windows/desktop/ms706274(v=vs.85).aspx Native Wifi functions] | ||
+ | : [http://redplait.blogspot.de/2010/11/wlanmsmdll-rpc-interfaces.html wlanmsm.dll RPC Interfaces] | ||
+ | : [https://sourceforge.net/p/mingw-w64/mingw-w64/ci/4a306baa4a206c9314bdc129e98abfa1aebe2b0e/tree/mingw-w64-crt/libarm32/wlansec.def Exports of wlansec.dll] | ||
+ | : [http://securityxploded.com/wifi-password-secrets.php WiFi Password Secrets] | ||
+ | |||
+ | ;Needed Skills | ||
+ | : Software Development in C and under Windows | ||
+ | : Familiarity with Windows networking | ||
+ | : Previous experience with RPC would be a plus | ||
+ | |||
+ | |||
+ | === USBXHCI driver for supporting USB 3.x controllers === | ||
+ | ReactOS currently ships with drivers for USB 1.x (OHCI/UHCI) and USB 2.x (EHCI) controllers only. | ||
+ | More and more modern computers come with USB 3.x controllers (XHCI), so ReactOS should come with a driver for them rather sooner than later. | ||
+ | While our USB 1.x and 2.x drivers are not yet complete and still under heavy development, this is a side project that can be implemented independently. | ||
+ | |||
+ | ;References | ||
+ | : [http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf Intel XHCI Specification] | ||
+ | : [https://github.com/vgalnt/reactos/commits/usbport Current work on USB in ReactOS] | ||
+ | |||
+ | ;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 | ||
Line 36: | Line 74: | ||
'''Useful for:''' End-users | '''Useful for:''' End-users | ||
− | Currently, ReactOS imports mmdevapi DLL from Wine | + | 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 | ||
Line 48: | Line 86: | ||
: [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] | ||
− | ; | + | ;Skills needed |
: Windows Audio Stack knowledge | : Windows Audio Stack knowledge | ||
: COM knowledge | : COM knowledge | ||
Line 54: | Line 92: | ||
=== Plug and Play (PnP) Storage Stack === | === Plug and Play (PnP) Storage Stack === | ||
− | Right now, PnP support in the storage stack is close to | + | Right now, PnP support in the storage stack is close to being 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 a 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 | + | Alleviating PnP support in scsiport would be the first task of this project. Then, turning uniata into a PnP-aware driver would permit SATA device hot-plugging. Finally, PnP-aware "cdrom_new" and "disk_new" drivers can be activated. |
;References | ;References | ||
Line 68: | Line 106: | ||
− | == | + | === Bluetooth Stack === |
− | + | Bluetooth is an integral part of communicating with mobile devices these days. | |
− | + | At the moment, ReactOS has no Bluetooth support. An initial Bluetooth stack for ReactOS should come with a Device Management as well as file transfer support (OBEX-FTP profile). | |
+ | The number of available Bluetooth stacks for Windows shows that you have a high degree of design freedom for your ReactOS Bluetooth stack, more than for most ReactOS components. | ||
− | + | ;References | |
+ | : [https://msdn.microsoft.com/de-de/library/windows/desktop/aa362932(v=vs.85).aspx Bluetooth under Windows] | ||
− | ; | + | ;Skills needed |
− | + | : Software Development in C and under Windows | |
− | + | ; Familiarity with Bluetooth | |
− | |||
− | : Software Development in C | ||
− | |||
+ | == Networking == | ||
=== Integrating SMB into ReactOS === | === Integrating SMB into ReactOS === | ||
'''Useful for:''' End-users and developers | '''Useful for:''' End-users and developers | ||
Line 86: | Line 124: | ||
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. | 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 | + | As such, ReactOS finally needs an implementation of SMB properly integrated into the operating system. SMB heavily relies on RPC and UNC paths 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 | + | ;Benefits |
− | Having SMB would highly improve ReactOS' abilities to transfer files over the network, both for users and developers! It would also lay the | + | : Having SMB would highly improve ReactOS' abilities to transfer files over the network, both for users and developers! It would also lay the groundwork for other Windows network services such as Printer Sharing. |
− | ; 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. | : [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. | ||
− | ; | + | ;Skills needed |
: 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 gluing code of different projects together | : Experience with gluing code of different projects together | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Line 119: | Line 145: | ||
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. | + | 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 | ||
− | : Terminal services support would allow ReactOS to | + | : Terminal services support would allow ReactOS to serve 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 | ;References | ||
: [[ReactOS Terminal Services]] | : [[ReactOS Terminal Services]] | ||
− | ;Skills | + | ;Skills needed |
: Network development experience. | : Network development experience. | ||
: Driver development experience. | : Driver development experience. | ||
Line 137: | Line 163: | ||
'''Useful for:''' Developers | '''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 | + | 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 such as 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 against the corresponding Windows operating system. |
;Benefits | ;Benefits | ||
Line 144: | Line 170: | ||
: Improved compatibility with third party drivers. | : Improved compatibility with third party drivers. | ||
− | ;Skills | + | ;Skills needed |
: Native API knowledge | : Native API knowledge | ||
: NT driver development skills | : NT driver development skills | ||
Line 152: | Line 178: | ||
'''Useful for:''' Developers | '''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, | + | 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, guesswork 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. | ||
Line 163: | Line 189: | ||
: Improved compatibility with third party drivers. | : Improved compatibility with third party drivers. | ||
− | ; | + | ;Skills needed |
: Display drivers development experience | : Display drivers development experience | ||
: Win32 API knowledge | : Win32 API knowledge | ||
Line 172: | Line 198: | ||
Implement support for mixing of audio streams. | Implement support for mixing of audio streams. | ||
;Benefits | ;Benefits | ||
− | : | + | : An 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. At the end of the project multiple audio streams should be able to be played at the same time. |
;References | ;References | ||
Line 180: | Line 206: | ||
: "Secret Rabbit Code" (SRC) [http://www.mega-nerd.com/SRC/ Sample Rate Converter] aka libsamplerate | : "Secret Rabbit Code" (SRC) [http://www.mega-nerd.com/SRC/ Sample Rate Converter] aka libsamplerate | ||
− | ;Skills | + | ;Skills needed |
: Windows Services familiarity | : Windows Services familiarity | ||
: Basic Audio file format familiarity | : Basic Audio file format familiarity | ||
Line 187: | Line 213: | ||
− | === Search | + | === Search Shell extension === |
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. | 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. | ||
− | |||
− | |||
;Benefits | ;Benefits | ||
− | : This would make our | + | : This would make our Explorer feel more like the original one and be an user improvement |
: Great compatibility test for our browseui/explorer infrastucture. | : Great compatibility test for our browseui/explorer infrastucture. | ||
− | ;Skills | + | ;Skills needed |
: Development in C/C++ and under Windows | : Development in C/C++ and under Windows | ||
: Knowledge of COM, ATL, and shell APIs would be a plus. | : Knowledge of COM, ATL, and shell APIs would be a plus. | ||
: Able to work without documentation, and only with debugging traces, WinDbg/API monitor | : Able to work without documentation, and only with debugging traces, WinDbg/API monitor | ||
+ | |||
+ | |||
+ | === Taskbar Shell extensions === | ||
+ | The shell in ReactOS lets user manager running applications, start other applications and manage files but nothing more. This idea is about implementing 3 small shell extensions for showing the state of the battery of the machine, for ejecting usb devices and implementing the quick launch toolbar. These are important requirements that we realized they are much needed while presenting ReactOS in real hardware. Not knowing the state of the battery or not being able to eject a usb flash drive is a serious usability problem. The shell extensions should be developed and tested to work on Windows. | ||
+ | |||
+ | ;Benefits | ||
+ | : Greater control of the machine right from the GUI shell. | ||
+ | : Makes testing and presenting the OS on real hardware much easier. | ||
+ | : Greater usability by making it possible to launch applications from the quick launch toolbar. | ||
+ | |||
+ | ;Skills needed | ||
+ | : Development in C/C++ and under Windows | ||
+ | : Knowledge of COM, ATL, and shell APIs would be a plus. | ||
+ | : Knowledge of device management APIs would be a plus. | ||
+ | |||
+ | |||
+ | === Support for the GPT Partitioning Scheme === | ||
+ | Currently, ReactOS relies on the traditional MBR (Master Boot Record) Partitioning Scheme for handling partitions on disks. | ||
+ | The modern GPT (GUID Partition Table) enables ReactOS to address larger disks, support more partitions and is a requirement to boot on modern UEFI-based computers. | ||
+ | |||
+ | The student shall research into the components required for GPT support and the work that needs to be done on ReactOS. For example, some components like our kernel and mountmgr.sys already have preliminary GPT support, whereas it is non-existent in the HAL and disk.sys. | ||
+ | At the end of the task, ReactOS shall be able to detect and use an external GPT-formatted disk. If there is still time left, the student may also add support for booting from GPT to our bootloader(s). | ||
+ | |||
+ | ;Skills needed | ||
+ | : Development in C | ||
+ | : Kernel-mode development | ||
+ | : Prior knowledge about MBR and GPT disk structures would be a huge plus. | ||
+ | |||
+ | |||
+ | === WebKit-based MSHTML implementation === | ||
+ | MSHTML is the central component for rendering HTML pages in applications written for Windows. | ||
+ | At the moment, ReactOS depends on a heavyweight Gecko-based MSHTML implementation that needs to be installed manually. | ||
+ | By providing a lightweight WebKit-based MSHTML implementation, ReactOS could render HTML pages out of the box. | ||
+ | This would also benefit the CHM help system, which is based on HTML files. | ||
+ | On top of this, a simple ReactOS Browser with tabbing and bookmarks may be sufficient for some people. | ||
+ | |||
+ | ;References | ||
+ | : [https://msdn.microsoft.com/en-us/library/aa741317(v=vs.85).aspx MSHTML Reference] | ||
+ | : [https://trac.webkit.org/wiki/WebKit2 WebKit2 API] | ||
+ | |||
+ | ;Benefits | ||
+ | : Greater usability by providing a web browser and HTML-based help system out of the box. | ||
+ | : No reliance on the heavyweight Gecko-based MSHTML sourced from WINE. | ||
+ | |||
+ | ;Skills needed | ||
+ | : Development in C/C++ and under Windows | ||
+ | : Knowledge of COM would be a plus. | ||
+ | : Familiarity with WebKit would be a plus. | ||
+ | |||
+ | |||
+ | === Improving the quality of our Registry Hive implementation === | ||
+ | ReactOS features a basic implementation of the Windows-compatible Registry Hive format for storing system and application settings. | ||
+ | There are two major areas where our current implementation could be improved: | ||
+ | # When ReactOS crashes, Registry Hives easily get corrupted and render the whole system unbootable. The reliability of the Registry Hive implementation shall be improved to make the effect of crashes less severe and also recover from partly corrupted Hives. | ||
+ | # Hives created by our mkhive tool are roughly compatible with the Windows format. The only part that is currently missing are the implementation of Security Descriptors. Implementing these could make the tool more usable and improve interoperability between Windows and ReactOS. | ||
+ | |||
+ | Related components in ReactOS are the cmlib library, the ntoskrnl Cm, and the mkhive tool. | ||
+ | |||
+ | ;References | ||
+ | : "The Internal Structure of the Windows Registry", MSc Thesis by Peter Norris, BSc (Hons), MBCS: http://amnesia.gtisc.gatech.edu/~moyix/suzibandit.ltd.uk/MSc/ | ||
+ | : Offline NT Password and Registry Editor: http://pogostick.net/~pnh/ntpasswd/ | ||
+ | : Bug reports [https://jira.reactos.org/browse/CORE-6762 CORE-6762], [https://jira.reactos.org/browse/CORE-9195 CORE-9195] and [https://jira.reactos.org/browse/CORE-10793 CORE-10793]. | ||
+ | |||
+ | ;Skills needed | ||
+ | : Development in C | ||
+ | : Kernel-mode development | ||
=== Performance Data Registry === | === Performance Data Registry === | ||
Line 212: | Line 302: | ||
: 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 | + | ;Skills needed |
: Registry API familiarity. | : Registry API familiarity. | ||
: Performance registry structure familiarity. | : Performance registry structure familiarity. | ||
Line 230: | Line 320: | ||
: [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 | + | ;Skills needed |
: Basic Windows development experience. | : Basic Windows development experience. | ||
: Knowledge of COM. | : Knowledge of COM. | ||
Line 247: | Line 337: | ||
* Optionally: | * Optionally: | ||
− | - | + | - Add support for command line parameters to RAPPS. For example: "rapps install chrome" (just like your favourite Linux distro package manager) or "rapps remove msvc2010_redist" |
− | - Separate download and install | + | - Separate the download and install operations so that a user could choose just to download the apps into a local cache and install some or all of them later (just like Steam or NVidia's driver updaters first does Download then asks to Install, 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 | - 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/C++ | : C/C++ | ||
− | ; Difficulty | + | ;Difficulty |
− | Medium | + | : Medium |
; 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 === | ||
'''Useful for:''' End-users | '''Useful for:''' End-users | ||
− | 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 | + | 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 front end 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 | + | ;Skills needed |
: Win32 API familiarity. | : Win32 API familiarity. | ||
: Partitioning and setup experience. | : Partitioning and setup experience. | ||
Line 276: | Line 367: | ||
=== Multi-Monitor Support === | === Multi-Monitor Support === | ||
− | + | Implementation of multi-monitor support has been almost nonexistent until now. Display device drivers expose them thanks to the HwVidGetVideoChildDescriptor callback, which videoprt.sys uses to enumerate monitors attached to it then to 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 | ;Benefits | ||
− | : Multi-monitor support would | + | : Multi-monitor support would allow ReactOS to become a serious player in professional desktop applications given the increasing number of double-screen installations present in modern workspaces. Document comparison, permanently visible e-mail reader or presentation applications are just a few benefits professionals get when using multiple monitors. |
− | : 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 | + | : 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 are things people do in the 21st century! |
− | : From a technical | + | : From a technical standpoint, properly supporting this feature would improve driver support and WIN32 application compatibility for APIs such as EnumDisplaySettings. |
;References | ;References | ||
Line 289: | Line 380: | ||
: [https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/WINNT/Graphics/Video/mp/xpdm/VBoxMPDriver.cpp Virtualbox video driver source] | : [https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/WINNT/Graphics/Video/mp/xpdm/VBoxMPDriver.cpp Virtualbox video driver source] | ||
− | ;Skills | + | ;Skills needed |
: Experience with Windows display drivers. | : Experience with Windows display drivers. | ||
− | : Experience with WINAPI, especially gdi32/user32.: Experience with | + | : Experience with WINAPI, especially gdi32/user32.: Experience with PnP, as this feature would require detection of connected monitors: Experience with EDID/VESA standards. |
+ | === Multi-Session Support === | ||
+ | Supporting multiple sessions is a prerequisite for Terminal Services. | ||
+ | TO BE ADDED WITH MORE DETAILS FOR GSOC 2018. | ||
== Enhancing web presence of ReactOS == | == Enhancing web presence of ReactOS == | ||
Line 299: | Line 393: | ||
'''Useful for:''' Developers | '''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 ( | + | 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 the trunk and starting a bunch of tests (about 10M tests) on it to make sure no 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 the years, the question of being able to catch regression patterns more or less automatically has been raised. Also, regtests provide a good performance indicator for ReactOS and evaluating their performances over commits can be critical as well. |
− | + | Thus there is 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 have the responsibility to implement such an API into Testman directly. | |
− | ; Skills needed | + | ;Skills needed |
: PHP/MySQL development | : PHP/MySQL development | ||
: REST API development | : REST API development | ||
− | ; Difficulty | + | ;Difficulty |
− | The project in itself shouldn't be difficult. Testman is a well-known product | + | : The project in itself shouldn't be difficult. Testman is a well-known product developed in-house. But deep attention must be given to security and the performance of the API. |
− | ; 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 | + | : 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 by directly developing a complete application to evaluate the performance of the tests over time. |
[[Category:Google Summer of Code]] | [[Category:Google Summer of Code]] |
Latest revision as of 18:34, 15 April 2017
This page lists all the project ideas for our Google Summer of Code 2017 application. Students should also visit our general GSoC 2017 page for more information including a Student Guide and our contact information.
Contents
- 1 Your idea!
- 2 Drivers
- 3 Networking
- 4 Durability
- 5 System Enhancements
- 5.1 Audio Mixer
- 5.2 Search Shell extension
- 5.3 Taskbar Shell extensions
- 5.4 Support for the GPT Partitioning Scheme
- 5.5 WebKit-based MSHTML implementation
- 5.6 Improving the quality of our Registry Hive implementation
- 5.7 Performance Data Registry
- 5.8 Management Console
- 5.9 Applications Manager Rapps
- 5.10 GUI 1st Stage Installer
- 6 Win32 Subsystem
- 7 Enhancing web presence of ReactOS
Your idea!
We are eager to hear about your proposal to improve either ReactOS or its infrastructure. Come and propose your project on the 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 with a mentor so 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 or kernel-mode development, 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. Also 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
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
Fundamental WiFi components
ReactOS already supports the majority of drivers for cabled Ethernet controllers. Supporting wireless WiFi controllers requires additional components for enumerating networks, handling a connection and encrypting the communication. These are almost non-existing in ReactOS right now, and WPA encryption is entirely unsupported. Having WiFi components would greatly improve the ReactOS experience on mobile computers.
The student should implement the basic components for WiFi connections found in modern Windows versions (NT6 and later). The components should support connecting to unencrypted and encrypted WEP/WPA/WPA2 networks. We're deliberately not targeting WinXP (NT5) here, because of major architectural changes in the WiFi components since then. If there is still time left, adequate GUI applications for connecting to WiFi networks and checking the status can be implemented.
- References
- Windows Vista DLLs and function descriptions
- 802.11 Wireless LAN Objects
- Native Wifi functions
- wlanmsm.dll RPC Interfaces
- Exports of wlansec.dll
- WiFi Password Secrets
- Needed Skills
- Software Development in C and under Windows
- Familiarity with Windows networking
- Previous experience with RPC would be a plus
USBXHCI driver for supporting USB 3.x controllers
ReactOS currently ships with drivers for USB 1.x (OHCI/UHCI) and USB 2.x (EHCI) controllers only. More and more modern computers come with USB 3.x controllers (XHCI), so ReactOS should come with a driver for them rather sooner than later. While our USB 1.x and 2.x drivers are not yet complete and still under heavy development, this is a side project that can be implemented independently.
- 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
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.
- Skills needed
- Windows Audio Stack knowledge
- COM knowledge
Plug and Play (PnP) Storage Stack
Right now, PnP support in the storage stack is close to being 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 a 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 device 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
Bluetooth Stack
Bluetooth is an integral part of communicating with mobile devices these days. At the moment, ReactOS has no Bluetooth support. An initial Bluetooth stack for ReactOS should come with a Device Management as well as file transfer support (OBEX-FTP profile). The number of available Bluetooth stacks for Windows shows that you have a high degree of design freedom for your ReactOS Bluetooth stack, more than for most ReactOS components.
- References
- Bluetooth under Windows
- Skills needed
- Software Development in C and under Windows
- Familiarity with Bluetooth
Networking
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 paths 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 groundwork 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.
- Skills needed
- Software Development in C and under Windows
- Familiarity with Win32 APIs and Networking
- Experience with gluing code of different projects together
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 serve 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 such as 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 against the corresponding 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, guesswork 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.
- Skills needed
- Display drivers development experience
- Win32 API knowledge
System Enhancements
Audio Mixer
Implement support for mixing of audio streams.
- Benefits
- An 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. At 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 Shell extension
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.
- Benefits
- This would make our Explorer feel more 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
Taskbar Shell extensions
The shell in ReactOS lets user manager running applications, start other applications and manage files but nothing more. This idea is about implementing 3 small shell extensions for showing the state of the battery of the machine, for ejecting usb devices and implementing the quick launch toolbar. These are important requirements that we realized they are much needed while presenting ReactOS in real hardware. Not knowing the state of the battery or not being able to eject a usb flash drive is a serious usability problem. The shell extensions should be developed and tested to work on Windows.
- Benefits
- Greater control of the machine right from the GUI shell.
- Makes testing and presenting the OS on real hardware much easier.
- Greater usability by making it possible to launch applications from the quick launch toolbar.
- Skills needed
- Development in C/C++ and under Windows
- Knowledge of COM, ATL, and shell APIs would be a plus.
- Knowledge of device management APIs would be a plus.
Support for the GPT Partitioning Scheme
Currently, ReactOS relies on the traditional MBR (Master Boot Record) Partitioning Scheme for handling partitions on disks. The modern GPT (GUID Partition Table) enables ReactOS to address larger disks, support more partitions and is a requirement to boot on modern UEFI-based computers.
The student shall research into the components required for GPT support and the work that needs to be done on ReactOS. For example, some components like our kernel and mountmgr.sys already have preliminary GPT support, whereas it is non-existent in the HAL and disk.sys. At the end of the task, ReactOS shall be able to detect and use an external GPT-formatted disk. If there is still time left, the student may also add support for booting from GPT to our bootloader(s).
- Skills needed
- Development in C
- Kernel-mode development
- Prior knowledge about MBR and GPT disk structures would be a huge plus.
WebKit-based MSHTML implementation
MSHTML is the central component for rendering HTML pages in applications written for Windows. At the moment, ReactOS depends on a heavyweight Gecko-based MSHTML implementation that needs to be installed manually. By providing a lightweight WebKit-based MSHTML implementation, ReactOS could render HTML pages out of the box. This would also benefit the CHM help system, which is based on HTML files. On top of this, a simple ReactOS Browser with tabbing and bookmarks may be sufficient for some people.
- References
- MSHTML Reference
- WebKit2 API
- Benefits
- Greater usability by providing a web browser and HTML-based help system out of the box.
- No reliance on the heavyweight Gecko-based MSHTML sourced from WINE.
- Skills needed
- Development in C/C++ and under Windows
- Knowledge of COM would be a plus.
- Familiarity with WebKit would be a plus.
Improving the quality of our Registry Hive implementation
ReactOS features a basic implementation of the Windows-compatible Registry Hive format for storing system and application settings. There are two major areas where our current implementation could be improved:
- When ReactOS crashes, Registry Hives easily get corrupted and render the whole system unbootable. The reliability of the Registry Hive implementation shall be improved to make the effect of crashes less severe and also recover from partly corrupted Hives.
- Hives created by our mkhive tool are roughly compatible with the Windows format. The only part that is currently missing are the implementation of Security Descriptors. Implementing these could make the tool more usable and improve interoperability between Windows and ReactOS.
Related components in ReactOS are the cmlib library, the ntoskrnl Cm, and the mkhive tool.
- References
- "The Internal Structure of the Windows Registry", MSc Thesis by Peter Norris, BSc (Hons), MBCS: http://amnesia.gtisc.gatech.edu/~moyix/suzibandit.ltd.uk/MSc/
- Offline NT Password and Registry Editor: http://pogostick.net/~pnh/ntpasswd/
- Bug reports CORE-6762, CORE-9195 and CORE-10793.
- Skills needed
- Development in C
- Kernel-mode development
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:
- Add support for command line parameters to RAPPS. For example: "rapps install chrome" (just like your favourite Linux distro package manager) or "rapps remove msvc2010_redist" - Separate the download and install operations so that a user could choose just to download the apps into a local cache and install some or all of them later (just like Steam or NVidia's driver updaters first does Download then asks to Install, 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 front end 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
Implementation of multi-monitor support has been almost nonexistent until now. Display device drivers expose them thanks to the HwVidGetVideoChildDescriptor callback, which videoprt.sys uses to enumerate monitors attached to it then to 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 allow ReactOS to become a serious player in professional desktop applications given the increasing number of double-screen installations present in modern workspaces. Document comparison, permanently visible e-mail reader or presentation applications are just a few benefits professionals get when using multiple monitors.
- 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 are things people do in the 21st century!
- From a technical standpoint, properly supporting this feature would improve driver support and WIN32 application compatibility for 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.
Multi-Session Support
Supporting multiple sessions is a prerequisite for Terminal Services. TO BE ADDED WITH MORE DETAILS FOR GSOC 2018.
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 the trunk and starting a bunch of tests (about 10M tests) on it to make sure no 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 the years, the question of being able to catch regression patterns more or less automatically has been raised. Also, regtests provide a good performance indicator for ReactOS and evaluating their performances over commits can be critical as well.
Thus there is 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 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 developed in-house. But deep attention must be given to security and the performance 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 by directly developing a complete application to evaluate the performance of the tests over time.