Michal Vodicka wrote:
Alternatively, write an INF which uses UsbScan built-in driver. It is
also junk and has ridiculous interface but it isn’t less stable than the
rest of w9x. We did it when supported w9x. And still use it for w2k
which support hopefully ends soon.
Does UsbScan support generic USB bulk requests?
Our device is not a scanner. 
Michal Vodicka wrote:
> Could you state what is so miserable about [BulkUSM sample]
Shortly, almost everything
I don’t remember all problems as I had to rewrite at least half of code
within past years and my memory leaks quickly. So only imcomplete list:
Thanks! That’s a good list of pointers (what to look for) and arguments
(why it needs replacement).
> IMHO if it is so miserable, MS should replace it […]
They already did. There is KMDF sample available and I doubt they’ll
rewrite WDM samples.
Understood. Unfortunately, as KMDF is closed-source, AFAIK there is no
public source code available that shows how to properly handle the
issues that were pointed out for BulkUSB. (Pointers welcome!)
We use UsbScan for legacy OSes (w9x and w2k) and WDM driver for
everything else.
Currently, I have one WDM driver for everything. Saves a lot of
headache. The problems of the last USB support incidents were
predominantly problems with 82801 chips. (Oh, and one customer whose USB
port actually stopped supporting USB2.0 at all.) No driver issues.
WDM driver could be replaced with both UMDF and KMDF versions.
For XP/Vista I also could replace our driver with a UMDF version.
But it (a) would be slower and (b) I would have to go back to different
install packages for different platforms again. Not inviting.
WinUsb itself is as fast as WDM driver so
UMDF driver using it can be as fast as your app using WDM driver.
Thanks, that’s interesting news! I’ll definitely look into direct
App<->WinUSB communication then, without any additional driver.
If you move your user mode app/library inside UMDF driver
and export different interface, performance can be comparable.
Unfortunately not for our protocol/requirements.
(Of course it is theoretically possible, but I would end up with 90% of
the application inside the UMDF driver. Better not.)
The second possibility is to use KMDF driver instead of WDM.
As stated - if I could, I’d rather do completely without any driver.
(Like we do in the Linux version of our software.)
So I’ll monitor WinUSB as a (probably good) option for the future.
Best regards, and many thanks for the pointers,
Hagen
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Hagen Patzke
Sent: Tuesday, February 19, 2008 10:46 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] usb driver DTM plug and play test failedDoes UsbScan support generic USB bulk requests?
Yes. As I wrote, we use it as an alternative to BulkUsb based WDM driver
at w9x and w2k. Originally we even started with it and the only reason
why to write own driver was a need for selective suspend at XP and
above. So I emulate UsbScan IOCTL interface (dumb and simple) in my
driver which makes user mode code a bit simpler.
Our device is not a scanner.
It doesn’t matter. Our devices might be seen as a kind of scanners but
we don’t see them this way
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Hagen Patzke
Sent: Tuesday, February 19, 2008 11:23 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] usb driver DTM plug and play test failedUnderstood. Unfortunately, as KMDF is closed-source, AFAIK
there is no
public source code available that shows how to properly handle the
issues that were pointed out for BulkUSB. (Pointers welcome!)
IMO it wouldn’t help. The main BulkUsb problem as I see it is wrong
design. You can fix individual problems as they come but you’re still
within limitations of original design. Four years before I noticed yet
another race conditions there. It can’t be fixed without major change
which could influence almost all the code. So I only wrote a note there
and decided to leave it there as probability is very low. Few weeks
before I received a crashdump and guess what. It was this one invoked by
DTM IO stress test at a new machine. Before the same code passed the
same test hundreds times.
Suggestion: run S3/S4 stress for several days at dual core (at least)
machines. This is the way how our OEMs usually find yet another original
BulkUsb code bug
> We use UsbScan for legacy OSes (w9x and w2k) and WDM driver for
> everything else.Currently, I have one WDM driver for everything. Saves a lot of
headache. The problems of the last USB support incidents were
predominantly problems with 82801 chips. (Oh, and one
customer whose USB
port actually stopped supporting USB2.0 at all.) No driver issues.
May I ask you how many drivers do you have deployed? The real headache
starts when you have millions in the field and have to support many OEMs
who run stress tests at their new machines and the driver which worked
with no problem before starts failing and everybody wants the solution
ASAP.
BTW, my current ratio of reported driver problems is about 10:1 for MS
Vista, of course. SP1 is real improvement but still USB is less
stable than XP SP2.
Unfortunately not for our protocol/requirements.
(Of course it is theoretically possible, but I would end up
with 90% of
the application inside the UMDF driver. Better not.)
Why not? We’re going this way because we have to but I don’t see a
technical problem with it.
So I’ll monitor WinUSB as a (probably good) option for the future.
At least all the bugs you encounter would be assigned to MS at WinQual
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
The pnp issue is fixed. thank you very much.