WDM vs WDF

Introduction

Architecturally, Windows Driver Frameworks (WDF) drivers are similar to Windows Driver Model (WDM) drivers. A WDM driver consists of a DriverEntry function, various dispatch routines that the operating system calls to service I/O requests, and additional driver-specific utility functions. A WDF driver consists of a DriverEntry function, various event callback functions that the framework calls to service I/O requests, and additional driver-specific utility functions. However, within this broad structure, the two models have important differences.

Kernel-Mode Driver Framework (KMDF) driver and User-Mode Driver Framework (UMDF) together they comprise WDF.

Differnece between WDF and WDM

WDM model is closely tied to the operating system. Drivers interact directly with the operating system by calling system service routines and manipulating operating system structures. In comparison, WDF model focuses on the driver’s requirements, and the framework library handles the majority of the interactions with the system.
In a WDM driver, the I/O dispatch routines map to particular major IRP codes. The dispatch routines receive IRPs from the I/O manager, parse them, and respond accordingly. In a WDF driver, the framework registers its own dispatch routines, which receive IRPs from the I/O manager, parse them, and then invoke the driver’s event callback functions to handle them. The event callback functions typically perform a more specific task than the general I/O dispatch routines of the WDM driver.
In WDM drivers, these driver roles are implicit, so the driver must keep track of which role each device object represents and respond to IRPs appropriately. WDF drivers, however, indicate explicitly whether a device object represents a PDO (KMDF only), FDO, or filter DO and register event callbacks that are specific to that role.
WDF drivers follow a regular pattern to create all types of objects:
1. Initialize the configuration structure for the object, if one exists.
2. Optionally initialize the attributes structure for the object.
3. Call the creation method to create the object.
The configuration structure holds pointers to object-specific information, such as the driver’s event callback functions for the object. The driver fills in this structure and then passes it to the framework when it calls the object creation method. For example, a call to WdfDriverCreate includes a pointer to a WDF_DRIVER_CONFIG structure that contains a pointer to the driver’s EvtDriverDeviceAdd callback function.
WDF supports a subset of WDM IRPs.
Like WDM drivers, KMDF and UMDF drivers are installed by using INF files. However, WDF driver installation sometimes requires a framework co-installer that is provided with the Windows Driver Kit (WDK).