ReactOS still installs to FAT by default and still calls itself alpha

The installer only accepts FAT16 or FAT32, and Setup will format the volume

By default ReactOS can only be installed on a machine that has a FAT16 or FAT32 partition as the active, bootable partition. The partition ReactOS is installed onto, which may or may not be the bootable one, must also be formatted FAT16 or FAT32, and ReactOS Setup can format the partitions if needed. There is no NTFS destination in that path, so a dual-boot plan has to preserve a FAT partition instead of repurposing an existing Windows volume, and the offer to format means a wrong click at the partition step takes the volume with it.

BtrFS became an option in 0.4.10, and the project calls it experimental while warning that regressions not triggered on a FAT setup may be observed. That warning matters more than it first reads, because a BtrFS install exercises a different driver, a different allocation path, and a different recovery story than the FAT path everyone else reports against. If you take the experimental route, budget for a filesystem problem that no existing bug report will match.

Alpha quality is stated as a data-loss warning, not a version number

The product quality warning says ReactOS is currently an Alpha quality operating system, that it is under heavy development, and that you have to be ready to encounter problems. It goes further: different things may not work well and it can corrupt the data present on your hard disk. The recommendation that follows is to test on a virtual machine or on a computer with no sensitive or critical data.

That is the project's own estimate of its failure modes, and it is worth reading literally rather than as boilerplate. A filesystem driver that misbehaves is exactly the kind of bug that damages a disk, and the warning is about your disk, not your session. The README describes installing by extracting the boot CD archive, burning the image, booting from it and following the instructions.

The compatibility target is Server 2003, not the NT4 through 7 range it advertises

Two different claims sit next to each other in the project description. One says ReactOS is an effort to develop a quality operating system compatible with applications and drivers written for the Microsoft Windows NT family, and it names NT4, 2000, XP, 2003, Vista and 7. The other says the project, although currently focused on Windows Server 2003 compatibility, is always keeping an eye toward Vista and future NT releases.

Read together, they mean the driver and application surface people actually test is Server 2003 era, and the longer list is intent rather than a claim about what runs. For a reader, the difference decides which applications are worth trying: software from the XP and 2003 era is in scope, software written for Vista or 7 is a research project.

The user-mode half is WINE, which is why WINE is not the alternative here

ReactOS is explicit that it is not another wrapper built on Linux like WINE, and that it does not attempt or plan to compete with WINE. It then explains that the user-mode part of ReactOS is almost entirely WINE-based, and that the two teams have cooperated closely in the past. Read that as a division of labour: the user-mode stack, where applications live, comes from the WINE codebase, and the original work is the kernel and driver side underneath it.

The consequence is that application compatibility decisions are largely inherited rather than researched from scratch, so an application that runs under WINE has a plausible path here, and the two projects diverge mainly where the kernel and driver model differ. The other half of the same paragraph sets expectations for anyone arriving from a Linux distribution: the project states it is not yet another OS and does not attempt to be a third player, and that people are not meant to uninstall Linux and use ReactOS instead. It is aimed at Windows users who want a Windows replacement that behaves like Windows.

The tree splits into a kernel side and a user-mode side, with no published compatibility score

The top level shows the shape of the work. `ntoskrnl/`, `win32ss/`, `hal/` and `drivers/` hold the kernel, the Windows subsystem layer, the hardware abstraction layer and the driver set. `base/`, `dll/`, `sdk/`, `subsystems/` and `modules/` hold services, libraries and interfaces. Build control sits in `CMakeLists.txt` and `CMakePresets.json`, with three toolchain files, `toolchain-gcc.cmake`, `toolchain-msvc.cmake` and `toolchain-clang.cmake`, plus `overrides-gcc.cmake` and `overrides-msvc.cmake`.

One entry is more interesting than it looks: `apistatus.lst` sits at the top level next to the build files, the kind of place a project tracks which Windows APIs exist in the tree. Its format is not explained in the visible README. Anyone planning to run a specific application should count the APIs that application needs rather than assume that a version number implies coverage.

RosBE or MSVC 2019+, and the build tree hands you five commands

To build the system the project strongly advises using the ReactOS Build Environment, with up-to-date versions for Windows and Unix, GNU-Linux, available from the build environment download page. Microsoft Visual C++ 2019 or newer is the documented alternative. The README then reduces the actual work to a configure step and Ninja: you run the configure script in the directory where you want the build files, choosing the script that matches your system, then build one module or all of them.

configure.cmd
configure.sh
ninja
ninja <modulename>
ninja bootcd

The boot target produces a CD image named `bootcd.iso`, and for people who only want to try the system, daily builds of bootable images are published on a separate page, which is a better starting point than building. The `toolchain-clang.cmake` file in the tree suggests a third route, but the README names only RosBE and MSVC, so treat Clang as undocumented rather than supported. Cloud-based development is offered through Gitpod, and the repository carries a `.gitpod.yml` and a `.gitpod.Dockerfile` for it.

Tagged releases are years apart while the tree moves daily

The release history explains why daily builds matter. Version 0.4.14 shipped in December 2021, 0.4.15 in March 2025, and 0.4.16 in August 2026. That is roughly three and a half years between the first two, then about seventeen months, while the last push to the default branch landed on 1 November 2026, so the work is continuous and the releases are not.

For a reader this decides where to point a virtual machine. A tagged ISO can be many months behind the tree that fixes the bug you are hitting, so a daily build is closer to what the project believes works today, at the cost of being untagged. The same gap shows in what gets funded: the README says donations are relied on to maintain the servers and to accelerate development by hiring full-time developers. The git history is the fast signal here, not the version number.

Contributors who have read leaked Windows source are turned away on principle

The contributing section carries a legal notice that deserves to be read before anyone sends a patch. If you have seen proprietary Microsoft Windows source code, including the leaked Windows NT 3.5, NT 4 and 2000 source code and the Windows Research Kernel, your contribution will not be accepted because of a potential copyright violation.

That constraint has a visible cost. Behaviour that exists only in the original source and not in public documentation has to be reconstructed from observation and reverse engineering, and a large amount of it will be approximated. It also shapes where discussion happens: the README states that the JIRA bug tracker is not for discussions and points people to the official chat and the forum instead, which means a compatibility question rarely becomes a searchable artifact. Bug reports are expected to be checked against JIRA first and filed with logs and as much information as possible, so the tracker is a record of defects rather than a record of what ReactOS can run.

Editorial conclusion

ReactOS suits someone who needs to run a specific legacy Windows binary or driver, who has a spare machine or a virtual machine, and who accepts that they are the test case. It does not suit a daily driver, a machine holding data you care about, or anyone expecting Windows 7 behavior. Before you install, confirm the target partition is FAT, read the alpha warning again, and check the daily build rather than the last tagged release.

Frequently asked questions

Official sources

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