Windows 98Me Compatibility Notes

Windows 98/Me Compatibility Notes

There are a few important differences between Windows 98/Me on the one hand and Windows 2000/XP on the other with respect to Plug and Play.

Surprise Removal

Windows 98/Me never sends an IRP_MN_SURPRISE_REMOVAL request. Consequently, a WDM driver needs to treat an unexpected IRP_MN_REMOVE_DEVICE as indicating surprise removal. The code samples I showed you in this chapter accomplish that by calling AbortRequests and StopDevice when they get this IRP out of the blue.

PnP Notifications

Windows 98/Me has calls to the IoReportTargetDeviceChange function fail with STATUS_NOT_IMPLEMENTED. It doesn t export the symbol IoReportTarget DeviceChangeAsynchronous at all; a driver that calls that function will simply fail to load in Windows 98/Me. Refer to Appendix A for information about how you can stub this and other missing support functions so as to be able to ship a single driver binary.

The Remove Lock

The original edition of Windows 98 didn t include any of the remove lock functions. Windows 98, Second Edition, and Windows Me include all but Io ReleaseRemoveLockAndWait, which is the same as not supporting any of the functions, in my view. I mean, the whole point of the remove lock mechanism is to gate IRP_MN_REMOVE_DEVICE, and that hinges on the omitted function.

To make matters worse, a driver that references a function that the Windows 98/Me kernel doesn t export simply won t load.

DDK sample programs cope with this incompatibility in one of two ways. Some samples use a custom-built mechanism instead of an IO_REMOVE_LOCK. Others provide functions with names like XxxAcquireRemoveLock, and so on, that mimic the names of the standard remove lock functions.

My sample drivers use a variation of the second of these approaches. By means of #define statements, I substitute my own declarations of the IO_REMOVE_LOCK object and support functions for the official ones. Thus, my sample code calls IoAcquireRemoveLock, and so on. In the samples that use GENERIC.SYS, preprocessor trickery actually routes these calls to functions with names such as GenericAcquireRemoveLock that reside in GENERIC.SYS. In the samples that don t use GENERIC.SYS, the preprocessor trickery routes the calls to functions with names such as AcquireRemoveLock that are located in a file named REMOVELOCK.CPP.

I could have written my samples in such a way that they would call the standard remove lock functions instead of my own in Windows XP. To make any of the samples work in Windows 98/Me, I d have needed to have you install WDMSTUB.SYS before you could run any of the samples. (See Appendix A.) I didn t think this was a good way to explain WDM programming.