Want to use Digital Oszilloscope DSO-2100 at parport LPT1

[lsmod]

Some time ago i already tried to get running a Digital Oszilloscope DSO-2100 at the parallel port LPT1.
But i give up to get it running.
Now i have another problem (http://forum.winehq.org/viewtopic.php?p=38741#38741) and so i have tested this again.

This time i added the keys to the registry for direct parport access:

Code: Select all

REGEDIT4

[HKEY_LOCAL_MACHINE\Software\Wine\VDM]

[HKEY_LOCAL_MACHINE\Software\Wine\VDM\Ports]
"read"="0x779,0x379,0x280-0x2a0"
"write"="0x779,0x379,0x280-0x2a0"

[HKEY_LOCAL_MACHINE\Software\Wine\VDM\ppdev]
"378"="/dev/parport0"

And the user is added to the group "lp" to have sufficient rights for the parport.

I installed the old Windows98-Version of the Oszilloscope software in "Windows ME" emulation.
The installation goes through without problems and can be started.
The splash screen is coming up and the nice and senseless music is being played.
Then the main windows is opened correct but i get still the message:
"SCOPE CARD NOT CONNECT OR NO POWER"
This is the same message as if the scope is not connected.

Here the output on the shell:

/wine/drive_c/Programme/DSO2100> wine DSO2100.exe
wine: Unhandled page fault on write access to 0x00650120 at address 0x7ef41a9e (thread 0014), starting debugger...
Unhandled exception: page fault on write access to 0x00650120 in 32-bit code (0x7ef41a9e).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:7ef41a9e ESP:0064e640 EBP:0064e6e8 EFLAGS:00010246( - 00 -RIZP1)
EAX:00650080 EBX:7ef43114 ECX:00000000 EDX:0064e628
ESI:0000004e EDI:00000000
Stack dump:
0x0064e640: 00651000 00001000 00000020 00000000
0x0064e650: 00110058 00113f18 00113f70 00000000
0x0064e660: 00000000 00113f70 0064e698 7ef79331
0x0064e670: 00110058 ffffffff 00000058 00000000
0x0064e680: 00110000 7efe3820 0064e698 7ef792ee
0x0064e690: 00110058 7efe3820 0064e6e8 7ef8c5a5
Backtrace:
=>0 0x7ef41a9e load_driver_module+0x1fe(name=0x113f78) [/mnt/ramdisk/wine-1.1.17~winehq1/programs/winedevice/device.c:103] in winedevice (0x0064e6e8)
1 0x7ef4236e load_driver+0x402() [/mnt/ramdisk/wine-1.1.17~winehq1/programs/winedevice/device.c:229] in winedevice (0x0064e958)
2 0x7ef4266e ServiceMain+0x11f(argc=1, argv=0x113de8) [/mnt/ramdisk/wine-1.1.17~winehq1/programs/winedevice/device.c:287] in winedevice (0x0064e9b8)
3 0x7ebbdf10 service_thread+0x156(arg=0x113908) [/mnt/ramdisk/wine-1.1.17~winehq1/dlls/advapi32/service.c:294] in advapi32 (0x0064ea18)
4 0x7efc126a call_thread_entry_point+0xe() in ntdll (0x0064ea28)
5 0x7efc12f2 call_thread_func+0x86(rtl_func=0x7ebbddba, arg=0x113908) [/mnt/ramdisk/wine-1.1.17~winehq1/dlls/ntdll/thread.c:432] in ntdll (0x0064eac8)
6 0x7efc14b6 start_thread+0x121(info=0x7ffd0fb8) [/mnt/ramdisk/wine-1.1.17~winehq1/dlls/ntdll/thread.c:491] in ntdll (0x0064f3c8)
7 0xf7e13195 start_thread+0xab() in libpthread.so.0 (0x0064f4c8)
8 0xf7d984ce __clone+0x5e() in libc.so.6 (0x00000000)
0x7ef41a9e load_driver_module+0x1fe [/mnt/ramdisk/wine-1.1.17~winehq1/programs/winedevice/device.c:103] in winedevice: movl $0x0,0xa0(%eax)
Unable to open file ''
Modules:
Module Address Debug info Name (29 modules)
PE 650000- 656000 Deferred ioport.sys
ELF 7bf00000-7bf03000 Deferred <wine-loader>
ELF 7ea35000-7ea4b000 Deferred hal<elf>
\-PE 7ea40000-7ea4b000 \ hal
ELF 7ea4b000-7eaba000 Deferred msvcrt<elf>
\-PE 7ea60000-7eaba000 \ msvcrt
ELF 7eaba000-7eb27000 Deferred rpcrt4<elf>
\-PE 7ead0000-7eb27000 \ rpcrt4
ELF 7eb46000-7eb80000 Deferred ntoskrnl<elf>
\-PE 7eb50000-7eb80000 \ ntoskrnl
ELF 7eb80000-7ebd9000 Dwarf advapi32<elf>
\-PE 7eb90000-7ebd9000 \ advapi32
ELF 7ebd9000-7ebe4000 Deferred libnss_files.so.2
ELF 7ebe4000-7ebee000 Deferred libnss_nis.so.2
ELF 7ebee000-7ec06000 Deferred libnsl.so.1
ELF 7edb7000-7ef02000 Deferred kernel32<elf>
\-PE 7edd0000-7ef02000 \ kernel32
ELF 7ef02000-7ef26000 Deferred libm.so.6
ELF 7ef30000-7ef44000 Dwarf winedevice<elf>
\-PE 7ef40000-7ef44000 \ winedevice
ELF 7ef44000-7f000000 Dwarf ntdll<elf>
\-PE 7ef60000-7f000000 \ ntdll
ELF f7cb7000-f7cbb000 Deferred libdl.so.2
ELF f7cbb000-f7e0d000 Export libc.so.6
ELF f7e0d000-f7e24000 Export libpthread.so.0
ELF f7e24000-f7e27000 Deferred iso8859-1.so
ELF f7e27000-f7e30000 Deferred libnss_compat.so.2
ELF f7e42000-f7f7f000 Deferred libwine.so.1
ELF f7f82000-f7fa1000 Deferred ld-linux.so.2
Threads:
process tid prio (all id:s are in hex)
00000008
00000009 0
0000000a
0000000b 0
0000000c
00000015 0
00000013 0
00000012 0
0000000e 0
0000000d 0
0000000f (D) C:\windows\system32\winedevice.exe
00000014 0 <==
00000011 0
00000010 0
Backtrace:
=>0 0x7ef41a9e load_driver_module+0x1fe(name=0x113f78) [/mnt/ramdisk/wine-1.1.17~winehq1/programs/winedevice/device.c:103] in winedevice (0x0064e6e8)
1 0x7ef4236e load_driver+0x402() [/mnt/ramdisk/wine-1.1.17~winehq1/programs/winedevice/device.c:229] in winedevice (0x0064e958)
2 0x7ef4266e ServiceMain+0x11f(argc=1, argv=0x113de8) [/mnt/ramdisk/wine-1.1.17~winehq1/programs/winedevice/device.c:287] in winedevice (0x0064e9b8)
3 0x7ebbdf10 service_thread+0x156(arg=0x113908) [/mnt/ramdisk/wine-1.1.17~winehq1/dlls/advapi32/service.c:294] in advapi32 (0x0064ea18)
4 0x7efc126a call_thread_entry_point+0xe() in ntdll (0x0064ea28)
5 0x7efc12f2 call_thread_func+0x86(rtl_func=0x7ebbddba, arg=0x113908) [/mnt/ramdisk/wine-1.1.17~winehq1/dlls/ntdll/thread.c:432] in ntdll (0x0064eac8)
6 0x7efc14b6 start_thread+0x121(info=0x7ffd0fb8) [/mnt/ramdisk/wine-1.1.17~winehq1/dlls/ntdll/thread.c:491] in ntdll (0x0064f3c8)
7 0xf7e13195 start_thread+0xab() in libpthread.so.0 (0x0064f4c8)
8 0xf7d984ce __clone+0x5e() in libc.so.6 (0x00000000)
fixme:ole:OaBuildVersion Version value not known yet. Please investigate it !
fixme:ole:OLEPictureImpl_SaveAsFile (0x149610)->(0x149b20, 0, (nil)), hacked stub.
fixme:ole:OLEPictureImpl_SaveAsFile (0x164ef0)->(0x1653d0, 0, (nil)), hacked stub.
err:ole:ITypeInfo_fnInvoke did not find member id -514, flags 0x2!
fixme:ole:OLEPictureImpl_SaveAsFile (0x1898d0)->(0x165398, 0, (nil)), hacked stub.
fixme:vxd:VXD_Open Unknown/unsupported VxD L"vkvxd.vxd". Try setting Windows version to 'nt40' or 'win31'.
fixme:ole:OLEPictureImpl_SaveAsFile (0x199008)->(0x199518, 0, (nil)), hacked stub.
fixme:ole:OLEPictureImpl_SaveAsFile (0xbbf210)->(0xbbf2e0, 0, (nil)), hacked stub.
err:heap:GlobalFree (0x8982): Page fault occurred ! Caused by bug ?

I would say there is just no access to the parport!?

[lsmod]

Additional i opened a bug report for this problem.
http://bugs.winehq.org/show_bug.cgi?id=21578

[Gert van den Berg]

I might be completely wrong, but here goes...

On Tue, Feb 2, 2010 at 12:27, lsmod <[email protected]> wrote:

Some time ago i already tried to get running a Digital Oszilloscope DSO-2100 at the parallel port LPT1.

I installed the old Windows98-Version of the Oszilloscope software in "Windows ME" emulation.

Module  Address                 Debug info      Name (29 modules)
PE        650000-  656000       Deferred        ioport.sys

That looks a lot like a driver, maybe this one:
http://www.brothersoft.com/ioport-download-47899.html

Drivers would not work under Wine.

IO Ports should NEVER be accessed directly on a multi-tasking
operating system. (If direct access takes place, multiple application
can access the port simultaneously, leading to crashes in the best
case...) If it runs under a Windows NT as a non-administrator user,
this is not the issue...

You might be able to bypass it by using a wrapper that sets up IO
permissions using http://linux.die.net/man/2/ioperm and then starts
the Wine program.. (It would probably need to run as root) Not sure if
that would be able to bypass driver issues...

fixme:vxd:VXD_Open Unknown/unsupported VxD L"vkvxd.vxd". Try setting Windows version to 'nt40' or 'win31'.

VXD drivers won't work, try a non Win9x mode...

I would say there is just no access to the parport!?

Or the parallel port only works if it is access by the proper
interfaces, not directly by an application doing stuff that only the
kernel should be doing...

Gert

[lsmod]

IO Ports should NEVER be accessed directly on a multi-tasking
operating system. (If direct access takes place, multiple application
can access the port simultaneously, leading to crashes in the best
case...) If it runs under a Windows NT as a non-administrator user,
this is not the issue...

Of course it would be better if there is a clean solution.
But if you want to connect and use the hardware you have then you will have no choice.
And such hardware based on a parallel port in windows is a typical relict if you are going to use Linux.
So what shall i do?

There are some notes that people get special hardware connected and used in wine like dongles.
The question is why this seems not to work any more?
In the other thread you can read that i have made multiple tests.

I undestand the problems with drivers, but the software i used was before NT.
There is another version of the software that also works under XP.
But as i have understand there is less hope to get it running in wine?

[oiaohm]

Depends on Driver. XP version is far more likely to work. Since there is a userspace interface for printer port in windows.

It all depends how the dongle is talked to. The ones that work are talked to using the userspace interfaces of windows. The ones that don't work are in your class using drivers to access.

[lsmod]

O.K. Thank you for your help.

Then it seems to be hopeless to get it running in Wine.

[Gert van den Berg]

On Wed, Feb 3, 2010 at 19:28, lsmod <[email protected]> wrote:

Gert van den Berg wrote:

IO Ports should NEVER be accessed directly on a multi-tasking
operating system. (If direct access takes place, multiple application
can access the port simultaneously, leading to crashes in the best
case...) If it runs under a Windows NT as a non-administrator user,
this is not the issue...

Of course it would be better if there is a clean solution.
But if you want to connect and use the hardware you have then you will have no choice.
And such hardware based on a parallel port in windows is a typical relict if you are going to use Linux.
So what shall i do?

Try a small C program that sets ioperm and then execs Wine... (iopl
might work as well...) (You might also want to drop root priviledges
before execing Wine....)

Gert

Something like:

#include<sys/io.h>

int main(int argc, char *argv[])
{
ioperm(0,0x3ff,1); /* Dangerous, overkill, allows access to all ports */

/* setuid(<your uid>); /* Drops permissions - have never used it,
check docs... Environment should probably be set up as well */

execlp("wine","wine","application.exe"); /* My unix C coding
needs practice, so this might just destroy your PC, read docs... */

return 1;
}

[Gert van den Berg]

Fixed code: /* Hopefully... Wrapping WILL %#$% it up... */
#include<sys/io.h>
#include<stdio.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
ioperm(0,0x3ff,1); /* Dangerous, overkill, allows access to all ports */

/* setuid(<your uid>); /* Drops permissions - have never used it,
check docs... Environment should probably be set up as well */
execlp("wine","wine","application.exe",NULL); /* My unix C coding
needs practice, so this might just destroy your PC, read docs... */
printf("Failed to run Wine\n");
return 1; /* Should never run */
}

[Martin Gregorie]

On Thu, 2010-02-04 at 19:46 +0200, Gert van den Berg wrote:

Fixed code: /* Hopefully... Wrapping WILL %#$% it up... */

Here's a version that compiles and runs. I've added a couple of extra
capabilities too:

- it passes the environment variables to its child process, so it runs
wine with execve() rather than execlp()

- the abandon() function reports errors, showing what the program
was doing, the error code that was returned and its meaning.

- Wine runs its command line arguments for added flexibility, so

testw winefile

runs Wine's Windows Explorer workalike. You'll see that it fiddles
with the argument list, substituting "wine" for the first argument
and adding a after the last argument null to terminate the array.
Both are necessary.

=========================testw.c============================
#include <sys/io.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>

void abandon(char *text)
{
fprintf(stderr,
"Error: %s: err %d,%s\n",
text, errno, strerror(errno));
exit(1);
}

int main(int argc, char *argv[], char *envp[])
{
char **args;
int i;

args = (char**)malloc((argc + 1) * sizeof(char*));
if (!args)
abandon("malloc() failed");

for (i = 1; i < argc; i++)
args = argv;

args[0] = "wine";
args = 0;
ioperm(0,0x3ff,1); /* Allows access to all ports: poss. dangerous */
setuid(geteuid()); /* set effective uid */
if (execve("/usr/bin/wine", args, envp) == -1)
abandon("Failed to run wine");

free(args);
return 0;
}
=====================end of testw.c=========================


Martin

[Gert van den Berg]

On Thu, Feb 4, 2010 at 21:41, Martin Gregorie <[email protected]> wrote:

On Thu, 2010-02-04 at 19:46 +0200, Gert van den Berg wrote:

Fixed code: /* Hopefully... Wrapping WILL %#$% it up... */

Here's a version that compiles and runs. I've added a couple of extra
capabilities too:

Mine compiles... (second version at least...)

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

Gert

[Martin Gregorie]

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

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:

1) Add the user(s) where Wine is run to the lp group.

2) run chmod on the relevant device files at boot time.
On a RedHat system this is simply done by adding

chmod uga+rw /dev/lp* /dev/parport*

to the end of /etc/rc/d/rc.local

3) modify the UDEV rules to give world access to the relevant
device files as they are created. This means adding a local
rules file to /etc/udev/rules.d to set the device file permissions.

Is there a driver involved, and if so, can its code be moved into some
userspace program or DLL and can the Oscilloscope program be modified to
use it?


Martin

[lsmod]

Thanks for your wrapper-program.
I tried it out today.
First i give the appropriate rights to the devices as root, then i started the Oszilloscope program with the wrapper as normal user.
But it still has no access to the parallel port.

Code: Select all

/wine/drive_c/Programme/DSO2100> winewrap DSO2100.exe &> winewrap_DSO2100.log
/wine/drive_c/Programme/DSO2100> ls -l /dev/lp*
crw-rw-rw- 1 root lp 6, 0  6. Feb 18:06 /dev/lp0
/wine/drive_c/Programme/DSO2100> ls -l /dev/par*
crw-rw-rw- 1 lp lp 99, 0  6. Feb 18:06 /dev/parport0

I could not start it as root, because the root cannot open a window in the X-Server in Debian.

Here the output from the shell:

Code: Select all

wine: Unhandled page fault on write access to 0x00650120 at address 0x7ef41a9e (thread 0015), starting debugger...
Unhandled exception: page fault on write access to 0x00650120 in 32-bit code (0x7ef41a9e).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:7ef41a9e ESP:0064e640 EBP:0064e6e8 EFLAGS:00010246(   - 00      -RIZP1)
 EAX:00650080 EBX:7ef43114 ECX:00000000 EDX:0064e628
 ESI:0000004e EDI:00000000
Stack dump:
0x0064e640:  00651000 00001000 00000020 00000000
0x0064e650:  00110058 00113df8 00113e58 00000000
0x0064e660:  00000000 00113e58 0064e698 7ef79331
0x0064e670:  00110058 ffffffff 00000060 00000000
0x0064e680:  00110000 7efe3820 0064e698 7ef792ee
0x0064e690:  00110058 7efe3820 0064e6e8 7ef8c5a5
Backtrace:
=>0 0x7ef41a9e load_driver_module+0x1fe(name=0x113f40) [/mnt/ramdisk/wine-1.1.17~winehq1/programs/winedevice/device.c:103] in winedevice (0x0064e6e8)
  1 0x7ef4236e load_driver+0x402() [/mnt/ramdisk/wine-1.1.17~winehq1/programs/winedevice/device.c:229] in winedevice (0x0064e958)
  2 0x7ef4266e ServiceMain+0x11f(argc=1, argv=0x113de8) [/mnt/ramdisk/wine-1.1.17~winehq1/programs/winedevice/device.c:287] in winedevice (0x0064e9b8)
  3 0x7ebbdf10 service_thread+0x156(arg=0x113908) [/mnt/ramdisk/wine-1.1.17~winehq1/dlls/advapi32/service.c:294] in advapi32 (0x0064ea18)
  4 0x7efc126a call_thread_entry_point+0xe() in ntdll (0x0064ea28)
  5 0x7efc12f2 call_thread_func+0x86(rtl_func=0x7ebbddba, arg=0x113908) [/mnt/ramdisk/wine-1.1.17~winehq1/dlls/ntdll/thread.c:432] in ntdll (0x0064eac8)
  6 0x7efc14b6 start_thread+0x121(info=0x7ffd0fb8) [/mnt/ramdisk/wine-1.1.17~winehq1/dlls/ntdll/thread.c:491] in ntdll (0x0064f3c8)
  7 0xf7e62195 start_thread+0xab() in libpthread.so.0 (0x0064f4c8)
  8 0xf7de74ce __clone+0x5e() in libc.so.6 (0x00000000)
0x7ef41a9e load_driver_module+0x1fe [/mnt/ramdisk/wine-1.1.17~winehq1/programs/winedevice/device.c:103] in winedevice: movl	$0x0,0xa0(%eax)
Unable to open file ''
Modules:
Module	Address			Debug info	Name (29 modules)
PE	  650000-  656000	Deferred        ioport.sys
ELF	7bf00000-7bf03000	Deferred        <wine-loader>
ELF	7ea35000-7ea4b000	Deferred        hal<elf>
  \-PE	7ea40000-7ea4b000	\               hal
ELF	7ea4b000-7eaba000	Deferred        msvcrt<elf>
  \-PE	7ea60000-7eaba000	\               msvcrt
ELF	7eaba000-7eb27000	Deferred        rpcrt4<elf>
  \-PE	7ead0000-7eb27000	\               rpcrt4
ELF	7eb46000-7eb80000	Deferred        ntoskrnl<elf>
  \-PE	7eb50000-7eb80000	\               ntoskrnl
ELF	7eb80000-7ebd9000	Dwarf           advapi32<elf>
  \-PE	7eb90000-7ebd9000	\               advapi32
ELF	7ebd9000-7ebe4000	Deferred        libnss_files.so.2
ELF	7ebe4000-7ebee000	Deferred        libnss_nis.so.2
ELF	7ebee000-7ec06000	Deferred        libnsl.so.1
ELF	7edb7000-7ef02000	Deferred        kernel32<elf>
  \-PE	7edd0000-7ef02000	\               kernel32
ELF	7ef02000-7ef26000	Deferred        libm.so.6
ELF	7ef30000-7ef44000	Dwarf           winedevice<elf>
  \-PE	7ef40000-7ef44000	\               winedevice
ELF	7ef44000-7f000000	Dwarf           ntdll<elf>
  \-PE	7ef60000-7f000000	\               ntdll
ELF	f7d06000-f7d0a000	Deferred        libdl.so.2
ELF	f7d0a000-f7e5c000	Export          libc.so.6
ELF	f7e5c000-f7e73000	Export          libpthread.so.0
ELF	f7e74000-f7e77000	Deferred        iso8859-1.so
ELF	f7e77000-f7e80000	Deferred        libnss_compat.so.2
ELF	f7e91000-f7fce000	Deferred        libwine.so.1
ELF	f7fd1000-f7ff0000	Deferred        ld-linux.so.2
Threads:
process  tid      prio (all id:s are in hex)
00000008 
	00000009    0
0000000a 
	0000000b    0
0000000c 
	00000014    0
	00000013    0
	00000012    0
	0000000e    0
	0000000d    0
0000000f (D) C:\windows\system32\winedevice.exe
	00000015    0 <==
	00000011    0
	00000010    0
Backtrace:
=>0 0x7ef41a9e load_driver_module+0x1fe(name=0x113f40) [/mnt/ramdisk/wine-1.1.17~winehq1/programs/winedevice/device.c:103] in winedevice (0x0064e6e8)
  1 0x7ef4236e load_driver+0x402() [/mnt/ramdisk/wine-1.1.17~winehq1/programs/winedevice/device.c:229] in winedevice (0x0064e958)
  2 0x7ef4266e ServiceMain+0x11f(argc=1, argv=0x113de8) [/mnt/ramdisk/wine-1.1.17~winehq1/programs/winedevice/device.c:287] in winedevice (0x0064e9b8)
  3 0x7ebbdf10 service_thread+0x156(arg=0x113908) [/mnt/ramdisk/wine-1.1.17~winehq1/dlls/advapi32/service.c:294] in advapi32 (0x0064ea18)
  4 0x7efc126a call_thread_entry_point+0xe() in ntdll (0x0064ea28)
  5 0x7efc12f2 call_thread_func+0x86(rtl_func=0x7ebbddba, arg=0x113908) [/mnt/ramdisk/wine-1.1.17~winehq1/dlls/ntdll/thread.c:432] in ntdll (0x0064eac8)
  6 0x7efc14b6 start_thread+0x121(info=0x7ffd0fb8) [/mnt/ramdisk/wine-1.1.17~winehq1/dlls/ntdll/thread.c:491] in ntdll (0x0064f3c8)
  7 0xf7e62195 start_thread+0xab() in libpthread.so.0 (0x0064f4c8)
  8 0xf7de74ce __clone+0x5e() in libc.so.6 (0x00000000)
fixme:ole:OaBuildVersion Version value not known yet. Please investigate it !
fixme:ole:OLEPictureImpl_SaveAsFile (0x149638)->(0x149b48, 0, (nil)), hacked stub.
fixme:ole:OLEPictureImpl_SaveAsFile (0x164f18)->(0x1653f8, 0, (nil)), hacked stub.
err:ole:ITypeInfo_fnInvoke did not find member id -514, flags 0x2!
fixme:ole:OLEPictureImpl_SaveAsFile (0x1898f8)->(0x1653c0, 0, (nil)), hacked stub.
fixme:vxd:VXD_Open Unknown/unsupported VxD L"vkvxd.vxd". Try setting Windows version to 'nt40' or 'win31'.
fixme:ole:OLEPictureImpl_SaveAsFile (0x198fd8)->(0x1994e8, 0, (nil)), hacked stub.
fixme:ole:OLEPictureImpl_SaveAsFile (0xbbf648)->(0xbbfb58, 0, (nil)), hacked stub.
err:heap:GlobalFree (0x89aa): Page fault occurred ! Caused by bug ?

[oiaohm]

lsmod you are using a very old version of wine. <== marks where the program stoped on the back trace.

Tells us inside some closed source driver that wine-device managed to load.

Is windows version in wine set to XP because it could be just a badly code program that finds OS by attempting to load drivers. ie vkvxd.vxd should not be attempted to be loaded under XP

By the way appartently native Linux solutions exist for DSO 2100's http://www.ise.pw.edu.pl/~wzab/dso2100pp/index.html http://freenet-homepage.de/kritikus/cli ... o2100.html

[Gert van den Berg]

Sorry, haven't seen this reply...

On Fri, Feb 5, 2010 at 00:32, Martin Gregorie <[email protected]> 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
needed.

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)

See http://en.wikipedia.org/wiki/X86_instru ... structions

http://en.wikipedia.org/wiki/Protected_ ... ege_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
developer manual...)

Gert

[oiaohm]

Gert van den Berg. Ring 0 by default has io permissions.

IOPL is a independent value to rings. To be correct it assigns what IO permission rings has. Basically from ring 0-3 call can be assigned IO permissions if you want. Even that they have related kinds of numbers. And that it is assigned to the ring running the application for it to work.

http://wiki.osdev.org/Security#I.2FO_Privilege_Level

Lot of people mix up IOPL and Rings. So you are not alone Gert van den Berg.

iopl and ioperm both require CAP_SYS_RAWIO. To be correct the process is still a protected process when iopl has been performed on it not a ring 0. Just port access and suspend interprets is granted to the process.

Now issue here we really don't want to have to grant this to anything non native. Even granting this to X11 risks big problems.

Really is a last resort option to enable iopl since it grants way too much access and can cause the kernel to die. ioperm maybe. But it can also have bad effects.

Ie ioperm and iopl are not protected by CAP_SYS_RAWIO without very good reason.

Using iopl can be kiss your filesystem by by if interpret were suspended then it locked up while a critical write was happening to filesystem.

ioperm not as bad. But it can still be hmm stuff running strange with no idea why.

Also any code using ioperm or iopl is Linux only. Must always be kept in mind that it is such.

[Martin Gregorie]

On Sun, 2010-02-07 at 00:13 +0200, Gert van den Berg wrote:

Sorry, haven't seen this reply...

On Fri, Feb 5, 2010 at 00:32, Martin Gregorie <[email protected]> wrote:

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

exec and friends are quite new to me The permissions involved here
are at the CPU level though...

Sure, but when threads and/or child processes are involved there is
normally some sort of permission, e.g suid, needed for the process to
use kernel-level access permissions. This is to keep malicious and/or
sloppily programmed process from causing damage.

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)

See http://en.wikipedia.org/wiki/X86_instru ... structions

http://en.wikipedia.org/wiki/Protected_ ... ege_levels is what
is blocking the instructions...

ioperm() sets the *process* port access permission bits for access to
the specified port range. So they must be passed wrapper->Wine->app to
be any use.

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

Exactly. However as the process that was given the permissions by
calling ioperm() is only the wrapper it must pass them to the
application via Wine before they can be any use. "man ioperm" tells all.


Martin

[oiaohm]

ioperm() sets the *process* port access permission bits for access to
the specified port range. So they must be passed wrapper->Wine->app to
be any use.

Martin Gregorie not that simple wish it was. Notice C:\windows\system32\winedevice.exe there were two exe's running not one.

From memory winedevice is started by wineserver. Not by main wine. And it winedevice that requires ioperm() we are talking code modification because the rest of the code does not require it.

So if wineserver was running before you run altered permissions on wine it would fail big time. Yet you don't want to fully grant access everywhere from wineserver or wine either.

suid is not required. CAP_SYS_RAWIO is all that is required. Please learn to forget it exists while on Linux Martin caps are the correct security way todo what every you would suid for.

With a bit of reworking it would be possible to make ioperm usable with wine. Issue is that it will cost a bit of speed on applications that don't need it.

[Gert van den Berg]

On Sun, Feb 7, 2010 at 04:49, oiaohm <[email protected]> wrote:

With a bit of reworking it would be possible to make ioperm usable with wine.   Issue is that it will cost a bit of speed on applications that don't need it.

It should only be needed for Windows 9x / DOS / Win 3.x apps? NT needs
the permissions to be set up anyway, so it doesn't need to be done by
default?

Gert

[Gert van den Berg]

On Sun, Feb 7, 2010 at 02:56, oiaohm <[email protected]> wrote:

Gert van den Berg.  Ring 0 by default has io permissions.

IOPL is a independent value to rings.  To be correct it assigns what IO permission rings has.  Basically from ring 0-3 call can be assigned IO permissions if you want.  Even that they have related kinds of numbers.  And that it is assigned to the ring running the application for it to work.

http://wiki.osdev.org/Security#I.2FO_Privilege_Level

(My assembler books are a few hundred km's away and the Intel
documentation is spread between 10's of PDFs...)

Ah, ok, so it looks like the IOPL is a flag value determining for
which rings the port permissions (settable with ioperm on Linux) is
checked?

Now issue here we really don't want to have to grant this to anything non native.  Even granting this to X11 risks big problems.

Direct I/O is dangerous.... (Even when ignoring the problems that
multitasking causes...) Which is why I started my first reply with a
rant on ehy it should never be done...

Really is a last resort option to enable iopl since it grants way too much access and can cause the kernel to die.   ioperm maybe.   But it can also have bad effects.

ioperm with all ports aren't much better....

Also any code using ioperm or iopl is Linux only.   Must always be kept in mind that it is such.

I was under the impression that BSD also have a iopl call, but it
seems that I am wrong...

[oiaohm]

NT drivers can still expect iopl permissions at times to be alter on applications so allowing the same thing under Linux we use iopl for. http://www.beyondlogic.org/porttalk/porttalk.htm Yes this is a open source version of the NT style driver to hack the permission.

Never underestimate windows coders means to hack the OS. Yes it has the same nightmare risks for Windows as it has for Linux.

ioperm should only be enabled on the applications that really require it. And only where it should be enabled.

Basically we are in the world of hell here. Gert van den Berg No matter what way we go there are going to be some big scary risks.