Rozdział 2

Architektura Windows NT

Przegląd struktury systemu Windows NT

Omówienie struktury Windows NT wymaga zrozumienia takich
pojęć, jak: modułowość oraz klient/serwer.

Termin modułowość oznacza, że struktura rdzenia podzielona jest na
małe, samodzielne jednostki, służące wyraźnie określonym celom,
jak przedstawia to rysunek 2.1. Modułowość jest strukturą niezwykle
pożądaną we wszystkich aspektach programowania komputerowego,
a systemy operacyjne nie stanowią tu wyjątku. Kod modułowy jest
łatwiejszy w obsłudze, ponieważ posiada wyraźnie sprecyzowane
cele, a całe segmenty kodu można wymieniać, co nie ma żadnego
wpływu na procedury wykorzystujące go do usług.

Idea struktury modularnej przeciwstawna jest koncepcji struktury
monolitycznej, wykorzystywanej częściej przez poprzednie systemy
operacyjne. W architekturze monolitycznej system operacyjny pracuje
w uprzywilejowanym trybie pracy procesora, a segmenty kodu oferują

Jądro

Display

Zarządzanie

pamięcią i I/O

System

operacyjny

System plików

Sieć

Rys. 2.1.
Modułowa
struktura systemu
operacyjnego

92

Rozdział 2

często wiele funkcji, które nie są jasno sprecyzowane (rysunek 2.2).
Pozwala to na zmniejszenie ilości kodu, jednak kosztem elastyczności
systemu.

Wiele osób dowiadując się, że Windows NT jest systemem operacyj-
nym typu klient/serwer przyjmuje, że chodzi tu o możliwość jego
wykorzystania w bazach danych typu klient/serwer lub w systemach
sieciowych. Owszem, NT nadaje się do tych aplikacji doskonale, ale
nie w tym rzecz. Chodzi o to, że elementy NT komunikują się ze sobą
w oparciu o schemat klient/serwer. Mówiąc ściślej, termin klient/
serwer odnosi się do sposobu rozmieszczenia modułów, co pokazuje
rysunek 2.3. Za klienta uważa się tę część kodu, która akurat czegoś
potrzebuje. Serwerem zaś jest ta część kodu, która spełnia żądanie.
Rozpatrzmy to na przykładzie: klientem jest program użytkowy, który
zamierza utworzyć na ekranie rysunek. Za pomocą precyzyjnego
komunikatu prosi on inną część kodu (w tym przypadku
prawdopodobnie podsystem Win32) o wykonanie tego rysunku.
Win32 spełnia tutaj rolę serwera. Taka jest właśnie istota działania
systemu klient/serwer.

System operacyjny

Proces systemu

operacyjnego

Proces systemu

operacyjnego

Proces systemu

operacyjnego

Proces systemu

operacyjnego

Proces systemu

operacyjnego

Proces systemu

operacyjnego

Rys. 2.2.

Monolityczna

konstrukcja

systemu

operacyjnego.

Architektura Windows NT

93

Tryb użytkownika a tryb jądra (uprzywilejowany)

Wspólną cechą systemu NT i

innych współczesnych,

zaawansowanych systemów operacyjnych jest podział zadań na
różnorodne kategorie, skorelowane z

konkretnymi trybami

korzystającymi z mikroprocesora. Wiele obecnie produkowanych
mikroprocesorów wspomaga tryby wielokrotne (zwane często
pierścieniami), w których programy mogą być realizowane. Tryby te
nadają pracującym w

ich obrębie programom różne stopnie

uprzywilejowania, aby mogły one uzyskać dostęp do sprzętu i do
innych programów. Windows NT korzysta z

trybu

uprzywilejowanego, nazywanego także trybem jądra oraz z trybu
nieuprzywilejowanego - czyli trybu użytkownika. Komponenty
pracujące w trybie jądra mają bezpośredni dostęp do zasobów sprzętu
i

oprogramowania systemu. W

Windows NT tylko kluczowe

elementy mogą pracować w

trybie jądra - wymaga tego

bezpieczeństwo i stabilność systemu. Jedynym elementem Windows
NT, który działa w uprzywilejowanym trybie pracy procesora jest NT
Executive, zawierający mikrojądro, abstrakcyjną warstwę sprzętową
i programy obsługi urządzeń.

Uwaga: Przed nieupoważnionym dostępem aplikacje trybu jądra
chronione są przez samą konstrukcję mikroprocesora, natomiast
aplikacje trybu użytkownika chronione są wzajemnie konstrukcją
systemu operacyjnego.

Wszystkie programy nie pracujące w trybie jądra pracują w trybie
użytkownika. Większość kodu w Windows NT pracuje w trybie

Jądro

Tryb użytkownika

Tryb jądra

Klient

Aplikacja

Display

Zarządzanie

pamięcią i I/O

System plików

Sieć

Rys. 2.3.Struktura
systemu
operacyjnego
klient/serwer

94

Rozdział 2

użytkownika. Zalicza się tutaj takie podsystemy środowiska, jak
Win32, POSIX oraz wszystkie programy użytkowe. Programy te mają
dostęp tylko do swoich 32-bitowych przestrzeni adresowych pamięci
i kontaktują się z resztą systemu, przesyłając komunikaty metodą
klient/serwer, czym zajmiemy się później.

W przypadku Windows NT, twórcy projektu postarali się
zaprogramować pracę jak największej części systemu operacyjnego
w trybie użytkownika. Zapewniło to systemowi stabilność i ochronę,
stanowiąc jednocześnie ułatwienie w pracach nad modyfikacją
komponentów wewnętrznych.

Wraz z Windows NT 4 wprowadzono - w odniesieniu do poprzednich
wersji - znaczną zmianę strukturalną. Konstruktorzy przenieśli dwa
główne podsystemy - moduły USER i GDI (interfejs urządzeń
graficznych) - do NT Executive, pracującego w

trybie jądra.

Wykonano to celem zwiększenia wydajności i zmniejszenia kosztów
(aczkolwiek są tacy, którzy twierdzą, że kosztem stabilności).
Wspomniane zmiany konstrukcyjne omówione zostały w dalszej
części tego rozdziału.

Komponenty struktury NT

Aby zrozumieć zasady działania Windows NT, należy przyjrzeć się
poszczególnym jego elementom i

zachodzącym między nimi

interakcjom. Rysunek 2.4. przedstawia główne warstwy Windows NT
i ich wzajemne powiązania.

Cztery główne elementy architektury systemu Windows NT to:

1. Abstrakcyjna Warstwa sprzętowa (HAL)

2. Jądro

3. Usługi NT Executive

4. Podsystemy środowiska

Każdy element tego systemu pełni ściśle określone zadania
w Windows NT.

Architektura Windows NT

95

Abstrakcyjna warstwa sprzętowa

Abstrakcyjna warstwa sprzętowa (HAL) jest interfejsem
programowym pomiędzy sprzętem a

resztą systemu. HAL

funkcjonuje jako biblioteka dołączana dynamicznie (DLL)
i odpowiada za ochronę systemu NT przed takimi elementami, jak
sterowniki przerwań czy interfejsy I/O. Taki rozdział zwiększa
przenośność NT, gdyż dla reszty systemu operacyjnego nie jest
ważne, na jakiej platformie fizycznej pracuje. Każda platforma
sprzętowa, na której działa NT, wymaga określonej warstwy HAL.
Chodzi o to, że w momencie przenoszenia NT do nowej architektury
procesorowej, warstwa HAL zostaje przepisana dla nowego
procesora. Pozostała część systemu może zostać ponownie
skompilowana, co właśnie sprawia, że NT jest w ogromnym stopniu
systemem przenośnym.

Tryb użytkownika

Tryb jądra

Podsystem

Win32

Serwis usług

Usługi NT

Executive

Microkernel

Object

Manager

16-bitowa

aplikacja

Windows

32-bitowa

aplikacja

Windows

Proces

rejestracji

Aplikacja

OS/2

Podsystem

OS/2

Podsystem

bezpieczeń-

stwa

Aplikacja

POSIX

Podsystem

POSIX

NT Virtual

DOS Machine

(NT VDM)

NT Virtual

DOS Machine

(NT VDM)

Aplikacja

DOS

Windows w

Win32

(WOW)

Process

Manager

Virtual

Memory

Manager

I/O

Manager

Security

Reference

Monitor

Local

Procedure

Call Facility

Hardware Abstraction Layer

Hardware

Rys. 2.4. Struktura
systemu Windows
NT.

96

Rozdział 2

HAL zapewnia także interfejs dla wieloprzetwarzania symetrycznego
(SMP). Serwer NT łączy się z dwiema abstrakcyjnymi warstwami
sprzętowymi dla każdej struktury procesora (Intel, MIPS, Power PC
i Alpha). Pierwsza warstwa HAL służy do wsparcia pracy poje-
dynczego procesora, druga zaś może wspomagać maksymalnie cztery
procesory. Na rynku dostępne są dodatkowe warstwy wspomagające -
do 32 procesorów na NT Server.

W odniesienia do każdego procesora zainstalowanego w komputerze,
warstwa HAL tworzy zwirtualizowany procesor dla mikrojądra.
Chodzi tutaj o to, że zwirtualizowany procesor ukrywa przed
systemem operacyjnym specyfikę właściwego procesora. Gdybyśmy
na przykład mieli dwa systemy multiprocesorowe - jeden pracujący na
procesorach Intel Pentium, a drugi na DEC Alpha AXP - to w każdym
z nich abstrakcyjne warstwy sprzętowe byłyby inne, jednak tworzone
przez HAL dla jądra procesory zwirtualizowane w

obydwu

przypadkach byłyby takie same. W systemie SMP na każdy procesor
fizyczny przypada jeden procesor zwirtualizowany.

HAL istnieje po to, by zminimalizować zależności sprzętowe, zwięk-
szając przy tym przenośność NT. Jednak dzięki ograniczeniu
zależności sprzętowych do niezbędnego minimum, konstruktorom
tego systemu udało się zredukować czas i

wysiłek, związany

z przenoszeniem NT na nową platformę.

Uwaga: We wstępnej fazie rozwoju Windows NT oprogramowanie
było wykonywane na sprzęcie opartym o mikroprocesor RISC I860
firmy Intel. Z czasem jednak z mikroukładu tego zrezygnowano ze
względów konstrukcyjnych. Rozpoczęto natomiast prace nad nowym
zestawem układów MIPS (wyśmienity przykład przenośności systemu
operacyjnego NT).

Do warstwy HAL dostęp mają tylko elementy NT Executive i nigdy
nie jest ona wywoływana bezpośrednio przez programy trybu
użytkownika. Warstwa HAL jest też pomyślana jako jedyny program
w systemie NT, któremu wolno komunikować się bezpośrednio ze
sprzętem. Metoda taka wzmacnia znacznie model zabezpieczeń NT.

W Windows NT wszystkie wywołania związane ze sprzętem mają
przechodzić przez warstwę HAL. W praktyce jednak pewna liczba
wywołań programów obsługi i jądra omija warstwę HAL i bezpośred-
nio komunikuje się ze sprzętem.

Wadę modelu opartego o abstrakcyjną warstwę sprzętową stanowi
fakt, że HAL jest główną przyczyną niekompatybilności ze starszymi

Architektura Windows NT

97

programami DOS-u i Windows, które miały zwyczaj korzystania
bezpośrednio ze sprzętu. Niekompatybilność ta jest jednak
stosunkowo niską ceną za bezpieczeństwo i przenośność.

Jądro

Jądro systemu Windows NT można porównać do prezydenta Stanów
Zjednoczonych. Jest ono bezpośrednio odpowiedzialne za wszystkie
czynności odbywające się w systemie. Przez nie przechodzą niemal
wszystkie funkcje systemu. Windows NT korzysta z mikrojądra, co
oznacza, że jądro zostało zredukowane do poziomu, w którym
zawiera ono tylko podstawy niezbędne do funkcjonowania.

Uwaga: Nie należy mylić jądra (czy też mikrojądra) z trybem jądra.
Istnieje między nimi związek, ale nie są sobie tożsame. Jądro to
utajona część kodu tworząca rdzeń systemu operacyjnego. Tryb jądra
natomiast to uprzywilejowany status operacji wspierany przez mikro-
procesor. W Windows NT mikrojądro pracuje w trybie jądra, co
oznacza, że pracuje w uprzywilejowanym trybie procesora, gdzie
mikroprocesor odpowiedzialny jest za ochronę jądra przed
uszkodzeniem.

Mikrojądro w Windows NT wyznacza grupie programów o nazwie
NT Executive wiele funkcji, przydzielonych w

tradycyjnych

systemach operacyjnych dla jądra. NT Executive - którego częścią
jest mikrojądro NT - pracuje w uprzywilejowanym trybie procesora.
Mikrojądro NT komunikuje się z NT Executive poprzez zestaw
niskopoziomowych funkcji pierwotnych systemu operacyjnego.

Uwaga: Wątki i procesy zostały zdefiniowane w podrozdziale „Mene-
dżer procesów”.

Głównym zadaniem jądra w

Windows NT jest koordynacja

i szeregowanie wątków. Wątek to fragment kodu przyporządkowany
danemu procesowi. Każdy wątek posiada swój numer priorytetowy od
1 do 31. Jądro koordynuje przydział wątków do dostępnych proceso-
rów w oparciu o ich liczby priorytetowe. Następnie jądro pozwala
wątkom pracować przez określony czas, po czym wywłaszcza je
i umożliwia pracę innemu procesowi.

98

Rozdział 2

Uwaga: Można nieraz przeczytać, że jądro szereguje procesy. Nie jest
to wprawdzie sformułowanie poprawne pod względem technicznym,
ale jest powszechnie przyjęte. Tak naprawdę jądro nie szereguje
procesów, szereguje ono jedynie wątki w kontekście danego procesu.

Właśnie dzięki tej procedurze możliwe jest wywłaszczanie
wielozadaniowe. Jądro nie może być wywłaszczone, ponieważ to ono
szereguje wykonanie kodu w

systemie. Nie może także być

przeniesione na dysk (w ramach pamięci wirtualnej).

W systemie wieloprocesorowym na każdym procesorze pracuje jeden
egzemplarz danego jądra. Można w ten sposób zachować spójność
zasobów wspólnego systemu, do których dostęp muszą mieć wątki
pracujące w różnych procesorach.

Jądro jest także odpowiedzialne za obsługę przerwań pochodzących
z urządzeń fizycznych (takich jak urządzenia I/O, zegary procesora
czy czasomierze). W

przypadku wystąpienia przerwania, jądro

wywłaszcza działający wątek, aby zająć się jego obsługą.

Ponadto jądro obsługuje sytuacje wyjątkowe, gdy procesorowi każe
się wykonać coś, na co on nie pozwala, jak np. wpisywanie do
zablokowanej części pamięci lub dzielenie przez zero.

Ostatnim wreszcie zadaniem jądra w Windows NT jest pomoc
w przywracaniu normalnej sytuacji po awarii zasilania. Jeśli system
NT wyposażony jest w inteligentne zasilanie awaryjne (UPS), jądro
powiadamiane jest o wystąpieniu awarii zasilania. Jądro koordynuje
wtedy właściwy sposób zamknięcia systemu, informując urządzenia
I/O o awarii i pozwalając im we właściwy sposób wznowić pracę.

Uwaga: Ponieważ jądro bierze udział w niemal każdej czynności
wykonywanej w

systemie NT, jego części krytyczne pisane są

w asemblerze. Zapewnia to możliwie szybkie i skuteczne reagowanie.
Dlatego też optymalizacja jest czynnikiem krytycznym przy
przenoszeniu NT do innej architektury.

NT Executive

Porównując jądro NT do prezydenta USA można konsekwentnie
powiedzieć, że NT Executive jest odpowiednikiem bezpośrednio
podlegającego mu personelu. Prezydent kieruje władzą wykonawczą,
tak jak jądro kieruje NT Executive. NT Executive wykonuje zadania
stanowiące żywotne interesy całego systemu, a którymi jądro nie

Architektura Windows NT

99

może zająć się bezpośrednio, ponieważ pochłonięte jest innymi
sprawami.

Można przyjąć taką oto przejrzystą i zwięzłą definicję: NT Executive
zapewnia systemowi operacyjnemu podstawy, które mogą służyć
wszystkim innym aplikacjom pracującym w systemie. Definicja ta
obejmuje takie usługi, jak zarządzanie obiektami, pamięcią wirtualną,
urządzeniami wejścia/wyjścia oraz zarządzanie procesami.

Uwaga: Zwróćmy uwagę, że jądro NT to tak naprawdę część NT
Executive.

NT Executive pracuje wyłącznie w trybie jądra i wywoływany jest
przez chronione podsystemy środowiska, gdy te chcą skorzystać
z usług. Ze względu na hierarchię systemu Windows NT, aplikacje
użytkownika nie wywołują bezpośrednio NT Executive, lecz zwracają
się do usług z podsystemów środowiska (takich jak Win32 i POSIX),
które z kolei wywołują struktury należące do NT Executive.

W NT Executive istnieją takie funkcje, których nie ujawniają
istniejące biblioteki API. Wynika to z faktu, iż konstruktorzy
Windows NT nie omieszkali zadbać o dobro rozwoju systemu
operacyjnego i przygotowali miejsce pod przyszłe komponenty.

Oprócz samego jądra, NT Executive zawiera następujące elementy
główne:

!

Zarządcę obiektów (Object Manager)

!

Zarządcę procesów (Process Manager)

!

Zarządcę pamięci wirtualnej (Virtual Memory Manager)

!

Funkcję umożliwiającą wywołanie procedury lokalnej (Local

Procedure Call Facility)

!

Monitor kontroli zabezpieczeń (Security Reference Monitor)

!

Zarządca urządzeń I/O (I/O Manager)

Przyjrzyjmy się teraz dokładniej powyższym komponentom NT
Executive i spróbujmy odpowiedzieć na pytania, czym się one
zajmują i jak ze sobą współdziałają.

100

Rozdział 2

Zarządca obiektów

Zadanie zarządcy obiektów polega na tworzeniu, modyfikowaniu
i usuwaniu obiektów używanych przez wszystkie systemy, składające
się na NT Executive. Obiekty to abstrakcyjne typy danych używane
do reprezentowania zasobów systemu operacyjnego. Zarządca
informuje także, jaki jest status obiektów w odniesieniu do reszty
systemu operacyjnego.

Obiekty mogą być konkretne (np. port) lub też abstrakcyjne (jak np.
wątek). Gdy obiekt jest tworzony, nadaje się mu nazwę, za pomocą
której inne programy mogą uzyskać do niego dostęp. Gdy dany
proces chce uzyskać dostęp do obiektu, żąda on (od zarządcy
obiektów) uchwytu do obiektu. Uchwyt wyposaża nas we wskaźnik,
dzięki któremu można obiekt zlokalizować i dowiedzieć się, jak
uzyskać do niego dostęp. Takie informacje sterujące dostępem
dostarczane są przez system zabezpieczeń NT.

Zarządca obiektów sprawuje również pieczę nad tym, by dany obiekt
nie pochłaniał zbyt wielu zasobów (przeważnie pamięci systemu)
przez występowanie w różnych typach obiektów.

Poza tym zarządca obiektów odpowiedzialny jest za usuwanie
obiektów nie przyporządkowanych żadnemu właścicielowi. Nazywa
się to „zbieraniem śmieci”. Brak takiego udogodnienia był jedną
z głównych przyczyn problemów w Windows 3.x. Gdy program
zawieszał się lub gdy w sposób niewłaściwy korzystał z zasobów
systemu, pochłonięte przez niego zasoby pamięci nie mogły być
należycie zwrócone do dostępnej puli systemu, co powodowało
komunikat o błędzie utraty zasobów systemowych. Mówimy wtedy
o „wyciekaniu pamięci”.

Zarządca procesów

Zarządca procesów odpowiedzialny jest za tworzenie, usuwanie oraz
modyfikowanie wszystkich procesów i

wątków, a

także za

dostarczanie reszcie systemu informacji dotyczących ich statusu.

Architektura Windows NT

101

Uwaga: Zgodnie z definicją proces obejmuje wirtualną przestrzeń
adresową, jeden lub więcej wątków, fragment kodu programu
wykonywalnego oraz zbiór zasobów systemowych. Wątek to
wykonywalny obiekt przynależny danemu procesowi, zawierający
licznik rozkazów (wskazuje on bieżącą pozycję w segmencie kodu
wykonywalnego danego procesu), dwa stosy i

zbiór wartości

rejestrów.

Zarządca procesów, jak i wszystkie komponenty NT Executive, pełni
kluczową rolę w

operacjach całego systemu. W

momencie

uruchomienia, aplikacja przybiera postać procesu, który wywołuje
zarządcę procesów. Ponieważ każdy proces musi mieć przynajmniej
jeden wątek, Process Manager wzywany jest ponownie - celem
utworzenia wątku (wykres na ilustracji 2.5).

Zarządca procesów używany jest do zarządzania wątkami, jednak to
nie on jest odpowiedzialny za szeregowanie procesów i wątków.
Zadanie to leży w gestii samego jądra.

Zarządca pamięci wirtualnej

Domeną Menedżera pamięci wirtualnej - VMM (Virtual Memory
Manager) jest zarządzanie obszarem pamięci wirtualnej systemu.
Pamięć wirtualna pozwala na korzystanie z zasobów dysku zamiast
z pamięci operacyjnej systemu - poprzez przenoszenie nie używanych
stron pamięci na dysk i ich wyszukiwanie wtedy, gdy są potrzebne.

Uruchomienie aplikacji

Wywołanie zarządcy

procesów w celu

stworzenia procesu

Wywołanie zarządcy

procesów w celu stworzenia

wątku początkowego

Rys. 2.5. Wykres
przedstawiający
połączenia
z Zarządcą
procesów podczas
uruchamiania
aplikacji

102

Rozdział 2

Jest to integralna część Windows NT, który przydziela każdemu
procesowi 32-bitową przestrzeń adresową, bez względu na
rzeczywistą ilość pamięci fizycznej w systemie.

Każdy proces ma do dyspozycji 4GB obszaru pamięci, z czego
pierwsze dwa gigabajty zarezerwowane są dla systemu, a pozostałe
dwa dla procesu. Zarządca pamięci wirtualnej odpowiedzialny jest za
tłumaczenie adresów pamięci procesu na fizyczne adresy pamięci
systemu. Jeśli adres pamięci procesu odnosi się do tej części pamięci,
która została przeniesiona na dysk, VMM odczytuje tę stronę z dysku.

Narzędzie do lokalnego wywoływania procedur LPC (Local
Procedure Call Facility)

Narzędzie LPC związane jest nierozerwalnie z Windows NT, jako
wykorzystującego architekturę typu klient/serwer. Jest to interfejs
pomiędzy wszystkimi procesami typu klient/serwer, realizowanymi
w lokalnym systemie Windows NT.

Struktura LPC jest bardzo podobna do zdalnego wywoływania proce-
dur (RPC) - z

tą jednak różnicą, że ukierunkowana jest na

komunikację pomiędzy procesami klientów i

serwerów na

komputerze lokalnym. Mówiąc ściśle, LPC jest mechanizmem
umożliwiającym wymianę informacji pomiędzy dwoma wątkami
w różnych procesach.

Jak już wspominaliśmy, podsystem Win32 jest aplikacją trybu
użytkownika i pracuje w swoim własnym obszarze pamięci. Gdy dany
program chce połączyć się z podsystemem Win 32, aby zażądać
usług, wywołuje funkcję z odpowiedniego pliku biblioteki DLL. Za
pomocą LPC funkcja ta przenosi żądanie do procesu podsystemu
Win32, który wykonuje instrukcje i - poprzez LPC - przekazuje
komunikat o zakończeniu tej operacji.

Program kontroli zabezpieczeń - SRM (Security Reference
Monitor)

Program kontroli zabezpieczeń jest opoką całej ochrony w systemie
Windows NT, odpowiedzialną za przestrzeganie w komputerze lokal-
nym wszystkich zaleceń dotyczących ochrony.

Kontrolę tę SRM sprawuje wraz z systemami administrującymi,
znanymi jako proces rejestracji i autoryzacji w lokalnym systemie
zabezpieczeń. Gdy użytkownik rejestruje się w systemie Windows
NT, sprawdzane są jego uprawnienia, a podsystem procesu rejestracji

Architektura Windows NT

103

żąda przyznania mu identyfikatora dostępu do zabezpieczeń (SAT).
Identyfikator taki zawiera wykaz przywilejów użytkownika oraz
potwierdzenie członkostwa grupy. Podczas danej sesji spełnia on rolę
klucza dla tego użytkownika. Kiedy chce on coś wykonać, musi
przedstawić swój identyfikator.

W tym właśnie przypadku program kontroli zabezpieczeń
współpracuje ściśle z zarządcą obiektów. Za każdym razem, gdy
użytkownik stara się uzyskać dostęp do obiektu, Object Manager
tworzy uchwyt (handle) do niego i - w celu określenia poziomu
dostępu przydzielonego temu uchwytowi - wywołuje program SRM.
SRM korzysta wtedy z

informacji zawartych w

identyfikatorze

użytkownika i porównuje je z przynależnym danemu obiektowi
wykazem praw dostępu. Ma to na celu sprawdzenie, czy można
udostępnić użytkownikowi żądany poziom dostępu do obiektu. W ten
sposób SRM sprawuje kontrolę nad zabezpieczaniem dostępu do
wszystkich obiektów w Windows NT.

Zarządca urządzeń I/O (I/O Manager)

Zarządca I/O odpowiedzialny jest za koordynację i przetwarzanie
wszystkich sygnałów wejścia i wyjścia systemu. Nadzoruje on
programy obsługi urządzeń, instalowalne systemy plików, sieciowe
programy przeadresowujące wejście-wyjście i

pamięć podręczną

systemu.

I/O Manager kładzie kres tradycyjnej, monolitycznej metodzie
projektowania sterowników I/O. Prezentuje on podejście warstwowe,
polegające na łączeniu i dopasowywaniu komponentów.

Podsystemy środowiska chronionego

Pośród celów stworzenia Windows NT znalazły się osobowość
(personalność) środowiska roboczego i kompatybilność. Obydwa
realizowane są poprzez podsystemy środowiska chronionego.

Środowisko robocze w Windows NT obejmuje różne zestawy inter-
fejsów programów użytkowych (API) i dzięki nim może w praktyce
funkcjonować tak, jakby były to odrębne systemy operacyjne.
W systemie Windows NT oprócz środowiska roboczego Win32,
Win16 oraz DOS, występuje także środowisko POSIX i OS/2.

Dla systemu operacyjnego posiadanie wielu różnych osobowości
stanowi skuteczny sposób na zachowanie kompatybilności systemu.

104

Rozdział 2

Windows NT nie odniósłby takiego sukcesu, gdyby nie potrafił
współpracować z oprogramowaniem DOS i Windows.

W systemie Windows NT można wyróżnić trzy podsystemy środowi-
ska chronionego:

!

podsystem Win32

!

podsystem POSIX

!

podsystem OS/2

Uwaga: Wprawdzie można spotkać środowiska robocze Win16 i DOS,
zaliczane do podsystemów środowiska chronionego, jednak są one
przeważnie częścią podsystemu Win32.

Podsystemy środowiska chronionego pełnią rolę pośredników między
aplikacjami poziomu użytkownika i NT Executive.

Wspomnieliśmy już, że NT Executive i wszystkie jego komponenty
pracują w trybie jądra, natomiast praktycznie cała reszta - w trybie
użytkownika. Do tego ostatniego zalicza się także wszystkie podsys-
temy środowiska, które funkcjonują całkowicie w trybie użytkownika.
Gdy dana aplikacja wywołuje podsystem środowiskowy, wywołanie
to przechodzi przez warstwę usług systemu do NT Executive.

Każdy podsystem środowiska prowadzi rejestr swoich własnych
procesów i pracuje niezależnie od innych podsystemów. Każda
aplikacja może działać tylko w tym podsystemie, dla którego została
zaprojektowana. Gdy nowa aplikacja wprowadzana jest do Windows
NT, system sprawdza nagłówek pliku i

określa, w

którym

podsystemie aplikacja ta ma być realizowana.

Zobaczmy, jak działa każdy z tych podsystemów.

Win32

Win32 jest rdzennym i elementarnym systemem Windows NT. Jego
podstawę stanowi zestaw funkcji API Win32, które powstawały wraz
z systemem NT. Wiele z tych funkcji to bezpośrednie rozszerzenia ich
odpowiedników typu Win16.

Architektura Windows NT

105

Uwaga:Win32 jest określeniem zarówno API, jak i podsystemu NT dla
wywołania usług związanych z Win32 API.

Uwaga: OS/2 Presentation Manager był przez pierwsze półtora roku
swojego istnienia traktowany jako domyślny i główny podsystem dla
Windows NT. Jednak w związku z sukcesem Windows 3.x Microsoft
zdecydował się użyć, jako głównego środowiska roboczego, interfejsu
Windows i związanych z nim interfejsów programów użytkowych.

W omówionym wcześniej modelu klient-serwer, podsystem Win32
działa jako serwer dla wszystkich innych podsystemów środowiska,
funkcjonujących w Windows NT. Inne podsystemy środowiska pełnią
rolę klientów i tłumaczą wywołania swoich usług na odpowiednie
wywołania obsługiwane przez podsystem Win32.

Podsystem Win32 odpowiedzialny jest za wszystkie operacje wejścia
i wyjścia użytkownika. Obsługuje on monitor, klawiaturę i mysz. Gdy
inne podsystemy, takie jak OS/2 czy POSIX, potrzebują skorzystać
z tych urządzeń, żądają od niego usług.

Projektując podsystem Win32, początkowo twórcy NT starali się
upodobnić jego funkcjonowanie do systemu Windows 3.x. Przyniosło
to skutek w postaci konstrukcji opartej na pięciu głównych częściach
- są to: Zarządca okna (zwany często USER - użytkownik), Interfejs
urządzeń graficznych (GDI), konsola, funkcje systemu operacyjnego
oraz programy obsługi urządzeń graficznych Win32 (rysunek 2.6).

Podsystem Win32

Konsola

Graphics Device

Interface (GDI)

Sterowniki

graficzne

Window

Manager (USER)

Funkcje systemu

operacyjnego

Rys. 2.6. Pierwotny
podsystem Win32
w Windows NT.

106

Rozdział 2

Jednakże w Windows NT 4 organizacja podsystemu Win32 uległa
zmianie. Na zamieszczonej ilustracji widać, że Interfejs urządzeń
graficznych (GDI) i

Zarządca okna (USER) wchodzą w

skład

podsystemu Win32.

Wszystkie inne podsystemy - dla operacji wejścia i

wyjścia

użytkownika - korzystają z interfejsu użytkowego Win32, gdyż zespół
opracowujący NT usunął elementy GDI i USER z podsystemu Win32
i przeniósł je do NT Executive.

Wiele kontrowersji wywołała kwestia stabilności systemu Windows
NT po dokonaniu tej zmiany. Krytycy zarzucali, że zwiększenie ilości
kodu pracującego w trybie jądra zwiększa prawdopodobieństwo
zawieszania się systemu, ponieważ procesy trybu jądra mają dostęp
do zasobów systemu.

W rzeczywistości jednak tak się wcale nie dzieje. W pierwotnym
modelu - gdzie GDI i USER znajdowały się w podsystemie Win32 -
uruchomienie wszystkich programów, opierających się na usługach
tych dwóch segmentów, nie byłoby możliwe w

przypadku

wystąpienia jakichś problemów, czego efektem byłaby blokada całego
interfejsu użytkownika.

Natomiast po przeniesieniu tych dwóch składników do NT Executive,
jądro może sprawować nad nimi kontrolę. Jeśli odmówią one posłu-
szeństwa, może ono zastosować kontrolę błędów (zamiast blokady
systemu) i pozwolić, aby system uruchomił się ponownie.

Rozwiązanie takie jest korzystniejsze, ponieważ lepiej jest ponownie
uruchomić system niż dopuścić do jego zablokowania. Obydwie me-
tody mają zarówno swoich zwolenników, jak i przeciwników.

MS-DOS i Win16 Popularność systemu

Windows NT umożliwia pracę większości aplikacji Windows 3.x
i DOS. W początkowych fazach rozwoju systemu NT zespół
konstruktorski i zarząd firmy Microsoft miały w tym względzie
mieszane uczucia.

Wyciągnięto (słuszny) wniosek, że brak takiej kompatybilności zmusi
użytkowników do kosztownej modernizacji oprogramowania, co
może mieć negatywny wpływ na sprzedaż systemu.

Oba środowiska robocze z łatwością dostosowały się do dynamicznej
konstrukcji NT.

Architektura Windows NT

107

W integracji tej chodziło o to, by:

!

Umożliwić pracę programom DOS-u oraz 16-bitowym aplikacjom

Windows bez jakichkolwiek modyfikacji.

!

Ochronić system i inne aplikacje 32-bitowe przed interferencją ze

strony programów DOS-u oraz aplikacji 16-bitowych.

!

Umożliwić 16-bitowym programom Windows i systemu DOS

pracę na platformach RISC.

!

Dostarczyć mechanizm wspólnego korzystania z danych przez 32-

bitowe i 16-bitowe programy Windows.

Wiele osób uważa, że Windows 3.x jest systemem operacyjnym. Pod
względem technicznym nie jest to jednak prawdziwy system
operacyjny, lecz raczej interfejs użytkownika, będący nakładką na
DOS, który jest prawdziwym systemem operacyjnym.

Tak więc pierwszym krokiem do zapewnienia kompatybilności było
stworzenie środowiska DOS. Środowisko DOS-u w Windows NT
znane jest pod nazwą wirtualna maszyna DOS-u (VDM), określane
również jako NTVDM. VDM jest pełną, 32-bitową aplikacją trybu
użytkownika, która żąda usług od podsystemu Win 32, a niekiedy
bezpośrednio od warstwy usług systemowych NT. VDM bazuje na
systemie DOS 5.0.

Windows NT umożliwia pracę dowolnej ilości aplikacji DOS-u, przy
czym każda aplikacja pracuje na swojej własnej wirtualnej maszynie.
Ponieważ VDM dla DOS-u nie są niczym innym, jak normalnymi
procesorami działającymi pod Windows NT - podlegają wielozada-
niowości z wywłaszczeniem, podobnie jak inne programy w systemie.
Widać więc, że Windows NT umożliwia - w odniesieniu do aplikacji
DOS-u - wielozadaniowość z zawłaszczaniem.

Inna cecha wirtualnej maszyny dla DOS-u wynika z faktu, iż
udostępnia ona użytkownikowi dodatkowo ponad 620KB pamięci
konwencjonalnej. Ogromną zaletą VDM jest zapewnienie aplikacjom
DOS-u możliwość pełnego korzystania z myszy, sieci i CD-ROM-u.
Pamięć angażowana jest wówczas w mniejszym stopniu, niż miało to
miejsce w podobnym systemie DOS, z tymi samymi usługami.

Tak, jak Windows 3.x bazuje na usługach DOS-u, tak też podsystem
Win16 opiera się na VDM z Windows NT. 16-bitowy emulator
Windows w VDM nazywa się WOW, czyli Windows on Win32.
Ponieważ emulator ten znajduje się wewnątrz VDM, większość usług
żąda on właśnie od VDM (tak jak standardowy Windows 3.x żąda

108

Rozdział 2

usług od DOS-u). VDM przekształca wtedy większość tych wywołań
bezpośrednio na wywołania przesyłane do podsystemu Win32.

Gdy 16-bitowy program Windows wykonuje wywołanie należące do
interfejsu programów użytkowych Win32, podsystem WOW korzysta
z procesu o nazwie thunking (konwersja kodów). Thunking służy do
przekształcania takich wywołań na odpowiadające im wywołanie
interfejsu API Win32, które następnie przekazywane jest do podsys-
temu Win32. Ten sam proces stosowany jest wtedy, gdy dane
z wywołania Win32 mają być przesłane do aplikacji Win16.

Thunking jest niezbędny, ponieważ musi istnieć standardowy zbiór
zasad dla konwersji 16-bitowych formatów danych na formaty 32-
bitowe i odwrotnie. Przejście z formatu 16-bitowego do 32-bitowego
jest łatwe, ponieważ pozostałe 16 bitów po prostu wypełnia się
zerami. Natomiast w przypadku przejścia z formatów 32-bitowych na
16-bitowe odrzucenie 16 bitów z pewnością spowodowałoby utratę
danych. Thunking funkcjonuje w podsystemie Win32 (rysunek 2.7)

Proces WOW

Thunk Layer

KERNEL32.DLL

GDI32.DLL

USER32.DLL

Thunk Layer

Thunk Layer

16 bitowa

aplikacja

Windows

16 bitowy

fragment jądra

16 bitowy

fragment GDI

16 bitowy

fragment programu

zarządcy okna USER

Rys. 2.7. Thunking

przeprowadza

konwersję 16-

bitowych wywołań
API na wywołania

32-bitowe i na

odwrót.

Architektura Windows NT

109

Z uwagi na fakt, iż środowisko Windows 3.x stosuje model pamięci
wspólnej, napisano wiele programów wymagających tej wspólnej
przestrzeni adresowej.

Aby zachować satysfakcjonującą kompatybilność z tymi aplikacjami,
wszystkie 16-bitowe programy Windows pracują w jednej wirtualnej
maszynie DOS-u.

Podsystem WOW nie jest wielowątkowy, a 16-bitowe aplikacje
Windows podlegają zasadom wielozadaniowości (tak jakby to się
działo w prawdziwym systemie Windows).

Uwaga: Prawda wygląda tak, że za każdym razem, gdy chcemy
uruchomić 16-bitową aplikację Windows, tworzony jest nowy wątek,
w związku z czym WOW jest wielowątkowy. Jednakże wątki te
mikrojądro szereguje inaczej, niż inne.

Normalnie, jądro NT szereguje wątki w oparciu o zasadę pierwszeń-
stwa. Gdy realizowany wątek zostaje wywłaszczony, jądro przekazuje
kontrolę wątkowi następnemu w kolejności. Inaczej jądro traktuje
wątki WOW. Otóż po wywłaszczeniu aktualnie pracującego wątku
WOW, uruchamia inne wątki. Dopóki jednak wątek ten nie odda
kontroli, jądro nie może wystartować żadnego innego wątku WOW.

Tak więc wprawdzie WOW dysponuje faktycznie więcej niż jednym
wątkiem, jednak tylko jeden z nich może być wykonywany. Należy
pamiętać, że nie jest to konstrukcja wadliwa, lecz została bardzo
starannie zaprojektowana. Stworzenie jej miało na celu zachowanie
kompatybilności z istniejącym oprogramowaniem 16-bitowym, które
przestałoby funkcjonować, gdyby podlegało wielozadaniowości
z wywłaszczaniem.

Poza tym wszystkie aplikacje w WOW pracują w jednej przestrzeni
pamięci wspólnej. Dlatego też awaria jednej, 16-bitowej aplikacji
Windows, może spowodować awarię wszystkich 16-bitowych progra-
mów w tym podsystemie realizowanych. Natomiast nie ma ona
żadnego wpływu na sam system ani jakąkolwiek, funkcjonującą
w nim, 32-bitową aplikację.

110

Rozdział 2

Uwaga: Wszystkie programy DOS-owe pracują w oddzielnych wirtu-
alnych maszynach DOS-u i podlegają wielozadaniowości z wywłasz-
czaniem. Natomiast 16-bitowe aplikacje Windows pracują w jednej
wirtualnej maszynie DOS-u i

podlegają wielozadaniowości

współbieżnej w

stosunku do siebie, a

wielozadaniowości

z wywłaszczeniem - względem reszty systemu.

Aplikacje DOS-u i Windows 3.x w ogromnej mierze korzystają
z intelowego kodu języka asemblera, trudno więc było sprawić, by
programy te działały bez modyfikacji na systemach RISC
(przetwarzanie danych o

zredukowanej liczbie rozkazów),

współpracujących z Windows NT. Udało się to jednak dzięki
naukowej pomysłowości. Wirtualna maszyna DOS-u rozbija
wszystkie wywołania na jednostki wykonywania rozkazów (IEU).
W architekturze Intel wywołania te mogą być wykonywane
bezpośrednio przez procesor. W

systemach RISC są one

przekształcane przez procedurę emulacyjną Intel-a, napisaną przez
Insignia Solutions Ltd (ten sam zespół, który tworzy SoftWindows
dla Macintosh-a).

W wersjach wcześniejszych (w stosunku do Windows NT 4),
emulowany kod oparty był na zbiorze rozkazów procesora typu 286.
Mogło to powodować problemy, ponieważ 16-bitowe programy
Windows, które wymagały trybu rozszerzonego 386, nie mogły
pracować w Windows NT pod emulacją WOW na procesorach RICS.
Stąd np. takie programy, jak Microsoft Office nie mogłyby pracować
na platformach RISC, gdyż wymagają trybu rozszerzonego 386.

Jedną z

głównych modernizacji systemu Windows NT 4 jest

rozszerzenie programu emulacyjnego, co zapewniło pełną
kompatybilność z repertuarem rozkazów modelu 486.

POSIX

Jak już wspominaliśmy, Microsoft przywiązywał - w czasie realizacji
systemu Windows NT - dużą wagę do różnych standardów systemów
otwartych. Firma wyszła z założenia, że systemy otwarte stwarzają
możliwość zaakceptowania przez rynek nowych, zaawansowanych
systemów operacyjnych.

Jednym z

najczęściej przytaczanych standardów, realizowanych

w Windows NT, jest zgodność z POSIX. POSIX oznacza przenośny
interfejs systemu operacyjnego (Portable Operating System Interface),
opracowany przez IEEE (Instytut Inżynierów Elektryków

Architektura Windows NT

111

i Elektroników), jako metoda przenoszenia aplikacji na platformy
UNIX-a. Jednakże POSIX został także zintegrowany z wieloma
(innymi, niż UNIX) systemami.

Istnieje wiele poziomów zgodności z POSIX - od POSIX.0 do
POSIX.12. Poziomy te stanowią zbiór propozycji i nie wszystkie
z nich zostały ratyfikowane jako standardy.

Podsystem POSIX w Windows NT zgodny jest z poziomem POSIX.1.
Zgodność z

POSIX.1. wymaga podstawowego minimum usług

zapewnianych przez NT. Gdy dana aplikacja POSIX pracuje
w Windows NT, uruchomiony zostaje podsystem POSIX, który
tłumaczy, wymagane w przypadku POSIX.1, wywołania interfejsu
programów użytkowych napisane w języku C - na wywołania
interfejsu API Win32, którymi dalej zajmuje się podsystem Win32.

Ze względu na swoje ograniczenia, POSIX.1 w Windows NT nie
stanowi zaplecza dla pracy w sieci ani zabezpieczenia systemu.

Oto niektóre z właściwości wymaganych przez POSIX:

1. Nazwy plików uwzględniające małe i duże litery, stosowane dzięki

NTFS (New Technology File System)

2. Zdolność wielokrotnego nadawania nazw plikom, również

osiągana dzięki NTFS

3. Kontrola trawersu (omijania) systemu plików, nadzorowana przez

prawo użytkownika - bypass traverse checking.

Każda aplikacja POSIX pracuje w swoim własnym obszarze pamięci
adresowej i podlega wielozadaniowości z wywłaszczaniem. Nie ma
zgodności co do zasadności umieszczenia podsystemu POSIX
w Windows NT. Niektórzy uważają, że chodziło o dostępność
aplikacji dla użytkowników. Zdaniem innych, przyświecał temu
szlachetny cel dostosowania się do standardów systemów otwartych.
Trzecia, dość popularna opinia głosi, iż miało to dowodzić
współdziałania NT z platformami UNIX-a.

Łatwość, z jaką podsystem POSIX został włączony do NT, świadczy
o klasie i elastyczności tego ostatniego. Jednak po samym
podsystemie POSIX nie należy się zbyt wiele spodziewać.

OS/2

Windows NT zaprojektowany był pierwotnie jako następna generacja
OS/2. Jego głównym interfejsem był OS/2 Presentation Manager,
będący połączeniem interfejsu graficznego z

programowo-

112

Rozdział 2

użytkowym. Na systemie tym miały pracować wszystkie standardowe
aplikacje OS/2, wliczając program współpracujący z monitorem
w trybie znakowym i program oparty o graficzny interfejs
użytkownika.

Nacisk na właściwości systemu OS/2 uległ zmniejszeniu, gdy
zdecydowano zaopatrzyć NT w interfejs Windows i skonstruować go
tak, aby stał się następcą platformy Windows.

W rezultacie powstał podsystem OS/2, na którym mogą pracować
standardowe aplikacje trybu znakowego OS/2 1.x. Nie mogą
pracować w nim aplikacje graficzne OS/2 2.x.

Uwaga: Podsystem OS/2 pracuje jedynie w maszynach działających
w oparciu o procesory Intela, a nie na platformach RISC.

Podsystem OS/2 stosowany jest jako podsystem środowiska
chronionego (podobnie jak podsystem POSIX). Tłumaczy on
wywołania interfejsu programów użytkowych OS/2 na wywołania
API Win32, obsługiwane przez podsystem Win32.

Podsystem OS/2 i wszystkie aplikacje OS/2 posiadają swoje obszary
pamięci chronionej i podlegają wielozadaniowości z wywłaszczaniem
- w stosunku do siebie i innych aplikacji pracujących w systemie.

Oprócz zasadniczego zestawu API, podsystem OS/2 zawiera wiele
interfejsów API LAN Manager-a, jak np. NetBIOS (podstawowy
sieciowy system we-wy) lub mailslots (obszary wymiany danych).
Różni się tym od podsystemu POSIX, który nie posiada interfejsu
API, umożliwiającego pracę w sieci.