Object-Based

Das Microsoft Windows NT-basierte Betriebssystem ist objektbasiert. Verschiedene Komponenten in der Exekutive definieren einen oder mehrere Objekttypen. Jede Komponente exportiert Kernelmodus-Unterstützungsroutinen, die Instanzen ihrer Objekttypen bearbeiten. Keine Komponente kann direkt auf die Objekte einer anderen Komponente zugreifen. Um die Objekte einer anderen Komponente zu verwenden, muss eine Komponente die exportierten Supportroutinen aufrufen.

Dieses Design ermöglicht es, das Betriebssystem sowohl portierbar als auch flexibel zu sein. Beispielsweise ist es möglich, dass ein zukünftiges Release des Betriebssystems eine neucodierte Kernelkomponente enthält, die die gleichen Objekttypen definiert, aber mit völlig unterschiedlichen internen Strukturen. Wenn diese hypothetische neucodierte Version des Kernels eine Reihe von Supportroutinen exportiert, die dieselben Namen und Parameter wie die vorhandene Menge haben, hätten die internen Änderungen keine Auswirkungen auf die Portabilität einer anderen Exekutivkomponente im vorhandenen System.

Ebenso müssen Treiber, um portierbar und konfigurierbar zu bleiben, mit dem Betriebssystem und miteinander kommunizieren, indem sie nur die Supportroutinen und andere Schnittstellen verwenden, die im WDK beschrieben werden.

Wie das Betriebssystem sind auch Treiber objektbasiert. Beispiel:

• Dateiobjekte stellen die Verbindung einer Anwendung im Benutzermodus mit einem Gerät dar.

• Geräteobjekte stellen die logischen, virtuellen oder physischen Geräte der einzelnen Treiber dar.

• Treiberobjekte stellen das Ladeimage jedes Treibers dar.

Der E/A-Manager definiert die Struktur und Schnittstellen für Dateiobjekte, Geräteobjekte und Treiberobjekte.

Wie jede andere Executive-Komponente verwenden Treiber Objekte, indem sie Kernelmodus-Supportroutinen aufrufen, die der E/A-Manager und andere Systemkomponenten exportieren. Kernelmodus-Unterstützungsroutinen haben im Allgemeinen Namen, die das spezifische Objekt identifizieren, das jede Routine bearbeitet, und den Vorgang, den jede Routine für dieses Objekt ausführt. Diese Unterstützungsroutinennamen haben die folgende Form:

PrefixOperationObject

where

Präfix Identifiziert die Kernelmoduskomponente, die die Supportroutine exportiert, und in der Regel die Komponente, die den Objekttyp definiert hat. Die meisten Präfixe haben zwei Buchstaben.

Vorgang Beschreibt, was mit dem -Objekt gemacht wird.

Objekt Gibt den Typ des Objekts an.

Beispielsweise erstellt die IoCreateDevice-Routine des E/A-Managers ein Geräteobjekt, das ein physisches, logisches oder virtuelles Gerät als Ziel von E/A-Anforderungen darstellt.

Eine Systemkomponente kann Routinen exportieren, die die Supportroutinen einer anderen Komponente aufrufen. Dadurch kann die Anzahl der Anrufe reduziert werden, die ein Treiber tätigen muss. Insbesondere der E/A-Manager exportiert bestimmte Routinen, die die Entwicklung von Treibern erleichtern. Beispielsweise ruft IoConnectInterruptEx, das Treiber der niedrigsten Ebene aufrufen, um ihre ISRs zu registrieren, die Kernelunterstützungsroutinen für Interruptobjekte auf.

Objektopacity

Einige systemdefinierte Objekte sind undurchsichtig: Nur die definierende Systemkomponente kennt die interne Struktur eines solchen Objekts und kann direkt auf alle Daten zugreifen, die ein Objekt enthält. Die Systemkomponente, die einen undurchsichtigen Objektexport definiert, unterstützt Routinen, die Treiber und andere Kernelmoduskomponenten aufrufen können, um dieses Objekt zu bearbeiten. Treiber greifen nie direkt auf undurchsichtige Objektstrukturen zu.

Hinweis Um die Portabilität des Treibers zu gewährleisten, müssen Treiber die vom System bereitgestellten Supportroutinen verwenden, um systemdefinierte Objekte zu bearbeiten. Die definierende Systemkomponente kann die interne Struktur ihrer Objekttypen jederzeit ändern.