Object-Based
Le système d’exploitation Microsoft Windows NT est basé sur des objets. Différents composants de l’exécutif définissent un ou plusieurs types d’objets. Chaque composant exporte des routines de prise en charge en mode noyau qui manipulent des instances de ses types d’objets. Aucun composant ne peut accéder directement aux objets d’un autre composant. Pour utiliser les objets d’un autre composant, un composant doit appeler les routines de support exportées.
Cette conception permet au système d’exploitation d’être à la fois portable et flexible. Par exemple, il est possible qu’une version ultérieure du système d’exploitation contienne un composant de noyau recoded qui définit les mêmes types d’objets, mais avec des structures internes entièrement différentes. Si cette hypothétique version recodée du noyau exporte un ensemble de routines de prise en charge qui ont les mêmes noms et paramètres que l’ensemble existant, les modifications internes n’auraient aucun effet sur la portabilité d’un autre composant exécutif dans le système existant.
De même, pour rester portables et configurables, les pilotes doivent communiquer avec le système d’exploitation et entre eux en utilisant uniquement les routines de prise en charge et d’autres interfaces décrites dans le WDK.
Comme le système d’exploitation, les pilotes sont également basés sur des objets. Par exemple :
Les objets File représentent la connexion d’une application en mode utilisateur à un appareil.
Les objets de périphérique représentent les appareils logiques, virtuels ou physiques de chaque pilote.
Les objets driver représentent l’image de chargement de chaque pilote.
Le gestionnaire d’E/S définit la structure et les interfaces pour les objets fichier, les objets de périphérique et les objets de pilote.
Comme tout autre composant exécutif, les pilotes utilisent des objets en appelant des routines de prise en charge en mode noyau que le gestionnaire d’E/S et d’autres composants système exportent. Les routines de prise en charge en mode noyau ont généralement des noms qui identifient l’objet spécifique que chaque routine manipule et l’opération que chaque routine effectue sur cet objet. Ces noms de routine de prise en charge se présentent sous la forme suivante :
PrefixOperationObject
where
Préfixe Identifie le composant en mode noyau qui exporte la routine de prise en charge et, généralement, le composant qui a défini le type d’objet. La plupart des préfixes ont deux lettres.
Opération Décrit ce qui est fait à l’objet .
Objet Identifie le type d’objet.
Par exemple, la routine IoCreateDevice du gestionnaire d’E/S crée un objet d’appareil pour représenter un appareil physique, logique ou virtuel comme cible des demandes d’E/S.
Un composant système peut exporter des routines qui appellent les routines de support d’un autre composant. Cela peut réduire le nombre d’appels qu’un pilote doit effectuer. Le gestionnaire d’E/S, en particulier, exporte certaines routines qui facilitent le développement de pilotes. Par exemple, IoConnectInterruptEx, que les pilotes de niveau inférieur appellent pour inscrire leurs ISR, appelle les routines de prise en charge du noyau pour les objets d’interruption.
Opacité de l’objet
Certains objets définis par le système sont opaques : seul le composant système de définition a connaissance de la structure interne d’un tel objet et peut accéder directement à toutes les données qu’un objet contient. Le composant système qui définit des exportations d’objets opaques prend en charge les routines que les pilotes et d’autres composants en mode noyau peuvent appeler pour manipuler cet objet. Les pilotes n’accèdent jamais directement aux structures d’objets opaques.
Note Pour maintenir la portabilité des pilotes, les pilotes doivent utiliser les routines de prise en charge fournies par le système pour manipuler des objets définis par le système. Le composant système de définition peut modifier la structure interne de ses types d’objets à tout moment.