: I don't remember Windows NT4 as supporting USB.
: You had to upgrade to Windows 2000 or XP to get support for USB.
: :> I am looking for some kind of example device driver:> source code for USB devices on WinNT++. I'm not really

OK, my mistake. One usually talks about WinNT, Win2K and WinXP
as three of the same. Hence the '++' trailing WinNT. But you
are right, I probably should have specified Win2K, unless some
WinNT4 service pack adds USB host controller support and hot-swap.

But the question still remains - example code anyone?

--
******************************************************
Never ever underestimate the power of human stupidity.

: :> I am looking for some kind of example device driver :> source code for USB devices on WinNT++. I'm not really:> sure as to what I am looking for, hence the muddy question.:> :> What I am certain of is that the example need to be dead :> simple - no multithreading, reentrant and who knows what. :> That rules out MS Developer Network. Block on all and :> everything, I do not care as long as it allows me to :> talk to the USB device one way or the other.
:
: why not use an USB chip that comes with complete win-whatsoever
: drivers, like FTDI ?

"This is not the insight I'm looking for, move along..."

FTDI does not release source code. Is there really no
publicly available USB miniport driver in source form?

--
******************************************************
Never ever underestimate the power of human stupidity.

:> I am looking for some kind of example device driver :> source code for USB devices on WinNT++. I'm not really:> sure as to what I am looking for, hence the muddy question.:> :> What I am certain of is that the example need to be dead :> simple - no multithreading, reentrant and who knows what. :> That rules out MS Developer Network. Block on all and :> everything, I do not care as long as it allows me to :> talk to the USB device one way or the other. :>
:
: Having said that, I have written several USB device drivers,
: the latest one of which is a FAT16 storage system that uses
: SCSI/Transparent Transport/Bulk-Only/USB.

Ooooh - Filesystems. Don't wanna go there... No Sir.

: Linux, however, does have source code for this, but
: it takes a *little* effort to determine how things work.

In the Linux case, we have the Rubini/Corbet book.
That makes life a lot easier, though I will not attemt
to pass the illusion that I have read the complete book.
The book is excellent on 'local' bus attached devices,
but becomes sketchy when it comes to SCSI/USB.

Then bulk pipe is what I want. Sounds like it will work
like a network socket from userland point of view.
Good Thing(TM)

: The Transparent Transport mechanism wraps SCSI commands
: and provides the message delimiting mechanism semantics
: using two USB Bulk pipes, one in each direction.
:
: If I knew a little bit more about your application,
: perhaps I could give you some more help.

I do not have one (yet.) But for the sake of the argument
lets pretend I have a typical simplistic USB-DAQ thingie.

In other words - the same thing one ususally do over
the serial port by means of some proprietary protocol,
just faster. I need access to a handful of setup/control
registers, that typically will result in a bulk data
transfer from USB device to PC host. Or vice versa.
How hard can that be? Very, evidently...

--

******************************************************
Never ever underestimate the power of human stupidity.

The only way this is trivial is if your device
appears to the system as a "serial-port", and
only uses bulk transfers. Otherwise, you'll be
creating your own device/interface class, which
has its advantages, but it means you'll be writing
a class/interface driver for the host computer
as-well-as the application.

I'll assume that you're going to go the more
"difficult" route to expose some of the other
fun stuff.

I would use a control pipe for these. Control
transfers have a request/response type of interface
that is ideal for configuration and polled status
applications.
Isochronous pipes are cool, if you are going
to display the data real-time, like an oscilloscope
for example. The USB reserves bandwidth for
isochronous pipes. However, isochronous transfers
have no reliability guarantees, unlike bulk
transfers, which re-transmit if packets are lost.

If you are not going to be displaying in
real-time, then a single bulk IN pipe can
be used to reliablby transfer the captured data
to the host application.

Another control pipe command.

If you go the route of using a control pipe and
a bulk IN pipe, there is no need to encapsulate
command messages over a "serial stream-like"
combination of a bulk IN and bulk OUT pipe.

If you do use the "serial port" type approach
(one bulk IN and one bulk OUT pipe), then you
will need to do all the usual message
framing and parsing to multiplex the different
commands and data over the link. Again, this
approach is more familiar to many programmers,
but much less elegant IMHO.

cause there are definately people lurking around who do exactly this
on a dayly basis. I'm also sure that the DDK will contain samlpes
which are as simple as it can get. But again, people there should be
able to be of more help than I.