ReactOS project requires students to participate in Google Summer of Code 2018

Hi, Habr!

We're glad to announce that the ReactOS operating system has been receiving slots for Google Summer of Code for the third year in a row!

In case of successful completion of the work, the participant of Google Summer of Code will receive 3,600 euros.

Who can participate?

Any undergraduate and graduate students can participate (since graduate students are considered to be PhD Students in US jurisdiction).

What needs to be done to participate?

1. Sign up for https://summerofcode.withgoogle.com/ ;
2. Choose the option of participation as a student;
3. Choose ReactOS as a participation project;
4. Describe in free form what you want to do in your proposal. More information about the design of posters can be viewed on the GSoC website , general recommendations on the postosal can be viewed at Google , and on the ReactOS wiki ;
5. Subscribe to the developers mailing list and duplicate the text from point 4 there;
6. Discuss your participation in the IRC ;
7. Take in your school Proof of Enrollment - paper that confirms that you are a student (or graduate student) of this school for the term of Google Summer of Code .

Hurry up! Submission of applications will end on March 27!

Possible ideas for participation - under the cut.

Possible ideas for participation

This year, the following ideas are offered as ideas (taken from the ReactOS Wiki and freely translated with the addition of background information):

1. Your idea. If you already know a little about the ReactOS infrastructure, then you can offer your idea for implementation within GSoC.
2. NDIS drivers for common modern versions of virtual machines. This will simplify the installation of ReactOS on the latest versions of virtual machines that no longer use network cards for which there are already drivers in the project (such as AMD PCnet, Realtek RTL8139 and NE2000).
3. The development of fundamental components to support Wi-Fi. The project now has support for open Wi-Fi networks and networks with WEP encryption , but there is no support for most of the APIs required for working with secure networks. To improve support for such networks, it is proposed to implement an API from Windows Vista +, also added in Windows XP SP3, about which you can read this link .
4. Plug-and-play support for storage stack. This will improve support for SCSI and SATA devices. It is proposed to start the task by improving the scsiport driver, and then improving PnP support in the UniATA driver.
5. Bluetooth protocol stack. Now there is no Bluetooth protocol support in ReactOS. It is proposed to start the task with the device manager and Bluetooth profile support for file transfer support (OBEX-FTP).
6. Driver for Intel High Definition Audio. ReactOS already has initial support for this specification for sound cards, and we need to finalize it so that such a driver can work on both Windows and ReactOS. Learn more about the bus interface - by reference .
7. Driver for Wine Audio. In the context of the Wine project, a driver is a module that implements a certain set of COM interfaces on top of various Linux libraries (in the context of sound, such as ALSA, OSS or PulseAudio). The presence of such a module will allow the use of the latest Wine libraries related to the sound API, will allow you to localize the entire interface in one place and make a sound stack compatible with Vista and newer Windows.
8. Audio Mixer - will improve the support for audio drivers, which prevents the absence of this component. Upon completion of this project should be able to play multiple audio streams at the same time. About Windows Audio Mixer you can read here .
9. Auto-configure proxies using PAC files (Proxy Auto-Configuration) and Web Proxy Auto-Discovery Protocol (WPAD), which will make it easier for the system to connect to local networks that use proxy servers.
10. Windows Remote Management (Windows Remote Management, WinRM ) - used for remote administration of Windows-based systems, conceptually a bit like SSH.
11. Further integration of SMB protocol support (Server Message Block, popularly known as "Network Neighborhood"). Despite the fact that Samba already exists, its code is in some places specific to Unix-like operating systems. This feature is very much in demand among new users of ReactOS (for example, transferring files from the host to the guest OS in VirtualBox is tied to support the network environment), and its implementation will lead to a general improvement in the support of the Windows network environment. As a starting point, the participant is invited to start with the Samba-TNG project. The SMB protocol specification is available here .
12. Terminal Services. One of the key components for the operation of the protocol for remote desktop connections is RDP . It is necessary to modify the existing implementation ( see the wiki for the existing functionality), complementing it with support for incoming remote desktop connections.
13. Extending ReactOS kernel test suites - covering tests of some parts of the kernel, such as the kernel cache manager, Plug and Play, and others. The main goal is in extensive testing of the Native API (a little more about it can be found here: http://hex.pp.ua/native-api.php ). As a reference, the behavior of the Windows kernel should be considered.
14. Writing tests for the Win32 subsystem. The NT kernel supports various interfaces between User-mode programs and kernel functions. Such interfaces are called subsystems, and in theory (and in practice ) you can write such a subsystem that can implement a set of APIs of another operating system. As part of this task, you will need to write various tests for the interaction between the kernel and the Win32 subsystem. As a reference implementation, it is necessary to consider the behavior of the kernel and Win32 subsystem of Windows itself. An optional task may be to launch another subsystem (such as OS / 2, or Interix ) inside ReactOS. More information about the NT kernel subsystems can be found on the English Wikipedia and in Mark Russinovich's book "Windows Internals".
15. The Windows Accessibility UI Automation API. Now this software interface is not implemented in ReactOS, although it is an important part of Windows OS, since various tools for people with disabilities are based on it (such as a narrator, for example). After the implementation of this API, the participant is invited to check his work using the open utility NVDA (Non Video Desktop Access), which helps blind people or people with visual impairments to use the computer. Also, after implementing this API, it will be offered to merge into the Wine project.
16. Expansion of the shell to search. As part of this task, you need to write a Shell Extension for ReactOS Explorer, which will search for files, since now this extension is not yet implemented. Also, this extension should provide compatible APIs for other search providers, as Windows does. You can read about shell extensions here , extensions that expand your search - here .
17. Support paravirtualization . To improve the experience of interacting with ReactOS and improve performance, it is proposed to implement some set of APIs to support various hypervisors. As part of GSoC, it is proposed to choose one of the possible areas of para-virtualization:
    
    • Get open Xen hypervisor drivers to work;
    • Implement a set of drivers that implement a subset of the HyperV hypervisor API (such improvements are also called "Enlightenments" ;
    • Improve the kernel to use VMI (virtual machine interface), the para-virtualization interface proposed by VMWare;
    • Test and integrate VirtIO drivers, or VirtualBox guest add-ons, or open-vm-tools in ReactOS.
18. Support for the recycle bin capabilities from Windows Vista (NT v6.0 +). In Windows Vista, the basket extension for the cart has been expanded, and its internal interface has changed. It is proposed within the project to document API changes and implement it in ReactOS. Windows shell can be read here .
19. Implement the MSHTML component over WebKit. As part of this project, you need to make an adapter between the WebKit API, and the MSHTML component API, which allows you to display HTML pages. You can read about the MSHTML interface here , WebKit interface - here .
20. Improve the registry implementation. To improve the implementation, two possible directions are proposed:
    
    • Improve the fault tolerance of the implementation so that the registry is not damaged if it fails;
    • Improve binary compatibility with the Windows registry. Now in the implementation of the registry are not implemented until the end of the security descriptors. Their implementation will help interoperability with Windows and improve the overall reliability of the system;
      Details of the internal structure of the registry can be found at this link .
21. Registry hive associated with performance counter data. Few know that the Windows registry has a special hive called HKEY_PERFORMANCE_DATA . This bush contains many different performance counters, but working with them can be quite inconvenient. ReactOS is currently missing this hive, and its implementation will help many applications (including those from Microsoft) to run. Learn more about how to use performance counters here .
22. Management console It is through it that almost all graphical administration utilities in Windows work. ReactOS has a rudimentary support for the management console snap-ins, and as part of this task, we need to improve this support. Read more about the management console here .
23. Support for PDB files in the implementation of the dbghelp library. These files contain debugging information for the application, and dbghelp contains the API for working with such files. Support for these files in ReactOS will allow debugging of user mode components in utilities such as WinDBG , Process Explorer, and others. About dbghelp you can read more here .
24. Cross-platform implementation of the kernel-level debugger (Kernel Debugger, KD). The Windows debugging tools (and ReactOS as well) from Microsoft are proprietary and work only under Windows. The implementation of such cross-platform utilities will allow you to debug ReactOS in kernel mode under another host OS, and also allow you to abandon the simpler debugging protocol KDBG, which is supported in builds from the GCC compiler.
25. Support for other ports for debugging ReactOS. ReactOS now supports debugging via the serial port (COM port, RS-232), although many computers no longer have such a port. Support for modern ports (such as 1394, Ethernet or USB) will help debug ReactOS on new computers, without using the Screen debug mode on them, in which everything is displayed on a computer monitor with ReactOS. As part of this task, it is also proposed to explore and implement the undocumented KDVM debugging protocol supported by Hyper-V and other hypervisors as an alternative.
26. Support error reporting. When Windows crashes, it writes its state to a memory dump, and then such a dump can be analyzed in the debugger. Support for memory dumps in ReactOS will simplify debugging and error reporting to developers. More information about memory dumps can be found here .
27. Multi-monitor support. Now in ReactOS there is support for listing monitors, thanks to the implemented API HwVidGetVideoChildDescriptor in the videoprt.sys driver. This driver then transmits the information to the Win32 subsystem driver (win32k.sys), and it is win32k.sys that decides how to display the picture on the second monitor - duplicate or expand the desktop, or not use the monitor. Implementing such an API will allow ReactOS to be used on multiple monitors, which can be very useful for developers, designers and ordinary users. More details can be read on MSDN .
28. Support for user mode print drivers. Within the Windows architecture, there are many interfaces for printer drivers (PostScript, Plotter, GDI / win32k). As part of this task, you must implement basic support for custom mode print drivers that use GDI interfaces. More information about such interfaces can be found here .
29. Multi-user support for multiple sessions. In modern Windows, this service is called "Remote Desktop Services" (Remote Desktop Services) and the implementation of support for multiple sessions will allow each user to work in their own isolated environment, starting from another user (creating a separate session) and improving compatibility with the capabilities of remote work with Windows . You can read about the remote desktop service here .
30. Web interface for developers. After switching to git, some old continuous integration utilities (such as buildbot , testman ) began to work worse with each other. Therefore, it is proposed to implement an improved version of the Web-interface for developers, which will allow you to show commits, builds, pull-requests, etc., and will be able to connect them with each other, including using search filters. This will help navigate the code base to new and old developers. Ideas for the web interface are detailed in the corresponding section of the ReactOS wiki .

As you can see, ideas for Google Summer of Code are complete. Do not miss your chance to work in an interesting project with first-class mentors and mentors in various fields. Choose any idea you like (or offer your own), register on the site and send your application!

PS Thanks to everyone who read to this point. A huge request to write about errors (grammatical, punctuation, syntax, speech, and, most importantly, actual) in a personal to me, or in our Telegram-chat .