Win32 API function
Create a new registry key
Delete a registry key
Open a key to get a handle to it
Enumerate the subkeys subordinate to the key of the handle
Look up the data for a value within a key
Some of the Win32 API calls for using the registry
When the system is turned off, most of the registry information is stored on the
disk in the hives. Because their integrity is so critical to correct system func-
tioning, backups are made automatically and metadata writes are flushed to disk to
prevent corruption in the event of a system crash.
Loss of the registry requires
software on the system.
11.3 SYSTEM STRUCTURE
In the previous sections we examined Windows as seen by the programmer
writing code for user mode.
Now we are going to look under the hood to see how
the system is organized internally, what the various components do, and how they
interact with each other and with user programs.
This is the part of the system
seen by the programmer implementing low-level user-mode code, like subsystems
and native services, as well as the view of the system provided to device-driver
Although there are many books on how to use Windows, there are many fewer
on how it works inside.
One of the best places to look for additional information
on this topic is
Microsoft Windows Internals
, 6th ed., Parts 1 and 2 (Russinovich
and Solomon, 2012).
11.3.1 Operating System Structure
As described earlier, the Windows operating system consists of many layers, as
depicted in Fig. 11-4. In the following sections we will dig into the lowest levels
of the operating system: those that run in kernel mode.
The central layer is the
NTOS kernel itself, which is loaded from
when Windows boots.
NTOS itself consists of two layers, the
, which containing most of the
services, and a smaller layer which is (also) called the
and implements the
underlying thread scheduling and synchronization abstractions (a kernel within the
kernel?), as well as implementing trap handlers, interrupts, and other aspects of
how the CPU is managed.
CASE STUDY 2: WINDOWS 8
The division of NTOS into kernel and executive is a reflection of NT’s
The VMS operating system, which was also designed by Cutler,
had four hardware-enforced layers: user, supervisor, executive, and kernel corres-
ponding to the four protection modes provided by the VAX processor architecture.
The Intel CPUs also support four rings of protection, but some of the early target
processors for NT did not, so the kernel and executive layers represent a soft-
ware-enforced abstraction, and the functions that VMS provides in supervisor
mode, such as printer spooling, are provided by NT as user-mode services.
The kernel-mode layers of NT are shown in Fig. 11-11. The kernel layer of
NTOS is shown above the executive layer because it implements the trap and inter-
rupt mechanisms used to transition from user mode to kernel mode.
System library kernel user-mode dispatch routines (ntdll.dll)
Hardware abstraction layer
Executive run-time library
CPU scheduling and synchronization: threads, ISRs, DPCs, APCs
NTOS executive layer
Procs and threads
all other devices
CPU, MMU, interrupt controllers, memory, physical devices, BIOS
Windows kernel-mode organization.
The uppermost layer in Fig. 11-11 is the system library (
), which ac-
tually runs in user mode.
The system library includes a number of support func-
tions for the compiler run-time and low-level libraries, similar to what is in
also contains special code entry points used by the kernel to ini-
tialize threads and dispatch exceptions and user-mode
). Because the system library is so integral to the operation of the ker-
nel, every user-mode process created by NTOS has
mapped at the same fixed
address. When NTOS is initializing the system it creates a section object to use
, and it also records addresses of the
entry points used by
Below the NTOS kernel and executive layers is a layer of software called the
Hardware Abstraction Layer
) which abstracts low-level hardware details
like access to device registers and DMA operations, and the way the parentboard