Page 342 - DCAP103_Principle of operating system

Unit 11: Operating System Structure

many system calls and most of the graphics. Since customers can install new device drivers, Notes
they have the power to affect the kernel and corrupt the system. For this reason, drivers must
be written with great care.

11.1.5 Implementation of Objects
Objects are probably the single most important concept in Windows 2000. They provide a uniform
and consistent interface to all system resources and data structures such as processes, threads,
semaphores, etc. This uniformity has various facets. First, all objects are named and accessed
in the same way, using object handles. Second, because all accesses to the objects go through the
object manager, it is possible to put all the security checks in one place and ensure that no process
can make an end run around them. Third, sharing of objects among processes can be handled in
a uniform way. Fourth, since all object opens and closes go through the object manager, it is easy
to keep track of which objects are still in use and which can be safely deleted. Fifth, this uniform
model for object management makes it easy to manage resource quotas in a straightforward way.

A key to understanding objects is to realize that an (executive) object is just some number of
consecutive words in memory (i.e., in kernel virtual address space). An object is a data, structure
in RAM, no more and no less. A file on disk is not an object, although an object (i.e., a data
structure in kernel virtual address space) is created for a file when it is opened. A consequence
of the fact that objects are just kernel data structures is that when the system is rebooted (or
crashes) all objects are lost. In fact, when the system boots, there are no objects present at all
(except for the idle and system processes, whose objects are hardwired into the ntoskrnl.exe
file). All other objects are created on the fly as the system boots up and various initialization
(and later user) programs run.

Objects have a structure, as shown in Figure 11.3. Each object contains a header with certain
information common to all objects of all types. The fields in this header include the object’s
name, the object directory in which it lives in object space, security information (so a check can
be made when an object is opened), and a list of processes with open handles to the object (if
a certain debugging flag is enabled).

Figure 11.3: The Structure of an Object

Object name
Directory in which the object lives
Object Security information (which can use object)
header Quota charges (cost to use the object)
List of processes with handles
Reference counts
Type name
Pointer to the type object
Access types
Quota charges
Synchronizable
Object Object-specific data Pageable
data
Open method
Close method
Delete method
Query name method
Parse method
Security method

LOVELY PROFESSIONAL UNIVERSITY 335