- The Skeleton Driver
- Skeleton Driver Classes, Objects, and Interfaces
- Using the Skeleton Driver as a Basis for Development
- Customize the Exports and Sources Files
- Customize the INX and Comsup.cpp Files
- Add Device-Specific Code to Driver.cpp and Device.cpp
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Add Device-Specific Code to Driver.cpp
In the driver.cpp file, you should add code to the OnDeviceAdd method to initialize your device and to change any device-specific settings. For example, if your driver must read settings from the registry before initializing the device, it should do so in OnDeviceAdd.
The CreateInstance, AddRef, Release, and QueryInterface methods from the Skeleton driver should suffice for most drivers.
Add Device-Specific Code to Device.cpp
The file Device.cpp is where you must do the most work. The Skeleton sample does not support an actual device, so it implements very few of the interfaces and callback objects that are required for the typical device.
In the Initialize method, you should set the locking constraint for your driver. The locking constraint determines whether your driver’s callback methods can be called concurrently or whether only one such method at a time can be active. Note, however, that the locking model applies strictly to the number of callback methods that are concurrently; it does not limit the number of I/O requests that can be active in your driver at one time.
If your driver is a filter driver, you should indicate that in the Initialize method as well, by calling the SetFilter method of the IDeviceInitialize interface.
In the Configure method, you create the I/O queues for the driver. Because the Skeleton driver does not handle actual I/O requests, it does not set up any queues. Most drivers, however, implement one or more queues through which UMDF dispatches I/O requests. To create a queue, the driver calls the IWdfDevice::CreateIoQueue method and specifies how the queue dispatches requests to the driver: in parallel as soon as they arrive, sequentially (one at a time), or only when the driver calls a method on the queue to request one. The driver then calls IWdfIoQueue::ConfigureRequestDispatching to specify the types of requests that should be directed to the queue. The driver must also implement methods in the IQueueCallbackXxx, IRequestCallbackXxx, and IFileCallbackXxx interfaces as appropriate to handle the request that is directed to its queues.
Finally, a driver that supports a Plug and Play device typically must implement the IPnPCallback interface and possibly the IPnPCallbackHardware and IPnPCallbackSelfManagedIo interfaces as well.
You should also either update the header file Internal.h or add your own device-specific header file with any additional definitions pertinent to your device-specific code.