Saulius Krasuckas wrote:
- On Sat, 14 Oct 2006, James Courtier-Dutton wrote:
- Rolf Kalbermatter wrote:
- Saulius Krasuckas [saulius2@ar.fi.lt] wrote:
Today I have tried to compile ntoskrnl.exe, then checked out master branch, compiled stock Wine, then tried to run win32 app which do simple port I/O after it loads (GIVE)IO.SYS driver. Driver simply loaded, did its initialization and immediatelly exited.
... I'm not positive these can all be easily added to a process operating in user space without some specific kernel support for this functionality and in fact allowing full IO access to a user space application such as Wine just doesn't seem safe to me.
...
Why do we need to give an application direct access to IO space?
Imagine some new motherboard model with uniq internal debugging device. And its supporting software designed only for Win32 platforms. Or imagine some proprietary portable music player connected via LPT and using its own protocol. User wants to make them work on linux. Just that's why.
I see two reports in out bugzilla on this topic: [6], [7].
IMHO, we don't need to give this access to all of applications. We just need a way to redirect operation from a particular win32 app to small piece of "raw-io-unrestricted" code.
[6] http://bugs.winehq.org/show_bug.cgi?id=3358#c6 [7] http://bugs.winehq.org/show_bug.cgi?id=3836#c8
This feature is being ask for by people who don't understand what most hardware requires from a "driver". 1) IO ports or memory mapped IO. 2) DMA handler 3) IRQ handler
Getting IO port access in wine really is not going to help a whole lot!
James