Wine device drivers proposal

[Damjan Jovanovic]

Hi

I've been trying to add STI (still image) support to
Wine, and I've made some progress. However, I see a
deep and unsurmountable need to add (at least
user-space) device drivers to Wine, and I would like
some feedback on these ideas.

Basically, many Windows device drivers are really
trivial, but required for many apps. A scanner driver
typically just accepts commands from a user-space app,
does minimal processing, and forwards that to Windows.
I've already hacked up Wine to get the same
functionality, and it works - partially.

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()

The problem is, how is a handle mapped to the
appropriate driver? I've thought about it, and come up
with 3 solutions. The first 3 don't require changes to
the wineserver but aren't pretty.

1. Make the driver a true Linux kernel mode driver,
and the handle its device file handle. Since
ReadFile() and WriteFile() just do read() and write()
system calls, this can be done. The problem is,
DeviceIoControl() has to be implemented using ioctl(),
and that's dangerous (sending the right codes to the
wrong device can be catastrophic). Also, it's not
portable to other OS's, and requires writing a kernel
module (which isn't fun).

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.

3. KERNEL32.DLL and / or NTDLL.DLL keep their own
handle table so they know which handles are driver
handles and deal with those appropriately. Having to
look up these tables for every call to ReadFile(),
WriteFile() and DeviceIoControl() might be very
inefficient, though.

4. Use an in-process solution, like a winelib DLL that
has exports for dealing with ReadFile(), WriteFile()
and DeviceIoControl(). This could be the most
efficient, but then again, you need an efficient way
to test a handle for being a driver handle, find the
appropriate driver, and call the right exported
function, which likely means the wineserver needs to
have knowledge of these drivers and provide
functionality for testing a handle for being a driver
handle and have a way to find the driver.

Let me know what you think.

Bye
Damjan


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/