Wine device drivers proposal

[James Courtier-Dutton]

Damjan Jovanovic wrote:
> 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
> 

I would like this but mainly for a different reason.
I help reverse engineer hardware so that we can write linux drivers for
it. This reverse engineering task would be easier if I could install the
windows drivers on my linux box and run them, and then watch their
activity with the hardware. For this to work, we would have to implement
the HAL.DLL in wine, a small kernel module for it to communicate with
and probably a few other bits.

This would greatly help the hardware reverse engineering requirements in
order to get hardware to interoperate with Linux. Currently, I have to
installed special .DLLs on a windows box and perform the logging there.
I would much prefer to do it all on Linux.

The side effect of this would be that wine will support some hardware
even before Linux gets support for it.

This "kernel module" would only be run for the reverse engineering task,
as it would most likely make the linux kernel very insecure.

Any comments

James