MacPorts version can't run 16-bit programs

Archaemic · Post by **Archaemic** » Sat Jun 20, 2009 3:13 pm

Whenever I try to run a 16-bit application with the version of Wine that built out of MacPorts, I get a crash similar to this one:

Code: Select all

wine: Unhandled page fault on read access to 0xffffffff at address 0x1017:0x0000093e (thread 0026), starting debugger...
couldn't load main module (2)
Unhandled exception: page fault on read access to 0xffffffff in 32-bit code (1017:0000093e).
fixme:dbghelp:addr_to_linear Failed to linearize address 8714:00006f03 (mode 0)
In 32 bit mode.
Register dump:
 CS:1017 SS:1487 DS:1487 ES:1527 FS:11ff GS:0037
 EIP:0000093e ESP:0000f262 EBP:0000f278 EFLAGS:00010286(  R- --  I S - -P- )
 EAX:152700b4 EBX:000000ae ECX:00001527 EDX:148700b4
 ESI:00000000 EDI:00001486
Stack dump:
0x1487:0xf262:  0ca5 c770 7b83 f278 1a88 120f 0018 0000
0x1487:0xf272:  0040 1486 0000 f299 1b43 120f 0018 1486
0x1487:0xf282:  0000 1e54 120f 1486 0000 00b4 1527 1487
023f: sel=11ff base=7eed0000 limit=00000fff 32-bit rw-
Backtrace:
=>0 0x1017:0x0000093e (0x1487:0xf278)
  1 0x120f:0x1b43 (0x1487:0xf298)
  2 0x8714:0x6f03 (0x1487:0x0000)
0x1017:0x0000093e: addb	%al,0x0(%eax)
Modules:
Module	Address			Debug info	Name (13 modules)
PE	60190000-60194000	Deferred        advapi32
PE	60310000-60325000	Deferred        user32
PE	60480000-60484000	Deferred        gdi32
PE	61e90000-61ee1000	Deferred        winmm
PE	621b0000-6221f000	Deferred        comdlg32
PE	62270000-62360000	Deferred        shell32
PE	62430000-62437000	Deferred        shlwapi
PE	624a0000-624b3000	Deferred        comctl32
PE	62590000-62596000	Deferred        winspool
PE	62750000-62754000	Deferred        ole32
PE	62880000-62884000	Deferred        rpcrt4
PE	7b810000-7b89e000	Deferred        kernel32
PE	7bc10000-7bc14000	Deferred        ntdll
Threads:
process  tid      prio (all id:s are in hex)
0000000c 
	00000014    0
	00000013    0
	00000012    0
	0000000e    0
	0000000d    0
0000000f 
	00000016    0
	00000015    0
	00000011    0
	00000010    0
00000018 
	00000019    0
00000023 (D) C:\windows\system32\winevdm.exe
	00000026    0 <==
	00000025    0
	00000024    0
Backtrace:
=>0 0x1017:0x0000093e (0x1487:0xf278)
  1 0x120f:0x1b43 (0x1487:0xf298)
  2 0x8714:0x6f03 (0x1487:0x0000)
err:ntdll:RtlpWaitForCriticalSection section 0x7b940910 "syslevel.c: Win16Mutex" wait timed out in thread 0024, blocked by 0026, retrying (60 sec)

(This one is from trying to run SimTower)

This has been happening for many versions, and I believe I have the latest version, still (at least the latest MacPorts version). This doesn't happen when I run the same applications with a precompiled binary on Linux.

I would file a bug report, but I have a suspicion that this is just a bad compile, as I've seen reports of 16-bit applications working on Macs that aren't MacPorts.

Anyone have any insight? I've asked the IRC channel a few times, but no one there seemed to know.

James McKenzie · Post by **James McKenzie** » Sun Jun 21, 2009 1:10 pm

Archaemic wrote:

Whenever I try to run a 16-bit application with the version of Wine that built out of MacPorts, I get a crash similar to this one:

Code:
wine: Unhandled page fault on read access to 0xffffffff at address 0x1017:0x0000093e (thread 0026), starting debugger...
couldn't load main module (2)
Unhandled exception: page fault on read access to 0xffffffff in 32-bit code (1017:0000093e).
fixme:dbghelp:addr_to_linear Failed to linearize address 8714:00006f03 (mode 0)
In 32 bit mode.
Register dump:
CS:1017 SS:1487 DS:1487 ES:1527 FS:11ff GS:0037
EIP:0000093e ESP:0000f262 EBP:0000f278 EFLAGS:00010286( R- -- I S - -P- )
EAX:152700b4 EBX:000000ae ECX:00001527 EDX:148700b4
ESI:00000000 EDI:00001486
Stack dump:
0x1487:0xf262: 0ca5 c770 7b83 f278 1a88 120f 0018 0000
0x1487:0xf272: 0040 1486 0000 f299 1b43 120f 0018 1486
0x1487:0xf282: 0000 1e54 120f 1486 0000 00b4 1527 1487
023f: sel=11ff base=7eed0000 limit=00000fff 32-bit rw-
Backtrace:
=>0 0x1017:0x0000093e (0x1487:0xf278)
1 0x120f:0x1b43 (0x1487:0xf298)
2 0x8714:0x6f03 (0x1487:0x0000)
0x1017:0x0000093e: addb %al,0x0(%eax)
Modules:
Module Address Debug info Name (13 modules)
PE 60190000-60194000 Deferred advapi32
PE 60310000-60325000 Deferred user32
PE 60480000-60484000 Deferred gdi32
PE 61e90000-61ee1000 Deferred winmm
PE 621b0000-6221f000 Deferred comdlg32
PE 62270000-62360000 Deferred shell32
PE 62430000-62437000 Deferred shlwapi
PE 624a0000-624b3000 Deferred comctl32
PE 62590000-62596000 Deferred winspool
PE 62750000-62754000 Deferred ole32
PE 62880000-62884000 Deferred rpcrt4
PE 7b810000-7b89e000 Deferred kernel32
PE 7bc10000-7bc14000 Deferred ntdll
Threads:
process tid prio (all id:s are in hex)
0000000c
00000014 0
00000013 0
00000012 0
0000000e 0
0000000d 0
0000000f
00000016 0
00000015 0
00000011 0
00000010 0
00000018
00000019 0
00000023 (D) C:\windows\system32\winevdm.exe
00000026 0 <==
00000025 0
00000024 0
Backtrace:
=>0 0x1017:0x0000093e (0x1487:0xf278)
1 0x120f:0x1b43 (0x1487:0xf298)
2 0x8714:0x6f03 (0x1487:0x0000)
err:ntdll:RtlpWaitForCriticalSection section 0x7b940910 "syslevel.c: Win16Mutex" wait timed out in thread 0024, blocked by 0026, retrying (60 sec)

(This one is from trying to run SimTower)

This has been happening for many versions, and I believe I have the latest version, still (at least the latest MacPorts version). This doesn't happen when I run the same applications with a precompiled binary on Linux.

I would file a bug report, but I have a suspicion that this is just a bad compile, as I've seen reports of 16-bit applications working on Macs that aren't MacPorts.

Anyone have any insight? I've asked the IRC channel a few times, but no one there seemed to know.

No, but I have the same problem trying to run a Win 16 program. I will
create a bug report and post the issue number here so that folks can
vote on it and add applications to the list.

One item, that is the program uses .Net1.1 as well and I was wondering
about the Win16 Mutex error.

James McKenzie

Archaemic · Post by **Archaemic** » Sun Jun 21, 2009 3:04 pm

I managed to dig up this old bug with basically the same symptoms:
http://bugs.winehq.org/show_bug.cgi?id=14920

I think this might be our culprit.

Alexandre Julliard · Post by **Alexandre Julliard** » Sun Jun 21, 2009 4:05 pm

"Archaemic" <[email protected]> writes:

This has been happening for many versions, and I believe I have the latest version, still (at least the latest MacPorts version). This doesn't happen when I run the same applications with a precompiled binary on Linux.

I would file a bug report, but I have a suspicion that this is just a bad compile, as I've seen reports of 16-bit applications working on Macs that aren't MacPorts.

Anyone have any insight? I've asked the IRC channel a few times, but no one there seemed to know.

Xcode 3 is broken and miscompiles the 16-bit code. You have to use Xcode
2.5 to build it.

--
Alexandre Julliard
[email protected]

austin987 · Post by **austin987** » Sun Jun 21, 2009 9:19 pm

On Sun, Jun 21, 2009 at 4:05 PM, Alexandre Julliard<[email protected]> wrote:

"Archaemic" <[email protected]> writes:

This has been happening for many versions, and I believe I have the latest version, still (at least the latest MacPorts version). This doesn't happen when I run the same applications with a precompiled binary on Linux.

I would file a bug report, but I have a suspicion that this is just a bad compile, as I've seen reports of 16-bit applications working on Macs that aren't MacPorts.

Anyone have any insight? I've asked the IRC channel a few times, but no one there seemed to know.
Xcode 3 is broken and miscompiles the 16-bit code. You have to use Xcode
2.5 to build it.

Could we add a configure check, or have some way of building a test
win16 program to make sure it builds properly?

--
-Austin

Archaemic · Post by **Archaemic** » Mon Jun 22, 2009 1:56 am

Although Xcode 2.5 says it's compatible with 10.5, I downloaded it and it only had a toolchain for Darwin 8, which is not the kernel I have, so I can't link anything :/

I also tried a MacPorts version of gcc 4.4.0, but the same problem as with Xcode 3's 4.0.1.

I ended up downloading an unofficial build of 1.1.21, which actually worked great.