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


    Hello, Habr!

    We hasten to inform you that the ReactOS operating system has been receiving slots on Google Summer of Code for the third year in a row!

    If the job is successfully completed, the Google Summer of Code participant will receive € 3,600.

    Who can participate?

    Any students and graduate students can participate (because in the jurisdiction of the United States graduate students are considered PhD Students ).

    What needs to be done to participate?

    1. Sign up at ;
    2. Choose an option to participate 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 proposal can be found on the GSoC website , general recommendations on proposal 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 Proof of Enrollment at your school - a paper that confirms that you are a student (or graduate student) of this school for the term Google Summer of Code .

    Hurry up! Application deadline is March 27th!

    Possible ideas for participation - under the cut.

    Possible ideas for participation

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

    1. Your idea. If you are already a little versed in the ReactOS infrastructure, then you can offer your idea for implementation within the framework of 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 the project already has drivers (such as AMD PCnet, Realtek RTL8139 and NE2000).
    3. Development of fundamental components to support Wi-Fi. Now the project has support for open Wi-Fi networks and networks with WEP encryption , but there is no support for most of the APIs needed to work with secure networks. To improve support for such networks, it is proposed to implement the API from Windows Vista +, also added to Windows XP SP3, which can be read about here .
    4. Support for plug-and-play technology for the 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 improve the PnP support in the UniATA driver .
    5. Bluetooth protocol support stack. ReactOS does not currently support Bluetooth. It is proposed to start the task with the device manager and Bluetooth profile support to support file transfer (OBEX-FTP).
    6. Driver for Intel High Definition Audio Bus. ReactOS already has initial support for this specification for sound cards, and it needs to be improved so that such a driver can work on both Windows and ReactOS. More information about the bus interface is here .
    7. Driver for Wine Audio. In the context of the Wine project, a driver is a module that implements a 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 make it possible to use the latest Wine libraries associated with the sound API, will 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 of audio drivers, which is hampered by the lack of this component. Upon completion of this project, it should be possible to play multiple sound streams at the same time. You can read about the Windows audio mixer here .
    9. Autoconfiguration of the proxy using PAC (Proxy Auto-Configuration) files and WPAD (Web Proxy Auto-Discovery Protocol), which will make it easier for the system to connect to local networks where proxy servers are used.
    10. Windows Remote Management ( WinRM ) - used to remotely administer systems running Windows, conceptually a bit like SSH.
    11. Further integration of support for the SMB protocol (Server Message Block, popularly known as the "Network Neighborhood"). Despite the fact that Samba already exists , its code in some places is specific to Unix-like operating systems. This feature is very popular among new ReactOS users (for example, transferring files from the host to the guest OS in VirtualBox is tied to supporting the network environment), and its implementation will lead to a general improvement in support for 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 running the RDP Remote Desktop Connection Protocol . It is necessary to refine the existing implementation (for the available functionality, see the wiki ), supplementing it with support for incoming connections to the remote desktop.
    13. ReactOS kernel test suite extension - tests cover 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: ). The behavior of the Windows kernel should be considered as reference results.
    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 ), one 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 of the kernel and the Win32 subsystem. As a reference implementation, it is necessary to consider the behavior of the kernel and the Win32 subsystem of Windows itself. An optional task might be to start another subsystem (such as OS / 2, or Interix ) inside ReactOS. More information about NT kernel subsystems can be found on the English Wikipedia and in Mark Russinovich’s book "Windows Internals".
    15. Windows Automation API for Accessibility. Now this software interface is not implemented in ReactOS, although it is an important part of Windows, as various tools for people with disabilities are based on it (such as a screen reader, for example). After implementing this API, the participant is invited to test his work with the open NVDA (Non Video Desktop Access) utility , which helps blind people or people with visual impairments to use a computer. Also, after implementing this API, it will be proposed for merging into the Wine project.
    16. Shell extension for search. As part of this task, you must write a Shell Extension for ReactOS Explorer that will search for files, as Now, such an extension has not yet been implemented. Also, this extension should provide compatible APIs for other search providers, as Windows does. You can read about shell extensions here , about extensions that extend the search here .
    17. Paravirtualization support . To improve the experience of interacting with ReactOS and increase productivity, it is proposed to implement a certain set of APIs to support various hypervisors. As part of GSoC, it is proposed to choose one of the possible areas of paravirtualization:
      • Make open Xen hypervisor drivers work ;
      • Implement a set of drivers that implement a subset of the HyperV hypervisor API (such enhancements are also called "Enlightenments" ;
      • Improve the kernel to use VMI (virtual machine interface), a para-virtualization interface proposed by VMWare;
      • Test and integrate VirtIO drivers , or VirtualBox guest add-ons, or open-vm-toolsin ReactOS.
    18. Support recycle bin features from Windows Vista (NT v6.0 +). In Windows Vista, the trash shell extension has been expanded and its internal interface has changed. It is proposed within the framework of the project to document API changes and implement it in ReactOS. Windows shell can be read here .
    19. Implementation of the MSHTML component on top of 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 , about the WebKit interface here .
    20. Improve registry implementation. To improve implementation, two possible directions are proposed:
      • Improve the resiliency of the implementation so that the registry does not get corrupted upon failure;
      • Improve binary compatibility with the Windows registry. Currently, security descriptors are not fully implemented in the registry implementation. 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. A registry hive associated with performance counter data. Few people know that there is a special bush called in the Windows registry HKEY_PERFORMANCE_DATA. This bush contains many different performance counters, but working with them can be quite inconvenient. ReactOS does not yet have this bush, and its implementation will help many applications (including those from Microsoft) to launch. 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 rudimentary support for snap-ins in the management console, and as part of this task, support needs to be improved. Read more about the management console here .
    23. Support for PDB files in the dbghelp library implementation. These files contain debugging information for the application, and dbghelp contains an API for working with such files. Support for these files in ReactOS will allow you to debug user-mode components in utilities such as WinDBG , Process Explorer, and others. You can read more about dbghelp here .
    24. Cross-platform implementation of the kernel level debugger (Kernel Debugger, KD). Microsoft's debugging tools for Windows (and ReactOS as well) are proprietary and work only under Windows. Implementing such cross-platform utilities will allow you to debug ReactOS in kernel mode under a different host OS, and will also allow you to abandon the simpler debugging protocol KDBG, which is supported in assemblies 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 do not already have such a port. Support for modern ports (such as 1394, Ethernet or USB) will help debug ReactOS on new computers without using the debug mode on them Screen, in which everything is displayed on a computer monitor with ReactOS. Also, as part of this task, as an alternative, it is proposed to investigate and implement the undocumented KDVM debugging protocol , supported by Hyper-V and other hypervisors.
    26. Error reporting support. When Windows crashes, it writes its state to a memory dump, and then such a dump can be analyzed in the debugger. Support for core dumps in ReactOS will simplify debugging and reporting bug reports to developers. Read more about memory dumps here .
    27. Support for multiple monitors. ReactOS now has support for enumerating monitors, thanks to the implemented HwVidGetVideoChildDescriptor API in the driver videoprt.sys. This driver then passes the information to the driver of the Win32 subsystem (win32k.sys), and it is win32k.sys that decides how to display the picture on the second monitor - duplicate, expand the desktop, or not use the monitor. Implementing such an API will allow using ReactOS on multiple monitors, which can be very useful for developers, designers and ordinary users. Read more 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 need to implement basic support for user-mode print drivers that use GDI. Read more about such interfaces here .
    29. Multi-user support for multiple sessions. In modern Windows, this service is called “Remote Desktop Services” and the implementation of support for multiple sessions will allow each user to work in their own isolated environment, start from another user (with the creation of a separate session) and improve compatibility with remote Windows capabilities . 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 display commits, builds, pull requests, etc., and will be able to associate them with each other, including using search filters. This will help new and old developers navigate the codebase. Ideas for the Web interface are detailed in the corresponding section of the ReactOS wiki .

    As you can see, there are plenty of ideas for Google Summer of Code. 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 suggest your own), register on the site and send your application!

    PS Thanks to everyone who read up to this point. A huge request to write about mistakes (grammatical, punctuation, syntactic, speech, and, most importantly, factual) in a personal email to me, or in our Telegram chat .

    Also popular now: