Adding support for a USB device

[Rolf Kalbermatter]

Dan Timis [mailto:timis at museresearch.com] wrote:
> I did some further investigation and it looks like CreateFile 
> (actually 
> CreateFileW) looks at the filename and if it starts with "\\.\" it 
> calls DEVICE_Open().  DEVICE_Open() compares the file name 
> (without the 
> "\\.\" ) against all the entries in VxDList[] and if there is a match 
> it returns a handle based on the appropriate entry in VxDList[].
>
> Let's say I add and entry in VxDList[] like this:
> 
>      { "MYDEVICE",   0x1234, NULL, DeviceIo_MyDevice },
> 
> If I call CreateFile("\\\\.\\MyDevice0", ...),  I will get back a 
> handle based on the entry above.  If I call 
> CreateFile("\\\\.\\MyDevice1", ...), I will get back another handle 
> based on the entry above.  But, when DeviceIo_MyDevice is 
> called I will 
> not be able to tell if this is the first or the second device.
> 
> of course I could add:
> 
>      { "MYDEVICE0",   0x1234, NULL, DeviceIo_MyDevice0 },
>      { "MYDEVICE1",   0x1234, NULL, DeviceIo_MyDevice1 },
> .
> .
> .
>      { "MYDEVICE256",   0x1234, NULL, DeviceIo_MyDevice256 },

VxDs are really Win95 (and Win3.1 to some extend). They do have a lot
of limitations and instantiation of device drivers might be actually
one, at least in the way those VxD io controls are implemented in Wine
at the moment.

I wouldn't advice to do above mentioned hack as it most certainly
never would be accepted into the Wine sources.
 
> There has to be a better way of doing this.  How does this work for, 
> let's say, a USB game controller?

Well in real Windows the NtCreateFile function allocates a DriverObject
which the DriverEntry function of the device driver can initialize to
identify the instance of the driver it refers to. This is then basically
the handle returned by the CreateFile function, eventually with a lookup
into an internal driver object list or maybe not.
The IO Control dispatch function of the driver gets this DriverObject
handle as one of its parameters and can therefore refer to the instance
data of the driver.

It may be worth looking into the possibility to actually support some
basic WDM architecture. This would then have to be done in NtCreateFile
which at the moment is a simple stub. This would however require some
infrastructure which at the moment is not really present and I'm not
sure if it would be necessary to actually add some extra functionality
to Wine server itself for this to work as desired, as such device drivers
would most probably need to be managed outside of the context of the
actual application process.
But transfering all such device driver calls to Wine server would
probably be quite slow in performance.

I'm also not sure as to how much such an extension would be wishful
in the context of Wine itself or if it would unnecessarily complicate
the existing Wine architecture. Maybe someone with more insigth into
NTDLL and its supposed architecture could explain more here?

Rolf Kalbermatter