Windows NT
kernel mode has full access to the hardware and system resources of the computer and runs code in a protected memory area. It controls access to scheduling, thread prioritization, memory management and the interaction with hardware. The kernel mode stops user mode services and applications from accessing critical areas of the operating system that they should not have access to; user mode processes must ask the kernel mode to perform such operations on their behalf. While the
x86 architecture supports four different privilege levels (numbered 0 to 3), only the two extreme privilege levels are used. Usermode programs are run with CPL 3, and the kernel runs with CPL 0. These two levels are often referred to as "ring 3" and "ring 0", respectively. Such a design decision had been done to achieve code portability to
RISC platforms that only support two privilege levels, though this breaks compatibility with
OS/2 applications that contain I/O privilege segments that attempt to directly access hardware.
Executive The Windows Executive services make up the low-level kernel-mode portion, and are contained in the file
ntoskrnl.exe. This is distinct from the concept of a "service process", which is a user mode component somewhat analogous to a
daemon in
Unix-like operating systems. . This is a
screenshot from
Sysinternals WinObj. ; Object Manager :The
Object Manager (internal name
Ob) is an executive subsystem that all other executive subsystems, especially system calls, must pass through to gain access to Windows NT resources—essentially making it a resource management infrastructure service. The object manager is used to reduce the duplication of object resource management functionality in other executive subsystems, which could potentially lead to bugs and make development of Windows NT harder. To the object manager, each resource is an object, whether that resource is a physical resource (such as a file system or peripheral) or a logical resource (such as a file). Each object has a structure or
object type that the object manager must know about. :Object creation is a process in two phases,
creation and
insertion.
Creation causes the allocation of an empty object and the reservation of any resources required by the object manager, such as an (optional) name in the namespace. If creation was successful, the subsystem responsible for the creation fills in the empty object. Finally, if the subsystem deems the initialization successful, it instructs the object manager to
insert the object, which makes it accessible through its (optional) name or a
cookie called a
handle. From then on, the lifetime of the object is handled by the object manager, and it's up to the subsystem to keep the object in a working condition until being signaled by the object manager to dispose of it. :Handles are identifiers that represent a reference to a kernel resource through an opaque value. Similarly, opening an object through its name is subject to security checks, but acting through an existing, open handle is only limited to the level of access requested when the object was opened or created. :Object types define the object procedures and any data specific to the object. In this way, the object manager allows Windows NT to be an
object-oriented operating system, as object types can be thought of as polymorphic
classes that define
objects. Most subsystems, though, with a notable exception in the I/O Manager, rely on the default implementation for all object type procedures. :Each instance of an object that is created stores its name, parameters that are passed to the object creation function, security attributes and a pointer to its object type. The object also contains an object close procedure and a reference count to tell the object manager how many other objects in the system reference that object and thereby determines whether the object can be destroyed when a close request is sent to it. Every named object exists in a hierarchical object
namespace. ;Cache Controller :Closely coordinates with the Memory Manager, I/O Manager and I/O drivers to provide a common cache for regular file I/O. The Windows Cache Manager 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. ;Configuration Manager :Implements the system calls needed by
Windows Registry. ;I/O Manager :Allows devices to communicate with user-mode subsystems. It translates user-mode read and write commands into read or write
IRPs which it passes to device drivers. It accepts
file system I/O requests and translates them into device specific calls, and can incorporate low-level device drivers that directly manipulate hardware to either read input or write output. It also includes a cache manager to improve disk performance by caching read requests and write to the disk in the background. ;Local Procedure Call (LPC) :Provides inter-process communication ports with connection semantics. LPC ports are used by user-mode subsystems to communicate with their clients, by Executive subsystems to communicate with user-mode subsystems, and as the basis for the local transport for
Microsoft RPC. ;Memory Manager :Manages
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 PE executables that lets an executable be mapped or unmapped in a single, atomic step. :Starting from Windows NT Server 4.0, Terminal Server Edition, the memory manager implements a so-called
session space, a range of kernel-mode memory that is subject to context switching just like user-mode memory. This lets multiple instances of the kernel-mode Win32 subsystem and GDI drivers run side-by-side, despite shortcomings in their initial design. Each session space is shared by several processes, collectively referred to as a "session". :To ensure a degree of isolation between sessions without introducing a new object type, the association between processes and sessions is handled by the Security Reference Monitor, as an attribute of a security subject (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 weren't part of the initial design, and had to be developed, with minimal disruption to the main line, by a third party (
Citrix Systems) as a prerequisite for their
terminal server product for Windows NT, called
WinFrame. Starting with Windows Vista, though, sessions finally became a proper aspect of the Windows architecture. No longer a memory manager construct that creeps into user mode indirectly through Win32, they were expanded into a pervasive abstraction affecting most Executive subsystems. As a matter of fact, regular use of Windows Vista always results in a multi-session environment. ;Process Structure :Handles
process and thread creation and termination, and it implements the concept of
Job, a group of processes that can be terminated as a whole, or be placed under shared restrictions (such as the total maximum of allocated memory, or CPU time). Job objects were introduced in
Windows 2000. ;PnP Manager :Handles
plug and play 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
USB or
IEEE 1394 FireWire) 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
Plug and Play Service, which handles the often complex tasks of installing the appropriate drivers, notifying services and applications of the arrival of new devices, and displaying GUI to the user. ;Power Manager :Deals with power events (power-off, stand-by, hibernate, etc.) and notifies affected drivers with special IRPs (
Power IRPs). ;Security Reference Monitor (SRM) :The primary authority for enforcing the security rules of the security integral subsystem. It determines whether an object or resource can be accessed, via the use of
access control lists (ACLs), which are themselves made up of access control entries (ACEs). ACEs contain a
Security Identifier (SID) and a list of operations that the ACE gives a select group of trustees—a user account, group account, or login session—permission (allow, deny, or audit) to that resource. ;GDI :The
Graphics Device Interface is responsible for tasks such as drawing lines and curves, rendering fonts and handling palettes. The
Windows NT 3.x series of releases had placed the GDI component in the user-mode
Client/Server Runtime Subsystem, but this was moved into kernel mode with Windows NT 4.0 to improve graphics performance. The primary operating system personality on Windows is the
Windows API, which is always present. The emulation subsystem which implements the Windows personality is called the
Client/Server Runtime Subsystem (csrss.exe). On versions of NT prior to 4.0, this subsystem process also contained the window manager, graphics device interface and graphics device drivers. For performance reasons, however, in version 4.0 and later, these modules (which are often implemented in user mode even on monolithic systems, especially those designed without internal graphics support) run as a kernel-mode subsystem.
Kernel-mode drivers Windows NT uses kernel-mode
device drivers to enable it to interact with
hardware devices. Each of the drivers has well defined system routines and internal routines that it exports to the rest of the operating system. All devices are seen by user mode code as a file object in the I/O manager, though to the I/O manager itself the devices are seen as device objects, which it defines as either file, device or driver objects. Kernel mode drivers exist in three levels: highest level drivers, intermediate drivers and low level drivers. The highest level drivers, such as file system drivers for
FAT and
NTFS, rely on intermediate drivers. Intermediate drivers consist of function drivers—or main driver for a device—that are optionally sandwiched between lower and higher level filter drivers. The function driver then relies on a bus driver—or a driver that services a
bus controller, adapter, or bridge—which can have an optional bus filter driver that sits between itself and the function driver. Intermediate drivers rely on the lowest level drivers to function. The
Windows Driver Model (WDM) exists in the intermediate layer. The lowest level drivers are either legacy Windows NT device drivers that control a device directly or can be a PnP hardware bus. These lower level drivers directly control hardware and do not rely on any other drivers.
Hardware abstraction layer The Windows NT
hardware abstraction layer (HAL) is a layer between the physical hardware of the computer and the rest of the operating system. It was designed to hide differences in hardware and provide a consistent platform on which the kernel is run. The HAL includes hardware-specific code that controls I/O interfaces,
interrupt controllers and multiple processors. However, despite its purpose and designated place within the architecture, the HAL is not a layer that sits entirely below the kernel, the way the kernel sits below the Executive: All known HAL implementations depend in some measure on the kernel, or even the Executive. In practice, this means that kernel and HAL variants come in matching sets that are specifically constructed to work together. In particular hardware abstraction does
not involve abstracting the instruction set, which generally falls under the wider concept of
portability. Abstracting the instruction set, when necessary (such as for handling the several revisions to the
x86 instruction set, or emulating a missing math coprocessor), is performed by the kernel, or via
hardware virtualization. The HAL is implemented in hal.dll. The HAL implements a number of functions that are implemented in different ways by different hardware platforms, which in this context, refers mostly to the
chipset. Other components in the
operating system can then call these functions in the same way on all platforms, without regard for the actual implementation. For example, responding to an interrupt is quite different on a machine with an
Advanced Programmable Interrupt Controller (APIC) than on one without. The HAL provides a single function for this purpose that works with all kinds of interrupts by various chipsets, so that other components need not be concerned with the differences. The HAL is loaded into kernel address space and runs in kernel mode, so routines in the HAL cannot be called directly by applications, and no user mode APIs correspond directly to HAL routines. Instead, the HAL provides services primarily to the Windows executive and kernel and to kernel mode device drivers. Although drivers for most hardware are contained in other files, commonly of file type
.sys, a few core drivers are compiled into hal.dll. Kernel mode device drivers for devices on buses such as
PCI and
PCI Express directly call routines in the HAL to access
I/O ports and registers of their devices. The drivers use HAL routines because different platforms may require different implementations of these operations. The HAL implements the operations appropriately for each platform, so the same driver executable file can be used on all platforms using the same
CPU architecture, and the driver source file can be portable across all architectures. On
x86 systems prior to
Windows 8, there are several different HAL files on the installation media. The Windows installation procedure determines which ones are appropriate for the current platform and copies it to the hard drive, renaming it to hal.dll if necessary. Among the criteria for this selection are: the presence of an
ACPI-compatible BIOS, the presence of an
APIC, and whether or not multiple processors are present and enabled. (The multiple cores of a
multi-core CPU, and even the "logical processors" implemented by a
hyperthreading CPU, all count as "processors" for this purpose.) On
x86-64 and
Itanium platforms there is just one possible hal.dll for each CPU architecture. On Windows 8 and later, the x86 version also only has one HAL. The HAL is merged (or statically linked) into ntoskrnl.exe starting with version 2004 of Windows 10, and the DLL only serves as a stub for backwards compatibility. == Boot sequence ==