ReactOS 和 WDDM 支持：现状、挑战和进展

ReactOS 的开发已经持续了很长时间，许多当前的贡献者在它开始时甚至还没有出生，但它的目标仍然没有改变： 提供与以下兼容的 ABI 体验 Windows 能够运行为微软系统设计的软件和驱动程序。近年来，该项目最雄心勃勃的方面之一是赶上对 硬件.

这一过程促成了一个关键目标：更接近现代 Windows 图形驱动程序架构。我们讨论的是 WDDM，它是自 Vista 时代以来取代 XDDM 的模型。在 ReactOS 生态系统中， 探索 WDDM 意味着了解 GPU 管理如何发生变化，系统的哪些部分进行了重组，以及为什么仅仅“激活”驱动程序不足以使一切像在 Windows 中一样运行。

什么是 WDDM 以及它为何如此重要

WDDM（Windows 显示驱动模型）对图形堆栈进行了彻底的改革： 将 GPU 的控制权从 Win32k 等组件转移到专用核心 （Dxgkrnl.sys）用于与制造商的微端口进行通信。每个版本（1.0、1.1、1.2 及更高版本）都定义了系统提供的接口及其实现方式，这与 DxDiag 中所示的 Direct3D 功能级别不同。

这种更加模块化且要求更高的架构超越了 XDDM 所提供的功能。在 WDDM 中， Dxgkrnl 充当协调器并且供应商驱动程序有助于清晰地定义入口点和契约。这种分离允许改进，例如虚拟化显存、GPU 调度程序，并且通过将部分逻辑移至用户模式，总体上提高了稳定性。

多年来，这两种架构都缺乏深入开发视频驱动程序的实用文档，这阻碍了开发进程。随着开放式 GPU 驱动程序的成熟， 社区获得了真正的参考 了解 OpenGL ICD 的行为、Vulkan 支持和模型转换。

XDDM 怎么了？兼容性、遗留问题以及突破点

从 Windows 8 开始，系统要求 GPU 驱动程序为 WDDM；然而， XDDM 并没有完全消失Windows Vista 和 Windows 7 允许 XDDM 驱动程序顺利加载，并且仍然存在与 WDDM 共存的旧机制。例如，加载 OpenGL ICD 的模块在各个版本之间几乎没有变化。

WDDM 与微端口的通信更加直接。Win32k 保留了一个系统调用跳转， Dxgkrnl 填充适当的接口，减少了旧子系统对 GPU 逻辑的参与。事实上，在系统启动时，会观察到特定的例程将 WDDM 链接到旧的 Win32k 环境，而无需接口架构。

有两个显示驱动程序需要详细了解：TSDDD.dll 和 CDD.dll。第一个是 TSDDD， 在会话 0 中手动加载 这是一个非常基础的 XDDM 驱动程序，几乎不会写入空白内存。在 NT5.x 系列（ReactOS 的基础）中，视频初始化失败通常会导致视频故障的错误检测；在 Vista 及更高版本中，由于第二个组件的存在，这种“真实”情况不再发生。

CDD.dll 比较有意思。它作为 XDDM 驱动程序，会发出 IOCTL 来与 WDDM 通信。这是唯一的方法 Dxgkrnl 和 Win32k 进行有意义的通信 在现代图形操作中。在初始化期间，Win32k 会查询适配器，但响应会被 cdd.dll 覆盖，以确保与 WDDM 的桥接。关键点：一旦启用 WDDM，就无法并行运行 XDDM 驱动程序。

OpenGL ICD、Vulkan 及其与系统的关系

OpenGL ICD 使用传统模块加载，并且 其流量变化不大 Vista、7、8 及更高版本之间的兼容性，这有利于使用不同代 ICD 进行交叉测试。Vulkan 的行为类似：系统将与 GPU 的交互委托给这些层，但在 WDDM 中，微端口和 Dxgkrnl 建立了实际的硬件“合约”。

这种混合结构解释了为什么我们仍然看到 XDDM 的残余与 WDDM 在系统组件中共存。 CDD.dll 桥 允许 Win32k 继续履行其经典角色而不阻碍现代道路，而 Dxgkrnl 和 miniport 则接管管理 GPU 的关键任务。

编译 WDDM 驱动程序以在 ReactOS 上进行测试

要启动 WDDM 驱动程序，您需要一个辅助部分：WDK 的 displib.lib，它 暴露初始化驱动程序的入口点 并“唤醒”Dxgkrnl，但不进行绑定。流程比较特殊：调用初始化 API，将数据结构传递给 Dxgkrnl，然后 Dxgkrnl 通过调用 引导 来自提供商的微端口。

该回调提供了与 Dxgkrnl 进行其余通信的接口。此时， Win32k 看起来没什么 在微端口的启动阶段，这与 XDDM 世界有着根本的区别。这种改编在 ReactOS 中很容易实现，为导入和编译在 Windows 上也能继续运行的 WDDM 驱动程序打开了大门。

ReactOS 中的 WDDM：屏幕优先

D3DKMT API 用于 DirectX 和 OpenGL 加速，因此在 ReactOS 上的第一个实验中，我们选择了 关注基础知识：获取视频输出这就是 VidPn（视频演示网络）世界和 Dxgkrnl 内相关硬件支持发挥作用的地方。

从 Windows 8 开始，出现了所谓的 KMDOD，它是 WDDM 微端口的一个变体， 他们放弃了 3D 加速它们更容易理解和上手：它们允许您管理视频模式、监视器和轨迹，而无需依赖规划器和其他复杂的 Dxgkrnl 子系统。

对于 ReactOS，实验是构建一个最小的 Dxgkrnl，它将通过 VidPn 查询可用模式，将它们交给 CDD，并在 Dxgkrnl 准备就绪时激活 CDD。 结果：系统开始与第一个 WDDM 驱动程序通信 现在显示真实条件下的图像。

首次成功：BasicDisplay.sys 和供应商驱动程序

当将 BasicDisplay.sys 加载到 ReactOS 中时，结论出乎意料地积极： WDDM 的容忍度比预期的要高。甚至可以仅为显示部分启动供应商驱动程序，而不需要它们支持 3D 加速。

在后来的测试中，视频输出出现了更多的驱动程序，包括一个 Nvidia公司 从那个时代 Windows 7，这使得 ReactOS 将现代显示器移至其原始分辨率和频率瓶颈不是 Win32k，而是实际的硬件支持，目前仍在扩展中。

为什么 XDDM 在 WDDM 的道路上仍然至关重要

尽管最终目标是 WDDM，但 ReactOS 要求其 XDDM 堆栈处于良好状态。原因是 CDD.dll 和 DWM 本身等组件 他们依赖旧世界的良好表现来弥合新旧之间的差距。事实上，DWM 引入的需求是 ReactOS 中当前的 Win32k 实现尚无法完全满足的，尽管该实现仍在持续改进。

XDDM 对 AMD GPU 的支持也得到了加速，这是在 为更复杂的 WDDM 驱动程序开辟道路所选择的路径是渐进的：首先是屏幕和模式，然后是更多的拼图碎片。

XDDM 和 WDDM 之间的主要区别

从 XDDM 迁移到 WDDM 最显著的变化之一是故障处理。使用 WDDM，大部分驱动程序逻辑被转移到用户模式，这意味着 驾驶员碰撞并不一定会造成系统崩溃。 完整。此外，GPU调度程序和虚拟化内存允许更细粒度的资源分配。

在 XDDM 中，Win32k 承担了更大的责任，与硬件的通信也更加严格。在 WDDM 中， Dxgkrnl 对微端口施加了明确的契约，而 Win32k 仍然是连接窗口子系统的桥梁。这使得诸如 DWM、合成和更可靠的演示等新功能得以实现。

• 规划和隔离 GPU 工作与 XDDM 的单片方法。
• 虚拟显存 以及更好地管理共享资源。
• 增加稳定性 将驱动程序逻辑迁移到用户模式时。
• 与 DWM 集成 以及现代化的展示路线。

目前的局限性和正在进行的工作

虽然 ReactOS 中的 WDDM 显示驱动程序支持已经在测试中成为现实，但硬件兼容性仍然决定着其发展速度。 真实设备需要非常具体的支持，并且每次跳跃都需要扩展子系统：从即插即用到内存管理和看门狗。

在启动时，还可以观察到 看门狗、Win32k 和 Dxgkrnl 为在 Dxgkrnl 中调度 D3DKMT API 做准备；这是一个特定的初始化步骤，但在忠实再现 Windows 行为时，它增加了额外的要求。

项目状态、社区和合作呼吁

最近，WDDM 的推进伴随着硬件方面的更多活动。有一些技术文章详细介绍了该过程，并且 欢迎通过捐赠、GitHub 或外展方式做出贡献。这是一个大型、长距离的战线：每个微端口和每条演示路线都​​增加了细微差别。

顺便提一下，值得记住的是该项目的性质：ReactOS 不 Linux ni Unix的。 为一个 对比分析，从头开始编写，与 Windows 二进制兼容，允许它本机运行 Windows 软件和驱动程序，而无需借助 Wine/Proton 等兼容层，尽管该项目还与该 FOSS 生态系统合作以改善结果。

实用新闻：ReactOS 0.4.15 和系统改进

除了 WDDM 之外，版本 0.4.15 还带来了大量变化： 新司机 存储 提高单位的稳定性和兼容性 USB以及更新的网络驱动程序。字体、桌面外壳、Windows API、主题和对话框也进行了调整。

我们对影响性能的缓存和内存管理进行了改进。此外， 添加了 LiveUSB 支持 对内核的即插即用管理器进行了深度修改，为更多第三方驱动程序打开了大门，图形界面进行了细微的调整，与基于文本的 USETUP 安装程序相比更易于使用。

在音频部分，现在可以从 Windows 声音堆栈启动，尽管 仍有一些粗糙之处需要消除。还值得注意的是，0.4.15 是第一个支持 64 位架构（amd64）直至桌面的版本，尽管由于 WOW64 仍在开发中，因此目前还没有官方的 64 位图像。

错误修复非常积极： 错误分配的桌面图标 已解决的问题包括改进任务栏图标和原生 ZIP 文件支持。所有这些旨在改善基本用户体验，同时解决硬件兼容性问题。

下载、安装和最低要求

ReactOS 0.4.15 镜像可以在 SourceForge 上获取。 在虚拟机上测试 （建议初学者使用）或使用 Rufus 等实用程序创建的 USB 驱动器安装在真实硬件上，就像使用标准 Windows 一样。

要求适中：x86 CPU（奔腾或更高版本）、64 MB RAM、FAT16/FAT32 分区上至少 450 MB 磁盘空间以及 大约 2 GB 额外 如果您计划安装软件或游戏，这些最低要求允许过去十年甚至更早的计算机在测试场景中运行系统。

使用建议和现实期望

目前，ReactOS 仍处于实验阶段。如果您需要，不建议将其作为主要操作系统。 现代特征 并与最新应用程序完全兼容。对于运行较新的软件，Linux 上的 Wine/Proton 仍然是一条非常稳定的路线，拥有庞大的支持生态系统。

尽管如此，ReactOS 的独特性使其成为 唯一无需任何中间件即可运行 Windows 二进制文件的开放系统 模拟器风格。这种方法对于需要研究应用程序和驱动程序行为的实验室、向后兼容、分析和受控环境来说很有吸引力。

社区背景和共同信息

在论坛和社交空间中，经常会看到这样的提醒：ReactOS 是一个 PC 系统， 可以运行Windows程序和驱动程序有时，还会显示成员和在线用户计数器，这是社区活力的简单指标，虽然没有技术价值，但表明人们对该项目的兴趣日益浓厚。

最近的媒体报道甚至指出，对某些版本的 Windows 的支持终止与 ReactOS 在 WDDM 方面的进展这不仅具有讽刺意味，而且表明社区正在调整优先事项以与当前的硬件和驱动程序保持相关性。

最终，所有的努力都汇聚到一个点： 打下坚实的基础 WDDM 可以在不放弃 XDDM 遗留系统（它仍然充当着连接各个世界的粘合剂）的情况下建立自己的体系。有了 CDD.dll 作为桥梁，Dxgkrnl 作为大脑，以及得益于开放驱动程序的微端口的更好理解，WDDM 的发展之路已经铺平，尽管仍有很长的路要走。

综上所述，ReactOS 中的 WDDM 支持正在从一个模糊的承诺转变为一系列切实的里程碑： 显示驱动程序启动、模式协调良好以及显示器以全分辨率工作硬件兼容性需要扩展，WOW64 等部分需要完成，Win32k 和 DWM 需要继续进行微调，但方向是明确的，社区已经在朝着这个方向努力。