Dan Timis [mailto:timis@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