On Wed, 12 Oct 2005 21:16:05 +0000, Eddahbi Karim wrote:
Now the mouse problem comes back but the workarounds don't work this time. It's not a regression, it's a bug enhancement.
The old workaround for WineX still work according to gentoo-forums [2].
It seems Warcraft relies upon NULL-addressed VirtualAlloc starting allocation from above a certain range - possibly they're pulling some silly bit-twiddling hack or optimisation. The Cedega patch linked to on the forums basically hints to mmap that it should allocate at a fixed address in this case:
http://lists.transgaming.org/pipermail/winex-devel/2004-May/000259.html
Which for WoW they seem to set this hint to 256mb - is there some aspect of the NT kernel we're not correctly implementing here? Does Windows always allocate from 256mb upwards?
Alexandre, Mike - does hinting to mmap in the port library as TransGaming do it seem like a good solution here or would it be better to adapt the preloader to block off the lowest $X megs?
thanks -mike
Mike Hearn schrieb:
On Wed, 12 Oct 2005 21:16:05 +0000, Eddahbi Karim wrote:
Now the mouse problem comes back but the workarounds don't work this time. It's not a regression, it's a bug enhancement.
ACK
The old workaround for WineX still work according to gentoo-forums [2].
It seems Warcraft relies upon NULL-addressed VirtualAlloc starting allocation from above a certain range - possibly they're pulling some silly bit-twiddling hack or optimisation. The Cedega patch linked to on the forums basically hints to mmap that it should allocate at a fixed address in this case:
http://lists.transgaming.org/pipermail/winex-devel/2004-May/000259.html
I tried that logic with the mmap wrapper but that did not help ... with and without printf. I'm just wondering of this code because start address must be a multiple of pagesize. WoW allocs sometimes less ... like 2 or 178 bytes.
Which for WoW they seem to set this hint to 256mb - is there some aspect of the NT kernel we're not correctly implementing here? Does Windows always allocate from 256mb upwards?
Alexandre, Mike - does hinting to mmap in the port library as TransGaming do it seem like a good solution here or would it be better to adapt the preloader to block off the lowest $X megs?
I'm away for a week so I dont have time to hack and test this into wine ... and I have no time for gaming either :-/
chris
thanks -mike
Mike Hearn schrieb:
On Wed, 12 Oct 2005 21:16:05 +0000, Eddahbi Karim wrote:
Now the mouse problem comes back but the workarounds don't work this time. It's not a regression, it's a bug enhancement.
ACK
The old workaround for WineX still work according to gentoo-forums [2].
It seems Warcraft relies upon NULL-addressed VirtualAlloc starting allocation from above a certain range - possibly they're pulling some silly bit-twiddling hack or optimisation. The Cedega patch linked to on the forums basically hints to mmap that it should allocate at a fixed address in this case:
http://lists.transgaming.org/pipermail/winex-devel/2004-May/000259.html
I tried that logic with the mmap wrapper but that did not help ... with and without printf. I'm just wondering of this code because start address must be a multiple of pagesize. WoW allocs sometimes less ... like 2 or 178 bytes.
Which for WoW they seem to set this hint to 256mb - is there some aspect of the NT kernel we're not correctly implementing here? Does Windows always allocate from 256mb upwards?
Alexandre, Mike - does hinting to mmap in the port library as TransGaming do it seem like a good solution here or would it be better to adapt the preloader to block off the lowest $X megs?
I'm away for a week so I dont have time to hack and test this into wine ... and I have no time for gaming either :-/
chris
thanks -mike
Hi
http://lists.transgaming.org/pipermail/winex-devel/2004-May/000259.html
Good news. This is working in wine too, with some modifications. I must set FIXED flag so I really get the desired addresses.
With the attached patch WoW is working for me, clicks on the playfield are now ok!
This patch is not for production, only for playing, delete the MESSAGE lines. This time a printf is no more necessary to hack around ;)
TODO make an AppDefault option ... I'm away now.
chris
WoW really seems to relay on this magic address.
Here are some lines of the output:
wine WoW.exe -opengl nil mmap 0x81000000, 1056833536, 0, 16418, -1 = 0x3cf20000 nil mmap 0x81000000, 528416768, 0, 16418, -1 = 0x81000000 nil mmap 0xa07f0000, 528416768, 0, 16418, -1 = 0x5c710000 nil mmap 0xa07f0000, 264175616, 0, 16418, -1 = 0xa07f0000 nil mmap 0xb03e0000, 264241152, 0, 16418, -1 = 0x6c300000 nil mmap 0xb03e0000, 132120576, 0, 16418, -1 = 0x74100000 ... nil mmap 0xb81e0000, 132120576, 0, 16418, -1 = 0xb81e0000 set mmap 0x10000000, 16384, 3, 50, -1 = 0x10000000 set mmap 0x10004000, 1179648, 0, 50, -1 = 0x10004000 nil mmap 0x7bea0000, 4096, 3, 50, -1 = 0x7bea0000 nil mmap 0x7bc80000, 4096, 3, 50, -1 = 0x7bc80000 trace:loaddll:load_builtin_dll Loaded module L"kernel32.dll" : builtin set mmap 0x10124000, 73728, 3, 50, -1 = 0x10124000 trace:process:init_current_directory starting in L"E:\World of Warcraft\" 0x18 trace:process:find_exe_file looking for L"WoW.exe" trace:process:find_exe_file Trying built-in exe L"E:\World of Warcraft\WoW.exe" trace:process:find_exe_file Trying native exe L"E:\World of Warcraft\WoW.exe" trace:process:__wine_kernel_init starting process name=L"E:\World of Warcraft\WoW.exe" file=0x1c argv[0]="WoW.exe" trace:process:__wine_kernel_init starting Win32 binary L"E:\World of Warcraft\WoW.exe" nil mmap 0x400000, 8855552, 7, 50, -1 = 0x400000 set mmap 0x10136000, 1114112, 3, 50, -1 = 0x10136000 ....
and while the game is running:
nil mmap 0x1a577000, 4096, 0, 50, -1 = 0x1a577000 nil mmap 0x1a576000, 4096, 0, 50, -1 = 0x1a576000 nil mmap 0x1a575000, 0, 0, 50, -1 = 0x1a575000 nil mmap 0x123d5000, 4096, 0, 50, -1 = 0x123d5000 nil mmap 0x123d5000, 0, 0, 50, -1 = 0x123d5000 nil mmap 0x122fb000, 4096, 0, 50, -1 = 0x122fb000 nil mmap 0x122fb000, 0, 0, 50, -1 = 0x122fb000 nil mmap 0x1a5ab000, 4096, 0, 50, -1 = 0x1a5ab000 nil mmap 0x1a5ab000, 0, 0, 50, -1 = 0x1a5ab000 nil mmap 0x1a5d5000, 4096, 0, 50, -1 = 0x1a5d5000 nil mmap 0x1a5d6000, 4096, 0, 50, -1 = 0x1a5d6000 nil mmap 0x1a5d5000, 0, 0, 50, -1 = 0x1a5d5000 nil mmap 0x19fff000, 4096, 0, 50, -1 = 0x19fff000 nil mmap 0x19ffe000, 4096, 0, 50, -1 = 0x19ffe000 nil mmap 0x19ffc000, 4096, 0, 50, -1 = 0x19ffc000 nil mmap 0x19ff9000, 0, 0, 50, -1 = 0x19ff9000 nil mmap 0x1233b000, 4096, 0, 50, -1 = 0x1233b000 nil mmap 0x1233b000, 0, 0, 50, -1 = 0x1233b000 nil mmap 0x12339000, 4096, 0, 50, -1 = 0x12339000 nil mmap 0x1233a000, 4096, 0, 50, -1 = 0x1233a000 nil mmap 0x1233c000, 4096, 0, 50, -1 = 0x1233c000
no more calls with start=NULL
Christoph <cr2005 <at> u-club.de> writes:
Hi
http://lists.transgaming.org/pipermail/winex-devel/2004-May/000259.html
With the attached patch WoW is working for me, clicks on the playfield are now ok!
I used a derived work [1] of your patches and it worked for me but not for others.
The patch I tested seems to make wineserver eats a lot of memory in some implementations.
chris
Thanks for the work you've done and for digging in the transgaming mailing lists.
[1] http://forums.gentoo.org/viewtopic-p-2800297.html
On Fri, 14 Oct 2005 19:02:02 +0200, Christoph wrote:
WoW really seems to relay on this magic address.
And yet it works in Windows which presumably does not have any WoW specific appgoo in it. So I imagine it's actually some weird quick of the NT kernel we're not emulating correctly here, but Alexandre is the true man to ask.
Mike Hearn schrieb:
On Fri, 14 Oct 2005 19:02:02 +0200, Christoph wrote:
WoW really seems to relay on this magic address.
And yet it works in Windows which presumably does not have any WoW specific appgoo in it. So I imagine it's actually some weird quick of the NT kernel we're not emulating correctly here, but Alexandre is the true man to ask.
I tested my patch yesterday for about 4 hours and I only had one crash. Game freezed. Got lock in ntdll, no run out of memory!
Here is maybe a clue. Can anyone outline the role of imm32.dll and if it can be involved in our problem?
I looked at the output, and this catched my eye. Here I started WoW without any wine hacks, just with my dropped MESSAGE lines, so with mouse click problem :
trace:loaddll:load_builtin_dll Loaded module L"C:\windows\system\opengl32.dll" : builtin EXE not mmap 0xbfe20000, 16384, 7, 50, -1 = 0xbfe20000 trace:loaddll:load_native_dll Loaded module L"C:\windows\system\IMM32.dll" : native EXE not mmap 0x10000000, 430080, 7, 50, -1 = 0x10000000 trace:loaddll:load_native_dll Loaded module L"E:\World of Warcraft\DivxDecoder.dll" : native not mmap 0x7ff90000, 4096, 3, 50, -1 = 0x7ff90000 trace:loaddll:load_builtin_dll Loaded module L"C:\windows\system\winmm.dll" : builtin EXE set mmap (nil), 655360, 7, 34, -1 = 0x7fedd000
imm32 is the only one loaded in 0x1xxxxxxx. I tried buildin and native version, no difference. later, WoW uses adresses like this:
not mmap 0x7d601000, 32768, 0, 50, -1 = 0x7d601000 not mmap 0x79b20000, 4096, 0, 50, -1 = 0x79b20000 not mmap 0x79921000, 1048576, 0, 50, -1 = 0x79921000 not mmap 0x6249d000, 4096, 0, 50, -1 = 0x6249d000 not mmap 0x7d641000, 212992, 0, 50, -1 = 0x7d641000 ...
mouse clicks do not work.
Here with my patch, mouse working
trace:loaddll:load_builtin_dll Loaded module L"C:\windows\system\opengl32.dll" : builtin not mmap 0xbfe20000, 16384, 7, 50, -1 = 0xbfe20000 trace:loaddll:load_native_dll Loaded module L"C:\windows\system\IMM32.dll" : native set mmap 0x10246000, 495616, 7, 50, -1 = 0x10246000 trace:loaddll:load_native_dll Loaded module L"E:\World of Warcraft\DivxDecoder.dll" : native not mmap 0x7ff90000, 4096, 3, 50, -1 = 0x7ff90000 trace:loaddll:load_builtin_dll Loaded module L"C:\windows\system\winmm.dll" : builtin set mmap 0x102bf000, 655360, 7, 50, -1 = 0x102bf000 not mmap 0x7ff60000, 4096, 3, 50, -1 = 0x7ff60000
and later game running:
not mmap 0x107c5000, 0, 0, 50, -1 = 0x107c5000 not mmap 0x1074d000, 4096, 0, 50, -1 = 0x1074d000 not mmap 0x1074e000, 4096, 0, 50, -1 = 0x1074e000 not mmap 0x1074c000, 4096, 0, 50, -1 = 0x1074c000 not mmap 0x10749000, 0, 0, 50, -1 = 0x10749000 not mmap 0x122ed000, 4096, 0, 50, -1 = 0x122ed000 not mmap 0x122ee000, 4096, 0, 50, -1 = 0x122ee000 not mmap 0x122ec000, 4096, 0, 50, -1 = 0x122ec000 not mmap 0x122e9000, 0, 0, 50, -1 = 0x122e9000 not mmap 0x107bf000, 4096, 0, 50, -1 = 0x107bf000 not mmap 0x107be000, 4096, 0, 50, -1 = 0x107be000 ...
just for fun I tested with 0x20000000. imm32.dll still at 0x10000000, wow uses 0x2xxxxxxx, mouse working.
0x30000000 works either, all other segfault or game starts but crash while entering the world.
chris
Mike Hearn <mh <at> codeweavers.com> writes:
On Wed, 12 Oct 2005 21:16:05 +0000, Eddahbi Karim wrote:
Now the mouse problem comes back but the workarounds don't work this time. It's not a regression, it's a bug enhancement.
The old workaround for WineX still work according to gentoo-forums [2].
It seems Warcraft relies upon NULL-addressed VirtualAlloc starting allocation from above a certain range - possibly they're pulling some silly bit-twiddling hack or optimisation. The Cedega patch linked to on the forums basically hints to mmap that it should allocate at a fixed address in this case:
http://lists.transgaming.org/pipermail/winex-devel/2004-May/000259.html
Which for WoW they seem to set this hint to 256mb - is there some aspect of the NT kernel we're not correctly implementing here? Does Windows always allocate from 256mb upwards?
The weird thing here, IMHO, is that the old workaround like switching to 2.6.12 kernels (which did the trick for me), using some "hacked" preloaders (which didn't do the trick for me) and all [1] don't work this time.
Only the Cedega fix *seems* to work (According to *one* post on the gentoo forum [2])
If you want some debugging informations, just give me the way to look for them and I'll give them.
thanks -mike
---------------------------------------------------------------------- Notes :
[1] http://forums.gentoo.org/viewtopic-t-390127.html [2] http://forums.gentoo.org/viewtopic-p-2794128.html#2794128
-
Christoph -
Christoph Rudorff -
Eddahbi Karim -
Mike Hearn