Microsoft KB Archive/29519

How to Write a Driver for a Custom Hardware Device

Q29519

The information in this article applies to:

Microsoft Windows Device Development Kit (DDK) for Windows, versions 3.0, 3.1

SUMMARY

This article describes how to manage custom communications hardware through an I/O interrupt.

To implement a device that is intended to replace one of the standard devices in Windows, obtain the Windows DDK from Microsoft and write the device driver to the appropriate specification. The DDK contains definitions of keyboard, mouse, display, communications, printer, and network drivers. The rest of this article discusses how to implement a driver for a device, such that the implemented driver does not replace a standard driver.

Windows version 3.1 includes an installable driver interface, which allows these types of drivers to be loaded during Windows initialization, coalesce messages they generate, and get notification of when standard or real mode Windows swaps them out of memory. For more information on installable drivers, please refer to Chapter 25 of the "Programmer's Reference, Volume 1: Overview" of the Windows SDK version 3.1. There is also a technical article on installable drivers in the Microsoft Developer Network (MSDN) CD-ROM.

MORE INFORMATION

Define a driver interface for the device and implement it in a dynamic linked library (DLL). To handle interrupts, place the interrupt handler in a FIXED DLL code segment. Any data accessed by the driver's interrupt handler must also be in a FIXED data segment. The interrupt handler may not make any Windows API calls except for calling the PostMessage function, which is defined to be reentrant and callable from an interrupt handler for just this purpose.

Note that, to interact properly with the kernel memory manager, the default data segment of the DLL should be movable if the DLL will make calls to any Windows APIs. Therefore, the interrupt data is usually in a separate segment.

Because the segment is FIXED, it will be page locked in enhanced mode. Also, it will not move in real mode. Therefore, the selector to the interrupt data segment may be legally referenced when it is stored in code, even in real mode.

For example, a simple interrupt handler could resemble the following:

    WM_DEVICENOTIFY EQU WM_USER + some number

    inthandler proc far

        push    ds
        push    ax
        mov     ax, _INTDATA
        mov     ds, ax
        assume ds:_INTDATA

        ... Process the interrupt at the device, and do the
        ... appropriate things to the interrupt controller.
        ... For this example, assume that an event type is in CX,
        ... which will be the wParam parameter of the posted message.
        ... Data could also be stored to a buffer or reading data
        ... from one. This buffer, or its selector, is stored in
        ... _INTDATA as well. This function cannot call GlobalLock,
        ... therefore the buffer must be fixed (and page locked in
        ... enhanced mode) and its actual segment or selector stored
        ... in _INTDATA.

        push    [hwndNotify]    ;; Stored in _INTDATA segment
        mov     ax, WM_DEVICENOTIFY
        push    cx
        sub     ax, ax
        push    ax              ;; NULL for lParam unless the driver has
        push    ax              ;; something more interesting...
        call    PostMessage

        ... pop other registers

        pop     ax
        pop     ds
        assume ds:nothing
        iret

    inthandler endp

The device driver should export an API to set the window that will receive the notification messages (typically a "DeviceOpen()" function). The window procedure for the window receiving notification will process the driver-defined message WM_DEVICENOTIFY.

In enhanced mode, a VxD (virtual device driver) should be written if any of the following conditions exist:

The device processes a lot of data or generates a lot of interrupts.
The timing of interrupt processing requires low interrupt latency.
Many I/O instructions are required to manage the device.

A VxD is a 32-bit flat-model device driver that runs at ring 0, allowing much faster response time to interrupts and lower overhead I/O. Windows DLLs run at a lower protection ring, which requires interrupts to be reflected from the 32-bit WIN386.EXE to the Windows driver, and slows down I/O instructions. A VxD can interact with a Windows driver or application by providing protected mode call-ins, which allows Windows code to call the VxD. For more information on writing a VxD, see the Windows DDK.

Additional query words: 3.00 3.10

Keywords : _IK kb16bitonly kbDDK
Issue type :
Technology : kbAudDeveloper kbWin3xSearch kbWinDDKSearch kbWinDDK300 kbWinDDK310