Share via


Driver Initialization and Cleanup

While the device driver may implement several or many functions, it exports only DrvEnableDriver to GDI. The driver exposes its other supported functions through a function table. The first call GDI makes to a device driver is to the DrvEnableDriver function. Within this function, the driver fills in the passed-in DRVENABLEDATA structure so that GDI can determine which other DrvXxx functions are supported and where they are located. The driver supplies the following information in DRVENABLEDATA:

  • The iDriverVersion member contains the graphics DDI version number for a particular Windows operating system version. The winddi.h header defines the following constants:

    Constant Operating System Version
    DDI_DRIVER_VERSION_NT4 Windows NT 4.0
    DDI_DRIVER_VERSION_NT5 Windows 2000
    DDI_DRIVER_VERSION_NT5_01 Windows XP

    For more information about how these constants are used, see DRVENABLEDATA.

  • The c member contains the number of DRVFN structures in the array.

  • The pdrvfn member points to an array of DRVFN structures that lists the supported functions and their indexes.

For GDI to call a function other than the driver's enable and disable functions, the driver must make the function's name and location available to GDI.

While DrvEnableDriver can also perform one-time initializations, such as the allocation of semaphores, a driver should not actually enable the hardware during DrvEnableDriver. Hardware initialization should occur in a driver's DrvEnablePDEV function. Likewise, a driver should enable the surface in the DrvEnableSurface function.

GDI calls the DrvDisableDriver function to notify the driver that it is about to be unloaded. In response to this call, the driver should free all resources and memory still allocated by the driver at this point.

If the hardware needs to be reset, GDI calls the driver's DrvAssertMode function.