Programming the Microsoft Windows Driver Model

Windows 98/Me Compatibility Notes

File I/O

The ZwXxx routines for accessing disk files don t work well in Windows 98/Me because of two basic problems one from the architecture of Windows and the other from what looks like an ordinary bug in the original release of Windows 98.

The first problem with file access has to do with the order in which Windows 98/Me initializes various virtual device drivers. The Configuration Manager (CONFIGMG.VXD) initializes before the Installable File System Manager (IFSMGR.VXD). WDM drivers for devices that exist at start-up time receive their IRP_MN_START_DEVICE requests during CONFIGMG s initialization phase. But since IFSMGR hasn t initialized at that point, it s not possible to perform file I/O operations by using ZwCreateFile and the other functions discussed earlier in this chapter. Furthermore, there s no way for a WDM driver to defer handling IRP_MN_START_DEVICE until file system functionality becomes available. If you don t have a debugger such as Soft-Ice/W running, the symptom you will see is a blue screen complaining of a Windows Protection error while initializing CONFIGMG.

A second and more crippling problem existed in the July 1998 retail release of Windows 98. The problem had to do with the validity checking that ZwReadFile, ZwWriteFile, and ZwQueryInformationFile perform on their arguments. If you supply an IO_STATUS_BLOCK in kernel-mode memory (and there s basically no way to do anything else), these functions probe a virtual address that doesn t exist. In this original release, the resulting page fault was caught by a structured exception handler and resulted in you getting back STATUS_ACCESS_VIOLATION even when you did everything right. I don t know of any workaround for this except by using the technique in the FILEIO sample. The problem was fixed in Windows 98, Second Edition, by the way.

The FILEIO sample in the companion content illustrates a way past these Windows 98/Me difficulties. FILEIO makes a run-time decision whether to call the ZwXxx functions or instead to call VxD services to perform file operations.

Floating Point

Floating-point operations are permissible in Windows 98/Me WDM drivers, but with some important restrictions relative to the situation in Windows XP:

• You can do floating-point (including MMX) operations in a WDM driver only in a system thread. System threads include those you create yourself by calling PsCreateSystemThread and system worker threads. Note that work item callbacks occur in a system worker thread, so you can do floating point in such a callback.

• You should do floating-point operations only at PASSIVE_LEVEL. (DISPATCH_LEVEL corresponds to VxD hardware interrupt handling in Windows 98/Me.)

The DDK cautions that you should not attempt to circumvent these rules. For example, you might be tempted to use KeSaveFloatingPointState and KeRestoreFloatingPointState in an IOCTL handler despite the explicit prohibition on doing so, or to manually save and restore the FPU state. What can happen to you is this: if an exception is pending in the coprocessor when you initially save the floating-point state, that exception will be taken when you restore the state. The kernel cannot correctly handle that exception. There is no workaround for this problem, which is inherent in the Intel processor design and the way VMCPD.VXD works.

Note that the FPUTEST sample program obeys these rules by refusing to work in Windows 98/Me.