Saulius Krasuckas wrote: > * On Sat, 14 Oct 2006, James Courtier-Dutton wrote: >> * Rolf Kalbermatter wrote: >>> * Saulius Krasuckas [EMAIL PROTECTED] 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
