Layered Driver Architecture

https://msdn.microsoft.com/en-us/library/ms791644.aspx

Layered Driver Architecture

Windows operating systems support a layered driver architecture. Every device is serviced by a chain of drivers, typically called a driver stack. Each driver in the stack isolates some hardware-dependent features from the drivers above it.
The following figure shows the types of drivers that could potentially be in a driver stack for a hypothetical device. In reality, few (if any) driver stacks contain all these types of drivers.
Layered Driver Architecture
As the preceding figure shows:
Above the driver stack is an application. The application handles requests from users and other applications, and calls either the Win32 API or a routine that is exposed by the user-mode client driver.
A user-mode client driver handles requests from applications or from the Win32 API. For requests that require kernel-mode services, the user-mode client driver calls the Win32 API, which calls the appropriate kernel-mode client or support routine to carry out the request. User-mode client drivers are usually implemented as dynamic-link libraries (DLL). Printers support many operations that can be performed in user mode, and so typically have user-mode clients; disks and other storage devices, networks, and input devices do not.
A kernel-mode client driver handles requests similar to those handled by the user-mode client, except that these requests are carried out in kernel mode, rather than in user mode.
A device class and miniclass driver pair provides the bulk of the device-specific support. The class driver supplies system-required but hardware-independent support for a particular class of device. Class drivers are typically supplied by Microsoft.
A miniclass driver handles operations for a specific type of device of a particular class. For example, the battery class driver supports common operations for any battery, while a miniclass driver for a vendor's UPS device handles details unique to that particular device. Miniclass drivers are typically supplied by hardware vendors.
A corresponding port driver (for some devices, this is a host controller or host adapter driver) supports required I/O operations on an underlying port, hub, or other physical device through which the device attaches. Whether any such drivers are present depends on the type of device and the bus to which it eventually connects.
All driver stacks for storage devices have a port driver. For example, the SCSI port driver provides support for I/O over the SCSI bus.
For USB devices, a hub and host controller driver pair perform the duties of the port driver. These drivers handle I/O between the devices on the USB bus and the bus itself.
A corresponding miniport driver handles device-specific operations for the port driver. For most types of devices, the port driver is supplied with the operating system, and the miniport driver is supplied by the device vendor.
At the bottom of the figure is the hardware bus driver. Microsoft supplies bus drivers for all the major buses as part of the operating system. You should not attempt to replace these drivers.
Network drivers have their own unique terminology, defined in Windows 2000 and Later Network Architecture and the OSI Model. Nevertheless, network drivers are similarly layered, and each layer isolates device-specific or protocol-specific functionality from the layer above it.
Exactly which drivers are present, and what they are called, depends on the type of device and the bus to which it connects.
Graphics cards, for example, require a display driver, a video port driver, and a video miniport driver. The display driver is analogous to the kernel-mode client driver in the previous figure. It provides general drawing capabilities and can often work with more than one graphics card. The video port driver supports device-independent graphics operations. It works in tandem with the video miniport driver, which provides functionality that is specific to one graphics card (or a family of graphics cards). The paired video port/miniport drivers are analogous to the port/miniport drivers in the figure, and no class/miniclass drivers are present. For more information, see Display Architecture.
For simplicity, filter drivers are not shown in the previous figure. However, a filter driver can fit in at any layer of the driver stack above the hardware bus driver. A filter driver adds value to an existing driver by "filtering" — intercepting and manipulating device I/O. As a general rule, filter drivers do not operate the hardware directly, but work only on data and I/O requests passed to them from the next-higher or next-lower driver.
DirectShow, the Microsoft software for video capture, includes system-supplied filter drivers that run in user mode. These filters act as clients of the kernel-mode stream class driver to expose the underlying video capture technology.