Device Interfaces (Windows Embedded CE 6.0)

1/6/2010

Device interface classes are the methods available to applications for accessing the capabilities of a device driver. They indicate to whatever receives notifications that a particular interface is present. A device driver can have multiple device interface classes, or it can have no device interface classes.

IClass registry subkeys reference device interfaces and their associated GUIDs. The header (.h) file that declares the interface typically defines the GUID and associates the GUID with the interface. The header file associates the interface with the GUID by defining the GUID. You must expose the interface classes through the IClass registry values or by calling AdvertiseInterface. You can also define your own interface classes.

There are no restrictions on the device interface. The means of accessing it is dependent on the interface.

The following code example shows how a header file typically defines a device interface GUIDs using a sample GUID.

#define DEVCLASS_IFCNAME_STRING TEXT("{12345678-1234-1234-1122334455667788}")
#define DEVCLASS_IFCNAME_GUID { 0x12345678, 0x1234, 0x1234, { 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88 } }

A driver in Device Manager that exposes an interface publicizes this by setting the IClass value set appropriately in the registry key passed into ActivateDeviceEx. With AdvertiseInterface, a device driver announces what device interfaces it exposes in the registry. This announcement is available to any application or driver that calls RequestDeviceNotifications. An application or driver can stop receiving device notifications by calling StopDeviceNotifications. These functions allow you to access the device interface's GUID and name. The GUID describes the device interface and the name disambiguates multiple instances of that device interface. For example, there is a GUID for the generic stream interface, and the names "COM1:" and "DSK1:" refer to two distinct instances of the generic stream interface.

It is possible for two different device interface classes GUIDs to have instances with the same name. The name has meaning only in the context of the access methods of the device interface named by the device interface class GUID.

A device driver should only export a device interface if it implements that device interface entirely. Any interaction with a driver will expect full support of the device interface it advertises.

By calling AdvertiseInterface, device drivers can explicitly send notifications. This is primarily for removable-media storage devices and other drivers that have not determined at load-time exactly which interfaces they will expose.

Device drivers should explicitly indicate that they can accept device handle access requests. If a device driver exposes a device handle-based interface, the driver should be able to accept an hOpenContext value of zero in the device driver's other functions. An hOpenContext value of zero indicates that the access is being requested on a device level and possibly with different OS level security. Device drivers that read AccessCode and ShareMode in their XXX_Open****function should treat device handle access requests appropriately. ** For more information on the XXX_Open function, see XXX_Open (Device Manager). GUIDs are used to indicate support for device-based access and for individual device handle-based interfaces.

For information about finding interfaces exposed by name or file handle by a particular device, see Device File Names.

The following table shows the predefined interfaces and the header file under %_WINCEROOT% in which the interfaces are defined.

See Also

Concepts

Device Driver Development Concepts
Loading Device Drivers
Bus Enumerator
Device Interface Notifications