Книга: Writing Windows WDM Device Drivers

Analyzing WdmIo and PHDIo

Analyzing WdmIo and PHDIo

From the user perspective, WdmIo and PHDIo differ in these respects: the platforms on which they run, the installation method, the method by which their resources are specified, and the number of devices that can be controlled.

WdmIo runs in Windows 98 and Windows 2000. PHDIo also runs in NT 3.51 and NT 4.

WdmIo devices can be installed by the user without a special installation program. PHDIo needs an installation program, but this should be a much easier option for users.

WdmIo receives its resources from the installation INF file. Different configurations can be chosen by the user in the Device Manager. The PHDIo resources are specified by the program that uses it. I can imagine situations in which each technique has its advantages.

Finally, more than one WdmIo device can be installed and they can all be used simultaneously by different Win32 applications[35]. Only one PHDIo device can be installed. This device can be used to control different hardware at different times, but not by two Win32 applications simultaneously. PHDIo could be enhanced fairly easily to make a series of devices (e.g., called .PHDIol, .PHDIo2, etc.). If an application found that .PHDIol was busy, it could try .PHDIo2, etc.

In most cases, PHDIo is the better bet, as it covers more platforms and can be installed fairly easily.

As you might have guessed by now, WdmIo and PHDIo do have some deficiencies. However, they do let you do simple I/O.

The most fundamental criticism of WdmIo and PHDIo is that they are too dangerous. A device driver should not let mere Win32 programmers control what happens in the kernel, even in the limited way that WdmIo and PHDIo allow. Use these drivers at your own risk.

The command set deliberately does not include conditional or loop commands. Such functionality can easily be implemented in user mode. The commands that are run to handle an interrupt could possibly benefit from such commands. However, a desire for simplicity rules these commands out for now. If you need to add such facilities for your drivers, do so.

The WdmIo and PHDIo drivers will correctly refuse to read or write to ports that are outside the range of allocated addresses. However, in most cases they will not report a command error if an out-of-range read or write is attempted. Only the PHDIO_IRQ_CONNECT command checks its register parameter.

Another possible improvement is to implement shadow output registers. Quite often, hardware registers are write-only. If you want to set a bit in an output port, reading the register, setting the bit, and writing out the register will not work. A shadow output register is a memory copy of the value that was last written. If the shadow value is read, the set bit operation will work successfully.

Both WdmIo and PHDIo disconnect from their interrupt when a file handle is closed. Make sure that your device does not generate any further interrupts.

The WdmIo driver copes fairly well if a WdmIo device's resources are reassigned. It will not allow resources to be reassigned if there are any open handles. When it receives a Plug and Play stop device message, it waits until all IRPs have completed.

As it stands, each WdmIo device is created as being shareable. It is probably a good idea to alter this characteristic to require exclusive access, as competing IRPs from different processes may result in some confusing results. The PHDIo driver's one .PHDIo device does require exclusive access, as only one open handle can be allowed to specify the resources.

I am sure that you can come up with other ideas for ways in which WdmIo and PHDIo can be enhanced. Go for it.

Оглавление книги