Uncovering this important but little-known
Executive subsystem
The Object Manager is the Windows NT Executive subsystem that
receives the least amount of attention or recognition. Ironically, the Object
Manager provides a resource management support infrastructure that all other NT
Executive subsystems (including the Memory Manager, I/O Manager, and Process
Manager) rely on. The Object Manager is a support subsystem that performs its
work behind the scenes. As an NT systems administrator or a Win32 programmer,
you probably will never interact directly with the Object Manager; however,
almost everything you do, from opening files to starting a program to viewing
the Registry, requires its assistance.
In this tour of the Object Manager, I'll first describe where the Object
Manager fits into NT's architecture, the role it plays in common operations, and
the services it provides. Next, I'll explain how NT's subsystems define object
types and what kind of information the Object Manager tracks. Finally, I'll look
at the Object Manager namespace, which is the doorway to file system namespaces
and the Registry namespace.
Resource Management
A major part of NT's role is managing a computer's physical and logical
resources, such as physical and virtual memory, disks, files, processes,
threads, synchronization primitives (semaphores, events, etc.), printers, and
video displays. NT must provide a mechanism whereby programs can look up
resources, share them, protect them, read and modify their attributes, and
interact with them. Thus, resource management encompasses tracking the state of
resources, allowing only actions consistent with their state, and an API so that
programs can manipulate them.
Files are a visible example of a common resource. NT provides an API for
creating and opening files; modifying their attributes (hidden, read-only,
etc.); and on NTFS, ensuring that programs honor file security settings.
Programs expect these capabilities, and NT implements its resource management
(i.e., the way NT efficiently keeps track of a file's state) hidden from
applications. The operating system does the work of tracking the state and
protecting resources.
In NT, the typical way a program accesses a resource such as a file is to
open or create the resource and then manipulate it. Usually, a resource is
assigned a name when it's created so that programs can share it. To look up or
open an existing shared resource or a global resource (e.g., a file system,
disk, or other physical device attached to the system), a program specifies the
resource's name. However, programs often create unnamed resources, which
typically are logical resources (e.g., synchronization primitives), that an
application will privately use.
Regardless of whether resources are physical resources (such as disk drives
and keyboards) or logical resources (such as files and shared virtual memory),
NT represents them as object data structures, which the Object Manager
defines. Objects are shells that other NT Executive subsystems can fill in so
that they can build custom object types to represent the resources they manage.
The Object Manager tracks information that is independent of the type of
resource an object represents; the subsystem-specific core of an object contains
data relevant to a particular resource.
The reason NT builds objects using the Object Manager's infrastructure is
simple: Each subsystem does not need to reinvent the wheel to track the
system-related state of an object, look up its resources, charge applications
for the memory required to allocate an object, and protect resources with
security. By concentrating these functions in the Object Manager, Microsoft can
share code across subsystems, write and validate NT's security code once, and
apply the same naming conventions to all resources.
Object Types
The Object Manager's duties involve creating object types, creating and
deleting objects, querying and setting an object's attributes, and locating
objects. As I mentioned previously, Executive subsystems (including the Object
Manager) create objects that represent the resources they manage. Before a
subsystem (e.g., the I/O Manager) can tell the Object Manager to make an object
(e.g., a file), the Object Manager must define the underlying object type
that the subsystem will instantiate the object from. Object types, like classes
in C++ parlance, store information common to all objects representing the same
type of resource. This information includes statistical information and pointers
to the method procedures that the subsystems will invoke when they perform
actions on an object of the corresponding type. Thus, when the Executive
subsystems initialize, they call a function in the Object Manager to define
their object types.
For example, open files require resource management, and the I/O Manager
subsystem builds file objects (with help from the Object Manager) to track open
files. Inside the file object's body, the I/O Manager keeps track of the file's
name, its logical volume, and whether the file is marked for deletion; the file
object also provides storage for private data associated with the file system
driver that the file belongs to.
Other examples of subsystem object types include process objects, which
represent active processes; section objects, which represent memory-mapped files
or shared memory; and device objects, which represent physical or logical
devices. Table 1 summarizes the 23 object types NT 4.0 defines.
As with objects, NT implements object types as data structures. Figure 1
shows typical information an object type data structure stores. The object
type's statistical data is useful for system monitoring. This data includes
information such as the name of the object type, how many objects of that type
currently exist, the maximum number of objects that have existed at any time,
and the default amount of memory that NT charges a process each time the
subsystem creates an object of that type.
Object type procedures or methods are what really differentiate object
types. When a subsystem creates an object type, the subsystem passes to the
Object Manager a data structure that contains pointers to all the object type
procedures. The Object Manager calls these procedures when the subsystem
requires actions performed on an object. For example, if a subsystem wants to
close an object, the Object Manager first calls the Okay-To-Close Procedure (if
the subsystem has specified one). If that procedure returns a FALSE value, an
error returns to the closer to signal that the object cannot be closed. If the
procedure returns a TRUE value, the Object Manager then calls the Close
Procedure so that the subsystem responsible for the object can clean up the
object's state. Each object type procedure receives a predefined list of
parameters that includes information pertinent to the requested operation. The
call-out mechanism the Object Manager uses for object types lets subsystems see
and control the actions taken on the objects (and therefore, the resources) that
they manage.
I'll describe the purpose of most of the object type procedures throughout
the rest of the article, but I'll comment on two unrelated procedures that
appear in Figure 1 now. The Dump Procedure is not defined for any object type,
nor does NT ever reference it. Microsoft developers probably relied on dump
procedures in the early days of NT, but they removed the code after they had the
basic object building blocks in place and working. The Security Procedure lets
subsystems implement object security schemes that differ from NT's default
security policies. NT falls back on its default security policies if a subsystem
does not define a Security Procedure.
Previous
Register
