ReactOS Development > Opis techniczny

Opis Techniczny

Wstęp

Architektura ReactOS'a oparta jest na tej znanej z Windows NT 4.0. Microsoft ogłaszał że architektura NT jest zmodyfikowanym mikro-jądrem (pomieszanie aspektów mikrokerneli i warstwowych systemów operacyjnych), jednak w ReactOS'ie inaczej pojmujemy tą architekturę. Budowa NT, a więc i ReactOS'a ,jest modułowa i warstwowa. Małe ślady mikrokernela w systemie nie wystarczą żeby całą architekturę nazwać zmodyfikowanym mikro-jądrem. W najniższej warstwie znajduje się "Executive", zawierający wszystko co uruchamiane jest w trybie jądra. Ponad Executive'm jest warstwa Chronionych Podsystemów. Owe podsystemy są implementacjami cech różnych systemów operacyjnych.

Executive

Executive jest wszystkim co działa w trybie jądra. Executive z grubsza można podzielić na: Warstwę Abstrakcji Sprzętu (Hardware Abstraction Layer, HAL), Sterowniki urządzeń, Kernel i Usługi Systemowe (wraz z podsystemem Win32). Wszystkie powyższe składniki działają w trybie jądra. HAL, Kernel i Usługi Systemowe są ogólnie przypisywane do Executive.

Warstwa Abstrakcji Sprzętu

Warstwa ta pozwala na uruchomienie kernela ReactOS'a na różnych płytach głównych x86. HAL wydziela kod specyficzny dla danej płyty głównej z kernela, tak więc różne płyty główne nie wymagają zmian w kernelu. Przykładami różnych systemów opartych na x86 mogą być zwykłe PC, japoński NEC PC98 czy x86 SGI Workstation.

Sterowniki urządzeń

Sterowniki urządzeń są rozszerzeniami do Executive, zależnymi od sprzętu. Pozwalają one na interakcję OS'u i urządzeń, jak i odwrotnie. ReactOS obecnie skupia się na zaimplementowaniu modelu sterowników Windows NT 4.0 . Model Sterownika Windows (Windows Driver Model, WDM) jest przede wszystkim związany z najbliższą przyszłością, jest on zestawem reguł według których można pisać przenośnie sterowniki do Windows'a.

Komunikacja

Sterowniki używają pakietów do komunikacji z kernelem i innymi urządzeniami. Pakiety są przesyłane przez Menedżera We/Wy (IO Manager, usługa systemowa) oraz korzystają z Pakietów Żądań We/Wy (IO Request Packets).

Kernel

Budowa kernela jest oparta na budowie jądra Micosoft Windows NT 4.0. W jej skład wchodzą Asynchroniczne Wywołania Procedur (Asynchronous Procedure Calls, APC), Wstrzymane Wywołania Procedur Deferred Procedure Calls, DPC), procesy, wątki, mutexy, semafory, spinlocki, kod czasowy i inne.

Usługi systemowe

W skład usług systemowych wchodzą: Menedżer We/Wy (IO Manager), Menedżer konfiguracji (Configuration Manager), Plug and Play, Menedżer zasilania (Power Manager), Menedżer Pamięci (Memory Manager), Wsparcie Executive (Executive Support), Menedżer Obiektów (Object Manager), Monitor Referencji Bezpieczeństwa (security reference monitor), struktura procesów (process structure), wywołanie procedur lokalnych (local procedure call), podsystem Win32.

Chronione Podsystemy

Chronione podsystemy pozwalają na uruchomienie "personaliów" różnych systemów operacyjnych ponad warstwą Executive. Pierwotnym celem ReactOS'a było zaimplementowanie podsystemu Win32, jednakże owy podsystem jest już zawarty w Executive i uruchamiany jest w trybie jądra, przez co nie musi być zawarty w Chronionych Podsystemach. Obecnie opracowywane podsystemy trybu użytkownika: POSIX, OS/2; Chronione Podsystemy potencjalnie opracowane w przyszłości: DOS (prawdopodobnie jako port FreeDOS OS); Graficzne Interfejsy dla Podsystemów wykonane z użyciem podsystemu Win32: sterowniki urządzeń graficznych Windows'a NT są ściśle powiązane z konstrukcją podsystemu Win32, przez co bezsensem jest łączenie podsystemów trybu użytkownika bezpośrednio ze sterownikami graficznymi. Dlatego też podsystemy te powinny korzystać z podsystemu Win32 działającego w trybie jądra. Nie oznacza to że podsystem musi być oparty na Menedżerze Okien Win32 (Win32 Window Manager), jednak powinien wykorzystywać grafiki podstawowe, dostarczane przez podsystem Win32.

Architektura Natywnego API

Architektura Natywnego API (Native API Architecture) w zwyczajnym rozumowaniu jest używana do wywołań usług działających w trybie jądra przez kod działający w trybie użytkownika. Jest to odpowiednikiem Interfejsu Wywołań Systemowych (System Call Interface) w większości systemów UNIX'owych. Microsoft Windows NT/2000/XP nie dostarcza programistom dokumentacji Architektury Natywnego API, muszą oni w zamian używać Win32 API. Odkąd ReactOS ma status Open Source nasze Natywne API jest otwarte dla programistów. Architektura Natywnego API zaimplementowana jest w NTDLL.dll. Poza wpisami Natywnego API trybu użytkownika, NTDLL.dll zawiera również kod rozpoczęcia procesu i ładowania modułu. Te wpisy wywołują KiSystemService w trybie jądra, która z kolei >>sprawdza (look up)<< usługę trybu jądra w tablicy systemowej: KiSystemServiceTable.

Kompatybilność docelowa

Oryginalnym celem dla ReactOS'a było osiągnięcie kompatybilności ze sterownikami i aplikacjami z Windows NT 4.0. Od tamtego czasu pojawił się Windows 2000 i Windows XP. Obydwa te systemy są sukcesorami Windows'a NT, dlatego też możemy stopniowo przesuwać naszą docelową kompatybilność, nie martwiąc się o architekturę (z grubsza się nie zmieni). Prawdę mówiąc wewnętrznie Windows 2000 przedstawia się jako Windows 5.0 a WindowsXP jako Windows 5.1. Zespół ReactOS zdecydował utrzymać Windows'a NT 4.0 jako oficjalny cel kompatybilności, dlatego że większość źródeł, książek i artykułów o technologii Windows NT/2000/XP jest napisanych dla Windows'a NT 4.0. Nie oznacza to wcale że późniejsze systemy NT nie będą obsługiwane w ReactOS'ie.