The Registry The configuration manager is responsible for implementing and managing the system registry.

The registry plays a key role in the configuration and control of Windows systems. It is the repository for both systemwide and per-user settings. Although most people think of the registry as static data stored on the hard disk, as youll see in this section, the registry is also a window into various in- memory structures maintained by the Windows e ecutive and kernel. !iewing and "hanging the #egistry In general, you should never have to edit the registry directly$ application and system settings stored in the registry that might re%uire manual changes should have a corresponding user interface to control their modification. &owever, as youve already seen a number of times in this book, some advanced and debug settings have no editing user interface. Therefore, both graphical user interface '()I* and command-line tools are included with Windows to enable you to view and modify the registry. Windows comes with one main ()I tool for editing the registry+#egedit.e e+and a number of command-line registry tools. #eg.e e, for instance, has the ability to import, e port, back up, and restore keys, as well as to compare, modify, and delete keys and values. It can also set or %uery flags used in )A" virtuali,ation. #egini.e e, on the other hand, allows you to import registry data based on te t files that contain A-"II or )nicode configuration data.

The I./ 0anager The I/O manager is the core of the I./ system because it defines the orderly framework, or model, within which I./ re%uests are delivered to device drivers. The I./ system is packet driven. 0ost I./ re%uests are represented by an I/O request packet 'I#1*, which travels from one I./ system component to another. 'As youll discover in the section 23ast I./,4 fast I./ is the e ception5 it doesnt use I#1s.* The design allows an individual application thread to manage multiple I./ re%uests concurrently. An I#1 is a data structure that contains information completely describing an I./ re%uest. '6oull find more information about I#1s in the section 2I./ #e%uest 1ackets4 later in the chapter.* The I./ manager creates an I#1 in memory to represent an I./ operation, passing a pointer to the I#1 to the correct driver and disposing of the packet when the I./ operation is complete. In contrast, a driver receives an I#1, performs the operation the I#1 specifies, and passes the I#1 back to the I./ manager, either because the re%uested I./ operation has been completed, or because it must be passed on to another driver for further processing. 1n1 0anager &andles 1lug and 1lay and supports device detection and installation at boot time. It also has the responsibility to stop and start devices on demand+this can happen when a bus 'such as )-7 or 3ireWire* gains a new device and needs to have a device driver loaded to support it. Its bulk is actually implemented in user mode, in the 1lug and 1lay -ervice, which handles

the often comple tasks of installing the appropriate drivers, notifying services and applications of the arrival of new devices, and displaying ()I to the user. -everal completely automated computer interfaces are currently used, each of which re%uires no device configuration by the computer user, and the only task of the user is to install software for the self-configuring devices.

I888 9:;< '3ireWire* 1"I, 0ini 1"I 1"I 8 press, 0ini 1"I 8 press 1"0"IA, 1" "ard, 8 press"ard )-7

3or most of these interfaces, very little technical information is available to the end-user about the performance of the interface. Although both 3ireWire and )-7 have bandwidth that must be shared by all devices, most modern operating systems are unable to monitor and report the amount of bandwidth being used or available, or report activity on what devices are currently using the interface.

Memory Manager The memory manager 'e plained in "hapter 9= in 1art >* implements virtual memory, a memory management scheme that provides a large, private address space for each process that can e ceed available physical memory. The memory manager also provides the underlying support for the cache manager. 0anages virtual memory, controlling memory protection and the paging of memory in and out of physical memory to secondary storage, and implements a general-purpose allocator of physical memory. It also implements a parser of 18 e ecutables that lets an e ecutable be mapped or unmapped in a single, atomic step. -tarting from Windows ?T -erver <.=, Terminal -erver 8dition, the memory manager implements a so-called session space, a range of kernel-mode memory that is sub@ect to conte t switching @ust like user-mode memory. This lets multiple instances of the kernelmode Win:> subsystem and (AI drivers run side-by-side, despite shortcomings in their initial design. 8ach session space is shared by several processes, collectively referred to as a BsessionB. To ensure a degree of isolation between sessions without introducing a new ob@ect type, the association between processes and sessions is handled by the -ecurity #eference 0onitor, as an attribute of a security sub@ect 'token*, and it can only be changed while holding special privileges. The relatively unsophisticated and ad-hoc nature of sessions is due to the fact they werenCt part of the initial design, and had to be developed, with minimal disruption to the main line, by a third party '"itri * as a prere%uisite for theirterminal server product for Windows ?T,

called Win3rame. -tarting with Windows !ista, though, sessions finally became a proper aspect of the Windows architecture. ?o longer a memory manager construct that creeps into user mode indirectly through Win:>, they were e panded into a pervasive abstraction affecting most 8 ecutive subsystems. As a matter of fact, regular use of Windows !ista always results in a multi-session environment.D9:E Cache Controller "losely coordinates with the 0emory 0anager, I./ 0anager and I./ drivers to provide a common cache for regular file I./. )ni%uely, the Windows "ache 0anager operates on file blocks 'rather than device blocks*, for consistent operation between local and remote files, and ensures a certain degree of coherency with memory-mapped views of files, since cache blocks are a special case of memory-mapped views and cache misses a special case of page faults. The cache manager 'e plained in "hapter 99, 2"ache 0anager,4 in 1art >* improves the performance of file-based I./ by causing recently referenced disk data to reside in main memory for %uick access 'and by deferring disk writes by holding the updates in memory for a short time before sending them to the disk*. As youll see, it does this by using the memory managers support for mapped files. The cache manager is a set of kernel-mode functions and system threads that cooperate with the memory manager to provide data caching for all Windows file system drivers 'both local and network*. In this chapter, well e plain how the cache manager, including its key internal data structures and functions, works5 how it is si,ed at system initiali,ation time5 how it interacts with other elements of the operating system5 and how you can observe its activity through performance counters. Well also describe the five flags on the Windows CreateFile function that affect file caching. Local Procedure Call (LPC) 1rovides inter-process communication ports with connection semantics. F1" ports are used by user-mode subsystems to communicate with their clients, by 8 ecutive subsystems to communicate with user-mode subsystems, and as the basis for the local transport for 0-#1". All modern operating systems re%uire a mechanism for securely transferring data between one or more processes in user mode, as well as between a service in the kernel and clients in user mode. Typically, )?IG mechanisms such as mailslots, files, named pipes, and sockets are used for portability, while other developers use window messages for graphical applications. Windows implements an internal I1" mechanism called Advanced Focal 1rocedure "all, or AF1", which is a high-speed, scalable, and secured facility for message passing arbitrary-si,e messages. Although it is internal, and thus not available for third-party developers, AF1" is widely used in various parts of Windows$ HH Windows applications that use remote procedure call '#1"*, a documented A1I, indirectly use

AF1" when they specify local-RPC over the ncalrpc transport, a form of #1" used to communicate between processes on the same system. Iernel-mode #1", used by the network stack, also uses AF1". HH Whenever a Windows process and.or thread starts, as well as during any Windows subsystem operation 'such as all console I./*, AF1" is used to communicate with the subsystem process '"-#--*. All subsystems communicate with the session manager '-0--* over AF1". HH Winlogon uses AF1" to communicate with the local security authentication process, F-A--. HH The security reference monitor 'an e ecutive component e plained in "hapter J* uses AF1" to communicate with the F-A-- process. HH The user-mode power manager and power monitor communicate with the kernel-mode power manager over AF1", such as whenever the F"A brightness is changed. HH Windows 8rror #eporting uses AF1" to receive conte t information from crashing processes. HH The )ser-0ode Ariver 3ramework ')0A3* enables user-mode drivers to communicate using AF1". ?ote AF1" is the replacement for an older I1" mechanism initially shipped with the very first kernel design of Windows ?T, called F1", which is why certain variables, fields, and functions might still refer to 2F1"4 today. Ieep in mind that F1" is now emulated on top of AF1" for compatibility and has been removed from the kernel 'legacy system calls still e ist, which get wrapped into AF1" calls*. Object Manager The /b@ect 0anager 'internal name/b* is an e ecutive subsystem that all other e ecutive subsystems, especially system calls, must pass through to gain access to Windows ?T resources+essentially making it a resource management infrastructure service.DJE The ob@ect manager is used to reduce the duplication of ob@ect resource management functionality in other e ecutive subsystems, which could potentially lead to bugs and make development of Windows ?T harder.DKE To the ob@ect manager, each resource is an ob@ect, whether that resource is a physical resource 'such as a file system or peripheral* or a logical resource 'such as a file*. 8ach ob@ect has a structure or ob@ect type that the ob@ect manager must know about. /b@ect creation is a process in two phases, creation and insertion. "reationcauses the allocation of an empty ob@ect and the reservation of any resources re%uired by the ob@ect manager, such as an 'optional* name in the namespace. If creation was successful, the subsystem responsible for the creation fills in the empty ob@ect.DLE 3inally, if the subsystem deems the initiali,ation successful, it instructs the ob@ect manager to insert the ob@ect, which makes it accessible through its 'optional* name or a cookie called a handle.D;E 3rom then on, the lifetime of the ob@ect is handled by the ob@ect manager, and itCs up to the subsystem to keep the ob@ect in a working condition until being signaled by the ob@ect manager to dispose of it.D9=E

&andles are identifiers that represent a reference to a kernel resource through an opa%ue value.D99E -imilarly, opening an ob@ect through its name is sub@ect to security checks, but acting through an e isting, open handle is only limited to the level of access re%uested when the ob@ect was opened or created. /b@ect types define the ob@ect procedures and any data specific to the ob@ect. In this way, the ob@ect manager allows Windows ?T to be an ob@ect orientedoperating system, as ob@ect types can be thought of as polymorphic classes that define ob@ects. 0ost subsystems, though, with a notable e ception in the I./ 0anager, rely on the default implementation for all ob@ect type procedures. 8ach instance of an ob@ect that is created stores its name, parameters that are passed to the ob@ect creation function, security attributes and a pointer to its ob@ect type. The ob@ect also contains an ob@ect close procedure and a reference count to tell the ob@ect manager how many other ob@ects in the system reference that ob@ect and thereby determines whether the ob@ect can be destroyed when a close re%uest is sent to it.D9>E 8very named ob@ect e ists in a hierarchical ob@ectnamespace.