Object-Based
El sistema operativo basado en Microsoft Windows NT se basa en objetos. Varios componentes del ejecutivo definen uno o varios tipos de objeto. Cada componente exporta rutinas de compatibilidad con el modo kernel que manipulan instancias de sus tipos de objeto. Ningún componente puede acceder directamente a los objetos de otro componente. Para usar los objetos de otro componente, un componente debe llamar a las rutinas de soporte técnico exportadas.
Este diseño permite que el sistema operativo sea portátil y flexible. Por ejemplo, es posible que una versión futura del sistema operativo contenga un componente de kernel recodado que defina los mismos tipos de objeto, pero con estructuras internas completamente diferentes. Si esta versión hipotética de recodificación del kernel exporta un conjunto de rutinas de soporte técnico que tienen los mismos nombres y parámetros que el conjunto existente, los cambios internos no tendrán ningún efecto en la portabilidad de cualquier otro componente ejecutivo del sistema existente.
Del mismo modo, para seguir siendo portátiles y configurables, los controladores deben comunicarse con el sistema operativo y entre sí usando solo las rutinas de soporte técnico y otras interfaces que se describen en el WDK.
Al igual que el sistema operativo, los controladores también se basan en objetos. Por ejemplo:
Los objetos de archivo representan la conexión de una aplicación en modo de usuario a un dispositivo.
Los objetos de dispositivo representan los dispositivos físicos, virtuales o lógicos de cada controlador.
Los objetos de controlador representan la imagen de carga de cada controlador.
El administrador de E/S define la estructura y las interfaces de objetos de archivo, objetos de dispositivo y objetos de controlador.
Al igual que cualquier otro componente ejecutivo, los controladores usan objetos llamando a rutinas de soporte de modo kernel que exportan el administrador de E/S y otros componentes del sistema. Por lo general, las rutinas de compatibilidad con el modo kernel tienen nombres que identifican el objeto específico que manipula cada rutina y la operación que realiza cada rutina en ese objeto. Estos nombres de rutina de compatibilidad tienen la siguiente forma:
PrefixOperationObject
where
Prefijo Identifica el componente en modo kernel que exporta la rutina de soporte técnico y, normalmente, el componente que definió el tipo de objeto. La mayoría de los prefijos tienen dos letras.
Operación Describe lo que se hace en el objeto .
Objeto Identifica el tipo de objeto.
Por ejemplo, la rutina IoCreateDevice del administrador de E/S crea un objeto de dispositivo para representar un dispositivo físico, lógico o virtual como destino de las solicitudes de E/S.
Un componente del sistema puede exportar rutinas que llaman a las rutinas de soporte técnico de otro componente. Esto puede reducir el número de llamadas que debe realizar un controlador. El administrador de E/S, en particular, exporta ciertas rutinas que facilitan el desarrollo de controladores. Por ejemplo, IoConnectInterruptEx, que llama a los controladores de nivel más bajo para registrar sus ISR, llama a las rutinas de compatibilidad del kernel para los objetos de interrupción.
Opacidad de objeto
Algunos objetos definidos por el sistema son opacos: solo el componente de sistema que define es consciente de la estructura interna de un objeto de este tipo y puede acceder directamente a todos los datos que contiene un objeto. El componente del sistema que define una exportación de objetos opaco admite rutinas que los controladores y otros componentes del modo kernel pueden llamar para manipular ese objeto. Los controladores nunca acceden directamente a estructuras de objetos opacas.
Nota Para mantener la portabilidad del controlador, los controladores deben usar las rutinas de soporte técnico proporcionadas por el sistema para manipular objetos definidos por el sistema. El componente de definición del sistema puede cambiar la estructura interna de sus tipos de objeto en cualquier momento.