ReactOS Demonstrates Working WDDM Display Path Using BasicDisplay.sys

ReactOS has taken another visible step toward supporting modern Windows graphics drivers: developers have demonstrated a working WDDM display driver path inside ReactOS, with the Microsoft Basic Display sample and even some vendor drivers showing a display at native resolutions — a milestone that matters because WDDM is the graphics driver model that has powered Windows since Vista and is required to address modern GPUs and high‑resolution/refresh displays.

Background / Overview​

ReactOS is an open‑source re‑implementation of the Windows NT family ABI and driver model with the long‑term aim of running Windows drivers and Windows applications natively. That compatibility effort has historically targeted the Windows Server 2003 era (the NT 5.x/6.0‑era interfaces), but hardware and drivers have moved on: modern GPUs and drivers use the Windows Display Driver Model (WDDM) introduced with Windows Vista and extended in every subsequent Windows release. ReactOS must therefore add WDDM support if it hopes to run contemporary graphics drivers and drive modern displays with vendor‑supplied drivers.
WDDM replaced the older XDDM/XPDM model used by Windows 2000/XP and introduced a split driver model (user‑mode and kernel‑mode components), GPU scheduling, GPU virtual memory, and tighter integration with DirectX and Desktop Window Manager. The Microsoft Basic Display driver (BasicDisplay.sys) is a useful test and fallback component because it implements a WDDM display path and is shipped by Windows as a generic display driver; getting BasicDisplay to start is therefore a pragmatic first step toward real WDDM vendor driver support.

---

What ReactOS developers have achieved​

The practical milestone: BasicDisplay.sys and vendor drivers running​

ReactOS developers reported getting the BasicDisplay.sys WDDM sample to load and to initialize enough of a display pipeline to power modern monitors at native resolutions and refresh rates. In short tests, the BasicDisplay sample — and, in some experiments, parts of vendor drivers (display/2D only) — were successfully started and produced a usable display output on ReactOS. That’s notable because it demonstrates an end‑to‑end path where ReactOS can present VidPn (video presentation network) modes to an XDDM/Win32k path while delegating display control to a WDDM miniport model.
One ReactOS developer summarized the experience by describing how WDDM drivers proved surprisingly accepting: “When I first got BasicDisplay.sys loading in ReactOS I noticed how forgiving WDDM truly was... I was quickly getting more drivers to show some kind of display out, allowing ReactOS to power modern monitors at their full resolutions and refresh rates.” This candid developer note captures the immediate, pragmatic success and the practical limitations the team encountered.

Why this is a meaningful engineering step​

• It proves the team’s approach to stub or implement the minimum Dxgkrnl functionality (VidPn and display-only pathways) can be made to work on ReactOS.
• It shows vendor WDDM drivers are often tolerant of being started in a constrained environment (display only, no full 3D acceleration), which lets ReactOS validate the basic display path without having to implement the entire DirectX kernel stack immediately.
• It highlights a clear, incremental roadmap: first display only (2D / mode setting), then progressively more complex subsystems (render, D3D, memory management, scheduling).

---

Technical deep dive: how WDDM support is being approached​

The pieces involved (high level)​

Supporting WDDM requires several components to cooperate:

• Dxgkrnl / D3DKMT — the Windows graphics kernel (Dxgkrnl.sys) mediates between user‑mode components, kernel miniports, and Win32k for mode setting and resource management.
• Miniport drivers / WDDM miniports — hardware vendors’ kernel components implement the DDI (device driver interfaces) required by WDDM.
• Win32k and CDD.dll — the legacy display glue that interacts with user‑mode rendering and composition still influences how a WDDM driver is discovered and started; CDD.dll acts as a bridge during initialization.
• BasicDisplay.sys & BasicRender — Microsoft’s reference/basic drivers provide a minimal test harness for display‑only operation and are especially useful for validation in a compatibility project.

ReactOS’ immediate engineering goal is not to ship a full Dxgkrnl replacement; rather, the team implemented a minimal Dxgkrnl-like surface enough to allow a WDDM miniport to register, enumerate VidPn modes, and hand back a mode to CDD/Win32k so the desktop can display. This pragmatic, incremental strategy reduces the initial attack surface and focuses effort on the parts of Dxgkrnl that are essential for mode enumeration and display initialization.

Compiling and initializing WDDM drivers​

A technical detail the ReactOS team had to handle is how modern WDDM drivers are started. WDDM miniports are not linked directly against Dxgkrnl at build time. Instead, WDK (Windows Driver Kit) provides helper libraries (for example, displib.lib and APIs such as DxgkInitializeDisplayOnlyDriver) that allow a WDDM miniport to trigger the kernel graphics subsystem to call into it — a callback setup that fills out the DDI table and starts the driver’s operations. Reimplementing or providing compatible shims for these initialization APIs (the “start handshake”) is a key item in making third‑party WDDM binaries start on a non‑Microsoft kernel. ReactOS’ engineers implemented enough of this handshake to get BasicDisplay and some vendor display drivers to accept being started.

What’s deliberately excluded (for now)​

• Full 3D acceleration (D3D runtime paths and usermode driver stacks) are not required for a basic display output and have been deliberately deferred.
• Advanced Dxgkrnl schedulers, preemption and GPU virtual memory management features are complex and only needed once render paths and accelerated Direct3D are targeted.
• Multi‑adapter/complex vendor features — many WDDM features are optional or versioned; ReactOS’ current experiment focuses on the display‑only subset which is significantly smaller than a full WDDM implementation.

---

Strengths demonstrated by the work​

• Pragmatic incrementalism. The ReactOS team focused on the smallest possible contract required to start display‑only WDDM drivers — VidPn enumeration, CDD bridging, and the driver start handshake — rather than attempting a full Dxgkrnl reimplementation in one go. That reduces risk and yields tangible results quickly.
• Vendor driver tolerance. The experiment showed WDDM miniports are often tolerant of being launched in constrained environments, which makes a compatibility approach feasible; ReactOS can use that tolerance to validate mode setting and display output even before implementing comprehensive GPU memory management.
• Immediate user value. Booting with a real display driver (even a display‑only vendor driver) unlocks more realistic testing scenarios: higher resolutions, modern monitor timings, and broader hardware testing than VGA or legacy XDDM fallbacks allow. This eases both development and QA.

---

Open problems and risks​

While the results are promising, several substantial challenges remain — some technical, some practical:

Win32k and XDDM compatibility remains essential​

ReactOS’ blog explicitly notes that XDDM support remains a requirement: CDD.dll and the older display glue still play a role in how the system boots and discovers displays; Win32k’s ability to handle Vista+ behaviors (DWM, modern APIs) is not yet feature‑complete on ReactOS. That means ReactOS must continue improving its XDDM compatibility and Win32k subsystem in parallel. In other words: WDDM support depends on having a robust XDDM/Win32k baseline.

Hardware diversity and vendor complexity​

Real GPUs and vendors implement a broad and sometimes idiosyncratic set of behaviors: firmware variations, UEFI GOP interactions, vendor-specific IOCTLs, and subtle timing expectations. Some vendor drivers assume the presence of features and kernel behaviors that are hard to emulate perfectly. The ReactOS team already noted that they began hitting limitations posed by hardware rather than their Win32k implementation, meaning the path to broad, reliable support will require a lot of iterative testing across vendor families (Intel, AMD, NVIDIA) and platform firmware.

Scope of Dxgkrnl features​

Dxgkrnl is large: scheduling, preemption, fault isolation, GPU virtual memory, multi‑engine support, and synchronization primitives. Each is a non‑trivial subsystem to reproduce with the precise semantics expected by third‑party drivers. If ReactOS attempts to implement these in full, the complexity grows significantly. The current strategy of focusing on display‑only reduces scope but it’s a partial solution by design.

Stability and user expectations​

Loading third‑party vendor drivers on an OS reimplementing kernel interfaces creates the risk of driver crashes, GPU hangs, or undefined behavior that can impact the host. Without full TDR/timeout/detection and recovery support, a misbehaving driver could destabilize the OS. The ReactOS team must carefully design fault containment and recovery strategies before recommending vendor WDDM drivers for general use. This is an engineering and testing challenge.

Legal and compatibility caveats (unverifiable claims flagged)​

There is frequent community curiosity about whether implementing Windows ABI/driver behavior is legally fraught. Historical precedent shows that re‑implementations can operate in a grey area depending on the methods used. ReactOS is an independent open‑source project that has historically avoided distributing Microsoft source and focuses on clean‑room reimplementation. Any claim that legal risk is zero would be unverifiable without legal review; readers should treat legal safety as not automatically guaranteed and consult legal counsel for commercial deployments. (This paragraph flags uncertainty and does not attempt a legal ruling.)

---

What this means for users and testers​

For enthusiasts and developers who want to experiment with ReactOS’ WDDM progress, here are practical, safety‑minded steps and expectations.

• Download the latest nightly builds and test images from the official ReactOS site or official mirrors.
• Prefer running tests in virtual machines (QEMU, VirtualBox, VMware) with pass‑through or generic display options to avoid hardware risk.
• If testing on real hardware, start with non‑critical machines and ensure you have recovery media available — driver tests can cause hangs or kernel panics.
• Use BasicDisplay.sys (the WDK sample) as the primary test case — it’s the simplest and includes expected behaviors for display‑only operation.
• Log and report failures: include DxDiag-like dumps, boot logs, and precise hardware/firmware versions. These are the data the ReactOS developers need.

Practical cautions:

• Do not use experimental ReactOS builds for production or any environment where data safety and security are critical.
• Be aware that many modern features (e.g., GPU accelerated Direct3D, Hardware‑accelerated GDI acceleration in Windows 7+) remain outside this display‑only milestone and will require substantially more development and testing.

---

How to interpret the technical claims and verify them yourself​

The most important technical claims in the ReactOS announcements are:

• BasicDisplay.sys can be started in ReactOS and produce display output.
• Some vendor WDDM drivers will start in display‑only mode and produce a usable image.
• Full Dxgkrnl functionality (render, scheduling, advanced memory management) is not implemented yet.

Each of these can be validated by:

• Reproducing the experiment with the same nightly ReactOS build and the BasicDisplay sample from a WDK build environment.
• Checking whether the display enumerates correct VidPn modes and whether Win32k detects the new display adapter.
• Observing logs that show Dxgk‑style initialization callbacks and driver start handshakes.

ReactOS’ own blog post describes the first step in detail and is the canonical explanation of the experiment; Microsoft’s WDDM documentation provides the authoritative reference for what a WDDM driver is expected to do (and thus what ReactOS must emulate). Cross‑referencing both is the right approach when evaluating progress.

---

Why this effort matters to the wider Windows‑compatibility ecosystem​

• Hardware support unlocks more applications. Running modern displays and vendor drivers enables more realistic testing of GUI applications, multimedia workloads, and games that rely on higher resolutions and acceleration fallbacks.
• A bridge to newer drivers. If ReactOS can progressively implement the WDDM surface, binary compatibility with a broader range of vendor drivers becomes feasible — expanding ReactOS’ practical utility beyond historical Windows Server 2003 era software.
• Cross‑pollination for open drivers and tooling. The work highlights where open‑source driver projects and the WDK documentation match or diverge; it also creates an environment where open tools can be exercised against Windows drivers in novel ways, potentially benefiting projects like Wine or kernel driver reverse‑engineering efforts.

---

Next technical milestones to watch​

ReactOS’ public roadmap (as implied by the WDDM blog series) and common sense suggest the next technical targets:

• Robust XDDM/Win32k improvements so CDD and composition behave reliably with WDDM drivers.
• Incremental Dxgkrnl expansions: improve VidPn handling, add more D3DKMT stubs, and build out basic synchronization and memory reporting that vendor drivers expect.
• Controlled experiments with render‑capable WDDM drivers, starting with limited render features and carefully sandboxed tests.
• Improved TDR / watchdog and fault recovery components to reduce risk from buggy vendor binaries.

---

How developers can help​

• Contribute tests and reproducible logs from different hardware platforms and vendor drivers.
• Help by porting or implementing specific Dxgkrnl stubs and VidPn helpers in small, well‑scoped patches.
• Fund or donate to ReactOS if you value continued progress on hardware compatibility; the project has repeatedly asked the community for support to sustain development.

---

Conclusion — cautious optimism​

The recent work to get BasicDisplay.sys and select vendor WDDM drivers to start on ReactOS is an important and tangible engineering milestone. It demonstrates that a compatibility path for modern Windows display drivers is feasible using a pragmatic incremental approach: implement just enough Dxgkrnl/VidPn behavior to start display‑only miniports, validate mode setting and output, and then iteratively expand toward more complex features.
However, the milestone is partial, not complete. The deeper Dxgkrnl subsystems (render, scheduling, memory virtualization), robust Win32k behavior under DWM, hardware idiosyncrasies, and fault containment remain unsolved engineering problems that will require significant work and broad testing across vendor ecosystems. The result is promising: a working display output with WDDM drivers is now possible on ReactOS, but the road to full, stable vendor driver compatibility and full 3D acceleration is long and will require continued community support and focused engineering.
For enthusiasts, developers, and testers, this is a good moment to follow the project closely, test nightly builds in safe environments, and, if possible, contribute logs, test cases, or code — because turning a display‑only experiment into reliable, broad WDDM compatibility is a collaborative engineering task, not a one‑person solution.

---

---

Source: Phoronix ReactOS Making Progress On Windows WDDM Driver Support - Phoronix