--- James Courtier-Dutton <[EMAIL PROTECTED]> 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