|Last modified: 7 November 2000.|
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.
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.
SurpriseRemovalOKflag to TRUE to stop W2000 complaining after a device is removed. This is particularly useful for peripherals that can easily be unplugged, such as USB devices.
SurpriseRemovalOKflag is in the
Parameters.DeviceCapabilities.CapabilitiesDEVICE_CAPABILITIES structure in the IRP stack. Set the flag after the Query Capabilities request has been processed by lower drivers. You only set this flag if the DEVICE_CAPABILITIES structure
Versionfield is at least 1.
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.
"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."The (slightly amended) Win32 code is available in cm.cpp. The header file cfgmgr32.h and the necessary library file cfgmgr32.lib are in the W2000 DDK directories.
There are three important conclusions from their analysis:
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.
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."