Adding support for a USB device

[Dan Timis]

Thanks Rolf (and Uwe).

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 },

There has to be a better way of doing this.  How does this work for, 
let's say, a USB game controller?

Thanks,

Dan

On Wednesday, December 10, 2003, at 10:22 AM, Rolf Kalbermatter wrote:

> Message: 2
> Date: Tue, 9 Dec 2003 14:56:16 -0800
> Subject: Adding support for a USB device
> From: Dan Timis <timis at museresearch.com>
> To: wine-devel at winehq.org
>
> Hi,
>
>> I need help with supporting a particular USB device under wine.  I 
>> have
>> to start by saying that although I am an experienced C/C++ programmer
>> with some Linux experience, I have almost no Windows or wine 
>> experience.
>>
>> The Windows code for which I need to provide support uses CreateFile()
>> to get a handle to the device.  The name of the device is something
>> like "\\.\MyDevice0" "\\.\MyDevice1" and so on.  Then, the code uses
>> DeviceIoControl() to read and write from/to the device.  The
>> requirement is not to change the windows code.
>>
>> I looked through the wine code and I found this in device.c:
>>
>> static const struct VxDInfo VxDList[]
>>
>> I could add another entry into the table and write a deviceio handler
>> (BOOL  (*deviceio)(DWORD, LPVOID, DWORD, LPVOID, DWORD, LPDWORD,
>> LPOVERLAPPED);).  I wrote some test code in Linux using libusb reading
>> and writing to the device so I know what to do inside the deviceio
>> handler.
>>
>> Is this the right approach?  If so, what do I need to do to get
>> CreateFile to return the right handle?
>
> I think it really depends on the type of device and the possibility to
> rewrite the device driver or not.
>
> \\.\MyDevice0 is just a device driver name which at some point is
> registered in the registry with the appropriate VXD, SYS, or WDM
> driver file. If you know the exact DeviceIOControls called into that
> driver with its parameters and all, you could rewrite the VXD, SYS or
> WDM driver to call directly the appropriate Unix device driver calls
> and maybe compile it as a Winelib driver.
> With a bit hacking in the CreateFile function it should be possible to
> call such a driver over DeviceIOControl or you could add the according
> code to the above mentioned VXDList.
>
>> Or should I write an external driver that gets loaded by wine?  If so,
>> how would I do that?  What are the chances that the Windows driver for
>> this device would just work with wine?
>
> If you don't know these details and want to use the original device
> driver you are probably out of luck. The current CreateFile 
> implementation
> is not really up to the task of loading an external native device 
> driver
> and invoke it over the DeviceIOControl (which could probably be 
> remedied
> with a little hacking at this point) and what is much more problematic
> there is little or no support for a lot of the Windows kernel services
> most device driver usually expect to be able to call. When they are not
> able to link to one or more of those functions at load time, loading of
> the device driver will simply fail in Wine, as it does with normal DLL
> files under all Win32 implementations, too.
>
> Rolf Kalbermatter
>