Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back

Mike Hearn-2
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



Reply | Threaded
Open this post in threaded view
|

Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back

Christoph Rudorff


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


Reply | Threaded
Open this post in threaded view
|

Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back

Christoph-2
In reply to this post by Mike Hearn-2


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



Reply | Threaded
Open this post in threaded view
|

Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back

thetemplar
In reply to this post by Mike Hearn-2
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

--
Eddahbi Karim <[hidden email]>
Freelance




Reply | Threaded
Open this post in threaded view
|

Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back

Christoph-2
In reply to this post by Christoph-2
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




Index: mmap.c
===================================================================
RCS file: /home/wine/wine/libs/wine/mmap.c,v
retrieving revision 1.10
diff -u -3 -p -r1.10 mmap.c
--- mmap.c 20 Jun 2005 11:43:47 -0000 1.10
+++ mmap.c 14 Oct 2005 16:40:53 -0000
@@ -58,6 +58,31 @@ static const int granularity_mask = 0xff
 static inline int munmap( void *ptr, size_t size ) { return 0; }
 #endif
 
+/* This function returns the address that mmap should use for any
+ * allocation where start is passed as NULL. */
+void *__memory_layout_override = NULL;
+static void *get_anon_mmap_null_address(size_t size)
+{
+    static int got_override = 0;
+    static void *low_alloc_ptr = NULL;
+    void * current_low_alloc_ptr;
+
+    if (!got_override)
+    {
+        //if (__memory_layout_override)
+ {
+            low_alloc_ptr = (void *)0x10000000;
+            got_override = 1;
+        }
+    }
+
+    current_low_alloc_ptr = low_alloc_ptr;
+
+    if (low_alloc_ptr)
+        low_alloc_ptr += size;
+    
+    return current_low_alloc_ptr;
+}
 
 #if (defined(__svr4__) || defined(__NetBSD__)) && !defined(MAP_TRYFIXED)
 /***********************************************************************
@@ -209,13 +234,27 @@ void *wine_anon_mmap( void *start, size_
             return start;
 #endif
     }
-    return mmap( start, size, prot, flags, fdzero, 0 );
+#include <wine/debug.h>
+WINE_DEFAULT_DEBUG_CHANNEL(module);
+    if ((start == NULL) && !(flags & MAP_FIXED)) {
+       MESSAGE("set ");
+       flags |= MAP_FIXED;
+       start = get_anon_mmap_null_address(size);
+    } else {
+       MESSAGE("nil ");
+    }
+    void *result = mmap( start, size, prot, flags, fdzero, 0 );
+
+MESSAGE("mmap %p, %i, %i, %i, %i = %p \n", \
+        start, size, prot , \
+        flags, fdzero, result);
+
+    return result;
 #else
     return (void *)-1;
 #endif
 }
 
-
 #ifdef HAVE_MMAP
 
 /***********************************************************************



Reply | Threaded
Open this post in threaded view
|

Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back

thetemplar
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

--
Eddahbi Karim
Freelance



Reply | Threaded
Open this post in threaded view
|

Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back

Mike Hearn-2
In reply to this post by Christoph-2
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.



Reply | Threaded
Open this post in threaded view
|

Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back

Christoph-2
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


Reply | Threaded
Open this post in threaded view
|

Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back

Jesse Allen
On 10/15/05, Christoph <[hidden email]> wrote:
> Mike Hearn schrieb:
>
> Here is maybe a clue. Can anyone outline the role of imm32.dll and if it
> can be involved in our problem?
>


imm32.dll seems to be a dll for internationalizing certain text.