Core Windows Architecture

To understand how drivers work, the best place to start is to examine how drivers fit into the core Windows operating system. The Windows system architecture consists of a number of layers, with applications at the top and hardware at the bottom. The follow picture is a simplified architectural diagram of Windows, showing how drivers integrate into the overall architecture.

Windows core operating system architecture
Applications and the Windows API
Applications typically initiate I/O requests. However, applications and services run in user mode and have no direct access to kernel-mode components. Instead, they issue I/O requests by calling the appropriate Windows API function, which in turn uses Windows components such as Ntdll.dll to pass the request to the appropriate kernel-mode component.

User Mode and Kernel Mode
Windows is divided into two distinctly different operating modes: user mode and kernel mode. Applications run in user mode, whereas the core operating system (the kernel)-which includes all kernel-mode drivers-runs in kernel mode. The two modes have distinctly different capabilities and associated risks:

User-mode programs are not trusted by the Windows core operating system. They run in a restricted environment that prevents them from compromising other applications or the core operating system.

Kernel-mode programs-including drivers-are trusted components of the Windows core operating system. They operate with relatively few restrictions and some corresponding risks.

The user mode/kernel mode boundary works somewhat like a one-way mirror. Applications can only communicate with the kernel indirectly, through the Windows API. When an application issues an I/O request, it cannot "see" into the kernel to pass the request directly to a kernel-mode driver. Kernel-mode drivers can "see" into user mode and pass data directly to an application. However, this approach involves security risks and is used only for limited purposes. Typically, when a kernel-mode driver returns data to an application, it does so indirectly, through one of the kernel subsystems.

Kernel Subsystems
Kernel subsystems handle much of the core Windows functionality. They expose the DDI routines that allow drivers to interact with the system. Drivers interact most frequently with the following subsystems:

I/O manager Facilitates communication between applications and devices. The I/O manager receives I/O requests from user mode and passes them to the appropriate driver. It also receives completed I/O requests from the driver and passes any data back to user mode and, ultimately, to the application that issued the request.

PnP manager Handles Plug and Play tasks such as enumerating the devices attached to a bus, constructing device stacks for every device, and handling the process of adding or removing devices while the system is running.

Power manager Handles changes in the computer's power state such as transitioning between the fully-powered working state and hibernation.

Other kernel subsystems that expose DDI routines include the memory manager and the process and thread manager. Although the kernel subsystems are separate components, complex dependencies exist between them. For example, the PnP manager's behavior depends on the power state and vice versa.

Drivers and Devices
Drivers provide an interface between their devices and the kernel subsystems. The kernel subsystems send I/O requests to the drivers, which process the request and communicate with the devices as required. Any data that the driver obtains from a device is typically passed back to the kernel subsystem that generated the request. Drivers also respond to requests from kernel subsystems such as the PnP manager or power manager to handle tasks such as preparing a device for removal or for hibernation.

more...........http://www.computercore2.com/