[Wine] Want to use Digital Oszilloscope DSO-2100 at parport LPT1
Gert van den Berg
wine-users at mohag.net
Sat Feb 6 16:13:34 CST 2010
Sorry, haven't seen this reply...
On Fri, Feb 5, 2010 at 00:32, Martin Gregorie <martin at gregorie.org> wrote:
> On Thu, 2010-02-04 at 23:02 +0200, Gert van den Berg wrote:
>> Thanks... Someone with more than 5 minutes of *nix programming
>> experience... ;) I actually hoped that a Perl script might be
>> possible, but that seemed unlikely... (My C coding needs exercise and
>> is usually restricted to microcontrollers...)
> My C is the other way up to yours - the lowest level I've written C for
> is my Microware OS-9 (68020) and Flex-09 (6809) systems - and I haven't
> written 6809 C for a very long time.
> However, what are we trying to do? I'm asking because I'm not sure its
> being achieved. In particular, you *must* use execve() to pass the
> changed permissions along to a child process (in this case to wine.exe).
> Then somebody would need to dig into Wine to know whether it passes them
> on to the program we're asking it to run, since that's where they are
exec and friends are quite new to me ;) The permissions involved here
are at the CPU level though...
> Is this something that would be better handled by other methods, i.e. by
> changing the device file permissions? The obvious ways are, in ascending
> order of difficulty:
To program / sys file are probably using in and out instructions to
access the ports... It is the CPU itself denying the access, not the
OS (but the OS can se up the initial permissions)
http://en.wikipedia.org/wiki/Protected_mode#Privilege_levels is what
is blocking the instructions...
Additional ports can be set to be accessible (which is what ioperm
does (iopl lets the application run in ring 0, which gives it the same
I/O access as the kernel))
I can't remember if the I/O permissions is at the ring level or at the
process level... (probably a good time to have a look at the intel
More information about the wine-users