Editing Windows Driver Model (section)

==Overview==
WDM drivers are layered in a stack and communicate with each other via [[I/O request packets]] (IRPs). The Microsoft Windows Driver Model unified driver models for the Windows 9x and Windows NT product lines by standardizing requirements and reducing the amount of code that needed to be written. WDM drivers will not run on operating systems earlier than Windows 98 or Windows 2000, such as Windows 95 (before the OSR2 update that sideloads the WDM model), Windows NT 4.0 and Windows 3.1. By conforming to WDM, drivers can be [[binary-code compatibility|binary compatible]] and [[source-code compatibility|source-compatible]] across Windows 98, Windows 98 Second Edition, [[Windows Me]], Windows 2000, [[Windows XP]] and [[Windows Server 2003]] on [[x86]]-based computers. WDM drivers are designed to be [[forward compatibility|forward-compatible]] so that a WDM driver can run on a version of Windows newer than what the driver was initially written for<!--for those who care, this makes Windows backward compatible, but the driver itself is being forward compatible-->, but doing that would mean that the driver cannot take advantage of any new features introduced with the new version. WDM is generally not [[backward compatibility|backward-compatible]], that is, a WDM driver is not guaranteed to run on any older version of Windows.  For example, [[Windows XP]] can use a driver written for [[Windows 2000]] but will not make use of any of the new WDM features that were introduced in Windows XP. However, a driver written for Windows XP may or may not load on Windows 2000.

WDM exists in the intermediary layer of Windows 2000 [[kernel-mode]] drivers and was introduced to increase the functionality and ease of writing drivers for Windows. Although WDM was mainly designed to be binary and source compatible between [[Windows 98]] and Windows 2000, this may not always be desired and so specific drivers can be developed for either operating system.

===Device kernel-mode drivers===
With the Windows Drivers Model (WDM) for devices Microsoft implements an approach to [[kernel mode]] drivers that is unique to [[Microsoft Windows|Windows operating systems]]. WDM implements a layered architecture for [[device drivers]], and every device of a computer is served by a stack of drivers. However, every driver in that stack can chain isolate hardware-independent features from the driver above and beneath it. So drivers in the stack do not need to interact directly with one another. WDM defines architecture and device procedures for a range of devices, such as display and the [[network card]], known as [[Network Driver Interface Specification]] (NDIS). In the NDIS architecture the layered network drivers include lower-level drivers that manage the hardware and upper-level drivers that implement network data transport, such as the [[Transmission Control Protocol]] (TCP).<ref name="Vieira">{{Cite book|title=Dependable Computing: 14th European Workshop, EWDC 2013, Coimbra, Portugal, May 15-16, 2013, Proceedings|editor1= Marco Vieira |editor2=Joao Carlos Cunha |publisher=Springer |year=2013|isbn=9783642387890|pages=64}}</ref>

While WDM defines three types of device drivers, not all driver stacks for a given device contain all types of device drivers. The three WDM device driver types are:<ref name="Vieira" />

'''Bus driver''': For every [[Bus (computing)|bus]] on the mainboard there is a one bus driver, with the primary responsibility for the identification of all devices connected to that bus and responding to plug and play events. Microsoft will provide bus drivers as part of the operating system,<ref name="Vieira" /> such as [[Peripheral Component Interconnect|PCI]], [[Plug-And-Play|PnPISA]], [[SCSI]], [[USB]] and [[FireWire]].

'''Function driver''': this is the principal driver for a device and it provides the operational interface for a device by handling read and write operations. Function drivers are written by the device vendors, and for their interaction with the hardware they depend on a specific bus driver being present in the Windows operating system.<ref name="Vieira" />

'''Filter driver''': This driver is optional, and can modify the behaviour of a device, such as input and output requests. These drivers can be implemented as lower-level and upper-level filter drivers.<ref name="Vieira" />

===Object-oriented driver stack===
Function drivers and bus drivers are often implemented as driver/minidriver pairs, which in practice is either a class or miniclass, or a port or miniport pair.<ref name="Blunden">{{Cite book|title=The Rootkit Arsenal: Escape and Evasion| author= Bill Blunden |publisher=Jones & Bartlett Publishers |year=2009|isbn=9781449661229|pages=460}}</ref>

Bus drivers for devices attached to a bus are implemented as class drivers and are hardware-agnostic. They will support the operations of a certain type of device. Windows operating systems include a number of class drivers, such as the kbdclass.sys driver for keyboards. Miniclass drivers on the other hand are supplied by the vendor of a device, and only support device specific operations, for a particular device of a given class.<ref name="Blunden" />

Port drivers support general [[input/output]] (I/O) operations for a peripheral hardware interface. The core functionality of port drivers is mandated by the operating system, and Windows operating systems integrate a variety of port drivers.  For example, the i8042prt.sys port driver for the 8042 microcontroller connects [[PS/2]] keyboards to the mainboard peripheral bus. The miniport drivers, like the miniclass drivers, are supplied by the hardware vendors and support only device specific operations of peripheral hardware that is connected to a port on the mainboard.<ref>{{Cite book|title=The Rootkit Arsenal: Escape and Evasion| author= Bill Blunden |publisher=Jones & Bartlett Publishers |year=2009|isbn=9781449661229|pages=460}}</ref><ref>{{cite web |url=http://www.microsoft.com/whdc/driver/wdf/wdf-intro.mspx |title=Introduction to the Windows Driver Foundation |date=2006-10-13 |access-date=2010-12-06 |publisher=[[Microsoft Developer Network]] |quote=The device class-specific driver models are typically structured as a port driver written by Microsoft paired with a miniport driver written by an independent hardware vendor. The port driver does much of the work required for the device class, and the miniport driver supports device-specific characteristics.}}</ref>

Each driver that processes an I/O request for a device has a corresponding object, which is loaded into [[main memory]]. A device object is created by the Windows operating system from the associated device class. Device objects contain structures of type DEVICE_OBJECT, which store pointers to their driver. At run time these pointers are used to locate a driver's dispatch routine and member functions. In the WDM driver stack, the filter driver device object, known as the upper filter, will receive an [[I/O request packet]] (IRP) for a device from the I/O manager. If the upper filter driver can not serve the request, it will locate the object of the driver one step down in the driver stack. The IRP is passed down the driver stack by calling the function IoCallDriver(), and processed by the function driver device object, also known as functional device object. The function driver device object in turn may pass the IRP to the lower filter, another filter device object. Then the IRP may be passed down to the bus driver, which operates as the physical device object. The bus driver object is at the bottom of the driver stack, and interacts with the [[hardware abstraction layer]], which is part of the [[Architecture of Windows NT|Windows operating system kernel]] and allows Windows operating systems to run on a variety of [[Processor (computing)|processors]], different [[memory management unit]] architectures, and a variety of computer systems with different I/O bus architectures.<ref>{{Cite book|title=The Rootkit Arsenal: Escape and Evasion| author= Bill Blunden |publisher=Jones & Bartlett Publishers |year=2009|isbn=9781449661229|pages=460–461}}</ref> The execution of an IRP is finished when any of the driver objects in the stack returns the request back to the I/O manager, with the result and a status flag.<ref name="Penkler">{{Cite book|title=Service Availability: Third International Service Availability Symposium, ISAS 2006, Helsinki, Finland, May 15-16, 2006, Revised Selected Papers|editor1= Dave Penkler |editor2=Manfred Reitenspiess |editor3=Francis Tam |publisher=Springer Science & Business Media |year=2006|isbn=9783540687245|pages=124}}</ref>