ReactOS- og WDDM-støtte: status, utfordringer og fremgang

ReactOS har vært under utvikling så lenge at mange av de nåværende bidragsyterne ikke engang var født da det startet, men målet forblir uendret: leverer en ABI-opplevelse som er kompatibel med Windows i stand til å kjøre programvare og drivere designet for Microsoft-systemet. I de senere årene har en av de mest ambisiøse frontene i prosjektet vært å ta igjen støtten for maskinvare.

Den prosessen har ført til et sentralt mål: å komme nærmere den moderne Windows-grafikkdriverarkitekturen. Vi snakker om WDDM, modellen som erstattet XDDM siden Vista-æraen. Innenfor ReactOS-økosystemet, Å utforske WDDM betyr å forstå hvordan GPU-administrasjon har endret seg, hvilke deler av systemet som ble omstrukturert og hvorfor det ikke er nok å bare «aktivere» en driver for å få alt til å fungere som i Windows.

Hva er WDDM og hvorfor det utgjør en forskjell

Relatert artikkel:

Alt ReactOS ikke kan gjøre mot Windows: En komplett, oppdatert analyse

WDDM, Windows Display Driver Model, introduserte en grundig overhaling av grafikkstakken: flyttet kontrollen over GPU-en fra komponenter som Win32k til en dedikert kjerne (Dxgkrnl.sys) som kommuniserer med produsentens miniporter. Hver revisjon (1.0, 1.1, 1.2 og senere) definerer hvilke grensesnitt systemet tilbyr og hvordan de implementeres, et konsept som er forskjellig fra Direct3D-funksjonsnivåene som sees i DxDiag.

Denne mer modulære og krevende arkitekturen går utover det XDDM tilbød. I WDDM, Dxgkrnl fungerer som orkestrator, og leverandørdriveren legger til rette for tydelige inngangspunkter og kontrakter. Denne separasjonen gir mulighet for forbedringer som virtualisert videominne, en GPU-planlegger og generelt større stabilitet ved å flytte noe av logikken til brukermodus.

I årevis var praktisk dokumentasjon for grundig utvikling av skjermdrivere mangelvare for begge arkitekturene, noe som hemmet fremgangen. Med modenheten til åpne GPU-drivere, samfunnet har fått reelle referanser for å forstå hvordan OpenGL ICD-er oppfører seg, Vulkan-støtte og modelloverganger.

Hva skjedde med XDDM? Kompatibilitet, rester og bristepunktet

Siden Windows 8 krever systemet at GPU-driveren er WDDM; XDDM forsvant ikke heltWindows Vista og 7 tillot innlasting av XDDM-drivere uten problemer, og det finnes fortsatt eldre mekanismer som sameksisterer med WDDM. Modulen som laster inn OpenGL ICD-er, for eksempel, endret seg knapt mellom versjoner.

Kommunikasjonen i WDDM til miniporten er mer direkte. Win32k beholder et syscall-hopp som Dxgkrnl fylles ut med riktig grensesnitt, noe som reduserer involveringen av det gamle delsystemet i GPU-logikken. Faktisk, når systemet starter opp, observeres spesifikke rutiner for å koble WDDM til den gamle Win32k-verdenen uten grensesnittarkitekturer.

Det finnes to skjermdrivere du bør kjenne til i detalj: TSDDD.dll og CDD.dll. Den første, TSDDD, Den lastes inn manuelt i økt 0 og det er en veldig grunnleggende XDDM-driver som knapt skriver til tomt minne. I NT5.x-familien (som grunnlag for ReactOS) resulterer en mislykket videoinitialisering ofte i en feilsjekk for videofeil; i Vista og senere oppstår ikke lenger denne "virkelige" situasjonen takket være den andre komponenten.

CDD.dll er den interessante. Mens den fungerer som en XDDM-driver, utsteder den IOCTL-er for å kommunisere med WDDM. Det er den eneste måten Dxgkrnl og Win32k kommuniserer meningsfullt under moderne grafisk drift. Under initialisering spør Win32k etter adaptere, men svaret overskrives av cdd.dll, som sikrer broen til WDDM. Et kritisk punkt: Når WDDM er aktivert, er det ikke mulig å kjøre en XDDM-driver parallelt.

OpenGL ICD, Vulkan og forholdet til systemet

OpenGL ICD-er lastes inn ved hjelp av den tradisjonelle modulen, og strømmen varierer ikke for mye mellom Vista, 7, 8 og senere, noe som muliggjorde krysstesting ved bruk av ICD-er fra forskjellige generasjoner. Vulkan oppfører seg på lignende måte: systemet delegerer interaksjon med GPU-en til disse lagene, men i WDDM etablerer miniporten og Dxgkrnl den faktiske maskinvare-"kontrakten".

Denne hybridstrukturen forklarer hvorfor vi fortsatt ser rester av XDDM som eksisterer sameksisterende med WDDM i systemkomponenter. CDD.dll-broen lar Win32k fortsette å oppfylle sin klassiske rolle uten å blokkere den moderne veien, mens Dxgkrnl og miniport tar over den kritiske oppgaven med å administrere GPU-en.

Kompilering av WDDM-drivere for testing på ReactOS

For å starte en WDDM-driver trenger du et hjelpeelement: displib.lib fra WDK, som eksponerer inngangspunktet for å initialisere driveren og «vekke» Dxgkrnl uten å binde mot den. Flyten er spesiell: initialiserings-API-et kalles, datastrukturer sendes til Dxgkrnl, og deretter returnerer Dxgkrnl kontrollen ved å kalle tilbakekallingen til boot fra leverandørens miniport.

Den tilbakekallingen gir grensesnittene for resten av kommunikasjonen med Dxgkrnl. På dette tidspunktet, Win32k maler ingenting i starten av miniporten, noe som er en fundamental forskjell fra XDDM-verdenen. Denne tilpasningen var enkel å implementere i ReactOS, og åpnet døren for å importere og kompilere WDDM-drivere som også fortsetter å fungere på Windows.

WDDM i ReactOS: Skjerm-først fokus

D3DKMT API-ene brukes til DirectX- og OpenGL-akselerasjon, så for det første eksperimentet på ReactOS valgte vi Fokuser på det grunnleggende: å få videoutgangDet er her VidPn-universet (Video Presentation Network) og den tilhørende maskinvarestøtten i Dxgkrnl kommer inn i bildet.

Siden Windows 8 finnes det såkalte KMDOD, en variant av WDDM-miniporter som de gir avkall på 3D-akselerasjonDe er enklere å forstå og komme i gang med: de lar deg administrere videomoduser, skjermer og baner uten å være avhengig av planleggeren og andre komplekse Dxgkrnl-undersystemer.

For ReactOS var eksperimentet å bygge en minimal Dxgkrnl som ville spørre de tilgjengelige modusene via VidPn, overlevere dem til CDD og aktivere CDD når Dxgkrnl var klar. Resultatet: Systemet begynte å snakke med sin første WDDM-driver Vis nå bildet under reelle forhold.

Første suksesser: BasicDisplay.sys og leverandørdrivere

Da jeg lastet BasicDisplay.sys inn i ReactOS, var konklusjonen uventet positiv: WDDM viste seg å være mer tolerant enn forventetDet var til og med mulig å lansere leverandørdrivere utelukkende for skjermdelen, uten at de måtte støtte 3D-akselerasjon.

I senere tester dukket det opp videoutganger med flere drivere, inkludert en driver for Nvidia fra æraen med Windows 7, som tillot ReactOS Flytt moderne skjermer til sin opprinnelige oppløsning og frekvensFlaskehalsen var ikke Win32k, men faktisk maskinvarestøtte, som fortsatt utvides.

Hvorfor XDDM fortsatt er avgjørende på veien mot WDDM

Selv om det endelige målet er WDDM, krever ReactOS at XDDM-stakken er i veldig god stand. Årsaken er at komponenter som CDD.dll og selve DWM De er avhengige av at den gamle verden fungerer bra for å bygge bro mellom den gamle og den nye. Faktisk introduserer DWM krav som den nåværende Win32k-implementeringen i ReactOS ennå ikke fullt ut kan oppfylle, selv om det fortsatt er fremgang.

Støtte for AMD GPU-er under XDDM har også blitt akselerert, et viktig skritt for å stabilisere feltet før åpner veien for mer komplekse WDDM-drivereDen valgte banen er trinnvis: først skjerm og moduser, deretter flere puslespillbrikker.

Viktige forskjeller mellom XDDM og WDDM

En av de mest bemerkelsesverdige endringene ved overgangen fra XDDM til WDDM er feilhåndtering. Med WDDM flyttes mye av driverlogikken til brukermodus, noe som betyr at En sjåførulykke trenger ikke å ødelegge systemet. fullført. I tillegg tillater GPU-planleggeren og virtualisert minne mer finmasket ressursallokering.

I XDDM hadde Win32k mye mer vekt, og kommunikasjonen med maskinvaren var mer stiv. I WDDM, Dxgkrnl pålegger miniporter en tydelig kontrakt, og Win32k forblir en bro til vindussystemet. Dette muliggjør nye funksjoner som DWM, komposisjon og mer pålitelige presentasjoner.

• Planlegging og isolasjon av GPU-arbeid kontra XDDMs monolittiske tilnærming.
• Virtuelt videominne og bedre forvaltning av delte ressurser.
• Økt stabilitet når du migrerer driverlogikk til brukermodus.
• Integrasjon med DWM og moderne presentasjonsruter.

Nåværende begrensninger og pågående arbeid

Selv om støtte for WDDM-skjermdrivere i ReactOS allerede er en realitet i testing, fortsetter maskinvarekompatibilitet å diktere tempoet. Ekte enheter krever svært spesifikk støtte, og hvert hopp krever voksende delsystemer: fra plug and play til minnehåndtering og watchdogs.

Ved oppstart observeres også kommunikasjon mellom vaktbikkje, Win32k og Dxgkrnl å forberede utsendelsen av D3DKMT API-ene i Dxgkrnl; dette er et spesifikt initialiseringstrinn, men det legger til ytterligere krav når det gjelder å gjengi Windows-oppførsel på en trofast måte.

Prosjektstatus, fellesskap og samarbeidsoppfordring

Den nylige utviklingen mot WDDM har blitt ledsaget av mer aktivitet rundt maskinvare. Det finnes tekniske artikler som beskriver prosessen og Bidrag inviteres via donasjoner, GitHub eller oppsøkende virksomhet.Dette er en stor front med lang avstand: hver miniport og hver presentasjonsrute tilfører nyanser.

Det er verdt å huske, i forbifarten, prosjektets natur: ReactOS ikke Linux ni Unix. For en komparativ analyse, er skrevet fra grunnen av for å være binærkompatibel med Windows, slik at den kan kjøre Windows-programvare og drivere direkte uten å ty til kompatibilitetslag som Wine/Proton, selv om prosjektet også samarbeider med det FOSS-økosystemet for å forbedre resultatene.

Praktiske nyheter: ReactOS 0.4.15 og systemforbedringer

Utover WDDM har versjon 0.4.15 medført en god del endringer: nye sjåfører lagring som forbedrer stabilitet og kompatibilitet med enheter USB, samt oppdaterte nettverksdrivere. Skrifter, skrivebordsskallet, Windows API-er, temaer og dialogbokser har også blitt justert.

Det er gjort forbedringer i mellombuffere og minnehåndtering som påvirker ytelsen. I tillegg, La til LiveUSB-støtte Etter dyptgående modifikasjoner av kjernens Plug and Play-behandler, som åpnet døren for flere tredjepartsdrivere, har det grafiske grensesnittet fått mindre justeringer for å gjøre det enklere å bruke sammenlignet med det tekstbaserte USETUP-installasjonsprogrammet.

I lyddelen er det nå mulig å starte med Windows-lydstakken, selv om det er fortsatt grove kanter som må glattes utDet er også verdt å merke seg at 0.4.15 er den første utgivelsen som støtter 64-bits arkitektur (amd64) opp til skrivebordet, selv om det ikke finnes noe offisielt 64-bits image ennå fordi WOW64 fortsatt er under arbeid.

Feilrettingene har vært omfattende: feilaktig tilordnede skrivebordsikoner Løste problemer inkluderer forbedrede ikoner på oppgavelinjen og støtte for innebygd ZIP-fil. Alt dette har som mål å forbedre den grunnleggende brukeropplevelsen samtidig som det ivaretar maskinvarekompatibilitet.

Nedlasting, installasjon og minimumskrav

ReactOS 0.4.15-bilder er tilgjengelige på SourceForge. Det er mulig test på virtuell maskin (anbefales for nybegynnere) eller installer på ekte maskinvare med en USB-stasjon laget med verktøy som Rufus, akkurat som du ville gjort med standard Windows.

Kravene er beskjedne: x86 CPU (Pentium eller nyere), 64 MB RAM, minst 450 MB diskplass på en FAT16/FAT32-partisjon og omtrent 2 GB ekstra Hvis du planlegger å installere programvare eller spill, tillater disse minimumskravene at datamaskiner fra det siste tiåret eller enda eldre kjører systemet i testscenarioer.

Anbefalinger for bruk og realistiske forventninger

Per i dag er ReactOS et eksperimentelt prosjekt. Det anbefales ikke som primært operativsystem hvis du trenger det. moderne funksjoner og full kompatibilitet med nyere applikasjoner. For å kjøre nyere programvare er Wine/Proton på Linux fortsatt en veldig stabil rute med et stort støtteøkosystem.

Likevel gjør det unike med ReactOS det til Det eneste åpne systemet som kjører Windows-binærfiler uten mellomprogramvare emulatorstil. Denne tilnærmingen gjør den interessant for laboratorier, bakoverkompatibilitet, analyse og kontrollerte miljøer der oppførselen til applikasjoner og drivere må studeres.

Fellesskapskontekst og felles budskap

I forum og sosiale medier er det vanlig å se påminnelser som: ReactOS er et PC-system som kan kjøre Windows-programmer og drivereNoen ganger vises også medlems- og brukertellere på nett, enkle indikatorer på samfunnets vitalitet som, uten teknisk verdi, peker på økende interesse for prosjektet.

Nyere mediefortellinger har til og med påpekt det tidsmessige sammenfallet mellom slutten av støtten for noen versjoner av Windows og ReactOS' fremgang mot WDDMMer enn ironisk er det et tegn på at fellesskapet justerer prioriteringer for å forbli relevant med nåværende maskinvare og drivere.

Til slutt samles all denne innsatsen om ett punkt: bygge et solid fundament hvor WDDM kan etablere seg uten å forlate XDDM-arven som fortsatt fungerer som limet mellom verdener. Med CDD.dll som bro, Dxgkrnl som hjernen, og miniporter bedre forstått takket være åpne drivere, er veien banet, selv om det fortsatt er mye å dekke.

Når man ser på alt det ovennevnte, går WDDM-støtte i ReactOS fra et vagt løfte til et sett med konkrete milepæler: Skjermdrivere som starter, moduser som forhandler godt og skjermer som fungerer med full oppløsningMaskinkompatibilitet må skaleres, deler som WOW64 må fullføres, og Win32k og DWM må fortsette å finjusteres, men retningen er klar, og fellesskapet presser allerede i den retningen.

Isaac

Lidenskapelig forfatter om verden av bytes og teknologi generelt. Jeg elsker å dele kunnskapen min gjennom å skrive, og det er det jeg skal gjøre i denne bloggen, vise deg alle de mest interessante tingene om dingser, programvare, maskinvare, teknologiske trender og mer. Målet mitt er å hjelpe deg med å navigere i den digitale verden på en enkel og underholdende måte.