Google Summer of Code 2011 Ideas
- 1 Hardware Compatibility
- 2 Networking
- 3 System Enhancements
- 4 UI Enhancement
Support running and booting of ReactOS on EFI systems instead of BIOS systems. This would allow running ReactOS on Intel Macs and other systems that do not use BIOS. Support must be added to freeloader and the ReactOS HAL. Lack of the VGA BIOS must be addressed as the ReactOS boot process relies heavily on one being present for display during the boot process.
Ability to boot natively on Intel Macs would provide ReactOS with a relatively stable hardware platform for testing purposes thanks to Apple's hardware design philosophy. It would also present Mac users with another alternative to running Windows applications.
Implementation of a Hardware Abstraction Layer that can interact with the ACPI interface for power management and device configuration.
Most modern motherboards possess ACPI support. ReactOS’ system components are ACPI aware but cannot truly use ACPI until the hardware abstraction layer supports the specification. Proper power management would require that the OS support ACPI and until the entire hardware interface stack in ReactOS has support implemented, ReactOS will be limited to running in a compatibility mode.
- ACPI specification: http://www.acpi.info/spec.htm
- The ACPI Component Architecture documentation: http://www.acpica.org/documentation/
Serial Over USB
Implement a driver for USB/serial debugging support. With the decreasing number of systems with a serial port, another mechanism for outputting debug information is needed. A low level USB driver that can output in serial format would help expand the number of platforms that can be used test ReactOS on. USB to serial adapters are quite prevalent, but outputting debug information out a USB port requires bypassing the need for traditional drivers or even a USB stack. This driver will serve a similar role as the current KDCOM driver.
- USB Open Host Controller Interface specification: ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf
- FTDI FT232R datasheet: http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232R.pdf
- Prolific PL2303 datasheet: http://www.prolific.com.tw/eng/downloads.asp?ID=23
Besides cygwin, few options are available for users who wish to remote into a Windows machine for simple commandline 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 rely on Linux remote desktop applications that require relaxing RDP security on the Windows systems.
Implement support for terminal services, allowing inbound remote desktop connections to ReactOS. This requires implementation of a video driver able to handle output to multiple window sessions.
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.
IFS Wrapper Driver
Future efforts to allow Windows NT to read/write to other filesystems such as ZFS would be considerably eased with a wrapper driver.
- Installable File System Design Guide: http://msdn.microsoft.com/en-us/library/ff548143(v=VS.85).aspx
- Installable File System Kit Samples: http://msdn.microsoft.com/en-us/library/ff548099(v=VS.85).aspx
- NTFS-3G driver & library: http://www.tuxera.com/community/ntfs-3g-download/
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.
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.
- 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
Implement support for user permissions based on Access Control Lists.
This will allow separation of users into groups and better control over user privileges in ReactOS. Security controls will then allow supporting multiple users on the same system.
Implement the Adobe Type Manager Font (atmf) driver for text rendering. Currently text rendering is done by copying glyphs onto bitmaps verbatim instead of using the information provided by font glyphs to properly draw them. A display driver implements several GDI functions for loading and correctly drawing text based on their glyphs.
The Win32 architecture provides an interface in which display drivers of various types can implement support for various rendering styles. A font driver would provide a testbench against that interface, which can then be fixed to add support for not only conventional display drivers for video output but also print drivers that may support special formats not supported by the baseline Win32.
- GDI functions implemented by printer and display drivers: http://msdn.microsoft.com/en-us/library/ff566549%28VS.85%29.aspx
Implement support for loading and applying global themes. The current support provided for themes is incomplete and does not follow the design in Windows to begin with. The classic Windows 2000 theme does not rely on theme support and is in fact a "default" look for when no themes are present.
Implementing the theme service would allow greater customization of ReactOS' user interface and open the OS up to interface designers that wish to experiment on Windows but do not have access to a Windows license. The work would also benefit Wine by providing another testbench against which our respective theme implementations could be compared against.
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 live CD 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.