Wine device drivers proposal

Damjan Jovanovic dj015 at yahoo.com
Mon Apr 4 04:50:49 CDT 2005


--- James Courtier-Dutton <James at superbug.demon.co.uk>
wrote:

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

I am not 100% happy about using the Linux kernel. How
would we deal with:

-Portability: It works only on Linux, nowhere else

-ioctl(): how does the DeviceIoControl() functions
know whether it is safe to use the native ioctl()
function with the same control codes or not?

Bye
Damjan


		
__________________________________ 
Yahoo! Messenger 
Show us what our next emoticon should look like. Join the fun. 
http://www.advision.webevents.yahoo.com/emoticontest



More information about the wine-devel mailing list