简介：ReactOS 0.3.15 源码包适合系统内核开发者、安全研究人员及对Windows兼容机制感兴趣的进阶学习者。该版本经实测可在Visual Studio 2012下编译生成ntoskrnl.exe与ntoskrnl.pdb，实现有限度的源码级内核调试，便于分析启动流程、内存管理、进程调度与硬件抽象层。包内共2000个文件，包含1376个C头文件、551个C源文件、72个说明文档和1个C++文件，压缩包约83.32MB，目录覆盖内核、驱动、win32子系统及DDK等模块；其中头文件定义核心数据结构和API，C源文件实现调度器、对象管理、内存管理等关键路径，txt文本对编译环境与调试配置有提示作用。借助生成的调试符号，可在调试器中设置断点并跟踪关键函数调用，对理解系统调用、驱动加载及内核实验很有帮助。当前已有174人学习下载，适合需要从源码层面理解类Windows操作系统构造并通过实际编译验证内核模块的开发者。
1. ReactOS 0.3.15 源码包能干什么：先看清它是重写而不是模拟
打开这个 zip 之前，先摆正一个预期：ReactOS 不是一个在 Windows 上装个虚拟层跑 Windows 软件的项目，它是从零重写一个能运行 Windows 驱动和软件的独立操作系统。内核是自己的、API 是自己实现的，目标是让 Windows 的 exe 和 .sys 驱动觉得“这就是 Windows”。0.3.15 这个版本虽然不像 0.4 系列那样接近可用状态，但它的源码结构、编译流程、子系统划分已经足够完整，是研究 NT 系操作系统实现和做 Windows 级兼容性测试的上手材料。适合这些人：想理解 Windows 内核子系统相互关系的人、想对比开源实现与闭源系统差异的人、以及想拿一个免费系统跑 Windows 软件做测试的从业者。这源码包不大，但你要是把它当普通软件装上就用，会栽不少跟头。
2. 源码包解剖与系统架构：它和 Windows 的对应关系
2.1 顶层目录的功能切分：dll、ntoskrnl、drivers 各自负责什么
解压 ReactOS-0.3.15-REL-src.zip 之后，看到的不是一个可以运行的系统，而是一棵树。我一般会按“能直接看到 NT 系架构影子”的顺序去读这棵树：dll 目录对应 Windows 系统目录里那一堆 DLL，ntoskrnl 目录对应内核主体，drivers 目录对应驱动，sdk 目录对应头文件与导入库。
dll 目录下的子目录直接映射到 Windows API 层。比如 dll/win32/kernel32、dll/win32/user32、dll/win32/gdi32，这三个目录分别是进程线程与内存管理的用户态入口、窗口消息与 UI 的入口、图形绘制的入口。往下翻还能看到 dll/win32/shell32、dll/win32/advapi32、dll/win32/ole32，这些就是你在 Windows 上调用 Shell API、注册表服务、COM 组件时经过的那一层。dll/ntdll 更特殊，它是用户态与内核态的边界，负责把 API 调用包装成系统服务请求。
ntoskrnl 目录就是内核本身。它包含进程调度、内存管理、对象管理器、IO 管理器、同步机制这些核心。0.3.15 这个版本的内核已经具备基本的多线程调度和虚拟内存管理，但和现代 Windows 内核比，少了大量安全机制和性能优化。读代码的时候别用“研究 Windows 内核”的心态去读，要用“理解 NT 设计骨架”的心态。
drivers 目录下能看到一堆常见驱动。以 0.3.15 时代的状态来看，它带了 FAT 文件系统驱动、ACPI 电源与主板驱动、键盘鼠标驱动、IDE 磁盘驱动、以及 rtl8139 这种常见网卡的驱动。这些驱动对应 Bus 驱动、Function 驱动和 Filter 驱动三个层次。你可以把某个驱动的代码拉出来，对照 Windows 设备管理器里的设备树结构去理解“驱动栈”的概念。这部分代码是比较值得下载下来反复读的。
sdk 目录则是编译和开发时需要的东西。include 下是头文件，lib 下是导入库。打开 sdk/include/ntddk.h 或者 sdk/include/windows.h，会发现它和 Windows SDK 的头文件在结构和名称上是高度对应的。假如你在 Windows 下开发过内核驱动，看这份头文件会觉得极其亲切。换句话说，这是一份能让你反过来理解 Windows 开发环境的开源 SDK。
从功能切分角度说，这份源码最大的价值不是“能跑”，而是“能对读”。它把 Windows 的模块边界真实地摆在你面前，而不是像黑匣子一样只能看文档猜内部逻辑。
2.2 从注册表与 NLS 子系统看兼容层设计逻辑
ReactOS 要兼容 Windows 应用程序，不只是把 API 函数名字对上就行，还得把 Windows 的环境“拟态”出来。0.3.15 源码里最能体现这一点的两个点，是注册表实现和 NLS（National Language Support，国家语言支持）子系统。
先看注册表。Windows 程序的很多配置写在注册表里，比如 HKEY_LOCAL_MACHINE\SYSTEM 下的服务配置、HKEY_CURRENT_USER\Software 下的应用设置。ReactOS 在 base/system 下有独立的注册表服务实现，它要模拟出“打开注册表键、枚举子键、读写值”的完整行为。源码里对应的是 base/system/config 那一组代码。这组代码的复杂度很能说明问题：Windows 的注册表不是一个简单的键值对数据库，它有 hive 文件格式、有数据缓存、有一整套安全描述符处理逻辑。ReactOS 在这个版本的实现是“能用但不够深”——比如某些时候键值的类型处理、大小写敏感规则和 Windows 原生表现不完全一致。你要是拿一个读写注册表很频繁的商业软件在这上面跑，能明显感觉到兼容性损耗。
再看 NLS 子系统。NLS 管理字符编码、代码页、区域设置。Windows 程序在显示非英文文本时，依赖系统里的代码页转换表和区域信息。ReactOS 在 dll/win32/kernel32 和 base/nls 里实现了这些表。我在实际测试的时候发现，0.3.15 对简体中文的覆盖是残缺的。你用英文区域跑系统没问题，但把区域切成中文后，某些程序会找不到对应的代码页数据然后回退到默认的 1252（西欧）编码，中文显示成乱码。这正好解释了后续 0.4 系列为什么要大改 NLS 模块。读这个部分源码时，你会发现“兼容性不是字符串处理，而是数据表驱动的环境仿真”。
理解了这两块，再看第三层：控制台子系统。Windows 的字符界面程序依赖 console host 提供输入输出缓冲、窗口标题、光标控制。ReactOS 在 base/shell/cmd 里有一个自己的 cmd.exe，在内核里有一个控制台驱动，在 user32 里有一套控制台 UI 渲染逻辑。这三层配合，才让一个用控制台 API 写的程序觉得自己活在一个 Windows 终端里。0.3.15 这一版的控制台实现说实话还很粗糙，我在 QEMU 里跑之前写的一个用控制台颜色输出的程序时，光标定位和颜色设置的行为和 Windows 原版有可见差异。
这一章看下来，你能形成的判断是：ReactOS 的兼容性精度取决于每个子系统的“实现完成度”。拿代码时先别期待所有功能都能跑，而是把源码当作一套 Windows 行为的参考实现来研究。下一步，就用这套源码编译出一个真正可以启动的 ISO 镜像。
3. 搭起编译环境：从源码到可启动 ISO 的完整流程
3.1 编译工具链的选择：为什么不用 MSVC 也不用普通 MinGW
一上来就想用 Visual Studio 的 cl.exe 编译 ReactOS 的人，基本都会卡死在第一步。原因是 ReactOS 源码里有很多 GNUC 相关的技巧性代码，比如特定结构体的零长度数组、内联汇编语法、以及 GCC 扩展的attribute用法。MSVC 在 0.3.15 那个年代完全不认这些东西。用普通 MinGW 也有问题：ReactOS 源码依赖的 CRT 启动代码和平台头文件是它自己的版本，普通镜像的 MinGW 缺少这些定制文件，编译出来的内核连链接阶段都过不去。
官方推荐的做法是使用 RosBE（ReactOS Build Environment），也就是 ReactOS 给社区准备的定制版编译环境。它本质上是基于 MinGW-w64 工具链改造的，额外带了 ReactOS 定制的 CRT、sysroot、编译驱动脚本。这个包在 0.3.15 年代对编译器版本卡得很死，如果你机器上装了比自己另装的 GCC 还新的版本，反而会因为标准库头文件冲突翻车。所以我的习惯是：单独准备一台干净的 Windows 虚拟机或者独立的目录，专门放 RosBE 和源码，不跟日常开发环境混在一起。
3.2 编译配置与完整命令：从 configure 到生成 bootcd
先说明：这部分操作在 Windows 上完成，用 RosBE 的命令行环境。装好 RosBE 之后，源码解压到的路径里不应该有空格和中文，否则后面生成 ISO 时会因为路径解析问题报错。我一般把源码解压到 C:\rosbuild\src 这种路径。
打开 RosBE 的命令行环境，首先确认环境变量正常：
cd C:\rosbuild\src echo %ROSBE_ARCH%如果 Echo 出来的是 i386，说明当前环境是 32 位目标配置，这是 0.3.15 最常见的配置。然后开始编译配置：
configure.cmd --with-debug --no-optimizationconfigure.cmd 的作用是生成 makefile 和编译所需的配置头文件。--with-debug会打开内核调试输出和断言，--no-optimization关掉编译器优化，这两项组合起来能让你后面用调试器看内核符号时不被优化代码扰乱。不要一上来就想要性能，调试期拿到清晰的调用栈比什么都重要。配置脚本跑完以后，进入构建阶段：
cd reactos mingw32-make bootcdbootcd 是这一步的核心目标，它会编译内核、驱动、系统 DLL、用户态程序，然后打出一个安装用的 ISO 镜像。mingw32-make 是 MinGW 系的 make 工具，在 RosBE 里已经配好 PATH，直接用就行。这一步在你的机器 CPU 不错的情况下，大约需要十分钟到半小时不等。0.3.15 编译整体耗时不算长，因为它目录里的源码量比 0.4 少一个数量级。
编译完成后，检查输出目录：
ls output-i386/bootcd.iso输出目录名是 output-后面跟架构名，看到 bootcd.iso 就是成功产物。我还建议顺手生成一份 livecd：
mingw32-make livecdlivecd 是免安装的体验光盘，启动以后直接进图形界面。bootcd 是安装盘，会把系统装进虚拟硬盘。如果只做功能测试，用 livecd 省事；要做性能测试或者反复重启验证，就优先 bootcd，装到磁盘上跑得稳。
3.3 编译产物与镜像类型的区别：看不懂先别下手测
编译产物不只是 bootcd.iso 和 livecd.iso 两种镜像这么简单。你在 output-i386 目录里还会看到一堆子目录。其中最重要的是 output-i386/bin，这里放着编译出来的模块文件，比如 ntoskrnl.exe、win32k.sys、r141081.sys 这类。注意：ReactOS 0.3.15 的模块名大多跟 Windows 一致，但文件内容完全是独立实现的，不要看到 ntoskrnl.exe 就以为下到了 Windows 内核源码。
bootcd 和 livecd 这两种镜像的使用场景差别很大。bootcd 走的是传统安装流程，有一个类似 Windows 安装程序的字符界面阶段，然后展开文件到目标磁盘，最后配置硬件并重启。livecd 则是直接把整个系统加载进内存启动，没有安装环节。livecd 在 0.3.15 这个年代相对不稳定，某些硬件上会出现加载失败。如果只是为了验证内核启动、看蓝屏前的内核日志，两种都能用；但如果你要测试驱动在持久化环境下的行为，建议一定用 bootcd 装进虚拟磁盘再测。另一个容易忽略的点：bootcd 生成的 ISO 同时包含安装环境和目标系统，体积通常比 livecd 大，启动速度也慢，但逻辑上更接近真实 Windows 部署流程。
3.4 编译阶段常见失败与处理：先认错误，再动参数
编译失败是我在这个版本上遇到过的最多问题。先说现象最普遍的一个：第一轮编译走到中段，报一堆 “undefined reference to _chkstk” 或 “_alloca_probe” 之类的链接错误。原因基本是 RosBE 里的 CRT 库版本与当前源码不匹配。0.3.15 源码的配套构建环境版本卡得比较紧，你用的 RosBE 要是比它晚太多，CRT 接口可能变了。解决方法是改用 RosBE 历史版本，或者干脆在 README 里找到 Release 时指定的构建环境版本号。第二个常见问题是编译器 Out Of Memory，在 32 位宿主机器上编译内核时容易爆。解决方法是把构建目录换成 NTFS 磁盘，并且临时加一个超过 2GB 的页面文件。第三个现象是编译到 shell 相关模块时报 “failure waiting for process to die”，这个通常是杀毒软件把编译进程给拦了。把这些工具目录加进白名单，或者干脆在断网状态下编译，可以绕过去。
这一章跑完，你就拿到了一个真正能启动的操作系统镜像。但别急着扔到真机上去跑，先把虚拟机环境配好，因为硬件兼容性问题在这个阶段最容易误导你。
4. 虚拟机安装与系统测试：把 ISO 跑起来并验证基本功能
4.1 虚拟机配置与参数选择：QEMU 下的稳定组合
我一般用 QEMU 而不是商业虚拟机软件去跑 0.3.15，原因有两点：一是 QEMU 的参数完全可控，出了问题可以直接在启动命令行里调整；二是 0.3.15 时代的 ReactOS 对商业虚拟机的网卡和声音设备支持不完善，但 QEMU 模拟的经典硬件组合恰好和 ReactOS 自带驱动覆盖范围重合。
下面是能稳定跑起来的最精简参数：
qemu-system-i386 -m 512 -hda reactos_disk.img \ -cdrom output-i386/bootcd.iso \ -boot d -net nic,model=rtl8139 -net user \ -display sdl逐个参数解释：-m 512表示给虚拟机分配 512MB 内存，0.3.15 内核在这个内存量级下工作稳定，给太多反而可能让早期版本的内存管理触发不必要的分支分支。-hda reactos_disk.img是一个用 qemu-img 创建的虚拟磁盘文件，用来承载安装的系统。-cdrom指向刚编译出来的安装镜像，-boot d让虚拟机优先从光盘启动进入安装界面。-net nic,model=rtl8139和-net user把网卡模拟成最常见百兆网卡芯片，再用用户态网络栈提供网络能力。-display sdl是图形界面显示后端，避免走远程桌面的额外干扰。
在 0.3.15 这个阶段，不要尝试把-cpu参数设置为新处理器型号。默认的 qemu32 或 pentium 级别 CPU 模型反而最稳，因为 ReactOS 的 CPU 特性检测没有现代系统那么完善，遇到太新的指令集扩展码可能直接踩进未定义路径。
4.2 安装过程与分区选择：避开 AIO 全脏坑
启动安装程序后，界面是一个蓝底的字符安装向导。你需要先做分区——0.3.15 的安装程序只能创建和格式化 FAT16/FAT32 分区，不认识 NTFS。我的习惯是让安装程序全盘自动分区，因为手动分区分出来的活动分区如果没标对，安装完后 BIOS 引导阶段会看不到启动扇区。分区完成后，选择安装目录，默认就是C:\ReactOS，不要改。这里有一个容易忽略的点：安装程序会询问目标文件系统，选 FAT32 而不是 FAT16，这样在后续往系统里拷贝安装包时不受 2GB 单文件限制。文件复制阶段大概需要几分钟，完成后安装程序会提示重启。
重启之后，虚拟机会从虚拟磁盘启动，进入 ReactOS 自己的图形登录界面。0.3.15 默认没有设置管理员密码，登录名用 Administrator，密码留空直接进。第一次启动会跑设备检测，如果你用的是上面那套 QEMU 参数，键盘、鼠标、显示、网卡都应该被正确识别。如果第一次启动花屏或者黑屏，大概率不是源码问题，而是启动显示参数没选对——后面避坑章节会展开说。
4.3 基础功能验证：从启动组件到系统信息面板
系统起来以后，先别急着装软件。按我的习惯，验证顺序是：内核信息 → 设备管理器 → 网络栈 → 基础 GUI 稳定性。
先打开命令行窗口启动一个进程列表，确认系统关键进程在跑。0.3.15 启动后应该能看到 csrss.exe、winlogon.exe、services.exe、lsass.exe 这几个用户态核心进程，以及内核模块中已经加载的 FAT 驱动和网卡驱动。这一步能确认你编译出来内核的基础功能没有缺失。然后打开系统属性里的设备管理器，逐个检查设备状态。正常情况下，标准 IDE 控制器、串口、并口、键盘、鼠标、显卡和 RTL8139 网卡都能正常识别，显示“工作正常”。
网络栈验证是最容易出惊喜的一步。在 ReactOS 的命令行窗口里执行：
ipconfig /all ping toucheng.com第一次执行时大概率网络是通的，但ping外网域名不见得能成，因为 0.3.15 的 DNS 解析器在某些配置下不会走 QEMU 的 user 网络 DNS 自动转发。先执行ipconfig /all看看默认网关和 DNS 地址是不是 10.0.2.2，如果拿到了说明网卡驱动和链路层没问题。GSM 网络连接不通时，再检查一下是不是没有用-net user启动，或是在系统里没有正确启用 DHCP 客户端。
把这几项验完，你手上已经有一套能跑起来的系统。不过真要拿它当测试机，你就得了解这个版本在运行时有哪些坑。接下来是我在实际测试过程中踩出来的记录，每一条都是血泪经验换来的。
5. 避坑指南：ReactOS 0.3.15 实操中绕不开的几条弯路
5.1 启动黑屏但虚拟机没死机：显卡驱动与显示后端不匹配
现象：QEMU 启动到一半，屏幕全黑，但是有光标闪烁，鼠标能动。
原因：0.3.15 自带的 VGA 驱动没有正确识别 QEMU 的 Cirrus 显卡模式，或者编译时没有把显示驱动编进内核，系统在换显示模式的时候找不到匹配的驱动就停止刷新画面。
解决：在 QEMU 启动参数里加-vga std，这是标准 VGA 模式，兼容性比 Cirrus 更稳。如果这样还是黑屏，改用-vga cirrus并确认编译时把drivers/display/cirrus编进去了。还有一种玄学情况：-display sdl在小分辨率窗口下不触发完整重绘，加一个-full-screen强制全屏能绕过。
5.2 安装到一半提示找不到磁盘：磁盘控制器模式不是 IDE
现象：安装程序进行到选择目标磁盘的步骤，列表里空白，看不到虚拟硬盘。
原因：QEMU 默认把虚拟磁盘挂到 IDE 控制器上，但如果你在 QEMU 参数里额外加了-device virtio-blk或者使用默认的 SCSI 控制器，ReactOS 0.3.15 里没有对应驱动，自然找不到磁盘。
解决：不要额外指定磁盘控制器类型，直接用-hda挂载。QEMU 对-hda默认模拟 IDE 通道，而 ReactOS 自带的 atapi IDE 驱动能接管这个控制器。如果你已经建好了虚拟磁盘，检查是不是用了-drive file=...,if=scsi这样的写法，改成if=ide就好。
5.3 启动时文件系统损坏：安装过程被异常中断或虚拟磁盘太小
现象：重启进入系统，启动管理器提示Failed to load \ReactOS\system32\ntoskrnl.exe或者干脆无法读取 FAT 分区。
原因：虚拟磁盘不满 200MB，FAT32 文件系统元数据区域与内核文件在物理扇区上交错，安装程序中有一个扇区对齐处理做得不够完善的情况；另外虚拟机没正常关机直接强杀进程也可能引发文件系统缓存未落盘。
解决：创建虚拟磁盘时至少给 512MB 容量，推荐 1GB，并且用 qemu-img 创建的时候显式设置 cluster size 为 16K 以上。还有强制操作纪律：不要直接关闭 QEMU 窗口结束虚拟机，在 ReactOS 的关机菜单里先关机。
5.4 中文软件乱码且无法切换区域：NLS 数据表缺失
现象：安装一个中文绿色软件，界面显示“| | |”这类方框乱码，把系统区域设置切成中文后依然没变化。
原因：0.3.15 自带的 NLS 数据表只覆盖了少量代码页。简体中文需要的代码页 936 表没有完全入库；系统字体目录里也没有中文字体文件。区域设置改了但代码页回退逻辑仍然按默认 1252 处理。
解决：在编译源码时打开base/nls目录里的数据文件，把简体中文字形表加进构建，但更快的办法是系统装好后手动拷入一个 truetype 中文字体和代码页转换 DLL。不急着用中文界面的场景下，建议直接用英文区域跑，把中文兼容问题当作这个版本已知的边界。
5.5 图形界面闪烁严重：缺少硬件加速只走慢速路径
现象：移动窗口边缘时撕裂感很强，窗口最小化/还原有明显延迟，浏览器滚动起来一帧一帧地跳。
原因：0.3.15 对虚拟显卡的加速支持非常有限，大部分 2D 绘制走的是内存软件位块传输路径，CPU 模拟模式下性能天然受限。
解决：这不是 bug，是模型限制。降低 QEMU 显示分辨率到 800x600，并将颜色深度降到 16bit，能减少位块传输数据量。如果你拿它做自动化测试而不是手动点击，用-display none -vnc :1在无界面模式下跑，再通过 VNC 客户端截图，会更顺手。
五条下来，你会发现绝大部分问题都不在“编译失败”，而是在“运行环境边界”。摸清这套边界之后，你就能拿 ReactOS 干一件比较有意思的事：把它当 Windows 软件的兼容性测试沙箱。
6. 进阶技巧：把自己写的 Windows 程序丢进 0.3.15 里测兼容性
当你能稳定启动一个 0.3.15 系统时，就可以把它当作一个参照物来测试 Windows 软件的 API 使用深度了。做法很简单：用 MinGW 编译一个纯 Win32 API 的小程序，丢进虚拟机里跑，看它在哪个 API 调用上先挂掉。
最常见的测试样例是窗口创建、注册表读写、文件对话框调用。我编译过这类小程序，核心逻辑不超过 100 行，只调用 CreateWindowEx、RegisterClass、SetWindowText 这三个基础 API。在 0.3.15 上，它通常能正常弹出一个窗口，但如果你调用 GetWindowLongPtr 这类比较冷门的函数，有概率触发未实现分支导致进程消失。这种“差一点点”的体验，能很直观地反映兼容层实现的边界在哪——它不如直接跑 Windows 上的黑盒测试那么多元，但对阅读源码的人来说直观得多。
#include <windows.h> LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) { if (msg == WM_DESTROY) PostQuitMessage(0); return DefWindowProc(hwnd, msg, wParam, lParam); } int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrev, LPSTR lpCmd, int nCmd) { WNDCLASS wc = {0}; wc.lpfnWndProc = WndProc; wc.hInstance = hInstance; wc.lpszClassName = "CompatTest"; RegisterClass(&wc); HWND hwnd = CreateWindow("CompatTest", "ReactOS Compat Test", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, 320, 200, NULL, NULL, hInstance, NULL); ShowWindow(hwnd, nCmd); MSG msg; while (GetMessage(&msg, NULL, 0, 0)) { TranslateMessage(&msg); DispatchMessage(&msg); } return 0; }编译命令很简单，只需要标准 MinGW：
i686-w64-mingw32-gcc -o compattest.exe compattest.c \ -mwindows -static -lkernel32 -luser32 -lgdi32 -lcomctl32-mwindows把子系统标记为 GUI，-static是关键：避免在 ReactOS 0.3.15 里找不到 MinGW 依赖的动态库而启动失败。-lcomctl32是因为控件样式初始化需要它，即使程序里没用 ListView。把生成的 exe 用共享文件夹或软盘镜像挂进虚拟机运行即可。
测试结果可以作为你判断 ReactOS API 实现完整度的依据：能弹窗说明 user32 的窗口注册与消息循环能用；程序退出前如果事件日志里没有调用失败的记录，说明这一层基本实现稳固。你可以在源码里搜索CreateWindowEx和DefWindowProc的实现位置，用调试器跟着源码走一遍调用链。从那时起，我每次拿到一个疑似“Windows 兼容层实现不够”的反馈问题，都强制走一遍“自己写测试程序、丢进 ReactOS、对照源码找断点”的流程。这个习惯比看十遍文档都管用。希望帮到你，动手试试吧。
本文还有配套的精品资源，点击获取
