Wine device drivers proposal

Damjan Jovanovic dj015 at yahoo.com
Mon Aug 29 03:45:33 CDT 2005


--- Evgeny F <johnlen at 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 



More information about the wine-devel mailing list