Re: Wine device drivers proposal
In message Mon, 28 Mar 2005 02:30:28 -0800, Damjan Jovanovic wrote:
I propose adding a driver loading system to Wine that works as follows: -CreateFile() gets a device filename, like (in my case) \\.\MiiScan0 -Currently, Wine's behaviour for such a filename is to try load a VXD. -In the case of VXD loading failure, a search is performed in (Wine's) C:\Windows\System32\Drivers (or somewhere else?) for a matching driver.
The driver is then loaded and used for (at least): ReadFile() WriteFile() DeviceIoControl() CloseHandle() I am doing now a dll which should load scanner microdriver and implement all the surrounding API's. Can anybody tell, what naming convention Windows uses for USB devices ("\\.\????")?
2. The driver is a file giving a process to start and some IPC method to use. Wine starts the process and uses the IPC method to communicate with the driver. This is good as far as Wine's current ReadFile() and WriteFile() go, since they don't have to know they're not writing to an actual file. The problem here is, which IPC method supports both read() and write() on the same file descriptor, preserves message boundaries, and carries out-of-band data for DeviceIoControl()? I was thinking TCP sockets, but they don't preserve message boundaries.
Local UNIX sockets would do fine, do we really have to preserve message bounderies? Evgeny
Saturday, August 27, 2005, 6:24:21 AM, Evgeny F wrote:
In message Mon, 28 Mar 2005 02:30:28 -0800, Damjan Jovanovic wrote:
I propose adding a driver loading system to Wine that works as follows: -CreateFile() gets a device filename, like (in my case) \\.\MiiScan0 -Currently, Wine's behaviour for such a filename is to try load a VXD. -In the case of VXD loading failure, a search is performed in (Wine's) C:\Windows\System32\Drivers (or somewhere else?) for a matching driver.
The driver is then loaded and used for (at least): ReadFile() WriteFile() DeviceIoControl() CloseHandle() I am doing now a dll which should load scanner microdriver and implement all the surrounding API's. Can anybody tell, what naming convention Windows uses for USB devices ("\\.\????")? [skip]
It looks like there are multiple projects going on along the same lines here. Ivan Leo and me working on this too (making safedisc protected games work on wine). So far we have functional DeviceIoCotrol on a device. But no support for read or write nor synchronization of any kind. Right now it blocks until processing is complete. I would suggest to cooperate in this development effort. There are number of issues to resolve, that a not so trivial. Also there are limits to how far wine can go in emulating native kernel. Some things are gust impossible to implement in the same manner. Please join #winehackers channel on freenode.net to discuss the the subject. Vitaliy.
--- Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote:
Saturday, August 27, 2005, 6:24:21 AM, Evgeny F wrote:
In message Mon, 28 Mar 2005 02:30:28 -0800, Damjan Jovanovic wrote:
I propose adding a driver loading system to Wine that works as follows: -CreateFile() gets a device filename, like (in my case) \\.\MiiScan0 -Currently, Wine's behaviour for such a filename is to try load a VXD. -In the case of VXD loading failure, a search is performed in (Wine's) C:\Windows\System32\Drivers (or somewhere else?) for a matching driver.
The driver is then loaded and used for (at least): ReadFile() WriteFile() DeviceIoControl() CloseHandle() I am doing now a dll which should load scanner microdriver and implement all the surrounding API's. Can anybody tell, what naming convention Windows uses for USB devices ("\\.\????")? [skip]
It looks like there are multiple projects going on along the same lines here. Ivan Leo and me working on this too (making safedisc protected games work on wine).
So far we have functional DeviceIoCotrol on a device. But no support for read or write nor synchronization of any kind. Right now it blocks until processing is complete.
How exactly did you change DeviceIoControl()?
I would suggest to cooperate in this development effort. There are number of issues to resolve, that a not so trivial. Also there are limits to how far wine can go in emulating native kernel. Some things are gust impossible to implement in the same manner.
Please join #winehackers channel on freenode.net to discuss the the subject.
Vitaliy.
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Monday, August 29, 2005, 3:13:43 AM, Damjan Jovanovic wrote:
It looks like there are multiple projects going on along the same lines here. Ivan Leo and me working on this too (making safedisc protected games work on wine).
So far we have functional DeviceIoCotrol on a device. But no support for read or write nor synchronization of any kind. Right now it blocks until processing is complete.
How exactly did you change DeviceIoControl()?
Mm that's a bit more complicated then just DeviceIoControl. Actually believe it or not but "DeviceIoControl" is unchanged. Vitaliy
--- Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote:
Monday, August 29, 2005, 3:13:43 AM, Damjan Jovanovic wrote:
It looks like there are multiple projects going on along the same lines here. Ivan Leo and me working on this too (making safedisc protected games work on wine).
So far we have functional DeviceIoCotrol on a device. But no support for read or write nor synchronization of any kind. Right now it blocks until processing is complete.
How exactly did you change DeviceIoControl()?
Mm that's a bit more complicated then just DeviceIoControl. Actually believe it or not but "DeviceIoControl" is unchanged.
What did you change? NtDeviceIoControl()?
Vitaliy
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
--- Evgeny F <johnlen(a)qsp.homelinux.org> wrote:
In message Mon, 28 Mar 2005 02:30:28 -0800, Damjan Jovanovic wrote:
I propose adding a driver loading system to Wine that works as follows: -CreateFile() gets a device filename, like (in my case) \\.\MiiScan0 -Currently, Wine's behaviour for such a filename is to try load a VXD. -In the case of VXD loading failure, a search is performed in (Wine's) C:\Windows\System32\Drivers (or somewhere else?) for a matching driver.
The driver is then loaded and used for (at least): ReadFile() WriteFile() DeviceIoControl() CloseHandle() I am doing now a dll which should load scanner microdriver and implement all the surrounding API's. Can anybody tell, what naming convention Windows uses for USB devices ("\\.\????")?
I don't know for sure, but I think there is no convention. The device names are dependant on the hardware / system. What "microdriver" are you talking about? Are you working on STI? For STI, there is a convention for Windows 2000 and onwards, something like \\.\USBSCAN\... (check the STI documentation on MSDN). If it's STI, I have some code; do you want it?
2. The driver is a file giving a process to start and some IPC method to use. Wine starts the process and uses the IPC method to communicate with the driver. This is good as far as Wine's current ReadFile() and WriteFile() go, since they don't have to know they're not writing to an actual file. The problem here is, which IPC method supports both read() and write() on the same file descriptor, preserves message boundaries, and carries out-of-band data for DeviceIoControl()? I was thinking TCP sockets, but they don't preserve message boundaries.
Local UNIX sockets would do fine, do we really have to preserve message bounderies? Evgeny
Yes, boundaries absolutely must be preserved, because USB bulk reads and writes occur in packets, not as streams. How are you going to extract packets from a stream at the other end? This is, by the way, a serious problem. I still haven't figured out how to do it, without major major changes to NTDLL, wineserver, and several other parts of wine. There are (ugly) hacks, like messing with the DLL import table to dynamically link it to other implementations of ReadFile(), WriteFile() and such. Bye Damjan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Damjan Jovanovic <dj015(a)yahoo.com> wrote:
What "microdriver" are you talking about? Are you working on STI? For STI, there is a convention for Windows 2000 and onwards, something like \\.\USBSCAN\... (check the STI documentation on MSDN). If it's STI, I have some code; do you want it?
Yes, it is scanner microdriver.
Yes, boundaries absolutely must be preserved, because USB bulk reads and writes occur in packets, not as streams. How are you going to extract packets from a stream at the other end?
There are some new type of socket, present since 2.6.4 kernel described in unix(7) manual page - SOC_SEQPACKET, which is both connection-oriented and preserves message bounderies. Will it work for that purpose?
Damjan Jovanovic <dj015(a)yahoo.com> wrote:
What "microdriver" are you talking about? Are you working on STI? For STI, there is a convention for Windows 2000 and onwards, something like \\.\USBSCAN\... (check the STI documentation on MSDN).
If it's STI, I have some code; do you want it?
Yes, it is scanner microdriver.
Yes, boundaries absolutely must be preserved, because USB bulk reads and writes occur in packets, not as streams. How are you going to extract packets from a stream at the other end?
There are some new type of socket, present since 2.6.4 kernel described in unix(7) manual page - SOC_SEQPACKET, which is both connection-oriented and preserves message bounderies. Will it work for that purpose
--- Evgeny F <johnlen(a)yandex.ru> wrote:
Damjan Jovanovic <dj015(a)yahoo.com> wrote:
What "microdriver" are you talking about? Are you working on STI? For STI, there is a convention for Windows 2000 and onwards, something like \\.\USBSCAN\... (check the STI documentation on MSDN).
If it's STI, I have some code; do you want it?
Yes, it is scanner microdriver.
Yes, boundaries absolutely must be preserved, because USB bulk reads and writes occur in packets, not as streams. How are you going to extract packets from a stream at the other end?
There are some new type of socket, present since 2.6.4 kernel described in unix(7) manual page - SOC_SEQPACKET, which is both connection-oriented and preserves message bounderies. Will it work for that purpose
No. Here's why: Your microdriver has a socket, and wine has a socket connected to that socket. When wine writes, your microdriver gets packets, and your microdriver can extract the boundaries and use the packets. But what happens when wine wants to read from the socket? How do you know to read from the scanner and send wine the packet, and what size that packet should be? You don't. Reading a USB pipe is a synchronous pull protocol and sockets use an asynchronous push protocol. That is why sockets can't be used. I've given this some thought, and wine needs to be changed. Drastically. Look at the hacks in ntdll/cdrom.c, kernel/volume.c and many others - the current handle system is coming apart at the seams. My advice is to add handle "types" eg. a file handle, cdrom handle, device handle, ..., with each handle being a pointer to something like: struct Handle { DWORD (*ReadFile)(VOID *buffer, DWORD size); DWORD (*WriteFile)(VOID *buffer, DWORD size); DWORD (*DeviceIoControl)(VOID *buffer, DWORD size); ... }; and have the ReadFile(), WriteFile() and DeviceIoControl() simply call the function pointers in the handle. That way it would be trivial to add a new device driver type of thing into wine: write new functions, and change CreateFile() to initialize handles for that device type with the right combination of function pointers. What do you think? ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
participants (4)
-
Damjan Jovanovic -
Evgeny F -
Evgeny F -
Vitaliy Margolen