Hi,
I recently tried to run the MS-Windows WWII strategy game "Hearts of Iron" using Wine on Linux. And it *very nearly* works. In fact, it's so close I'm trying to debug the problem in the hope of getting it working. I hope that someone here can give me a few wine debugging tips.
Actually, the game runs perfectly - absolutely "gold" standard. I gave it a 5-hour "stress test" ;-) and did not experience a single problem. There are some minor problems on startup, but there are reasonable workarounds for those.
The problem, though, is that saved games cannot be loaded. Unfortunately, this is a show-stopper as a game of HoI typically takes several days to play! Fortunately the problem is 100% repeatable.
FYI: I'm running Debian Sarge on x86, no native windows partition. I first tried the latest debian wine package, and then rebuilt from CVS HEAD code of Fri 13 August (possibly a bad day to choose :-). Exactly the same behaviour occurred.
Info on the game can be found here: http://www.heartsofiron-game.com/. It's a WWII strategy game with pleasant but not intensive graphics.
When running "wine HoI.exe" and trying to load a saved game, a message is output: wine: Unhandled exception (thread 0009), starting debugger.. Usage: winedbg [--auto] [--gdb] comdline There is then no response to the keyboard; no debugger prompt or anything. Is this meant to start a debugger interactive session here, or am I supposed to somehow start a debugger and point it at the wine process? If so, info on how to do so would be appreciated.
I ran "winedbg HoI.exe" and got exactly the same behaviour, though with a bit more info: <output> First chance exception: page fault on read access to 0x00000006 in 32-bit code (0x004191fb). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:004191fb ESP:406bf4ec EBP:406bfe94 EFLAGS:00210206( - 00 - RIP1) EAX:48258e60 EBX:00000000 ECX:00000000 EDX:007e5f44 ESI:418736c0 EDI:45ae16e3 Stack dump: 0x00000000: 00000000 00000000 00000000 00000000 0x00000010: 00000000 00000000 00000000 00000000 0x00000020: 00000000 00000000 00000000 00000000 0x00000030: 00000000 00000000 00000000 00000000 0x00000040: 00000000 00000000 00000000 00000000 0x00000050: 00000000 00000000 00000000 00000000 0x00000060:
Backtrace: =>1 0x004191fb (0x406bfe94) 2 0x005af5b2 (0x406bff20) 3 0x404ff9f2 start_process+0xf2(arg=0x0) [process.c:995] in kernel32 (0x406bfff4) 4 0x4002c151 wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000) 0x004191fb: movl 0x6(%ecx),%ecx Wine-dbg> </output>
Qn: is there any way of getting function names in that backtrace rather than just addresses? I've tried "CFLAGS=-g ./configure" when rebuilding wine, but haven't had time to test the resulting wine binaries.
And then is there a way to step through at the source rather than assembly level?
It's apparent here that %ecx is null when not expected to be, resulting in a bad access to memory address 0x00000006.
I also tried the "WINEDEBUG=+relay" option as recommended in the wine docs. However after leaving the program running overnight, and having generated 3 gigabytes of log output, the point where the bug occurs hadn't been reached. I think that what's happening is that there is a thread (0011) which is driven by timer ticks [probably doing GUI or sound stuff], and that because HoI is running much more slowly under +relay, that the thread doing the load-game work (0009) isn't actually getting any CPU time at all. NB: the log was only 3GB because I used grep to discard output about RtlEnterCriticalSection and RtlLeaveCriticalSection. Without that, the log would be closer to 30GB!
Any suggestions on how to make progress on this issue are welcome. Pointers to documentation on debugging this sort of thing are very welcome.
By the way, I'm an experienced c/c++ developer on unix/linux, but know very little about Windows programming (and frankly would prefer to leave it that way :-). It's been a while since I've used gdb and friends, but can brush up on that if it's useful.
Cheers,
Simon
PS: Congrats to the Wine team. I was most impressed how well HoI ran on wine.