ReactOS
A little more than a decade ago, I came across a little project called FreeWin95, aiming to create a clone of Windows 95 in much the same way that Linux cloned UNIX. It seemed somewhat interesting, but in order to have a chance at being useful, it needed a working release and at the time it didn’t even have any code.
In 1998, the project was relaunched with the name ReactOS. This time, it aimed to produce a clone of Windows NT. Because Microsoft’s roadmap showed that it would be sticking with the NT kernel for a while (and Microsoft is still using it in Vista), this seemed more promising. As a user of Windows NT 4.0, I decided to keep an eye on it.
Over the years, ReactOS has periodically impinged on my consciousness. I haven’t used Windows seriously for a few years, but I am still rather fond of the NT kernel design. It made some very interesting design decisions, such as the ability to plug in different personalities and support different userspace kernel APIs easily. Unfortunately, it was buried under so much legacy-compatibility cruft that it never really had a chance to show off its strengths.
Over the years, the focus of ReactOS kept slowly shifting. Originally aiming to be a functional clone of Windows NT 4.0, it now incorporates some features from Windows 2000 (NT 5.0), XP (NT 5.1), and 2003 (NT 5.2).
Because ReactOS always aimed to be binary-compatible with Windows, a lot of device drivers can be used directly without modification. While they can’t use any of the Microsoft-supplied drivers for generic hardware, one of the strengths of Windows is that there is a plethora of third-party driver support. Things like nVidia’s display drivers can be used to provide 3D acceleration to applications, as shown off by running Unreal Tournament on ReactOS. It should be noted, however, that this can only be managed with a little patching of the nVidia driver binaries.
Not all drivers will work correctly. While most of the interfaces are identical, some parts are very different. The cache controller and memory manager are completely unlike their Windows NT counterparts, preventing some drivers from working.
Another group has overlapping, if somewhat different, goals to ReactOS. The WINE project aims to provide replacements for most of the userland libraries found on a Windows system. A significant amount of code sharing goes in between the two projects. Some components from WINE can be re-used directly in ReactOS. Some can be used with a few minor changes, and some are superfluous. GUI applications, for example, are run on the native display, and so GDI calls don’t need to be turned into X11 calls.
This code sharing is not all one-way. Code from ReactOS has found its way into various driver wrappers for Linux, such as NDISWrapper for WiFi drivers and Captive for NTFS support. The GNU toolchain for Windows has similarly benefited from contributions by ReactOS developers, as has QEMU. WINE, of course, also accepts some patches.
In spite of ten years of development, ReactOS is still considered "alpha" quality. It works reasonably well in emulated or virtualized environments, but hasn’t been tested on much real hardware. In spite of this, it is capable of running a variety of Windows software, including large applications like OpenOffice quite well. In a few years when support for Windows XP runs out and businesses are looking to migrate, ReactOS might be a good solution.