Type | DWORD | 1 |
Start | DWORD | 2 |
DisplayName | REG_SZ | 'PHDIo' |
ErrorControl | DWORD | 1 |
Now reboot your system. The PHDIo driver should now be running. Check the
If you change the driver, the actions you must take to use the new version vary from platform to platform. In Windows 98, you must reboot the system. In NT 3.51 and NT 4, use the Control Panel Devices applet to stop the old driver and start the new one. In Windows 2000, use the book software
The PHDIo driver is started in all Hardware profiles.
The
In a similar way to
You should now be able to run
As with WdmIo, if you use PHDIo to talk to some of your own custom hardware, you should not need to do any clever hardware configuration, as only you will know where your device lives.
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.
Conclusion
This chapter has introduced the WdmIo and PHDIo drivers. It has described the facilities that they make available to Win32 applications. WdmIo has its resources specified in its INF file. The resources are given to PHDIo in the Win32
The next chapters look at the construction of these drivers, how they queue IRPs to serialize hardware access and they perform interrupt driven I/O.
Chapter 16
Hardware I/O IRP Queuing
This chapter starts looking at the WdmIo and PHDIo drivers. Although the text only refers to the WdmIo driver, the techniques used in PHDIo are identical.
Any driver that talks to a real device will need to control access to the hardware. Chapter 9 mentioned that Critical section routines should be used to run routines that cannot be interrupted. Critical section routines are now used for real.
However, the main new requirement for a driver that accesses hardware is that it serializes all the IRPs that it processes. If more than one Win32 process has opened a device and is issuing IRPs, each IRP must not try to talk to the hardware at the same time[36]. If the IRPs can be processed very quickly, critical sections should be used. However, in most cases, the relevant IRPs need to be put into a queue and processed serially, one by one.
Processing IRPs serially will, of course, reduce performance. If jobs can be carried out in parallel, try to do it that way.
You may wish to impose further strictures on users of your device. You could insist that a certain IOCTL be used just before a read request. Although it is best to keep these restrictions to a minimum, do put in any relevant checks. You could use the
Processing IRPs serially is such a common requirement that the Windows Driver Model includes special support for this technique. Each device object contains a device queue of IRPs. The standard StartIo driver callback is used to process the queued IRPs one at a time. The device object and IRP structures have fields that are used by the I/O Manager to manage the queue, and cancel and cleanup queued IRPs safely.
This chapter, therefore, looks at the device IRP queue, StartIo routines, and how to cancel and cleanup IRPs. The next chapter looks at interrupt handling and all its associated topics.
Figure 16.1 illustrates the queuing of two Read IRPs and one IOCTL IRP. The main Read and IOCTL dispatch routines perform some initial checking of the IRPs before they are queued for
