2026 年 7 月 5 日，ReactOS 的 nightly 构建在真实硬件上跑通了 Half-Life 2。
这个 2004 年发售的游戏，在一个 30 年历史的开源操作系统项目上，以原生二进制兼容的方式运行——没有 Wine，没有虚拟机，没有翻译层。一块 GeForce GTX 960 通过 NVIDIA 368.61 版 Windows 驱动程序完成渲染。Creative Sound Blaster Audigy 声卡负责音频输出。
对 ReactOS 社区而言，这不是一个简单的好奇心实验。这是对项目核心架构主张的一次验证。
ReactOS 到底是什么
ReactOS 是一个从零开始重写的 Windows NT 兼容操作系统。它的目标是二进制兼容：Windows 应用程序和设备驱动在 ReactOS 上不做任何修改就能直接运行。
理解这个项目，需要把它和 Wine 区分开。Wine 运行在 Linux 或 macOS 内核之上，实时将 Windows API 调用翻译成 POSIX 等效调用。它是一个兼容层，不是一个操作系统。
ReactOS 的做法不同。它自己实现了 NT 内核、驱动模型（KMDF/WDDM）、Win32 子系统（kernel32.dll、gdi32.dll、user32.dll）以及大量系统库。当一个 Windows .exe 运行在 ReactOS 上时，它的调用路径与在 Windows 上结构一致——从用户态 DLL 一路向下，经过 ReactOS 自己的系统调用接口，最终抵达 ReactOS 的 NT 内核。
这一区别是 ReactOS 存在的全部理由。Wine 把 Windows API 翻译给 Linux 内核。ReactOS 则直接提供一个 Windows 内核。
项目的起源可以追溯到 1996 年的 FreeWin95 项目。目标是做一个 Windows 95 的克隆。两年后，这个项目在只有讨论、没有代码的状态下解散。Jason Filby 接手后，将目标转向 Windows NT，项目更名为 ReactOS，原则从「先讨论设计」改为「先写代码」。
2006 年，一场代码审计风波迫使项目暂停超过一年——有人指控部分代码可能来自对 Windows 二进制文件的反汇编。ReactOS 随后确立了严格的 clean-room 逆向工程策略：只能通过公开的外部行为观察来推导实现，不得接触微软源代码。这一约束至今仍然有效。
技术突破的时间线
2026 年上半年的三次突破，构成了 ReactOS 图形兼容性最密集的进展期。
3 月——WDDM 和 KMDF 落地。 ReactOS 首次实现了 Windows Display Driver Model 和 Kernel-Mode Driver Framework。这两个子系统是 Windows XP 时代 GPU 驱动程序能够加载的前提。在此之前，NVIDIA、AMD、Intel 的 Windows 驱动要么加载失败，要么在初始化阶段崩溃。WDDM/KMDF 实现后，项目宣布 Windows XP/Server 2003 时代的 GPU 驱动兼容率达到约 90%。
6 月——Half-Life 进入游戏。 社区成员「Zombiedeth」在 Dell OptiPlex 台式机（Intel Core i5 2400 Sandy Bridge + NVIDIA GeForce 8400GS）上成功运行了初代 Half-Life。这证明了 ReactOS 的 Win32 图形子系统、NT 内核、OpenGL ICD 驱动栈能够在真实硬件上协同完成 3D 渲染。GoldSrc 引擎使用 OpenGL 2.1，它的运行意味着整个调用链——从 user32 到 gdi32 到内核模式驱动——都达到了功能完备的程度。
7 月——Half-Life 2 流畅运行。 不到一个月后，ReactOS 用户 Aotori Hibiki 在 YouTube 上传了 HL2 的实机演示。使用的 nightly 构建搭配 GeForce GTX 960 显卡，游戏内表现正常。HL2 使用 Source 引擎，渲染路径依赖 DirectX 9——shader model 2.0 到 3.0，动态度阴影贴图，HDR 光照管线。相比 GoldSrc 时代的 OpenGL 固定管线，这是一个复杂度高出一个量级的图形负载。
Half-Life 2 为什么是标志性基准
选择 HL2 作为兼容性基准并非偶然。Source 引擎是 2004 年 PC 游戏的技术分水岭：它将 DirectX 9 的可编程 shader 管线推到了主流消费级硬件上。运行 HL2 意味着操作系统需要正确支持以下全部子系统：
- Direct3D 9 运行时与相应的 DDI 接口
- 顶点 shader 与像素 shader 的编译和执行
- 纹理采样与混合状态管理
- 深度缓冲与模板缓冲操作
- 多 pass 渲染与渲染目标切换
这些功能中任何一个的 API 行为偏差——包括微软自己实现中的非预期行为——都可能直接导致渲染错误或崩溃。HL2 在这条路径上通过了，说明 ReactOS 的 DirectX 兼容性已经从「能初始化」进化到了「能承受真实游戏负载」。
与 Wine 的路径分歧
这是一个常被混淆的问题，值得再展开一次。
Wine 做的是用户态 API 翻译。一个 Windows 程序调用 CreateFileW，Wine 拦截这个调用，将其转换为 Linux 的 open 系统调用。这个过程在用户空间完成，内核不参与 Windows 语义的理解。
ReactOS 做的是内核级兼容。同一个 CreateFileW 调用，在 ReactOS 上走的是 ReactOS 自己实现的 kernel32.dll → ntdll.dll → 系统调用 → NT 内核的完整路径。结构和 Windows 一致。
这两种路径的优劣取决于使用场景。Wine 的优势在于依靠成熟的 Linux 内核获得稳定性、安全性和现代硬件支持。ReactOS 的优势在于能够运行依赖内核模式驱动的软件——比如杀毒软件、磁盘工具、以及需要真正 Windows 驱动栈的硬件外设。
对于 Half-Life 2 来说，差异更加具体。Wine 通过翻译层将 DirectX 9 调用转换为 OpenGL（通过 wined3d）或 Vulkan（通过 DXVK）。ReactOS 则直接使用 NVIDIA 的 Windows 驱动来执行 DirectX 9 的原生路径。两者的性能特征和兼容性范围天然不同。
实际意义与局限
能给 Half-Life 2 提供 30fps 以上的可玩帧率是一个工程成就。但这不意味着 ReactOS 已经是一个日常可用的操作系统。
项目本身仍然处于 alpha 阶段。官方推荐仅用于评估和测试。当前的兼容性目标锁定在 Windows Server 2003（NT 5.2），这意味着一大票现代软件——从 Chrome 最新版到 Adobe Creative Cloud，从 DirectX 11 游戏到任何需要 UWP 运行时支持的应用——都不在当前的覆盖范围内。
3D 游戏的运行依赖的大多是那些在 2004 到 2010 年间发布的、可独立通过 DirectX 9 路径渲染的标题。现代游戏需要的 DirectX 12、Vulkan、以及对应的 WDDM 2.x 驱动模型，都是 ReactOS 短期无法触及的领域。
但路径已经清晰了。WDDM 1.0 跑通了。NT6 系统调用的第一步迈出去了。30 年前从零开始的 NT 内核重实现，如今可以承载一个有图形管线、有声音输出、有输入响应的完整 DirectX 9 游戏。
30 年后，离「日常可用」还有多远
ReactOS 的 30 年开发历程在开源历史上是一个异常值。很少有志愿项目能够在没有企业赞助的情况下，维持如此长时间、如此高架构野心的工程投入。
2025 年 3 月发布的 0.4.15 是项目历史上 commit 数最多的稳定版本，主要由 Carl Bialorucki 领导。他随后在 2025 年 5 月被 ReactOS Deutschland e.V. 聘用为全职合同开发者——对于这个几乎完全依赖志愿劳动的项目来说，这是一个结构性的变化。
0.4.16 的路线图包括将 nightly 构建整合为统一 ISO、改进安装程序、以及持续扩展驱动兼容性。NT6 系统调用的实现工作也已经启动，这是通向 Vista 及之后版本兼容性的第一步。
那一天不会很快到来。但在 2026 年 7 月，一个 30 年前启动的项目、一段 22 年前的 DirectX 9 游戏、一块 9 年前的显卡——在完全由社区编写的开源 NT 内核上协同运行。
这道拼图的每一块都不是依靠微软代码拼出来的。这才是值得讨论的部分。
参考链接
- Phoronix: ReactOS Now Capable Of Running Half-Life 2
- Fingerlakes1 报道
- ReactOS 官方推特
- YouTube: Half-Life 2 on ReactOS 实机演示
- ReactOS 官网
- Lobsters 讨论
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。