ReactOS Hits a Real Milestone: Half-Life Runs In-Game on Open-Source Windows

ReactOS just cleared a bar that a lot of people probably assumed it would never reach: running Valve's original Half-Life past the menu and into actual gameplay. The project's developers announced on X on 10 June 2026 that the Windows build of Half-Life now runs on their open-source operating system, with community user "Zombiedeth" providing the footage and the hardware details.

This matters because of what ReactOS actually is. It is not a Linux distribution with a Windows theme. It is a from-scratch reimplementation of the Windows NT architecture, aiming for binary compatibility with Windows applications and drivers at the kernel and Win32 subsystem level. You take an unmodified Windows executable, drop it on ReactOS, and the goal is that it just runs. That is a far harder problem than Wine faces, because Wine sits on top of a working Linux kernel and only has to translate the userspace API calls. ReactOS has to be the kernel, the driver model, the graphics stack, and the Win32 personality all at once.

Why Half-Life is a meaningful test case

Half-Life is a 1998 title, so from a raw performance standpoint it asks almost nothing of modern silicon. But it is a brutal compatibility test. The GoldSrc engine touches a lot of the Windows surface area that tends to be incompletely implemented in clean-room reimplementations: DirectDraw and Direct3D paths, WinMM for audio, DirectSound, raw input handling, and the registry plumbing the Steam-era and retail builds expect. A game initializing is one thing. People have reported Half-Life at least reaching its loading stages under ReactOS in past years. Getting it to render a level, respond to input, and stay alive long enough to walk Gordon Freeman through Black Mesa is a meaningfully harder result, because every one of those subsystems has to be correct enough at the same time.

That is the distinction the developers are drawing here. Initialization exercises the loader and a handful of API stubs. In-game means the full frame loop is working: input polling, audio mixing, the 3D rasterization path, and timing all holding together without a crash.

The hardware it ran on

The detail that stood out to me is how ordinary and how old the test rig is.

Component	Spec
System	Dell OptiPlex
CPU	Intel Core i5-2400 (Sandy Bridge, 4 cores, 3.1 GHz base)
GPU	NVIDIA GeForce 8400 GS
Era	CPU ~2011, GPU ~2007

The Core i5-2400 is a 2011-era Sandy Bridge part, a 95W quad-core that still turns up constantly in surplus office desktops and homelab parts bins. The GeForce 8400 GS is older still, a low-end Tesla-architecture card from around 2007. That pairing is significant for ReactOS specifically. The project's driver compatibility leans on real Windows drivers in many cases, and older, simpler GPUs with well-understood XP-era driver stacks are far more likely to load cleanly than anything modern. Nobody is running a current Ada or RDNA card here, and that is the point. ReactOS targets the Windows Server 2003 / XP driver model, so 2007-vintage silicon with mature INF-based drivers is exactly the sweet spot.

For anyone with a shelf of retired OptiPlex and similar small-form-factor machines, this is a relatable platform. These are the boxes that get repurposed as Proxmox nodes, Pi-hole hosts, and NAS heads. Seeing one boot ReactOS and run a Half-Life session is a fun reminder that the cheap, abundant end of the used hardware market is where a lot of this experimentation actually happens.

Putting the milestone in perspective

Nobody should read this as ReactOS being a practical daily gaming OS. If your goal is simply playing Half-Life, the path of least resistance is trivial today. The native Linux build via Steam works, the Source remaster exists, and Wine plus Proton handle the original cleanly on basically anything. ReactOS itself shares a substantial amount of code with Wine for the userspace Win32 implementation, so a lot of the application-compatibility heavy lifting is a collaborative effort between the two projects.

What makes this notable is the trajectory. ReactOS has been in active development for 28 years, which is the kind of timeline that wears down most volunteer projects. The alpha label has stuck around for a long time, and progress on the graphics and driver side has historically been the slow part. A demanding-enough commercial game reaching playable state on the GPU path is a concrete, demonstrable sign that the hardest subsystems are maturing, not just the file manager and the calculator.

Where this fits for the hardware crowd

If you want to reproduce this, the lesson from Zombiedeth's setup is to stay period-correct. ReactOS rewards old, well-documented hardware:

• Stick to GPUs from the XP/Vista era where the original Windows drivers are simple and stable. The GeForce 8400 GS and its 8000/9000-series siblings are a known-reasonable bet.
• Sandy and Ivy Bridge desktops are plentiful, cheap, and have predictable chipset support, making them low-risk test beds.
• Run it on bare metal where you can, since GPU passthrough and the 3D path are exactly the parts that benefit from real hardware rather than a virtualized display adapter.

The broader pattern here is the same one that keeps homelab hardware interesting long past its retail relevance. A 15-year-old CPU and an 18-year-old GPU, the kind of parts that cost almost nothing secondhand, are still doing useful and genuinely novel work. ReactOS reaching playable Half-Life is a small result in absolute terms, but it is the kind of incremental win that, stacked over enough years, is how a clean-room Windows reimplementation slowly becomes real. The source is all on GitHub for anyone who wants to follow the driver and graphics work directly.