As I've mentioned in my previous posts, Microsoft is trying to simplify the development of windows device driver by changing the corresponding driver framework. Therefore, WDM (Windows Driver Model), which is the old framework will gradually be replaced by WDF (Windows Driver Foundation). WDF can be further subdivided into 2 frameworks: the Kernel-Mode Driver Framework (KMDF), which allows the development of kernel-mode drivers, and the User-Mode Driver Framework (UMDF), which allows the development of user-mode drivers. Actually, WDF and its frameworks build on top of WDM and provide abstractions that are easier to understand and implement. Therefore, even though it'll be possible to continue writing WDM drivers (Microsoft has never up to now prohibited the creation of drivers using any of the legacy Windows NT driver technologies), it'll be much easier and safer to use WDF.

Since windows drivers will be created either by KMDF or UMDF, in this post I'll just try to provide some (theoritical) posts that provide introductory information for WDF. I'll write different posts that provide information on how to develop drivers using KMDF and UMDF. So, the first place to look at should be http://www.microsoft.com/whdc/driver/wdf/default.mspx and especially the following documents:

Based on the second link (the WinHEC presentation), I would like to show an array that shows both the current driver models and the future (at least in Windows Vista) for different device/driver classes: 

Device Class Current Model (Windows XP)
 Windows Vista (and afterwards)
Display Adapters Video Port Longhorn Display Driver Model (LDDM)
Storage Adapters (SCSI & ATA) SCSIport STORport, ATAport SCSIport, STORport, ATAport
Network Adapters Network Driver Interface Specification (NDIS) Network Driver Interface Specification (NDIS)
Video Capture Devices (Webcams)
 AvStream AvStream
Audio Adapters AvStream, PortCIs
 AvStream, PortCIs
File System Filters (e.g. Antivirus)
 FS Mini Filter FS Mini Filter
Printers UniDrv UniDrv
Scanners Windows Image Acquisition (WIA) Windows Image Acquisition (WIA)
PCI, PC Card, generic filter drivers Windows Driver Model (WDM) Kernel-Mode Driver Framework (KMDF)
Biometric Devices Windows Driver Model (WDM) or
NDIS WDM 		Kernel-Mode Driver Framework (KMDF)
Smart Card Devices Windows Driver Model (WDM) Kernel-Mode Driver Framework (KMDF)
Legacy Devices (serial, parallel) Windows Driver Model (WDM) Kernel-Mode Driver Framework (KMDF)
CD-ROMs
 CdRom/ClassPnP Kernel-Mode Driver Framework (KMDF)
Modems, Cable Modems Windows Driver Model (WDM) Kernel-Mode Driver Framework (KMDF)
Keyboard, Mouse Windows Driver Model (WDM) Kernel-Mode Driver Framework (KMDF)
IEEE 1394 (Firewire) devices Windows Driver Model (WDM) Kernel-Mode Driver Framework (KMDF)
Bluetooth devices Windows Driver Model (WDM) Kernel-Mode Driver Framework (KMDF)
SD devices Windows Driver Model (WDM) Kernel-Mode Driver Framework (KMDF)
USB isochronous devices Windows Driver Model (WDM) Kernel-Mode Driver Framework (KMDF)
USB non-isochronous devices Windows Driver Model (WDM) User-Mode Driver Framework (UMDF)
Digital Cameras Windows Image Acquisition (WIA) User-Mode Driver Framework (UMDF)
Portable Media Players Windows Media Device Manager (WMDM) Service
 Windows Portable Device (WPD) - based on UMDF
Cell Phones No support Windows Portable Device (WPD) - based on UMDF
PDAs No support Windows Portable Device (WPD) - based on UMDF
Other (future) devices Windows Driver Model (WDM) User-Mode Driver Framework (UMDF) or
Kernel-Mode Driver Framework (KMDF) or
Windows Driver Model (WDM)


Most of the first 8 models in this array (eg NDIS, SCSIport, etc) follow the port-miniport model. The idea behind this model is that instead of having to write a whole WDM driver, Microsoft provides a driver (i.e. the "port") that covers all the functionality that is common between the devices of the same class. The driver writer just needs to write a small "plug-in" (i.e. the "miniport") that communicates with the port and takes care of the rest of the functionality that depends solely on the actual device. Of course, it's possible for a driver developer to write a WDM network driver, instead of relying on NDIS, but this would just be a lot more work for the same result.