On the same day Windows 10 reaches end-of-support, ReactOS—the open-source operating system aiming to natively run Windows apps and drivers—has published a long-awaited milestone: an initial, working investigation of WDDM (Windows Display Driver Model). It’s only display-output for now, not 3D acceleration—but it’s the first real bridge to the driver model Windows has used since Vista and mandated since Windows 8.
In a deep-dive post, ReactOS developer The_DarkFire_ details the pitfalls, progress, and pragmatic detours required to get a WDDM miniport driver to light up a display on ReactOS. Starting with the Basic Display Adapter sample from the WDK and moving on to vendor drivers—including an NVIDIA Windows 7 driver—the team managed to drive modern monitors at native resolutions and refresh rates.
No, ReactOS isn’t ready to replace Windows on your main machine. But for the only open-source OS that aims to run Windows software and drivers natively (not via Linux/Unix layers), speaking WDDM is a foundational step toward modern GPUs and features like DWM, virtualized GPU memory, and user-mode drivers that don’t take down the whole OS when they crash.
XDDM vs WDDM: the generational shift ReactOS must cross
A quick refresher:
- XDDM (Windows XP Display Driver Model) is the legacy architecture from the Windows 2000/XP era. A lot of graphics logic lives in win32k.sys with limited isolation—drivers can impact the whole system.
- WDDM (Windows Display Driver Model) arrived with Vista and became the default with Windows 8. It moves GPU management into dxgkrnl.sys (the DirectX graphics kernel) and communicates with vendor miniports via versioned interfaces (WDDM 1.0, 1.1, 1.2…). WDDM enables DWM, GPU virtual memory, scheduling, and user-mode driver components for robustness.
ReactOS still targets a NT 5.x-style kernel (XP/2003 vintage) and has spent years hardening XDDM—which, ironically, is still necessary even for WDDM. Why? Because Windows retains XDDM glue pieces that bridge win32k and the WDDM stack:
- TSDDD.dll is a minimal XDDM display driver loaded at session 0 to ensure a basic framebuffer exists.
- CDD.dll (Canonical Display Driver) is also XDDM, but it’s the translator and conduit between win32k and dxgkrnl. It issues IOCTLs that let the two worlds talk, and it enables safety nets like falling back to the Basic Display Driver if the vendor driver fails—avoiding the “video init failure” BSoD you can still hit on NT 5.x if no display driver loads.
Bottom line: To run WDDM properly, ReactOS must keep improving its XDDM path—because CDD stresses win32k and DWM also relies on kernel-mode capabilities that ReactOS is still building.
What ReactOS has working today
1) Bootstrapping WDDM miniports without dxgkrnl linking
WDDM miniports don’t link directly against dxgkrnl. Instead, they call into a WDK-supplied helper (displib.lib) to initialize Dxgkrnl, which then calls back into the miniport’s init routines to provide the interface vtable the driver needs. ReactOS built an alternate implementation so it can compile and import WDDM drivers—even in Windows—establishing a clean foothold.
2) A “minimal dxgkrnl” for display-only
Full dxgkrnl is a beast (scheduler, memory manager, sync, queues). For display output, you can get surprisingly far with VidPN (Video Present Network) and its hardware plumbing. ReactOS implemented just enough to query modes from the miniport, pass them to CDD, and activate CDD when dxgkrnl spins up. With that, the WDK Basic Display Adapter sample renders on ReactOS.
3) Vendor drivers in display-only mode
The biggest surprise: WDDM is fairly forgiving. The team was able to start vendor drivers (e.g., an NVIDIA Windows 7 driver) in 2D/display-only mode and get signal out at native resolutions/refresh rates. The next blocker wasn’t win32k—it was ReactOS’s hardware support (PCIe, ACPI, buses), which the project is already improving.
What’s not there (yet)
- 3D acceleration & D3DKMT: ReactOS can load OpenGL and Vulkan ICDs (and demonstrates Vista’s opengl32.dll and MESA Vulkan ICD loading), but D3DKMT APIs plus the dxgkrnl memory/scheduler subsystems needed for Direct3D aren’t implemented.
- DWM: The Desktop Window Manager depends on kernel-mode capabilities current ReactOS win32k doesn’t fully expose. The team acknowledges DWM needs its own article—and more kernel work.
A pragmatic stepping stone is KMDOD (Kernel Mode Display-Only Driver), introduced in Windows 8: a WDDM-style miniport that drops 3D and focuses on display. It’s simpler, uses fewer dxgkrnl interfaces, and is a perfect foundation to stabilize WDDM display while the rest of the stack matures.
Why this matters—even if you won’t daily-drive ReactOS
- Driver availability: Modern Windows only ships WDDM drivers. Supporting WDDM is table stakes for new GPUs and contemporary monitors.
- System resilience: WDDM user-mode components and GPU virtual memory reduce whole-OS crashes from driver faults.
- Open NT lab: ReactOS is the only open-source OS that aims to run Windows software and drivers natively. Cracking WDDM is one of its tallest walls. This is the first foothold.
The road ahead (and how to help)
The plan is clear:
- Keep strengthening XDDM (so CDD and win32k can carry WDDM’s load).
- Adopt KMDOD patterns to lock down display-only WDDM.
- Expand hardware support (PCIe, ACPI, bus/interrupt handling).
- Grow dxgkrnl (VidPN, memory, scheduler, D3DKMT).
- Tackle DWM when win32k is ready.
The ReactOS team is publishing more WDDM/hardware posts and welcomes donations, code contributions on GitHub, and word-of-mouth. If you care about an open, Windows-compatible kernel that can run native drivers, this is your moment to nudge it forward.
TL;DR: ReactOS can now load WDDM miniports and render display output—even with some legacy NVIDIA drivers—at native resolutions. It’s not 3D and it’s not DWM, but it’s the first real bridge to the post-Vista graphics model. On the day Windows 10 signs off, the timing is poetic: the open clone just learned to speak the modern Windows graphics dialect.
