Object-Based

System operacyjny Microsoft Windows NT jest oparty na obiektach. Różne składniki w kadrze wykonawczej definiują jeden lub więcej typów obiektów. Każdy składnik eksportuje procedury wsparcia trybu jądrowego, które operują wystąpieniami jego typów obiektów. Żaden składnik nie może bezpośrednio uzyskać dostępu do obiektów innego składnika. Aby użyć obiektów innego składnika, składnik musi wywołać wyeksportowane procedury pomocy technicznej.

Ten projekt pozwala systemowi operacyjnemu być zarówno przenośny, jak i elastyczny. Na przykład przyszłe wydanie systemu operacyjnego może zawierać ponownie zakodowany składnik jądra, który definiuje te same typy obiektów, ale z zupełnie różnymi strukturami wewnętrznymi. Jeśli ta hipotetyczna ponownie zakodowana wersja jądra eksportuje zestaw procedur pomocy technicznej, które mają takie same nazwy i parametry jak istniejący zestaw, zmiany wewnętrzne nie miałyby wpływu na przenośność żadnego innego składnika wykonawczego w istniejącym systemie.

Podobnie, aby pozostać przenośnym i konfigurowalnym, sterowniki muszą komunikować się z systemem operacyjnym i ze sobą przy użyciu tylko procedur pomocy technicznej i innych interfejsów opisanych w zestawie WDK.

Podobnie jak system operacyjny, sterowniki są również oparte na obiektach. Przykład:

• Obiekty plików reprezentują połączenie aplikacji w trybie użytkownika z urządzeniem.

• Obiekty urządzeń reprezentują logiczne, wirtualne lub fizyczne urządzenia każdego sterownika.

• Obiekty sterowników reprezentują obraz ładowania każdego sterownika.

Menedżer we/wy definiuje strukturę i interfejsy dla obiektów plików, obiektów urządzeń i obiektów sterowników.

Podobnie jak w przypadku każdego innego składnika wykonawczego sterowniki używają obiektów, wywołując procedury obsługi trybu jądra, które są eksportowane przez menedżera we/wy i innych składników systemowych. Procedury obsługi trybu jądra zazwyczaj mają nazwy, które identyfikują konkretny obiekt, który manipuluje każda procedura, oraz operację, którą każda z nich wykonuje na tym obiekcie. Te nazwy procedur obsługi mają następującą formę:

PrefixOperationObject

gdzie

Przedrostek Identyfikuje składnik trybu jądra, który eksportuje procedurę obsługi i, zwykle, składnik, który zdefiniował typ obiektu. Większość prefiksów ma dwie litery.

Operacja Opisuje, co robi się z obiektem.

Obiekt Określa typ obiektu.

Na przykład procedura IoCreateDevice menedżera we/wy tworzy obiekt urządzenia, który reprezentuje fizyczne, logiczne lub wirtualne urządzenie jako cel żądań we/wy.

Jeden składnik systemu może eksportować procedury, które wywołują procedury wspierające innego składnika. Może to zmniejszyć liczbę wywołań, które musi wykonać sterownik. Menedżer we/wy, w szczególności, eksportuje pewne procedury, które ułatwiają rozwój sterowników. Na przykład IoConnectInterruptEx, który sterowniki najniższego poziomu wywołują w celu zarejestrowania swoich ISRs, wywołuje funkcje pomocnicze jądra dla obiektów przerwania.

Nieprzezroczystość obiektów

Niektóre obiekty zdefiniowane przez system są nieprzezroczyste: tylko definiujący składnik systemu jest świadomy takiej wewnętrznej struktury obiektu i może bezpośrednio uzyskać dostęp do wszystkich danych, które zawiera obiekt. Składnik systemowy definiujący nieprzezroczysty obiekt eksportuje procedury wsparcia, które sterowniki i inne składniki trybu jądra mogą wywoływać, aby manipulować tym obiektem. Sterowniki nigdy nie uzyskują bezpośredniego dostępu do nieprzezroczystych struktur obiektów.

Uwaga Aby zachować przenośność sterowników, sterowniki muszą używać dostarczonych przez system procedur pomocniczych do manipulowania obiektami zdefiniowanymi przez system. Definiujący składnik systemowy może w dowolnym momencie zmienić wewnętrzną strukturę typów obiektów.