One of the areas that takes some getting used to is the terms specific to the sub systems of Windows, and how that relates to driver development. Originally I thought I would just keep my books around me, but instead decided to post it here. If the original authors get upset with this (I have emailed them to see, but no responses yet) I will remove them. I doubt there will be a problem, but I don't find plagorism to be the most sincere form of flattery, and will abide by their wishes if they feel otherwise.
Note: When we talk about "NT" in these explainations, it refers to all Microsoft Operating Systems that use NT as the core (NT, W2K, XP, Windows Server 2003 etc). Most of the definitions / descriptions come from books, web sites with slight modifications for clarity. If you find a definition is incomplete, please drop me a line
and let me know.
The lowest layer within the operating system is the hardware abstraction layer (HAL). This layers deals directly with the hardware of the machine, and as its name implies, HIDES the complexities to layers above it. The HAL DLL contains the processor/machine specific details that would otherwise be exposed to the system. In this way, the operating system can be more portable across platforms through the use of a different HAL for each platform.
The kernel is the brain child of the system that provides all the essential services such as scheduling, interrupt dispatching, multi-processor synchronization etc. All other components of the NT core are preemptive. This allows for a more robust design and make NT somewhat unique as few operating systems have their core multithreaded. (ie: you can have more than one thread running in a priviledged mode)
The NT Executive
The NT executive constitutes the majority of the Windows NT core. It sits on top of the kernel and provices a complex interface to the "outside world". The NT executive forms the part of the Windows NT core that is fully preemptive. Generally, the core components added by developers form a part of the NT executive or rather the I/O Manager. Hence, driver developers should always keep in mind that their code has to be fully preemptive.
The Object Manager
Windows NT is designed in an object-oriented fashion. Windows, devices, drivers, files, mutexes, processes, and threads have one thing in common: All of them are treated as objects. The main tasks of the Object Manager is to control:
- Memory allocation/deallocation for objects
- Object name space maintenance.
- Handle maintenance. (The handle returned when an object is opened by a process)
- Reference count maintenance.
- Object security.
The I/O Manager
The I/O Manager controls everything related to input and output. It provides a framework that all the I/O-related modules (device drivers, file systems, Cache Manager, and network drivers) must adhere to.
The Security Reference Monitor
The Security Reference Monitor is responsible for validating a processs access permissions against the security descriptor of an object. The Object Manager uses the services of the Security Reference Monitor while validating a processs request to access any object.
The Virtual Memory Manager
The following two tasks are performed by the Virtual Memory Manager component of the operating system when it comes to the hardware memory:
- It provides a virtual machine, which is easy to program, on top of raw hardware, which is cumbersome to program. For example, an operating system provides services to access and manipulate files. Maintaining data in files is much easier than maintaining data on a raw hard disk.
- It allows the applications to share the hardware in a transparent way. For example, an operating system provides applications with a virtual view of the CPU, where the CPU is exclusively allotted to the application. In reality, the CPU is shared by various applications, and the operating system acts as an arbitrator.
The Process Manager
The Process Manager is responsible for creating processes and threads. Windows NT makes a very clear distinction between processes and threads. A process
is composed of the memory space along with various objects (such as files, mutexes, and others) opened by the process and the threads running in the process. A thread
is simply an execution context that is, the CPU state (especially the register contents). A process has one or more threads running in it.
The Local Procedure Call Facility
The local procedure call (LPC) facility is specially designed for the subsystem communication. LPC is based on remote procedure call (RPC), which is the de facto Unix standard for communication between processes running on two different machines.
The System Call Interface
The system call interface is a very thin layer whose only job is to direct the system call requests from the user mode processes to appropriate functions in the Windows NT core.
Understanding Ring 0
The operating system operates at several levels, or modes. The mode with the most privileges is Ring 0, which is also known as Kernel Mode. The name Ring 0 comes from the concept in which modes are visualized as a group of concentric circles around the CPU (picture those models of the solar system we all made in junior high school, especially the planets with rings of moons). The innermost circle is known as Ring 0, and any functions that are permitted to operate in Ring 0 are closer to the CPU and have more direct access to the CPU functions. These are what we call low-level services.
Software applications do not have access to Kernel Mode; instead, they run in User Mode. In User Mode, applications dont have direct access to any functions, and must request services from the operating system. This, of course, is slower than grabbing whatever you need without having to ask the operating system.
Depending on the operating system or how you want to describe the various levels of access to the CPUs features, you can define operating systems as having three Ring levels or two Ring levels. For Windows 95, Windows 98, and Windows NT, we usually discuss only two Ring levels, which are translated as Kernel Mode and User Mode. As another example, however, OS/2 has three clearly defined Rings; some operating system functions are at Ring 0, others are at Ring 1, and applications operate at Ring 3.