wine users - Feb 2010 - Want to use Digital Oszilloscope DSO-2100 at parport LPT1

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:
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!?

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

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

On Tue, Feb 2, 2010 at 12:27, lsmod <wineforum-user at winehq.org>
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

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?

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?

On Wed, Feb 3, 2010 at 19:28, lsmod <wineforum-user at winehq.org>
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;
}

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 */
}

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:
/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:
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 ?

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.

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

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.