Supporto ReactOS e WDDM: stato, sfide e progressi

ReactOS è in fase di sviluppo da così tanto tempo che molti degli attuali collaboratori non erano nemmeno nati quando è iniziato, ma il suo obiettivo rimane invariato: fornire un'esperienza ABI compatibile con Windows in grado di eseguire software e driver progettati per il sistema Microsoft. Negli ultimi anni, uno degli obiettivi più ambiziosi del progetto è stato quello di recuperare il ritardo nel supporto per hardware.

Questo processo ha portato a un obiettivo chiave: avvicinarsi all'architettura moderna dei driver grafici di Windows. Stiamo parlando di WDDM, il modello che ha sostituito XDDM a partire dall'era di Vista. All'interno dell'ecosistema ReactOS, Esplorare WDDM significa capire come è cambiata la gestione della GPU, quali parti del sistema sono state ristrutturate e perché non basta semplicemente "attivare" un driver per far funzionare tutto come in Windows.

Cos'è WDDM e perché fa la differenza

Articolo correlato:

Tutto ciò che ReactOS non può fare contro Windows: un'analisi completa e aggiornata

WDDM, Windows Display Driver Model, ha introdotto una profonda revisione dello stack grafico: ha spostato il controllo della GPU da componenti come Win32k a un core dedicato (Dxgkrnl.sys) che comunica con le miniport del produttore. Ogni revisione (1.0, 1.1, 1.2 e successive) definisce quali interfacce offre il sistema e come vengono implementate, un concetto diverso dai livelli di funzionalità Direct3D presenti in DxDiag.

Questa architettura più modulare e impegnativa va oltre ciò che XDDM offriva. In WDDM, Dxgkrnl funge da orchestratoree il driver del fornitore semplifica la definizione di punti di ingresso e contratti. Questa separazione consente miglioramenti come la memoria video virtualizzata, uno scheduler GPU e, in generale, una maggiore stabilità, spostando parte della logica in modalità utente.

Per anni, la documentazione pratica per lo sviluppo approfondito di driver video è stata scarsa per entrambe le architetture, il che ha ostacolato il progresso. Con la maturità dei driver GPU aperti, la comunità ha acquisito riferimenti reali per comprendere il comportamento degli ICD OpenGL, il supporto Vulkan e le transizioni dei modelli.

Che fine ha fatto XDDM? Compatibilità, residui e punto di rottura

A partire da Windows 8, il sistema richiede che il driver GPU sia WDDM; tuttavia, XDDM non è scomparso completamenteWindows Vista e 7 consentivano il caricamento dei driver XDDM senza problemi, e ci sono ancora meccanismi legacy che coesistono con WDDM. Il modulo che carica gli ICD OpenGL, ad esempio, è rimasto pressoché invariato tra le versioni.

La comunicazione in WDDM con la miniporta è più diretta. Win32k mantiene un salto di syscall che Dxgkrnl si riempie con l'interfaccia appropriata, riducendo il coinvolgimento del vecchio sottosistema nella logica della GPU. Infatti, all'avvio del sistema, si osservano routine specifiche che collegano WDDM al vecchio mondo Win32k senza interfacciarsi con architetture.

Ci sono due driver video che dovresti conoscere in dettaglio: TSDDD.dll e CDD.dll. Il primo, TSDDD, Viene caricato manualmente nella sessione 0 ed è un driver XDDM molto elementare che scrive a malapena su una memoria vuota. Nella famiglia NT5.x (come base per ReactOS), un'inizializzazione video non riuscita spesso causa un bugcheck per errore video; in Vista e versioni successive, questa situazione "reale" non si verifica più grazie al secondo componente.

CDD.dll è quello interessante. Mentre agisce come driver XDDM, emette IOCTL per comunicare con WDDM. È l'unico modo Dxgkrnl e Win32k comunicano in modo significativo Durante le moderne operazioni grafiche. Durante l'inizializzazione, Win32k richiede gli adattatori, ma la risposta viene sovrascritta da cdd.dll, garantendo il bridge verso WDDM. Un punto critico: una volta abilitato WDDM, non è possibile eseguire un driver XDDM in parallelo.

OpenGL ICD, Vulkan e la relazione con il sistema

Gli ICD OpenGL vengono caricati utilizzando il modulo tradizionale e il suo flusso non varia eccessivamente tra Vista, 7, 8 e versioni successive, il che ha facilitato i test incrociati utilizzando ICD di generazioni diverse. Vulkan si comporta in modo simile: il sistema delega l'interazione con la GPU a questi livelli, ma in WDDM, il miniport e Dxgkrnl stabiliscono il "contratto" hardware effettivo.

Questa struttura ibrida spiega perché nei componenti del sistema vediamo ancora residui di XDDM coesistere con WDDM. Il bridge CDD.dll consente a Win32k di continuare a svolgere il suo ruolo classico senza bloccare il percorso moderno, mentre Dxgkrnl e miniport assumono il compito critico di gestire la GPU.

Compilazione dei driver WDDM per i test su ReactOS

Per avviare un driver WDDM è necessario un pezzo ausiliario: displib.lib del WDK, che espone il punto di ingresso per inizializzare il driver e "risveglia" Dxgkrnl senza vincolarlo. Il flusso è particolare: viene invocata l'API di inizializzazione, le strutture dati vengono passate a Dxgkrnl e quindi Dxgkrnl restituisce il controllo chiamando la callback di Boot dal miniport del provider.

Tale callback fornisce le interfacce per il resto della comunicazione con Dxgkrnl. A questo punto, Win32k non sembra niente all'inizio del miniport, il che rappresenta una differenza fondamentale rispetto al mondo XDDM. Questo adattamento è stato semplice da implementare in ReactOS, aprendo la strada all'importazione e alla compilazione di driver WDDM che continuano a funzionare anche su Windows.

WDDM in ReactOS: focus sullo schermo

Le API D3DKMT vengono utilizzate per l'accelerazione DirectX e OpenGL, quindi per il primo esperimento su ReactOS abbiamo optato per Concentrati sulle basi: ottenere l'output videoÈ qui che entrano in gioco l'universo VidPn (Video Presentation Network) e il relativo supporto hardware all'interno di Dxgkrnl.

Da Windows 8 esistono i cosiddetti KMDOD, una variante dei miniport WDDM che rinunciano all'accelerazione 3DSono più facili da capire e da usare: consentono di gestire modalità video, monitor e traiettorie senza dover ricorrere al planner e ad altri complessi sottosistemi Dxgkrnl.

Per ReactOS, l'esperimento consisteva nel creare un Dxgkrnl minimo che interrogasse le modalità disponibili tramite VidPn, le passasse a CDD e attivasse CDD quando Dxgkrnl fosse stato pronto. Il risultato: il sistema ha iniziato a comunicare con il suo primo driver WDDM ora mostra l'immagine in condizioni reali.

Primi successi: BasicDisplay.sys e driver del fornitore

Caricando BasicDisplay.sys in ReactOS, la conclusione è stata inaspettatamente positiva: Il WDDM si è rivelato più tollerante del previstoEra addirittura possibile lanciare driver del fornitore esclusivamente per la parte di visualizzazione, senza richiedere loro di supportare l'accelerazione 3D.

Nei test successivi, le uscite video sono apparse con più driver, incluso un driver per Nvidia dall'epoca di Windows 7, che ha permesso a ReactOS Spostare i monitor moderni alla loro risoluzione e frequenza nativeIl collo di bottiglia non era Win32k, ma il supporto hardware effettivo, che è ancora in fase di espansione.

Perché XDDM è ancora cruciale sulla strada verso WDDM

Anche se l'obiettivo finale è WDDM, ReactOS richiede che il suo stack XDDM sia in ottime condizioni. Il motivo è che componenti come CDD.dll e DWM stesso Dipendono dal buon funzionamento del vecchio mondo per colmare il divario tra il vecchio e il nuovo. Di fatto, DWM introduce requisiti che l'attuale implementazione Win32k in ReactOS non è ancora in grado di soddisfare pienamente, nonostante i continui progressi.

È stato accelerato anche il supporto per le GPU AMD sotto XDDM, un passo importante per stabilizzare il campo prima aprendo la strada a driver WDDM più complessiIl percorso scelto è incrementale: prima schermata e modalità, poi altri pezzi del puzzle.

Differenze chiave tra XDDM e WDDM

Uno dei cambiamenti più significativi nel passaggio da XDDM a WDDM è la gestione degli errori. Con WDDM, gran parte della logica del driver viene spostata in modalità utente, il che significa che Un incidente stradale non deve necessariamente mettere fuori uso il sistema. completo. Inoltre, lo scheduler GPU e la memoria virtualizzata consentono un'allocazione delle risorse più dettagliata.

In XDDM, Win32k aveva un peso molto maggiore e la comunicazione con l'hardware era più rigida. In WDDM, Dxgkrnl impone un contratto chiaro sui miniporti, e Win32k rimane un ponte verso il sottosistema a finestre. Ciò consente nuove funzionalità come DWM, compositing e presentazioni più affidabili.

• Pianificazione e isolamento del lavoro della GPU rispetto all'approccio monolitico di XDDM.
• Memoria video virtuale e una migliore gestione delle risorse condivise.
• Maggiore stabilità durante la migrazione della logica del driver alla modalità utente.
• Integrazione con DWM e percorsi di presentazione moderni.

Limitazioni attuali e lavori in corso

Sebbene il supporto dei driver di visualizzazione WDDM in ReactOS sia già una realtà in fase di test, la compatibilità hardware continua a dettare il passo. I dispositivi reali richiedono supporti molto specificie ogni salto richiede l'espansione dei sottosistemi: dal plug and play alla gestione della memoria e ai watchdog.

All'avvio si osserva anche la comunicazione tra watchdog, Win32k e Dxgkrnl per preparare l'invio delle API D3DKMT all'interno di Dxgkrnl; si tratta di una fase di inizializzazione specifica, ma aggiunge requisiti aggiuntivi quando si tratta di riprodurre fedelmente il comportamento di Windows.

Stato del progetto, comunità e richiesta di collaborazione

La recente spinta verso WDDM è stata accompagnata da una maggiore attività in ambito hardware. Esistono articoli tecnici che descrivono in dettaglio il processo e Si invitano i partecipanti a contribuire tramite donazioni, GitHub o attività di sensibilizzazione.Si tratta di un fronte ampio e di lunga distanza: ogni miniporto e ogni percorso di presentazione aggiungono sfumature.

Vale la pena ricordare, di sfuggita, la natura del progetto: ReactOS non Linux ni Unix. Per un analisi comparativa, è scritto da zero per essere compatibile a livello binario con Windows, consentendogli di eseguire software e driver Windows in modo nativo senza ricorrere a livelli di compatibilità come Wine/Proton, sebbene il progetto collabori anche con quell'ecosistema FOSS per migliorare i risultati.

Notizie pratiche: ReactOS 0.4.15 e miglioramenti del sistema

Oltre a WDDM, la versione 0.4.15 ha apportato una serie di modifiche: nuovi driver immagazzinamento che migliorano la stabilità e la compatibilità con le unità USB, oltre a driver di rete aggiornati. Sono stati apportati miglioramenti anche ai font, alla shell del desktop, alle API di Windows, ai temi e alle finestre di dialogo.

Sono stati apportati miglioramenti alla gestione della cache e della memoria che incidono sulle prestazioni. Inoltre, Aggiunto supporto LiveUSB In seguito a profonde modifiche al gestore Plug and Play del kernel, che hanno aperto le porte a un maggior numero di driver di terze parti, l'interfaccia grafica ha ricevuto piccole modifiche per renderla più facile da usare rispetto al programma di installazione USETUP basato su testo.

Nella sezione audio, è ora possibile iniziare con lo stack audio di Windows, sebbene ci sono ancora degli spigoli da smussareVale anche la pena notare che la versione 0.4.15 è la prima a supportare l'architettura a 64 bit (amd64) fino al desktop, anche se non esiste ancora un'immagine ufficiale a 64 bit perché WOW64 è ancora in fase di sviluppo.

Le correzioni dei bug sono state intense: icone del desktop assegnate in modo errato I problemi risolti includono icone migliorate nella barra delle applicazioni e supporto nativo per i file ZIP. Tutto ciò mira a migliorare l'esperienza utente di base, affrontando al contempo la compatibilità hardware.

Download, installazione e requisiti minimi

Le immagini di ReactOS 0.4.15 sono disponibili su SourceForge. È possibile test su macchina virtuale (consigliato per i principianti) oppure installarlo su hardware reale con un'unità USB creata con utility come Rufus, proprio come faresti con Windows standard.

I requisiti sono modesti: CPU x86 (Pentium o successivo), 64 MB di RAM, almeno 450 MB di spazio su disco su una partizione FAT16/FAT32 e circa 2 GB aggiuntivi Se si prevede di installare software o giochi, questi requisiti minimi consentono ai computer dell'ultimo decennio o anche più vecchi di eseguire il sistema in scenari di test.

Raccomandazioni per l'uso e aspettative realistiche

Al momento, ReactOS è un progetto sperimentale. Non è consigliato come sistema operativo primario se necessario. caratteristiche moderne e piena compatibilità con le applicazioni più recenti. Per l'esecuzione di software più recenti, Wine/Proton su Linux rimane una soluzione molto stabile con un ampio ecosistema di supporto.

Tuttavia, l'unicità di ReactOS lo rende il L'unico sistema aperto che esegue binari Windows senza alcun middleware stile emulatore. Questo approccio lo rende interessante per laboratori, compatibilità con le versioni precedenti, analisi e ambienti controllati in cui è necessario studiare il comportamento di applicazioni e driver.

Contesto della comunità e messaggi comuni

Nei forum e negli spazi social, è comune vedere promemoria come: ReactOS è un sistema per PC che può eseguire programmi e driver WindowsA volte vengono visualizzati anche i contatori dei membri e degli utenti online, semplici indicatori della vitalità della comunità che, senza valore tecnico, segnalano un crescente interesse per il progetto.

Recenti narrazioni mediatiche hanno addirittura evidenziato la coincidenza temporale tra la fine del supporto per alcune versioni di Windows e I progressi di ReactOS verso WDDMPiù che un'ironia, è un segnale che la community sta allineando le priorità per rimanere al passo con l'hardware e i driver attuali.

Alla fine, tutto questo sforzo converge verso un punto: costruire una solida base dove WDDM può affermarsi senza abbandonare l'eredità di XDDM che ancora funge da collante tra i mondi. Con CDD.dll come ponte, Dxgkrnl come cervello e le miniport meglio comprese grazie ai driver aperti, la strada è tracciata, anche se c'è ancora molto da fare.

Considerando tutto quanto sopra, il supporto WDDM in ReactOS si sta spostando da una vaga promessa a una serie di traguardi tangibili: Driver di visualizzazione che si avviano, modalità che negoziano bene e monitor che funzionano a piena risoluzioneLa compatibilità hardware deve essere ampliata, elementi come WOW64 devono essere completati e Win32k e DWM devono essere ulteriormente perfezionati, ma la direzione è chiara e la comunità sta già spingendo in quella direzione.

Isaac

Scrittore appassionato del mondo dei byte e della tecnologia in generale. Adoro condividere le mie conoscenze attraverso la scrittura, ed è quello che farò in questo blog, mostrarti tutte le cose più interessanti su gadget, software, hardware, tendenze tecnologiche e altro ancora. Il mio obiettivo è aiutarti a navigare nel mondo digitale in modo semplice e divertente.