http://bugs.winehq.org/show_bug.cgi?id=34095
Bug #: 34095 Summary: GOG Imperialism does not run in Wine 1.6 / OSX Product: Wine Version: 1.6 Platform: x86 OS/Version: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-dplay AssignedTo: wine-bugs@winehq.org ReportedBy: alexei.svitkine@gmail.com Classification: Unclassified
Imperialism from GOG (http://www.gog.com/gamecard/imperialism) is broken in Wine 1.6 on OSX from MacPorts. It used to work in 1.5.
It fails with the following short log:
err:dplay:DPLAYX_ConstructData : unable to map static data into process memory space (487) err:module:attach_process_dlls "dplayx.dll" failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for L"C:\GOG Games\Imperialism\Imperialism.exe" failed, status c0000142
Attached is a more verbosed log via "WINEDEBUG=+relay,+seh,+tid wine Imperialism.exe &> log.txt".
http://bugs.winehq.org/show_bug.cgi?id=34095
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
--- Comment #1 from Austin English austinenglish@gmail.com 2013-07-19 18:36:54 CDT --- Please run a regression test.
http://bugs.winehq.org/show_bug.cgi?id=34095
--- Comment #2 from Bruno Jesus 00cpxxx@gmail.com 2013-07-21 08:14:02 CDT --- Does "winetricks directplay" solves the issue?
http://bugs.winehq.org/show_bug.cgi?id=34095
alexei.svitkine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |julliard@winehq.org
--- Comment #3 from alexei.svitkine@gmail.com 2013-07-21 09:59:10 CDT --- Did a regression test:
2f48b12c575c4e1afc6115a39d60722acda73d7d is the first bad commit commit 2f48b12c575c4e1afc6115a39d60722acda73d7d Author: Alexandre Julliard julliard@winehq.org Date: Tue Apr 2 12:22:17 2013 +0200
gdi32: Use the Mac driver by default.
:040000 040000 e10b7a4d18cbf2ec65d103ec4139a08c62806385 bcd658b0fa5d8dd00c630c4e1b3ef268427b8432 M dlls
http://bugs.winehq.org/show_bug.cgi?id=34095
--- Comment #4 from alexei.svitkine@gmail.com 2013-07-21 10:09:13 CDT --- It looks like dlls/dplayx/dplayx_global.c tries to map some data at 0x50000000 in memory.
My guess is that using the mac driver changes what's loaded in the address space such that by the time that code runs, that memory loc is taken by something else.
I guess the question is whether the data needs to be at 0x50000000 (i.e. is that what happens under Windows and do programs use hardcoded offsets into that data), or can we change that address to pick a location that's free?
If it does need to be at 0x50000000, then during the wine init sequence, it should probably reserve that space early on so that other stuff can't be loaded there and then use the reserved space by the time dxplay needs to be loaded.
http://bugs.winehq.org/show_bug.cgi?id=34095
--- Comment #5 from alexei.svitkine@gmail.com 2013-07-21 10:34:52 CDT --- Indeed, something is mapped at that address:
455a5000-54f55000 255680K rw-/rw- NONE - DEFAULT uwir=0 sub=0
There's a comment in the file that says the magic 0x50000000 is needed because there are pointers to that block and the code doesn't do relocating yet:
/* Presently the shared data structures use pointers. If the * files are not mapped into the same area, the pointers will no * longer make any sense :( * FIXME: In the future make the shared data structures have some * sort of fixup to make them independent between data spaces. * This will also require a rework of the session data stuff. */
Unless someone implements the above, it sounds to me like the simplest solution is to reserve that space early during startup, so that other stuff can't take it.
http://bugs.winehq.org/show_bug.cgi?id=34095
--- Comment #6 from alexei.svitkine@gmail.com 2013-07-21 11:00:42 CDT --- I tried out my proposal of reserving the region in question during the startup sequence and it seems to work.
I surrounded the code in get_display_driver() in dlls/gdi32/driver.c with the following two functions:
LPVOID mem = VirtualAlloc((LPVOID)0x50000000, 1024 * 1024, MEM_RESERVE, PAGE_NOACCESS);
/* get_display_driver() code... */
VirtualFree(mem, 0, MEM_RELEASE);
This seems to fix the issue.
http://bugs.winehq.org/show_bug.cgi?id=34095
--- Comment #7 from alexei.svitkine@gmail.com 2013-07-21 11:05:05 CDT --- (get_display_driver() is named DRIVER_load_driver on TOT)
http://bugs.winehq.org/show_bug.cgi?id=34095
--- Comment #8 from alexei.svitkine@gmail.com 2013-07-21 11:06:10 CDT --- (oops, ignore my last comment - that's not true..)
http://bugs.winehq.org/show_bug.cgi?id=34095
--- Comment #9 from alexei.svitkine@gmail.com 2013-07-21 11:23:57 CDT --- Created attachment 45350 --> http://bugs.winehq.org/attachment.cgi?id=45350 Patch that fixes the issue
http://bugs.winehq.org/show_bug.cgi?id=34095
Ralph crumby@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |crumby@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=34095
--- Comment #10 from alexei.svitkine@gmail.com 2013-07-22 21:46:22 CDT --- Sent the patch to wine-devel.
http://bugs.winehq.org/show_bug.cgi?id=34095
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |2f48b12c575c4e1afc6115a39d6 | |0722acda73d7d
http://bugs.winehq.org/show_bug.cgi?id=34095
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1|2f48b12c575c4e1afc6115a39d6 | |0722acda73d7d |
https://bugs.winehq.org/show_bug.cgi?id=34095
hanska2@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hanska2@luukku.com
--- Comment #11 from hanska2@luukku.com --- What happened to the patch?
https://bugs.winehq.org/show_bug.cgi?id=34095
alexei.svitkine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bunglehead@gmail.com
--- Comment #12 from alexei.svitkine@gmail.com --- Wine team weren't keen on it, so the bug remains unfixed. Here's the thread on wine-devel:
https://www.winehq.org/pipermail/wine-devel/2013-August/100683.html
https://bugs.winehq.org/show_bug.cgi?id=34095
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |leslie_alistair@hotmail.com Ever confirmed|0 |1
--- Comment #13 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- The issue is caused by the address used in function DPLAYX_ConstructData found in file dplayx_global.c. LPVOID lpDesiredMemoryMapStart = (LPVOID)0x50000000;
No sure on the exactly solution but this is where I would start looking.
https://bugs.winehq.org/show_bug.cgi?id=34095
--- Comment #14 from Ken Thomases ken@codeweavers.com --- The problem is not really specific to the Mac driver. It does seem that loading the Mac driver makes it much more likely that the particular address range is used for something before dplay tries to use it, there's no guarantee either way.
It's possible that one could use the Mac driver and it would happen to not use that address range.
It's also possible that one could use the X11 driver and it would happen to use that address range, resulting in the same problem. This could happen on Linux as well as OS X.
It's somewhat random. Any given build of Wine or the system libraries and frameworks could change it.
The only real fix would be to change dplay to not require a specific address range.
https://bugs.winehq.org/show_bug.cgi?id=34095
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |2f48b12c575c4e1afc6115a39d6 | |0722acda73d7d
https://bugs.winehq.org/show_bug.cgi?id=34095
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |imwellcushtymelike@gmail.co | |m Regression SHA1|2f48b12c575c4e1afc6115a39d6 | |0722acda73d7d |
--- Comment #15 from Matteo Bruni matteo.mystral@gmail.com --- Ken, you already added that regression commit in July 2013 and Alexandre dropped it since it's not really a regression. Please don't do that over and over again...
https://bugs.winehq.org/show_bug.cgi?id=34095
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|bunglehead@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=34095
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|regression | CC|imwellcushtymelike@gmail.co | |m |
--- Comment #16 from Ken Sharp imwellcushtymelike@gmail.com --- Remove the keyword then!
https://bugs.winehq.org/show_bug.cgi?id=34095
--- Comment #17 from alexei.svitkine@gmail.com --- Also, given that it doesn't look like anyone is going to fix the dplayx code any time soon, I don't see why you can't just land the proposed patch in the mean time.
It safely guards the needed address space for dplayx during initialization, so that when dplayx is initialized it can get access to that region of memory.
I understand that ideally dplayx should be fixed to not require a fixed address, but I don't see the harm in landing the work around for now to unbreak the games that use dplayx until such a point in time that the dplayx code can be re-worked.
https://bugs.winehq.org/show_bug.cgi?id=34095
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man@post.com
https://bugs.winehq.org/show_bug.cgi?id=34095
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #18 from winetest@luukku.com --- The patch doesn't apply against wine 2.0 at all.
-
wine-bugs＠winehq.org