In your example for usbkbd.sys, you overwrite hidusb.sys. However, this is not necessary, as you can change in the registry which driver is loaded for an instance of a device (the NTMPDriver entry for Win98).

While at Intel, I wrote a utility, USBRegEd.exe (available at http://www.usb.org/developers/data/tools/USBRegEd.ZIP). Now this version works only on Win98 (possibly ME, but I haven't tried). In the future, I will write a version for Win2K.

Older USB 1 peripherals will still work in a USB 2 system, as USB 2 hubs can reduce the data rate to USB 1 level. The cabling and connector system is exactly the same. In addition, a microframe of 125 microseconds will be introduced.

This tip is swiped from the AnchorChips EzUsbSys driver which says that it was swiped from Walter Oney. Thanks.

I suggest that you also read the article at http://www.microsoft.com/hwdev/ntdrivers/interact.htm describing the InteractiveInstall INF file directive. And http://www.microsoft.com/hwdev/setup/SetupAPI.htm describes how to generate more SetupAPI logs during W2000 Setup and device installation.

• ChkINF  a perl script that checks INF files
• Disabler  Test tool that repeatedly disables and re-enables a device
• GenINF  INF wizard
• Grapher  A tool which can be used to build, examine and test WDM-CSA audio filter graphs
• MakeNTF  Creates an NTF file from AFM files
• PciTool  Control Panel applet that displays PCI Configuration Information
• StampINF  Insert driver version and date stamp
• Verifier  Driver Verifier mentioned on page 121 of my book
• WuStamp  Insert driver version and date stamp

• www.bluewatersystems.com
• www.cmkrnl.com
• www.oneysoft.com
• www.osr.com

"You can get information about all kinds of devices (real\virtual\logical) currently present in the system using CM APIs. The function code given here basically walks the devnode tree and prints the device description of all the devices. I just modified DriverNameToDeviceDesc functions used in USBVIEW sample of DDK (ddk\src\wdm\usbview\devnode.c) to demonstrate this functionality."

There are three important conclusions from their analysis:

• The DPC latency (time from hardware interrupt to when a medium importance Deferred Procedure Call routine runs) in NT 4 is much better than W98. W98 can be as much as an order of magnitude worse, ie DPCs can take as long as 16ms to be run in W98 in typical load conditions.

• Intel suggest that for some applications, a minimal DPC routine may be useful. Post-interrupt processing is instead deferred further to a real-time priority system thread. Intel say that the advantage of this approach is that system threads are easier to program correctly than DPC routines.

  In this scenario, the DPC routine simply sets an event. The system thread waits for the event to be set. It then does any post-interrupt servicing.

  In NT 4, Intel found that a high (28) real-time priority thread did not increase the DPC latency significantly. However in W98, this "thread latency" was much worse, eg as much as 128ms.

  If a medium (24) real-time priority thread is used instead, the NT 4 latency went up considerably, to as much as 16ms. The W98 response was still worse, but much the same as the high priority case.

  Intel conclude that W98 drivers should not use this thread technique, but should rely on DPC routines instead.

• Intel also found that the optional Microsoft Plus! 98 Pack Virus Scanner made the high real-time priority thread case worse still.
  Similarly they found that different W98 sound schemes have a major negative impact on thread latency.

One of the authors, Erik Cota-Robles, also added this comment to me:

"Also, our results apply not just to drivers that use their own threads but also to drivers which queue CriticalWorkItems from a DPC. An enqueued CriticalWorkItem will experience the thread latency that we measured since critical work items are serviced by a WDM kernel worker thread executing at default real-time priority. In general that thread will be blocked waiting on the queue and it will be awakened via a kernel event or equivalent mechanism."