ReactOS: a from-scratch Windows NT clone, still at Alpha

What ReactOS actually is, and who it is for

ReactOS is an operating system, not a compatibility layer. The README is explicit about this: it is "not another wrapper built on Linux, like WINE." The difference matters. WINE runs Windows binaries on top of a Linux kernel and reimplements the Win32 API in user space. ReactOS reimplements the kernel side too, from ntoskrnl down through the HAL and the driver model, so that a Windows driver can be loaded by the system rather than translated by a shim. The target is the Windows NT family: NT4, 2000, XP, 2003, Vista and 7 are named in the README, with Windows Server 2003 as the current compatibility focus.

The audience follows from that design decision. Someone who wants to run one old Windows program on a modern Linux box has WINE and does not need ReactOS. Someone who wants to understand how a Windows NT kernel is structured, who wants to write or debug a driver against a transparent codebase, or who wants a Windows-shaped system they can modify freely, has a reason to look at this. The README also frames it as "a replacement for Windows users who want a Windows replacement that behaves just like Windows," which is the long-term ambition rather than the current state.

How the NT architecture is reproduced in C

The repository layout tells you how the system is assembled. At the top level you find ntoskrnl/, hal/, win32ss/, drivers/, subsystems/, sdk/, dll/, base/, boot/ and modules/. That is a recognisable NT split: the kernel, the hardware abstraction layer, the Win32 subsystem, the driver tree, the environment subsystems, the public SDK headers, the user-mode libraries, the base user-mode programs, and the boot chain. A CMakeLists.txt at the root plus configure.cmd, configure.sh and separate toolchain files for GCC, Clang and MSVC drive the build.

The user-mode side leans on WINE. The README states that "the user-mode part of ReactOS is almost entirely WINE-based" and that the two teams have cooperated closely. So the architecture is hybrid in a specific way: kernel, HAL, driver model and the Win32 subsystem are original ReactOS code, while a large block of the user-space DLLs derives from WINE. Anyone evaluating the project should read that sentence carefully, because it means the compatibility surface is not uniformly maintained by one team.

The build system is CMake wrapped in a configure step. The README says to run configure in the directory where you want build files, then use ninja with a module name or with no argument to build everything. apistatus.lst at the root tracks API implementation status, which is the closest thing to a coverage map the repository exposes.

Building ReactOS with RosBE or MSVC

The README strongly advises the ReactOS Build Environment (RosBE), with versions for Windows and for Unix/GNU-Linux on the project's Build Environment wiki page. Microsoft Visual C++ 2019 or later is the documented alternative. After configure, the build itself is Ninja. This block assumes you are already inside a configured build directory, which is what the README describes:

ninja

Running Ninja with no module name builds all modules. To build one module instead, pass its name as the argument, per the README's instruction to "run ninja <modulename>". To produce an installable image rather than a tree of binaries, the README gives a separate target:

ninja bootcd

The README states this creates a CD image named bootcd.iso in the build directory. That file is what you boot from. If you do not want to build at all, the project publishes fresh bootable images on its Daily builds page, and release builds are linked from the download page.

Installing ReactOS on VirtualBox, VMware or real hardware

The installation constraint is the first thing to check, and the README states it plainly: by default ReactOS can only be installed on a machine whose active, bootable partition is FAT16 or FAT32. The partition ReactOS itself goes on must also be FAT16 or FAT32, and Setup can format partitions if needed. Since 0.4.10 the BtrFS file system is an option, but the README calls it experimental and warns that regressions not seen on FAT setups may appear. NTFS is not offered as an installation target in the README text.

The documented procedure is short: extract the archive contents, burn the CD image, boot from it, and follow the instructions. The Installing ReactOS wiki page and the INSTALL file in the repository carry the detail the README leaves out.

# from the wiki: boot the burned bootcd.iso, then run Setup

For a virtual machine, the practical reading of the README is the same as for hardware: give the VM a FAT-formatted virtual disk and boot the ISO. The project's own warning is the strongest guidance here, and it is worth quoting rather than paraphrasing: ReactOS is Alpha quality, and it "can corrupt the data present on your hard disk." The README recommends a virtual machine or a computer with no sensitive or critical data. If your goal is simply to see the desktop, a VM is the only sensible first step.

The Alpha warning is the main limitation

The README's product quality warning is not boilerplate. It says ReactOS is currently Alpha, that it is under heavy development, and that different things may not work well. Data corruption on the hard disk is listed as a possible outcome. That single sentence rules out a large set of use cases: production desktops, anything holding the only copy of a file, and any machine you cannot afford to reimage.

There is a second limitation that the README does not resolve. The compatibility target is Windows Server 2003, with Vista and later described as something the project keeps "an eye toward." Applications that depend on newer Windows behaviour, on modern driver signing, or on APIs introduced after that era are outside the stated target. The README does not claim otherwise, and it does not publish a percentage of working applications.

A third constraint is architectural. Because the user-mode libraries are largely WINE-derived, a bug you hit in a user-space DLL may be a WINE bug with its own upstream, and a fix may not belong in this repository. That is a consequence of the design, not a defect, but it changes where you file the report.

ReactOS next to WINE: different layer, different job

The obvious comparison is WINE, and the README makes the distinction itself. WINE is a compatibility layer that lets Windows programs run on Linux; ReactOS is an operating system with its own kernel that aims to be binary-compatible with Windows at the driver level as well as the application level. If you need to run a Windows application on an existing Linux workstation, WINE is the right tool and ReactOS is not, because ReactOS is not something you install on top of your current system.

A second alternative for many readers is simply a virtual machine running Windows. That gives you real compatibility and none of the Alpha risk, at the cost of a licence and the loss of any ability to read or modify the kernel. ReactOS offers the opposite trade: full source under GPL-2.0 and a kernel you can rebuild, in exchange for incomplete compatibility and the data-loss warning.

The README is careful to say ReactOS does not attempt to compete with WINE, and that people are not meant to uninstall Linux and switch. Treat the two as answering different questions rather than as rivals.

Licence, releases and the cost of staying current

The code is under GNU GPL 2.0, and the repository carries COPYING plus several additional licence files (COPYING.ARM, COPYING.LIB, COPYING3, COPYING3.LIB), which suggests some components are under different terms. Anyone redistributing ReactOS or a modified build should read those files rather than assume a single licence covers the whole tree. This is a description of what the repository contains, not legal advice.

The release cadence is visible in the tags: 0.4.16 in August 2026, 0.4.15 in March 2025, and 0.4.14 in December 2021. That is roughly a year and a half between the two most recent releases, and more than three years before that. The repository's default branch is master and the last push was on 2026-09-21, so development activity on the branch is continuous even though tagged releases are infrequent. If you track master rather than a release, expect the usual cost of tracking a moving branch in an Alpha codebase: rebuilds that break, and no stability promise between tags.

Contributors face one non-technical constraint the README states directly. If you have seen proprietary Microsoft Windows source code, including the leaked NT 3.5, NT 4 and 2000 sources or the Windows Research Kernel, your contribution will not be accepted because of potential copyright violation. That is a clean-room requirement, and it applies before any code review.

Editorial conclusion

Adopt ReactOS if you want to study or test a clean-room NT implementation and you can keep it inside a virtual machine or a spare disk. Do not adopt it as a daily driver or as a place to keep data, because the README states it is Alpha and can corrupt the data on your hard disk. Before you commit, verify the current release notes on the download page, confirm the FAT16 or FAT32 partition layout your target machine actually has, and check the JIRA tracker for the specific failure you care about.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. reactos/reactos on GitHub
4. README
5. Releases