There are three design principles to consider for a Windows Driver to be DCH-compliant:
- Declarative (D): Install the driver by using only declarative INF directives. Don’t include co-installers or RegisterDll functions.
- Componentized (C): Edition-specific, OEM-specific, and optional customizations to the driver are separate from the base driver package. As a result, the base driver, which provides only core device functionality, can be targeted, flighted, and serviced independently from the customizations.
- Hardware Support App (H): Any user interface (UI) component associated with a Windows Driver must be packaged as a Hardware Support App (HSA) or preinstalled on the OEM device. An HSA is an optional device-specific app that’s paired with a driver. The application can be a Universal Windows Platform (UWP) or Desktop Bridge app. You must distribute and update an HSA through the Microsoft Store. For details, see Hardware Support App (HSA): Steps for driver developers and Hardware Support App (HSA): Steps for app developers.
Driver packages that are DCH-compliant contain an INF file and binaries that install and run on Universal Windows Platform (UWP)-based editions of Windows 10. They also install and run on other editions of Windows 10 that share a common set of interfaces. WIndows 11 is designed for DHC drivers.
DCH-compliant driver binaries can use KMDF, UMDF 2, or the Windows Driver Model (WDM).
DCH-compliant drivers consist of the following parts:
- A base driver
- Optional component packages
- An optional hardware support app
The base driver contains all the core functionality and shared code. The optional component packages can contain customizations and additional settings.
Typically, a device manufacturer, or independent hardware vendor (IHV), writes the base driver. Then, a system builder, or original equipment manufacturer (OEM), provides any optional component packages.
After an IHV has certified the base driver package, it can be deployed on all OEM systems. Because a base driver package can be used across all systems that share a hardware part, Microsoft can test the base driver package broadly via Windows Insider flighting, rather than limiting distribution to specific machines.
The OEM validates only the optional customizations that it provides for the OEM system.