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

From ReactOS Wiki
Jump to: navigation, search
(Pierre says Dokan is cool enough)
Line 101: Line 101:
== Drivers ==
== Drivers ==
=== IFS Wrapper Driver ===
NT IFS drivers for alternate filesystems are relatively scarce, due partially to the complexity of the IFS interface and the lack of documentation for several years.  A FUSE implementation for Windows is also not ideal compared to a genuine kernel mode IFS driver.  A kernel mode wrapper IFS driver can however considerably ease development of filesystem drivers on Windows. A demonstration implementation using code derived from NTFS-3G would provide the foundation for future drivers for other non-Windows filesystems and also a testbench for ReactOS’ own filesystem library interface.
* Future efforts to allow Windows NT to read/write to other filesystems such as ZFS would be considerably eased with a wrapper driver.
* [http://msdn.microsoft.com/en-us/library/ff548143(v=VS.85).aspx Installable File System Design Guide]
* [http://msdn.microsoft.com/en-us/library/ff548099(v=VS.85).aspx Installable File System Kit Samples]
* [http://www.tuxera.com/community/ntfs-3g-download/ NTFS-3G driver & library]
;Skills Needed
* Driver development experience.
* Filesystem development experience.
=== NT "Wine audio" driver ===
=== NT "Wine audio" driver ===

Revision as of 19:05, 22 February 2015

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

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

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.


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.

Develop a spam honeypot

Useful for: End users

In spite of the deployement of various anti-spam features (including captchas and backlists), ReactOS forum has been the target of repeated spam attacks. These attacks ruined the good shape of boards while requiring extensive time from our admins. The idea here is to attempt a third strategy against spam to allow to automate the fight against spam. The student would have to develop a simple honeypot where spambots could spam providing major information: IP address, email address and message. This done, we could then automatically feed our backlist database for Drupal and phpBB not on assumptions but on facts.

Skills needed
  • PHP/MySQL development
  • Basic knowledge of phpBB & Drupal

This project should be easily completed by a student. This should offer him a bit of time to go into deeper features, described below.


If the student goes fast enough, two options are available for him. He can either develop an admin database so that we can easily review spam data in case of user complain, or he can start thinking about integrating the honeypot with our Drupal & phpBB and evaluation early performances of it. Third option is also available if he has suggestions!

Usability enhancement

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:

  • 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 language



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

GUI 1st Stage Installer

To make ReactOS more user friendly for installation, a GUI installation instead of a rather limited text-mode installer is needed. This could be run off of the LiveCD and act as a frontend to the disk formatter and installer we already have implemented.

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.


SSH Service

Implement a native Windows service for accepting SSH connections and authenticating with Windows accounts to allow the user to interact with Windows through the command prompt should they not need access to the GUI shell. Once authenticated, any commands passed through SSH are executed using the user's credentials to prevent abuse of the service's privileges. And as the user is not technically logged in, there are no restrictions with respect to how many connections are permitted except as system resources allow.

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

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.

Terminal services support would allow ReactOS to service as a terminal server/thin client server. Organizations that wish to provide a shared workstation with Windows would have a free alternative that does not have complex licensing terms covering multi-session usage. The display driver for terminal services can also be used to support fast user-switching and even possibly multi-monitor support.
Skills Needed
  • Network development experience.
  • Driver development experience.
  • Knowledge/familiarity with RDP protocol.


NT "Wine audio" driver

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.

  • 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.
Needed Skills
  • Windows Audio Stack knowledge
  • COM knowledge


Kernel mode test suite

Improve our existing kernel mode test suite 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.

  • 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

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.

  • Improved stability.
  • More information about undocumented behavior.
  • Improved compatibility with third party drivers.
Needed skills
  • Display drivers development experience
  • Win32 API knowledge


Wine-based Win32 subsystem (Arwinss)

There is a proof of concept done which shows the possibility to reuse majority of Wine code for implementing user32.dll, gdi32.dll and win32k.sys, which would be binary compatible enough to ultimately work even in native Windows. However, the Arwinss branch is based on an now old Wine architecture and old ReactOS GDI code. The goal of this task would be to:

  • "update" Arwinss branch to the newest Wine 1.7 architecture (including DIB engine and other changes)
  • bring in changes from ReactOS win32k graphic code which happened after Arwinss was last updated
  • find the source and fix a well defined set of Arwinss-specific bugs
  • Greatly superior application compatibility level
  • Improved usability
Skills Needed
  • Good knowledge of C language
  • Familiarity with Win32 and GDI APIs
  • Generic knowledge of Windows NT architecture
  • Knowledge of core principles of Wine architecture

Conduct a performance review and estimate performance improvements strategies.