|
|
|
The NT-based operating system is object-based. Various components in the executive define one or more object types. Each component exports kernel-mode-only support routines that manipulate instances of its object types when these routines are called. No component is allowed to access any instance of another component's object types directly. Each component must call the exported support routines in order to use another component's objects.
Strict adherence to these conventions allows the operating system to be both portable and flexible. For example, a future release of the operating system could contain a wholly or partially recoded Kernel component that defines the same object types, possibly with entirely different internal structures, and exports a set of support routines with the same names and parameters as the existing set. This hypothetical recoded version of the Kernel would have no effect on the portability of any other executive component in the existing system. In other words, operating system components do not practice back-door communication, and drivers also must shun this practice to remain portable and configurable.
Like the operating system, drivers and their devices are also object-based. To all other components in the system, including user-mode code, a connection to a device is represented as an open operation of one of the I/O Manager's file objects. Within the I/O system, each driver's logical, virtual, and/or physical devices are represented as device objects. Within the I/O Manager, each driver's load image is represented as a driver object. The I/O Manager defines the object types for file objects, device objects, and driver objects.
Like any other executive component, drivers use objects by calling kernel-mode support routines exported by the I/O Manager and other system components. Kernel-mode support routines generally have names that identify the specific object each manipulates and the operation each performs on that object. These support routine names have the form:
PrefixOperationObject
where
Prefix
Identifies the kernel-mode component that exports the support routine and, usually, the component that defined the object type. Most prefixes have two letters.
Operation
Describes what is done to the object.
Object
Identifies the type of object.
For example, IoCreateDevice, which each kernel-mode driver calls one or more times during device initialization, creates a device object to represent a physical, logical, or virtual device as the target of I/O requests.
For convenience, one system component can export routines that call another component's support routines. The I/O Manager, in particular, exports certain routines that make it easier to develop drivers. For example, IoConnectInterrupt, which lowest-level drivers call to register their ISRs, calls the Kernel's support routines for interrupt objects.
Some system-defined objects are opaque: only the defining system component "knows" an object type's internal structure and can directly access all the data an object contains. The system component that defines an object usually exports support routines that drivers and other kernel-mode components can call to manipulate that object. For example, the system's Kernel component exports support routines that the I/O Manager calls to initialize and connect interrupt objects when a lowest-level driver registers its ISR.
Note To maintain driver portability, drivers must use the system-supplied support routines to manipulate system-defined objects. The defining system component can change the internal structure of its object types at any time.