Part I introduces the Windows NT Operating System and some of the issues of filesystem driver development.
• Chapter 1, Windows NT System Components• Chapter 2, File System Driver Development• Chapter 3, Structured Driver Development
In ibis chapter:• The Basics
« The Windows NTKernel* The Windows NT
ExecutiveWindows NT System
Components
The focus of this book is the Windows NT file system and the interaction of thefile system with the other core operating system components. If you are interestedin providing value-added software for the Windows NT platform, the topics onfilter driver design and development should provide you with a good under-standing of some of the mechanics involved in designing such software.
File systems and filter drivers don't exist in a vacuum, but interact heavily with therest of the operating system. This chapter provides an overview of the maincomponents of the Windows NT operating system.
The Basics
Operating systems deal with issues that users prefer to forget, including initial-izing processor states, coordinating multiple CPUs, maintaining CPU cachecoherency, managing the local bus, managing physical memory, providing virtualmemory support, dealing with external devices, defining and scheduling userprocesses/threads, managing user data stored on external devices, and providingthe foundation for an easily manageable and user-friendly computing system.Above all, the operating system must be perceived as reliable and efficient, sinceany perceived lack of these qualities will almost certainly result in the universalrejection and thereby in the quick death of the operating system.
Contrary to what you may have heard, Windows NT is not a state-of-the-art oper-ating system by any means. It employs concepts and principles that have beenknown for years and have actually been implemented in many other commercialoperating systems. You can envision the Windows NT platform as the result of aconfluence of ideas, principles, and practices obtained from a wide variety of
Chapter 1: Windows NT System Components
sources, from both commercial products and research projects conducted by
universities.
Design principles and methodologies from the venerable UNIX and OpenVMSoperating system platforms, as well as the MACH operating system developed atCMU, are obvious in Windows NT. You can also see the influence of less sophisti-cated systems, such as MS-DOS and OS/2. However, do not be misled intothinking that Windows NT can be dismissed as just another conglomeration ofrehashed design principles and ideas. The fact that the designers of Windows NTwere willing to learn from their own experiences in designing other operatingsystems and the experiences of others has led to the development of a fairlystable and serious computing platform.
The Core Architecture
Certain philosophies derived from the MACH operating system are visible in thedesign of Windows NT. These include an effort to minimize the size of the kernel
and to implement parts of the operating system using the client-server model,
with a message-passing method to transfer information between modules. Further-more, the designers have tried to implement a layered operating system, whereeach component interacts with other layers via a well-defined interface.
The operating system was designed specifically to run in both single-processor
and symmetric multiprocessor environments.
Finally, one of the primary goals was to make the operating system easilyportable across many different hardware architectures. The designers tried toachieve this goal by using an object-based model to design operating systemcomponents and by abstracting out those small pieces of the operating systemthat are hardware-dependent and therefore need to be reimplemented for eachsupported platform; the more portable components can, theoretically, simply berecompiled for the different architectures.
Figure 1-1 illustrates how the Windows NT operating system is structured. Thefigure shows that Windows NT can be broadly divided into two main compo-nents: user mode and kernel mode.
User mode
The operating system provides support for protected subsystems. Each protectedsubsystem resides in its own process with its memory protected from othersubsystems. Memory protection support is provided by the Windows NT Virtual
Memory Manager.
The Basics
Figure 1-1. Overview of the Windows NT operating system environment
The subsystems provide well-defined Application Programming Interfaces (APIs)that can be used by user-mode processes to obtain desired functionality. Thesubsystems then communicate with the kernel-mode portion of the operatingsystem using well-defined system service calls.
Chapter 1: Windows NT System Components
NOTE Microsoft has never really documented the operating-system-provid-ed system-service calls. They instead encourage application develop-ers for the Windows NT platform to use the services of one of thesubsystems provided by the operating system environment.
By not documenting the native Windows NT system service APIs,the designers have tried to maintain an abstract view of the operat-ing system. Therefore, applications only interact with their preferrednative subsystem, leaving the subsystem to interact with the operat-ing system. The benefit to Microsoft of using this philosophy is totie most applications to the easily portable Win32 subsystem (thesubsystem of choice and, sometimes, the subsystem of necessity),and also to allow the operating system to evolve more easily thanwould be possible if major applications depended on certain specif-ic native Windows NT system services.
However, it is sometimes more efficient (or necessary) for WindowsNT applications and kernel-mode driver developers to be able to ac-cess the system services directly. In Appendix A, Windows NT Sys-tem Services, you'll find a list of the system services provided by theWindows NT I/O Manager to perform file I/O operations.
Environment subsystems provide an API and an execution environment to userprocesses that emulates some specific operating system (e.g., an OS/2 or UNIX orWindows 3.x operating system). Think of a subsystem as the personality of theoperating system as viewed by a user process. The process can execute comfort-ably within the safe and nurturing environment provided by the specificsubsystem without having to worry about the capabilities, programming inter-faces, and requirements of the core Windows NT operating system.The following environment subsystems are provided with Windows NT:
Win32
The native execution environment for Windows NT. Microsoft actively encour-ages application developers to use the Win32 API in their software to obtain
operating system services.
This subsystem is also more privileged than the others.* It is solely respon-sible for managing the devices used to interact with users; the monitor,keyboard, and mouse are all controlled by the Win32 subsystem. It is also the
* In reality, this is the only subsystem that is actively encouraged by Microsoft for use by third-party ap-plication program designers. The other subsystems work (more often than not) but seem to exist only aschecklist items. If, for example, you decided to develop an application using the POSIX subsystem in-stead, you will undoubtedly encounter limitations and frustrations due to the very visible lack of commit-ment on behalf of Microsoft in making the subsystem fully functional and full featured.
The Basics________________________________________________7
sole Window Manager for the system and defines the policies that control theappearance of graphical user interfaces.
POSIX
This exists to provide support to applications conforming to the POSIX 1003.1source-code standard. If you have applications that were developed to usethe APIs defined in that standard, you should theoretically be able to compile,link, and execute them on a Windows NT platform.
There are severe restrictions on functionality provided by the POSIXsubsystem that your applications must be prepared to accept. For example,no networking support is provided by the POSIX subsystem.
OS/2
Provides API support for 16-bit OS/2 applications on the Intel x86 hardware
platform.
WOW (Windows on Windows)
This provides support for 16-bit Windows 3.x applications. Note, however,that 16-bit applications that try to control or access hardware directly will not
execute on Windows NT platforms.
VDM (Virtual DOS Machine)
Provided to support execution of 16-bit DOS applications. As in the case of16-bit Windows 3.x applications, any process attempting to directly control oraccess system hardware will not execute on Windows NT.Integral subsystems extend the operating system into user space and provideimportant system functionality. These include the user-space components of the
Security subsystem (e.g., the Local Service Authority); the user-space components
of the Windows NT LAN Manager Networking software; and the Service ControlManager responsible for loading, unloading, and managing kernel-mode driversand system services, among others.
Kernel mode
The difference between executing code in kernel mode and in user mode is thehardware privilege level at which the CPU is executing the code.
Most CPU architectures provide at least two hardware privilege levels, and many
provide multiple levels. The hardware privilege level of the CPU determines the
possible set of instructions that code can execute. For example, when executingin user mode, processes cannot directly modify or access CPU registers or page-tables used for virtual memory management. Allowing all user processes access tosuch privileges would quickly result in chaos and would preclude any serioustasks from being performed on the CPU.
8___________________________Chapter 1: Windows NT System Components
Windows NT uses a simplified hardware privilege model that has two privilegelevels: kernel mode, which allows code to do anything necessary on theprocessor;* and user mode, where the process is tightly constrained in the rangeof allowed operations.
If you're familiar with the Intel x86 architecture set, kernel mode is equivalent tothe Ring 0 privilege level for processors in the set and user mode to Ring 3-
The terms kernel mode and user mode, although often used to describe code
(functions), are actually privilege levels associated with the processor. Therefore,
the term kernel-mode code simply means that the CPU will always be in kernel-mode privilege level when it executes that particular code, and the term user-mode code means that the CPU will execute the code at user-mode privilege level.
Typically, as a third-party developer, you cannot execute Windows NT programs
while the CPU is at kernel-mode privilege level unless you design and developWindows NT kernel-mode drivers.
The kernel-mode portion of Windows NT is composed of the following:
The Hardware Abstraction Layer (HAL)
The Windows NT operating system was designed to be portable acrossmultiple architectures. In fact, you can run Windows NT on Intel x86 plat-forms, DEC Alpha platforms, and also the MIPS-based platforms (although
support for this architecture has recently been discontinued by Microsoft).
Furthermore, there are many kinds of external buses that you could use withWindows NT, including (but not limited to) ISA, EISA, VL-Bus, and PCI busarchitectures. The Windows NT developers created the HAL to isolate hard-ware-specific code. The HAL is a relatively thin layer of software thatinterfaces directly with the CPU and other hardware system components andis responsible for providing appropriate abstractions to the rest of the system.The rest of the Windows NT Kernel sees an idealized view of the hardware,as presented by the HAL. All differences across multiple hardware architec-tures are managed internally by the HAL. The set of functions exported by theHAL are invoked by both the core operating system components (e.g., theWindows NT Kernel component), and device drivers added to the operatingsystem.
The HAL exports functions that allow access to system timers, I/O buses,DMA and Interrupt controllers, device registers, and so on.
* Code that executes in kernel mode can do virtually anything with the system. This includes crashingthe system or corrupting user data. Therefore, with the flexibility of kernel-mode privileges comes a lotof responsibility that kernel-mode designers must be aware of.
The Windows NT Kernel
The Windows NT Kernel
The Windows NT Kernel provides the fundamental operating system function-ality that is used by the rest of the operating system. Think of the kernel as
the module responsible for providing the building blocks that can subse-quently be used by the Windows NT Executive to provide all of the powerful
functionality offered by the operating system. The kernel is responsible for
providing process and thread scheduling support, support for multiprocessorsynchronization via spin lock structures, interrupt handling and dispatching,
and other such functionality.
The Windows NT Kernel is described further in the next section.
The Windows NT Executive
The Executive comprises the largest portion of Windows NT. It uses theservices of the kernel and the HAL, and is therefore highly portable acrossarchitectures and hardware platforms. It provides a rich set of system services
to the various subsystems, allowing them to access the operating systemfunctionality.
The major components of the Windows NT Executive include the ObjectManager, the Virtual Memory Manager, the Process Manager, the I/OManager, the Security Reference Monitor, the Local Procedure Call facility, theConfiguration Manager, and the Cache Manager.
File systems, device drivers, and intermediate drivers form a part of the I/Osubsystem that is managed by the I/O Manager and are part of the Windows
NT Executive.
The Windows NT Kernel
The Windows NT Kernel has been described as the heart of the operating system,although it is quite small compared to the Windows NT Executive. The kernel isresponsible for providing the following basic functionality:• Support for kernel objects
• Thread dispatching
• Multiprocessor synchronization• Hardware exception handling
• Interrupt handling and dispatching
• Trap handling
• Other hardware specific functionality
Chapter 1: Windows NT System Components
The Windows NT Kernel code executes at the highest privilege level on theprocessor.* It is designed to execute concurrently on multiple processors in asymmetric multiprocessing environment.
The kernel cannot take page faults; therefore, all of the code and data for thekernel is always resident in system memory. Furthermore, the kernel code cannotbe preempted; therefore, context switches are not allowed when a processorexecutes code belonging to the kernel. However, all code executing on anyprocessor can always be interrupted, provided the interrupt level is higher thanthe level at which the code is executing.
IRQ Levels
The Windows NT Kernel defines and uses Interrupt Request Levels (IRQLs) to
prioritize execution of kernel-mode components. The particular IRQL at which apiece of kernel-mode code executes determines its hardware priority. All inter-rupts with an IRQL that is less than or equal to the IRQL of the currentlyexecuting kernel-mode code are masked off (i.e., disabled) by the Windows NTKernel. However, the currently executing code on a processor can be interruptedby any software or hardware interrupt with an IRQL greater than that of theexecuting code. IRQLs are hierarchically ordered and are defined as follows (inincreasing order of priority):
PASSIVE_LEVEL
Normal thread execution interrupt levels. Most file system drivers are asked toprovide functionality by a thread executing at IRQL PASSIVE_LEVEL,though this is not guaranteed. Most lower-level drivers, such as devicedrivers, are invoked at a higher IRQL than PASSIVE_LEVEL.
This IRQL is also known as LOW_LEVEL.APC_LEVEL
Asynchronous Procedure Call (APC) interrupt level. Asynchronous ProcedureCalls are invoked by a software interrupt, and affect the control flow for atarget thread. The thread to which an APC is directed will be interrupted, andthe procedure specified when creating the APC will be executed in thecontext of the interrupted thread at APC_LEVEL IRQL.
DISPATCH_LEVEL
Thread dispatch (scheduling) and Deferred Procedure Call (DPC) interruptlevel. DPCs are defined in Chapter 3, Structured Driver Development. Once a
* The highest privilege level is defined as the level at which the operating system software has completeand unrestricted access to all capabilities provided by the underlying CPU architecture.
The Windows NT Kernel_______________________________________U_thread IRQL has been raised to DPC level or greater, thread scheduling isautomatically suspended.
Device Interrupt Levels (DIRQLs)
Platform-specific number and values of the device IRQ levels.
PROFILE_LEVEL
Timer used for profiling.CLOCK1_LEVEL
Interval timer clock 1.
CLOCK2_LEVEL
Interval timer clock 2.
IPI_LEVEL
Interprocessor interrupt level used only on multiprocessor systems.POWER_LEVEL
Power failure interrupt.HIGHEST_LEVEL
Typically used for machine check and bus errors.
APC_LEVEL and DISPATCH_LEVEL interrupts are software interrupts. They arerequested by the kernel-mode code and are lower in priority than any of the hard-ware interrupt levels. The interrupts in the range CLOCK1_LEVEL to HIGH_LEVEL are the most time-critical interrupts, and they are therefore the highestpriority levels for thread execution.
Support for Kernel Objects
The Windows NT Kernel also tries to maintain an object-based environment. Itprovides a core set of objects that can be used by the Windows NT Executive andalso provides functions to access and manipulate such objects. Note that theWindows NT Kernel does not depend upon the Object Manager (which formspart of the Executive) to manage the kernel-defined object types.
The Windows NT Executive uses objects exported by the kernel to construct evenmore complex objects made available to users.Kernel objects are of the following two types:
Dispatcher objects
These objects control the synchronization and dispatching of system threads.Dispatcher objects include thread, event, timer, mutex, and semaphore objecttypes. You will find a description of most of these object types in Chapter 3.
/2___________________________Chapter 1: Windows NT System Components
Control objects
These objects affect the operation of kernel-mode code but do not affectdispatching or synchronization. Control objects include APC objects, DPCobjects, interrupt objects, process objects, and device queue objects.The Windows NT Kernel also maintains the following data structures:
Interrupt Dispatcher Table
This is a table maintained by the kernel to associate interrupt sources withappropriate Interrupt Service Routines.Processor Control Blocks (PRCBs)
There is one PRCB for each processor on the system. This structure containsall sorts of processor-specific information, including pointers to the threadcurrently scheduled for execution, the next thread to be scheduled, and theidle thread.
NOTE Each processor has an idle thread that executes •whenever no other
thread is available. The idle thread has a priority below that of allother threads on the system. The idle thread continuously loopslooking for work such as processing the DPC queue and initiating acontext switch whenever another thread becomes ready to executeon the processor.
Processor Control Region
This is a hardware architecture-specific kernel structure that contains pointersto the PRCB structure, the Global Descriptor Table (GOT), the InterruptDescriptor Table (IDT), and other information.DPC queue
This global queue contains a list of procedures to be invoked whenever theIRQL on a processor falls below IRQL DISPATCH_LEVEL.Timer queue
A global timer queue is also maintained by the NT Kernel. This queuecontains the list of timers that are scheduled to expire at some future time.Dispatcher database
The thread dispatcher module maintains a database containing the executionstate of all processors and threads on the system. This database is used by thedispatcher module to schedule thread execution.
In addition to the object types mentioned above, the Windows NT Kernel main-tains device queues, power notification queues, processor requester queues, andother such data structures required for the correct functioning of the kernel itself.
The Windows NT Kernel_______________________________________13
Processes and Threads
A process is an object* that represents an instance of an executing program. InWindows NT, each process must have at least one thread of execution. Theprocess abstraction is composed of the process-private virtual address space forthe process, the code and data that is private to the process and contained withinthe virtual address space, and system resources that have been allocated to theprocess during the course of execution.
Note that process objects are not schedulable entities in themselves. Thereforeyou cannot actually schedule a process to execute. However, each processcontains one or more schedulable threads of execution.
Each thread object executes program code for the process and is therefore sched-uled for execution by the Windows NT Kernel. As noted above, more than onethread can be associated with any process, and each thread is scheduled forexecution individually.
The context of a thread object consists of user- and kernel-stack pointers for thethread, a program counter for the thread indicating the current instruction beingexecuted, system registers (including integer and floating-point registers)containing state information, and other processor status maintained while thethread is executing.
Each thread has a scheduling state associated with it. The possible states areinitialized, ready-to-run, standby, running, waiting, and terminated. Only onethread can be in the running state on any processor at any given instant, thoughmultiple threads can be in this state on multiprocessor systems (one perprocessor).
Threads have execution priority levels associated with them; higher prioritythreads are always given preference during scheduling decisions and alwayspreempt the execution of lower priority threads. Priority levels are categorizedinto the real-time priority class and the variable priority class.
* The Windows NT Kernel defines the fundamental thread and process objects. The Windows NT Exec-
utive uses the core structures defined by the kernel to define Executive thread and process object abstrac-tions.
14 ____ __________Chapter 1: Windows NT System Components
NOTE It is possible to encounter situations of priority-inversion on Win-dows NT systems, where a lower-priority thread may be holding acritical resource required by a higher-priority thread (even a threadexecuting with real-time priority). Any thread that is of higher-priori-ty than the one holding the critical resource would then get the op-portunity to execute even if it has a priority lower than that of thethread waiting for the resource.*
The scenario described above violates the assumption that higherpriority threads will always preempt and execute before any lowerpriority threads are allowed to execute. This could lead to incorrectbehavior, especially in situations where thread priorities must bemaintained (e.g., for real-time processes). Kernel-mode designersmust anticipate and understand that these situations can occur un-less they ensure that resource acquisition hierarchies are correctlydefined and maintained.
Windows NT does not provide support for features such as priorityinheritance that could automatically help avoid the priority inver-sion problem.
Most kernel-provided routines for programmatically manipulating or accessingthread or process structures are not exposed to third-party driver developers.
Thread Context and Traps
A trap is the processor-provided mechanism for capturing the context of an
executing thread when certain events occur. Events that cause a trap include inter-rupts, exception conditions (described in Chapter 3), or a system service callcausing a change in processor mode from user mode to kernel mode of execution.
When a trap condition occurs, the operating system trap handler is invoked.t TheWindows NT trap handler code saves the information for an executing thread inthe form of a call frame before invoking an appropriate routine to process the
trap condition. Here are two components of a call frame:
A trap frame
This contains the volatile register state.
* Priority inversion requires three threads to be running concurrently: the high-priority thread that re-
quires the critical resource, the low-priority thread that has the resource acquired, and the intermediate-priority thread that does not want or need the resource and therefore gets the opportunity to preempt thelow-priority thread (because it has a higher relative priority) but also (in the process) prevents the high-
priority thread from executing even though it has a relatively lower priority.
t The trap handler is written in assembly, is highly processor- and architecture-specific, and is a core
piece of functionality provided by the Windows NT Kernel.
The Windows NT Executive_____________________________________75
An exception frame
When exception conditions occur that cause the trap handler to be invoked,the nonvolatile register state is also saved.In addition, the trap handler also saves the previous machine state and any infor-mation that will allow the thread to resume execution after the trap condition hasbeen processed appropriately.
The Windows NT Executive
The Windows NT Executive is composed of distinct modules, or subsystems, each
of which assumes responsibility for a primary piece of functionality. Typically,references to Windows NT kernel-mode code actually refer to modules in theExecutive.
The Executive provides a rich set of system service calls (an API) for subsystemsto access its services. In addition, the Executive also provides comprehensivesupport to developers who wish to extend the existing functionality. Develop-ment is usually in the form of third-party device drivers, installable file systemdrivers, and other intermediate and filter drivers used to provide value-addedservices.
The various components that comprise the Windows NT Executive maintain moreor less strict boundaries around themselves. Once again, the object-based natureof the operating system manifests itself in the prolific use of abstract data typesand methods. Modules do not directly access the internal data structures of othermodules; note that, although the designers have managed to stick to well-definedinterfaces internally, modules still make many assumptions when they invokeeach other. The assumptions are often in the form of expectations of whatprocessing the called module will perform and how error conditions will behandled and/or reported. Finally, as you will observe later in this book, thesynchronization hierarchy employed by the Executive components when theyrecursively invoke each other is more than just a little complicated.
The Windows NT Object Manager
All components of the Windows NT Executive that export data types for use byother kernel-mode modules use the services of the Object Manager to define,create, and manage the data types, as well as instances of the data types.
The NT Object Manager manages objects. An object is defined as an opaque datastructure implemented and manipulated by a specific kernel-mode (Executive)component. Each object may have a set of operations defined for it; these include
Chapter 1: Windows NT System Components
operations to create an instance of the object, delete an instance of the object,wait for the object to be signaled, and signal the object.
The Object Manager provides the capabilities to do the following:
• Add new object types to the system dynamically (note that the Object Man-ager does not concern itself with the internal data structure of the object).
• Allow modules to specify security and protection for instances of the object
type.
• Provide methods to create and delete object instances.
• Allow the module defining an object type to provide its own methods (such
as methods for create, close, and delete operations) to manipulate instancesof object types.• Provide a consistent methodology to maintain references of instances of the
object type.• Provide a global naming hierarchy based upon the more commonly used file
system hierarchy inverted-tree format.The Object Manager maintains a global name space for Windows NT. All namedobjects in the system can be accessed via this name space. The object name spaceis modeled on normal filenaming conventions. Therefore, there is a global rootdirectory named \"\\\" created by the Object Manager during system initialization.Executive components can create directories and subdirectories under the rootdirectory and then create instances of defined object types under any such direc-tory. Whenever an object is created or inserted (even for file-system-definedobjects such as files and directories), parsing of the object name begins at the rootof the Object-Manager-maintained name space. If an object type has a parsemethod defined for it (as for example, file objects representing open file systemfiles and directories), the Object Manager invokes the parse method for the object.Chapter 2, File System Driver Development, provides additional information onhow the Object Manager handles requests to open or create on-disk file or direc-tory objects.
The object type structure maintained by the NT Object Manager contains informa-tion such as the type of memory pool from which instances of the object type
should be allocated, the valid access types for the object, pointers to proceduresassociated with the object (these are optional and could include pointers tocreate, open, close, delete, and other such procedures), and some synchroniza-tion structure maintained by the Object Manager for all object instances of theparticular type.
Each object instance has a standard object header and an object-type-specificobject body associated with it. The standard object header contains information
The Windows NT Executive_____________________________________17_
such as pointers to the name of the object (if any), a security descriptor associatedwith the object (if any), the access mode for the object, reference counts for theobject, a pointer to the object type (to which the object instance belongs), andother attributes associated with the object.
Whenever a thread successfully opens an instance of a particular object type, theNT Object Manager returns to the requesting thread an opaque handle to theobject instance. Note that there can be more than one handle to any objectinstance at any given point in time. For example, object handles can potentiallybe inherited.
The Object Manager maintains information associated with each object handle,including a pointer to the object instance, the access information for the openoperation, and other attributes for the handle. Note that there is no direct relation-ship between the handle and the pointer to the open instance of the object type.The handle is typically an index into an object table, which is composed of anarray of object table entries.
WARNING Handles are specific to a process. Therefore, if a thread successfully
performs a create and open operation and obtains a handle in re-turn, all threads for the particular process can use that handle.
However, if the same handle is used in the context of a thread asso-ciated -with any other process, you will receive an error code indicat-ing that the handle is invalid.*
Other Windows NT Executive Components
As mentioned earlier, the other major components of the Windows NT Executiveare as follows:
The Process Manager
This component is responsible for the creation and deletion of processes andthreads. It uses the services provided by the Windows NT Kernel to performtasks such as suspending an executing process, resuming execution of aprocess, providing process information, and so on.
* Although this may not make sense to you yet, this error is a leading cause of frustration to driver de-velopers who open a resource in their DriverEntry () routine and then try to use the returned handlein some other dispatch routine, which is typically executed in the context of another thread (and process).
18__________________________Chapter 1: Windows NT System Components
The Local Procedure Call (LPC) facility
This facility is the mechanism by which messages can be passed between twoprocesses on the same node.* The client process typically passes parametersto a server process and requests some services. In return, it may receive someprocessed data back from the server process.
The client's call to the server is intercepted by a stub in the client process that
packages the parameters being sent to the server procedure. Then the LPCfacility provides the mechanism for the client process to transmit the data tothe server and then wait for a response back from the server. This is doneusing a Port object, defined and created by the LPC facility.
The LPC facility is modeled on the Remote Procedure Call mechanism used toimplement the client-server model across machines connected by a local orwide area network. The LPC facility is better optimized for communicationwithin a node where all processes have access to the same physical memory.
Security Reference Monitor
This module is responsible for enforcing security policy on the local node. Italso provides object auditing facilities.
Virtual Memory Manager
The Windows NT Virtual Memory Manager (VMM) manages all available phys-ical memory on the local node. It is also responsible for providing virtual
memory management functionality to the rest of the operating system, as well
as to all applications that execute on the node.
Almost all kernel-mode and user-mode modules must interact with the Virtual
Memory Manager component. Most modules are clients of the Virtual MemoryManager and therefore depend on the VMM to provide memory managementservices. File systems, however, are special, because they must often provide
services to the VMM (e.g., for reading or writing page files). File system
designers must understand thoroughly the interactions of file system driverswith the VMM module. The VMM is discussed in greater detail in Chapter 5,The NT Virtual Memory Manager.
Cache Manager
The Windows NT Executive contains a dedicated caching module to providevirtual block caching functionality (in system memory) for file data stored on
secondary storage media. The Cache Manager uses the services of the
Windows NT Virtual Memory Manager to provide caching functionality. All ofthe native NT file system driver implementations use the services of the Cache
* A single node can be defined as a computer containing either a single processor or multiple processors.Multiple nodes can potentially be networked together to create a Windows NT cluster.
The Windows NT Executive_____________________________________19
Manager. The Windows NT Cache Manager is discussed in detail in Chapters6-8.
I/O Manager
The Windows NT I/O Manager defines and manages the framework withinwhich all kernel-mode drivers (including file system, network, disk, interme-diate, and filter drivers) can reside. The I/O Manager is described in detail in
Chapter 4, The NTI/O Manager.
因篇幅问题不能全部显示，请点此查看更多更全内容