ReactOS- und WDDM-Unterstützung: Status, Herausforderungen und Fortschritt

ReactOS befindet sich schon so lange in Entwicklung, dass viele der heutigen Mitwirkenden bei Projektbeginn noch gar nicht geboren waren. Das Ziel bleibt jedoch unverändert: eine Windows -kompatible ABI-Umgebung zu bieten , die Software und Treiber für Microsofts Betriebssystem ausführen kann. In den letzten Jahren war die Integration von Hardwareunterstützung eine der ambitioniertesten Aufgaben des Projekts.

Dieser Prozess hat zu einem zentralen Ziel geführt: der Angleichung an die moderne Windows-Grafiktreiberarchitektur. Die Rede ist von WDDM, dem Modell, das XDDM in der Vista-Ära ablöste. Im ReactOS-Ökosystem bedeutet die Auseinandersetzung mit WDDM, zu verstehen, wie sich das GPU-Management verändert hat , welche Systemkomponenten umstrukturiert wurden und warum die einfache Aktivierung eines Treibers nicht ausreicht, um die gleiche Funktionalität wie unter Windows zu gewährleisten.

Was ist WDDM und warum macht es einen Unterschied?

In Verbindung stehender Artikel:

Alles, was ReactOS gegen Windows nicht kann: Eine vollständige, aktualisierte Analyse

WDDM (Windows Display Driver Model) revolutionierte die Grafikarchitektur: Die GPU-Steuerung wurde von Komponenten wie Win32k auf einen spezialisierten Kernel (Dxgkrnl.sys) verlagert, der mit den Miniports des Herstellers kommuniziert. Jede Revision (1.0, 1.1, 1.2 und nachfolgende Versionen) definiert die vom System bereitgestellten Schnittstellen und deren Implementierung – ein Konzept, das sich von den Direct3D-Funktionsebenen in DxDiag unterscheidet.

Diese modularere und anspruchsvollere Architektur geht über die Möglichkeiten von XDDM hinaus. In WDDM fungiert Dxgkrnl als Orchestrator , während der Herstellertreiber klare Einstiegspunkte und Schnittstellen bereitstellt. Diese Trennung ermöglicht Verbesserungen wie virtualisierten Videospeicher, einen GPU-Scheduler und allgemein eine höhere Stabilität, indem Teile der Logik in den Benutzermodus verlagert werden.

Jahrelang war die praktische Dokumentation für ein tieferes Verständnis von Videotreibern beider Architekturen rar, was den Fortschritt behinderte. Mit der zunehmenden Reife von Open-Source-GPU-Treibern hat die Community nun praxisnahe Referenzen erhalten , um das Verhalten von OpenGL-ICDs, die Vulkan-Unterstützung und die Übergänge zwischen verschiedenen Modellen zu verstehen.

Was ist mit XDDM passiert? Kompatibilität, Reste und der Bruchpunkt

Seit Windows 8 benötigt das System einen WDDM-Grafiktreiber; XDDM ist jedoch nicht vollständig verschwunden . Windows Vista und 7 ermöglichten das problemlose Laden von XDDM-Treibern, und einige ältere Mechanismen existieren weiterhin parallel zu WDDM. Das Modul zum Laden von OpenGL-ICDs hat sich beispielsweise zwischen den Versionen kaum verändert.

Die Kommunikation zwischen WDDM und dem Miniport ist direkter. Win32k behält einen Systemaufruf-Sprung bei, den Dxgkrnl mit der entsprechenden Schnittstelle füllt , wodurch die Beteiligung des alten Subsystems an der GPU-Logik reduziert wird. Tatsächlich werden beim Systemstart spezifische Routinen ausgeführt, um WDDM mit der alten Win32k-Welt zu verbinden, ohne die Architekturen zu vermischen.

Es gibt zwei Grafiktreiber, die genauer betrachtet werden sollten: TSDDD.dll und CDD.dll. Der erste, TSDDD, wird in Sitzung 0 manuell geladen und ist ein sehr einfacher XDDM-Treiber, der kaum in leeren Speicher schreibt. In der NT5.x-Familie (wie der ReactOS-Basis) führt eine fehlgeschlagene Videoinitialisierung üblicherweise zu einer Fehlerprüfung auf Videofehler; in Vista und späteren Versionen tritt diese Situation dank der zweiten Komponente nicht mehr auf.

Die CDD.dll ist von besonderem Interesse. Sie fungiert als XDDM-Treiber und sendet gleichzeitig IOCTLs zur Kommunikation mit WDDM. Nur so können Dxgkrnl und Win32k während des modernen Grafikbetriebs sinnvoll miteinander kommunizieren. Bei der Initialisierung fragt Win32k die Adapter ab, die Antwort wird jedoch von der CDD.dll überschrieben, wodurch die Verbindung zu WDDM hergestellt wird. Wichtig: Sobald WDDM aktiv ist, kann kein XDDM-Treiber parallel ausgeführt werden.

OpenGL ICD, Vulkan und die Beziehung zum System

OpenGL-ICDs werden über das herkömmliche Modul geladen, und ihr Ablauf unterscheidet sich zwischen Vista, 7, 8 und späteren Versionen nicht wesentlich , was Cross-Tests mit ICDs verschiedener Generationen ermöglichte. Vulkan verhält sich ähnlich: Das System delegiert die GPU-Interaktion an diese Schichten, aber in WDDM stellen der Miniport und Dxgkrnl den eigentlichen Hardware-„Vertrag“ her.

Diese Hybridstruktur erklärt, warum in Systemkomponenten noch immer Überreste von XDDM neben WDDM zu finden sind. Die CDD.dll-Brücke ermöglicht es Win32k, seine klassische Rolle weiterhin zu erfüllen, ohne den modernen Weg zu blockieren, während Dxgkrnl und der Miniport die kritische Aufgabe der GPU-Verwaltung übernehmen.

Kompilieren von WDDM-Treibern zum Testen auf ReactOS

Zum Starten eines WDDM-Treibers wird eine Hilfskomponente benötigt: die displib.lib des WDK. Diese stellt den Einstiegspunkt für die Initialisierung des Treibers und das „Aufwecken“ von Dxgkrnl bereit, ohne eine Bindung an diesen herzustellen. Der Ablauf ist festgelegt: Die Initialisierungs-API wird aufgerufen, Datenstrukturen werden an Dxgkrnl übergeben, und anschließend gibt Dxgkrnl die Kontrolle durch Aufruf der Miniport- Startfunktion des Herstellers zurück.

Dieser Callback stellt die Schnittstellen für die weitere Kommunikation mit Dxgkrnl bereit. Win32k spielt in den Anfangsphasen des Miniports keine Rolle , was einen grundlegenden Unterschied zur XDDM-Welt darstellt. Diese Anpassung ließ sich in ReactOS unkompliziert implementieren und ermöglichte so den Import und die Kompilierung von WDDM-Treibern, die auch weiterhin unter Windows funktionieren.

WDDM in ReactOS: Fokus auf den Bildschirm

Die D3DKMT-APIs dienen der DirectX- und OpenGL-Beschleunigung. Daher lag der Fokus des ersten Experiments unter ReactOS auf den Grundlagen: der Videoausgabe . Hier kommt das VidPn-Universum (Video Presentation Network) mit seiner zugehörigen Hardwareunterstützung innerhalb von Dxgkrnl ins Spiel.

Seit Windows 8 gibt es KMDODs, eine Variante der WDDM-Miniports, die auf 3D-Beschleunigung verzichten . Sie sind einfacher zu verstehen und zu verwenden: Sie ermöglichen die Verwaltung von Videomodi, Monitoren und Pfaden, ohne auf den Scheduler und andere komplexe Dxgkrnl-Subsysteme angewiesen zu sein.

Für ReactOS bestand das Experiment darin, ein minimales Dxgkrnl zu entwickeln, das die verfügbaren Modi über VidPn abfragte, sie an CDD weiterleitete und CDD aktivierte, sobald Dxgkrnl bereit war. Das Ergebnis: Das System begann mit seinem ersten WDDM-Treiber zu kommunizieren und unter realen Bedingungen ein Bild anzuzeigen.

Erste Erfolge: BasicDisplay.sys und Herstellertreiber

Das Laden von BasicDisplay.sys unter ReactOS lieferte unerwartet positive Ergebnisse: WDDM erwies sich als toleranter als erwartet . Es war sogar möglich, ausschließlich Treiber der Hersteller für die Anzeigekomponente zu starten, ohne 3D-Beschleunigung anzufordern.

In nachfolgenden Tests kamen weitere Videoausgänge mit Treibern zum Einsatz, darunter ein Nvidia- Treiber aus der Windows-7 -Ära , der es ReactOS ermöglichte , moderne Monitore mit ihrer nativen Auflösung und Bildwiederholfrequenz zu betreiben . Der Flaschenhals war nicht Win32k, sondern die noch immer wachsende Kompatibilität mit der tatsächlichen Hardware.

Warum XDDM auf dem Weg zu WDDM immer noch entscheidend ist

Obwohl WDDM das Endziel ist, benötigt ReactOS einen einwandfrei funktionierenden XDDM-Stack. Komponenten wie CDD.dll und DWM selbst sind nämlich darauf angewiesen, dass das alte System reibungslos funktioniert, um den Übergang zum neuen zu ermöglichen. Tatsächlich stellt DWM Anforderungen, die die aktuelle Win32k-Implementierung in ReactOS noch nicht vollständig erfüllen kann, obwohl Fortschritte erzielt werden.

Die Unterstützung für AMD-GPUs unter XDDM wurde ebenfalls beschleunigt – ein wichtiger Schritt zur Stabilisierung der Systemlandschaft, bevor komplexere WDDM-Treiber eingeführt werden . Der gewählte Ansatz ist inkrementell: Zuerst werden Anzeige und Modi implementiert, dann weitere Komponenten.

Wichtige Unterschiede zwischen XDDM und WDDM

Eine der wichtigsten Änderungen beim Wechsel von XDDM zu WDDM betrifft das Fehlermanagement. Bei WDDM wird ein Großteil der Treiberlogik in den Benutzermodus verlagert, sodass ein Treiberabsturz nicht zwangsläufig das gesamte System lahmlegt. Darüber hinaus ermöglichen der GPU-Scheduler und der virtualisierte Speicher eine präzisere Ressourcenzuweisung.

In XDDM hatte Win32k eine deutlich höhere Priorität, und die Kommunikation mit der Hardware war unflexibler. In WDDM definiert Dxgkrnl einen klaren Vertrag für die Miniports , und Win32k fungiert als Brücke für das Fenstersystem. Dies ermöglicht neue Funktionen wie DWM, Compositing und zuverlässigere Darstellungen.

• Planung und Isolation der GPU-Arbeit im Vergleich zum monolithischen Ansatz von XDDM.
• Virtueller Videospeicher und eine bessere Verwaltung gemeinsam genutzter Ressourcen.
• Erhöhte Stabilität beim Migrieren der Treiberlogik in den Benutzermodus.
• Integration mit DWM und moderne Präsentationswege.

Aktuelle Einschränkungen und laufende Arbeiten

Das Booten von WDDM-Displaytreibern unter ReactOS ist zwar in der Testphase bereits möglich, die Hardwarekompatibilität stellt jedoch weiterhin eine große Herausforderung dar. Geräte in der Praxis benötigen sehr spezifische Unterstützung , und jeder Fortschritt erfordert die Erweiterung von Subsystemen: von Plug-and-Play bis hin zu Speichermanagement und Watchdog-Timern.

Beim Start wird auch eine Kommunikation zwischen Watchdog, Win32k und Dxgkrnl beobachtet , um den Einsatz der D3DKMT-APIs innerhalb von Dxgkrnl vorzubereiten; dies ist ein spezifischer Initialisierungsmoment, der jedoch zusätzliche Anforderungen mit sich bringt, wenn es darum geht, das Verhalten von Windows originalgetreu nachzubilden.

Projektstatus, Community und Aufruf zur Zusammenarbeit

Die jüngsten Bemühungen um WDDM gingen mit verstärkten Aktivitäten rund um die Hardware einher. Es gibt Fachartikel, die den Prozess detailliert beschreiben und zu Beiträgen in Form von Spenden, GitHub oder Öffentlichkeitsarbeit einladen . Es handelt sich um ein umfangreiches und langfristiges Projekt: Jede Miniportierung und jeder Release-Pfad bringt neue Nuancen mit sich.

Man sollte übrigens den Charakter des Projekts bedenken: ReactOS ist weder Linux noch Unix . Zum Vergleich : Es wurde von Grund auf so entwickelt, dass es binärkompatibel mit Windows ist und somit Windows-Software und -Treiber nativ ausführen kann, ohne auf Kompatibilitätsschichten wie Wine/Proton zurückzugreifen. Das Projekt arbeitet jedoch auch mit diesem Open-Source-Ökosystem zusammen, um die Leistung zu verbessern.

Praktische Neuigkeiten: ReactOS 0.4.15 und Systemverbesserungen

Neben WDDM bietet Version 0.4.15 zahlreiche weitere Änderungen: Neue Speichertreiber verbessern die Stabilität und Kompatibilität mit USB- Laufwerken , und auch die Netzwerktreiber wurden aktualisiert. Schriftarten, die Desktop-Oberfläche, Windows-APIs, Designs und Dialogfelder wurden ebenfalls optimiert.

Verbesserungen beim Caching und Speichermanagement führten zu einer höheren Leistung. Zudem wurde nach umfangreichen Änderungen am Plug-and-Play-Manager des Kernels die Unterstützung für LiveUSB hinzugefügt , wodurch die Nutzung weiterer Treiber von Drittanbietern ermöglicht wird. Die grafische Benutzeroberfläche wurde leicht angepasst, um die Bedienung im Vergleich zum textbasierten USETUP-Installer zu vereinfachen.

Im Audiobereich kann man nun mit dem Windows-Soundstack arbeiten, obwohl es noch einige Unzulänglichkeiten gibt . Erwähnenswert ist auch, dass Version 0.4.15 die erste Version mit Unterstützung für die 64-Bit-Architektur (amd64) bis hin zum Desktop ist, obwohl es noch kein offizielles 64-Bit-Image gibt, da die Entwicklung von WOW64 noch läuft.

Die Fehlerbehebungen waren umfangreich: Falsch zugewiesene Desktop-Symbole wurden korrigiert, Taskleistensymbole in der Größe angepasst und native Unterstützung für ZIP-Dateien hinzugefügt. All dies zielt darauf ab, die Benutzerfreundlichkeit zu verbessern und gleichzeitig die Hardwarekompatibilität zu gewährleisten.

Download, Installation und Mindestanforderungen

ReactOS 0.4.15-Images sind auf SourceForge verfügbar. Sie können es in einer virtuellen Maschine ausprobieren (empfohlen für Anfänger) oder es auf physischer Hardware mithilfe eines USB-Sticks installieren, der mit Tools wie Rufus erstellt wurde, genau wie bei einer Standard-Windows-Installation.

Die Systemanforderungen sind moderat: ein x86-Prozessor (Pentium oder neuer), 64 MB RAM, mindestens 450 MB Festplattenspeicher (partitioniert als FAT16/FAT32) und zusätzlich 2 GB, falls Sie Software oder Spiele installieren möchten. Mit diesen Mindestanforderungen können Computer aus dem letzten Jahrzehnt oder sogar noch älter das System in Testszenarien ausführen.

Anwendungsempfehlungen und realistische Erwartungen

ReactOS ist derzeit ein experimentelles Projekt. Es wird nicht als primäres Betriebssystem empfohlen, wenn Sie moderne Funktionen und volle Kompatibilität mit aktuellen Anwendungen benötigen. Für neuere Software ist Wine/Proton unter Linux weiterhin eine sehr stabile Option mit einem großen Support-Ökosystem.

Trotzdem ist ReactOS aufgrund seiner einzigartigen Natur das einzige Open-Source-System, das Windows-Binärdateien ohne emulatorartige Zwischenschichten ausführen kann. Dieser Ansatz macht es interessant für Labore, Abwärtskompatibilität, Analysen und kontrollierte Umgebungen, in denen das Verhalten von Anwendungen und Treibern untersucht werden muss.

Gemeinschaftskontext und gemeinsame Botschaften

In Foren und sozialen Medien sieht man häufig Hinweise wie: ReactOS ist ein PC-Betriebssystem, das Windows-Programme und -Treiber ausführen kann . Manchmal werden auch Mitglieder- und Online-Nutzerzähler angezeigt – einfache Indikatoren für die Aktivität der Community, die zwar keinen technischen Wert haben, aber das wachsende Interesse am Projekt verdeutlichen.

Aktuelle Medienberichte weisen sogar auf die zeitliche Übereinstimmung zwischen dem Supportende für einige Windows-Versionen und den Fortschritten von ReactOS in Richtung WDDM hin . Dies ist weniger eine Ironie als vielmehr ein Zeichen dafür, dass die Community ihre Prioritäten anpasst, um mit aktueller Hardware und Treibern kompatibel zu bleiben.

Letztendlich läuft all diese Anstrengung auf ein einziges Ziel hinaus: die Schaffung einer soliden Grundlage, auf der WDDM Fuß fassen kann, ohne das Erbe von XDDM aufzugeben, das nach wie vor die Verbindung zwischen den Welten darstellt. Mit CDD.dll als Brücke, Dxgkrnl als zentralem Element und dank Open-Source-Treibern besser verständlichen Miniports ist der Weg geebnet, auch wenn noch einiges zu tun bleibt.

Angesichts all dessen entwickelt sich die WDDM-Unterstützung in ReactOS von einem vagen Versprechen zu einer Reihe greifbarer Meilensteine: Startfähige Displaytreiber, reibungslos funktionierende Modi und Monitore, die in voller Auflösung arbeiten . Es gibt zwar noch einiges zu tun, um die Hardwarekompatibilität zu erweitern, Komponenten wie WOW64 zu vervollständigen und Win32k und DWM weiter zu optimieren, aber die Richtung ist klar, und die Community treibt sie bereits voran.

Holger

Leidenschaftlicher Autor über die Welt der Bytes und der Technologie im Allgemeinen. Ich liebe es, mein Wissen durch Schreiben zu teilen, und genau das werde ich in diesem Blog tun und Ihnen die interessantesten Dinge über Gadgets, Software, Hardware, technologische Trends und mehr zeigen. Mein Ziel ist es, Ihnen dabei zu helfen, sich auf einfache und unterhaltsame Weise in der digitalen Welt zurechtzufinden.