- WDDM przenosi zarządzanie GPU do Dxgkrnl i miniportów, z dala od Win32k.
- ReactOS już się uruchamia sterowniki WDDM wyświetla i negocjuje tryby poprzez VidPn i CDD.
- Solidny stos XDDM pozostaje koniecznością dla postępu w WDDM i DWM.
- ReactOS 0.4.15 ulepszył sterowniki, LiveUSB, zwiększył wydajność i jest zgodny z architekturą amd64.
ReactOS jest rozwijany już tak długo, że wielu obecnych współpracowników nie było jeszcze na świecie, gdy projekt się zaczynał. Mimo to jego cel pozostaje niezmienny: zapewnić środowisko ABI zgodne z Windows zdolny do obsługi oprogramowania i sterowników zaprojektowanych dla systemu Microsoft. W ostatnich latach jednym z najbardziej ambitnych celów projektu było nadrobienie zaległości w zakresie wsparcia dla sprzęt komputerowy.
Ten proces doprowadził do kluczowego celu: zbliżenia się do nowoczesnej architektury sterowników graficznych systemu Windows. Mowa o WDDM, modelu, który zastąpił XDDM od czasów Visty. W ekosystemie ReactOS, Poznanie WDDM oznacza zrozumienie, jak zmieniło się zarządzanie GPU, które części systemu zostały zrestrukturyzowane i dlaczego nie wystarczy po prostu „aktywować” sterownika, aby wszystko działało jak w systemie Windows.
Czym jest WDDM i dlaczego ma znaczenie
WDDM (Windows Display Driver Model) wprowadził gruntowną przebudowę stosu graficznego: przeniesiono kontrolę nad GPU z komponentów takich jak Win32k do dedykowanego rdzenia (Dxgkrnl.sys), który komunikuje się z miniportami producenta. Każda wersja (1.0, 1.1, 1.2 i nowsze) definiuje, jakie interfejsy oferuje system i jak są one implementowane – koncepcja ta różni się od poziomów funkcji Direct3D widocznych w DxDiag.
Ta bardziej modułowa i wymagająca architektura wykracza poza to, co oferował XDDM. W WDDM, Dxgkrnl działa jako orkiestrator, a sterownik dostawcy ułatwia jasne punkty wejścia i kontrakty. To rozdzielenie pozwala na wprowadzenie ulepszeń, takich jak wirtualizowana pamięć wideo, harmonogram GPU i, ogólnie rzecz biorąc, większa stabilność dzięki przeniesieniu części logiki do trybu użytkownika.
Przez lata brakowało praktycznej dokumentacji dotyczącej dogłębnego rozwoju sterowników wideo dla obu architektur, co hamowało postęp. Wraz z rozwojem otwartych sterowników GPU, społeczność zyskała realne punkty odniesienia aby zrozumieć jak zachowują się OpenGL ICD, jak obsługuje Vulkan i jak modelują przejścia.
Co się stało z XDDM? Zgodność, resztki i punkt krytyczny
Od wersji Windows 8 system wymaga, aby sterownik GPU obsługiwał WDDM; jednak XDDM nie zniknął całkowicieSystemy Windows Vista i 7 umożliwiały ładowanie sterowników XDDM bez żadnych problemów, a z WDDM nadal współistnieją przestarzałe mechanizmy. Na przykład moduł ładujący karty ICD OpenGL praktycznie nie zmienił się między wersjami.
Komunikacja w WDDM z miniportem jest bardziej bezpośrednia. Win32k zachowuje skok wywołania systemowego, który Dxgkrnl wypełnia się odpowiednim interfejsem, zmniejszając zaangażowanie starego podsystemu w logikę GPU. W rzeczywistości, podczas rozruchu systemu, obserwuje się określone procedury łączące WDDM ze starym środowiskiem Win32k bez użycia architektur interfejsowych.
Istnieją dwa sterowniki ekranu, które powinieneś znać szczegółowo: TSDDD.dll i CDD.dll. Pierwszy, TSDDD, Jest ładowany ręcznie w sesji 0 To bardzo podstawowy sterownik XDDM, który praktycznie nie zapisuje danych do pustej pamięci. W rodzinie NT5.x (stanowiącej podstawę ReactOS) nieudana inicjalizacja wideo często powoduje błąd sprawdzający awarię wideo; w systemie Vista i nowszych ta „rzeczywista” sytuacja nie występuje już dzięki drugiemu komponentowi.
Ciekawostką jest plik CDD.dll. Działając jako sterownik XDDM, wysyła on IOCTL-e, aby komunikować się z WDDM. To jedyny sposób. Dxgkrnl i Win32k komunikują się w sposób znaczący Podczas nowoczesnej operacji graficznej. Podczas inicjalizacji Win32k pyta o adaptery, ale odpowiedź jest nadpisywana przez plik cdd.dll, co zapewnia mostek do WDDM. Kluczowa kwestia: po włączeniu WDDM nie jest możliwe równoległe uruchomienie sterownika XDDM.
OpenGL ICD, Vulkan i związek z systemem
Moduły OpenGL ICD są ładowane przy użyciu tradycyjnego modułu i jego przepływ nie zmienia się nadmiernie między systemami Vista, 7, 8 i nowszymi, co ułatwiło testy krzyżowe z wykorzystaniem układów ICD z różnych generacji. Vulkan zachowuje się podobnie: system deleguje interakcję z GPU do tych warstw, ale w WDDM miniport i Dxgkrnl ustanawiają faktyczny „kontrakt” sprzętowy.
Ta hybrydowa struktura wyjaśnia, dlaczego w komponentach systemu nadal można zaobserwować pozostałości XDDM współistniejące z WDDM. Most CDD.dll pozwala systemowi Win32k nadal pełnić jego klasyczną rolę, nie blokując nowoczesnej ścieżki, podczas gdy Dxgkrnl i miniport przejmują krytyczne zadanie zarządzania GPU.
Kompilacja sterowników WDDM do testowania w ReactOS
Aby uruchomić sterownik WDDM potrzebny jest element pomocniczy: displib.lib pakietu WDK, który udostępnia punkt wejścia w celu zainicjowania sterownika i „obudzić” Dxgkrnl bez wiązania się z nim. Przepływ jest specyficzny: wywoływane jest API inicjujące, struktury danych przekazywane są do Dxgkrnl, a następnie Dxgkrnl zwraca kontrolę, wywołując funkcję zwrotną boot z miniportu dostawcy.
To wywołanie zwrotne zapewnia interfejsy dla reszty komunikacji z Dxgkrnl. W tym momencie, Win32k nic nie maluje na początku miniportu, co stanowi zasadniczą różnicę w stosunku do świata XDDM. Ta adaptacja była łatwa do wdrożenia w ReactOS, otwierając drzwi do importowania i kompilacji sterowników WDDM, które nadal działają w systemie Windows.
WDDM w ReactOS: nacisk na ekran
Interfejsy API D3DKMT służą do przyspieszenia DirectX i OpenGL, dlatego w pierwszym eksperymencie na ReactOS zdecydowaliśmy się na Skup się na podstawach: uzyskaniu wyjścia wideoTutaj właśnie w grę wchodzi wszechświat VidPn (Video Presentation Network) i powiązane z nim wsparcie sprzętowe w ramach Dxgkrnl.
Od Windows 8 istnieją tzw. KMDOD, wariant miniportów WDDM, który rezygnują z przyspieszenia 3DSą łatwiejsze do zrozumienia i rozpoczęcia pracy: umożliwiają zarządzanie trybami wideo, monitorami i trajektoriami bez polegania na planiście i innych złożonych podsystemach Dxgkrnl.
W przypadku ReactOS eksperyment polegał na stworzeniu minimalnego pliku Dxgkrnl, który miałby za pośrednictwem VidPn sprawdzać dostępne tryby, przekazywać je do CDD i aktywować CDD, gdy Dxgkrnl był gotowy. Wynik: system zaczął komunikować się ze swoim pierwszym sterownikiem WDDM teraz pokaż obraz w rzeczywistych warunkach.
Pierwsze sukcesy: BasicDisplay.sys i sterowniki dostawców
Podczas ładowania pliku BasicDisplay.sys do ReactOS, konkluzja była niespodziewanie pozytywna: WDDM okazał się bardziej tolerancyjny niż oczekiwanoMożliwe było nawet uruchomienie sterowników dostawców wyłącznie dla tej części wyświetlacza, bez wymagania od nich obsługi akceleracji 3D.
W późniejszych testach wyjścia wideo pojawiły się z większą liczbą sterowników, w tym ze sterownikiem dla Nvidia z epoki Windows 7, co umożliwiło ReactOS Przenieś nowoczesne monitory do ich natywnej rozdzielczości i częstotliwościWąskim gardłem nie był Win32k, lecz faktyczne wsparcie sprzętowe, które jest wciąż rozszerzane.
Dlaczego XDDM nadal ma kluczowe znaczenie na drodze do WDDM
Chociaż ostatecznym celem jest WDDM, ReactOS wymaga, aby stos XDDM był w bardzo dobrym stanie. Powód jest taki, że komponenty takie jak CDD.dll i sam DWM Zależą one od sprawnego działania starego systemu, aby wypełnić lukę między starym a nowym. W rzeczywistości DWM stawia wymagania, których obecna implementacja Win32k w ReactOS nie jest jeszcze w stanie w pełni spełnić, mimo że postęp jest ciągły.
Przyspieszono także obsługę procesorów graficznych AMD w ramach XDDM, co stanowi ważny krok w kierunku stabilizacji sytuacji przed otwierając drogę do bardziej złożonych sterowników WDDMWybrana ścieżka ma charakter przyrostowy: najpierw ekran i tryby, a następnie więcej elementów układanki.
Kluczowe różnice między XDDM i WDDM
Jedną z najbardziej znaczących zmian w przejściu z XDDM na WDDM jest obsługa błędów. W przypadku WDDM znaczna część logiki sterownika jest przenoszona do trybu użytkownika, co oznacza, że Wypadek kierowcy nie musi powodować awarii systemu. kompletne. Ponadto harmonogram GPU i wirtualizowana pamięć umożliwiają bardziej precyzyjną alokację zasobów.
W XDDM Win32k miał znacznie większy ciężar, a komunikacja ze sprzętem była bardziej sztywna. W WDDM, Dxgkrnl narzuca jasną umowę miniportom, a Win32k pozostaje pomostem do podsystemu okienkowego. Umożliwia to nowe możliwości, takie jak DWM, kompozycja i bardziej niezawodne prezentacje.
- Planowanie i izolacja pracy GPU w porównaniu z monolitycznym podejściem XDDM.
- Wirtualna pamięć wideo i lepsze zarządzanie współdzielonymi zasobami.
- Zwiększona stabilność podczas migracji logiki sterownika do trybu użytkownika.
- Integracja z DWM i nowoczesnych tras prezentacji.
Obecne ograniczenia i prace w toku
Choć obsługa sterownika wyświetlacza WDDM w ReactOS jest już rzeczywistością testową, kompatybilność sprzętowa nadal dyktuje tempo. Prawdziwe urządzenia wymagają bardzo specyficznych podpór, a każdy skok wymaga rozbudowy podsystemów: od plug and play po zarządzanie pamięcią i systemy nadzorujące.
Podczas uruchamiania obserwuje się również komunikację pomiędzy watchdog, Win32k i Dxgkrnl aby przygotować się do wysłania interfejsów API D3DKMT w ramach Dxgkrnl. Jest to konkretny krok inicjalizacji, ale wiąże się z dodatkowymi wymaganiami, jeśli chodzi o wierne odtworzenie zachowania systemu Windows.
Status projektu, społeczność i zaproszenie do współpracy
Ostatniemu dążeniu do WDDM towarzyszyła większa aktywność w obszarze sprzętu. Istnieją artykuły techniczne szczegółowo opisujące ten proces i Można nas wspierać poprzez darowizny, GitHub lub poprzez działania informacyjne.To duży front o dużym zasięgu: każdy miniport i każda trasa prezentacji dodaje niuansów.
Warto przy okazji przypomnieć charakter projektu: ReactOS nie Linux ni Unix. Dla analiza porównawcza, został napisany od podstaw tak, aby był binarnie kompatybilny z systemem Windows, co pozwala na uruchamianie oprogramowania i sterowników Windows bezpośrednio bez konieczności korzystania z warstw kompatybilności, takich jak Wine/Proton, chociaż projekt współpracuje także z ekosystemem FOSS w celu uzyskania lepszych wyników.
Praktyczne wiadomości: ReactOS 0.4.15 i usprawnienia systemu
Oprócz WDDM wersja 0.4.15 przyniosła sporą partię zmian: nowi kierowcy magazynowanie które poprawiają stabilność i kompatybilność z jednostkami USB, a także zaktualizowane sterowniki sieciowe. Zmodyfikowano również czcionki, powłokę pulpitu, interfejsy API systemu Windows, motywy i okna dialogowe.
Wprowadzono ulepszenia w zakresie pamięci podręcznej i zarządzania pamięcią, które wpływają na wydajność. Ponadto, Dodano obsługę LiveUSB Po gruntownej modyfikacji menedżera Plug and Play jądra, otwierającej drzwi do większej liczby sterowników innych firm, graficzny interfejs użytkownika przeszedł drobne zmiany, dzięki którym jest łatwiejszy w użyciu w porównaniu z instalatorem tekstowym USETUP.
W sekcji audio możliwe jest teraz rozpoczęcie korzystania ze stosu dźwięków systemu Windows, chociaż nadal są ostre krawędzie do wygładzeniaWarto również zauważyć, że wersja 0.4.15 jest pierwszą wersją obsługującą architekturę 64-bitową (amd64) aż do komputerów stacjonarnych, chociaż nie ma jeszcze oficjalnego obrazu 64-bitowego, ponieważ prace nad WOW64 wciąż trwają.
Naprawiono wiele błędów: nieprawidłowo przypisane ikony pulpitu Rozwiązane problemy obejmują ulepszone ikony na pasku zadań i natywną obsługę plików ZIP. Wszystko to ma na celu poprawę podstawowego doświadczenia użytkownika przy jednoczesnym zapewnieniu zgodności sprzętowej.
Pobieranie, instalacja i minimalne wymagania
Obrazy ReactOS 0.4.15 są dostępne na SourceForge. Możliwe test na maszynie wirtualnej (zalecane dla początkujących) lub zainstaluj na prawdziwym sprzęcie za pomocą dysku USB utworzonego za pomocą narzędzi takich jak Rufus, tak jak zrobiłbyś to w przypadku standardowego systemu Windows.
Wymagania są skromne: procesor x86 (Pentium lub nowszy), 64 MB pamięci RAM, co najmniej 450 MB miejsca na dysku w partycji FAT16/FAT32 i około 2 GB dodatkowo Jeśli planujesz instalację oprogramowania lub gier, te minimalne wymagania pozwolą na uruchomienie systemu w scenariuszach testowych na komputerach z ostatniej dekady, a nawet starszych.
Zalecenia dotyczące użytkowania i realistyczne oczekiwania
Na dzień dzisiejszy ReactOS jest projektem eksperymentalnym. Nie zaleca się go jako podstawowego systemu operacyjnego, jeśli potrzebujesz nowoczesne funkcje i pełną kompatybilność z najnowszymi aplikacjami. Do uruchamiania nowszego oprogramowania Wine/Proton na Linuksie pozostaje bardzo stabilną opcją z bogatym ekosystemem wsparcia.
Mimo wszystko wyjątkowość ReactOS sprawia, że jest to Jedyny otwarty system, który obsługuje pliki binarne systemu Windows bez żadnego oprogramowania pośredniczącego w stylu emulatora. Takie podejście jest interesujące dla laboratoriów, w celu zapewnienia wstecznej kompatybilności, analiz i środowisk kontrolowanych, w których konieczne jest badanie zachowania aplikacji i sterowników.
Kontekst społeczności i wspólne przesłania
Na forach i w przestrzeniach społecznościowych często można zobaczyć przypomnienia takie jak: ReactOS to system komputerowy, który może uruchamiać programy i sterowniki systemu Windows. Czasami wyświetlane są również liczniki członków i użytkowników online, które są prostymi wskaźnikami żywotności społeczności, ale bez wartości technicznej wskazują na rosnące zainteresowanie projektem.
Ostatnie doniesienia medialne wskazywały nawet na zbieżność czasową pomiędzy końcem wsparcia dla niektórych wersji systemu Windows a Postęp ReactOS w kierunku WDDMTo coś więcej niż ironia – to znak, że społeczność ustala priorytety, aby pozostać na bieżąco z najnowszym sprzętem i sterownikami.
Ostatecznie wszystkie te wysiłki zmierzają do jednego punktu: zbuduj solidny fundament gdzie WDDM może się zadomowić bez porzucania dziedzictwa XDDM, które wciąż stanowi spoiwo między światami. Z CDD.dll jako mostem, Dxgkrnl jako mózgiem i miniportami lepiej zrozumianymi dzięki otwartym sterownikom, droga jest utorowana, choć wciąż jest wiele do zrobienia.
Biorąc pod uwagę powyższe, obsługa WDDM w ReactOS zmienia się z mglistej obietnicy w zestaw konkretnych kamieni milowych: Sterowniki wyświetlacza, które się uruchamiają, tryby, które dobrze się integrują, i monitory, które działają w pełnej rozdzielczościTrzeba zwiększyć skalę kompatybilności sprzętu, dokończyć takie elementy jak WOW64, a Win32k i DWM nadal udoskonalać. Kierunek jest jednak jasny i społeczność już działa w tym kierunku.
Pisarz z pasją zajmujący się światem bajtów i technologii w ogóle. Uwielbiam dzielić się swoją wiedzą poprzez pisanie i właśnie to będę robić na tym blogu, pokazywać Ci wszystkie najciekawsze rzeczy o gadżetach, oprogramowaniu, sprzęcie, trendach technologicznych i nie tylko. Moim celem jest pomóc Ci poruszać się po cyfrowym świecie w prosty i zabawny sposób.