(yeah i'm bored :/)
Seems the WoW appdb page (apart from being a great example of what an appdb entry should be like!) recommends users patch their Wine to run WoW properly.
The patch is this one, which I am SURE we discussed before but I can't find the thread! So my questions are:
* Is this working around a bug in WoW? (my guess - almost certainly yes)
* What exactly is it doing?! No comments! It seems to be forcing the kernel to follow an NT allocation pattern.
* How should we fix this properly? Forcing the rtld to map every DSO in a predictable manner seems awfully hard work. Likewise, kernel patches would kind of suck ...Is this approach of a new preloader region and then doing manual mmap management going to work?
These are questions for Alexandre really but if nobody has any better ideas then maybe we should try and incorporate allocation patterns into our test suite and match Windows. Seems very lame for users to have to patch the preloader to play a game as popular as WoW is.
thanks -mike
mike@linux:~/Downloads> cat wow.patch.0.9.11 --- wine/libs/wine/mmap.c.orig 2006-01-27 04:58:28.000000000 -0900 +++ wine/libs/wine/mmap.c 2006-01-27 05:00:46.000000000 -0900 @@ -164,7 +164,26 @@
#endif /* (__svr4__ || __NetBSD__) && !MAP_TRYFIXED */
+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) + { + 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; + } + /*********************************************************************** * wine_anon_mmap * @@ -212,6 +231,8 @@ return start; #endif } + if ((start == NULL) && !(flags & MAP_FIXED)) + start = get_anon_mmap_null_address(size); return mmap( start, size, prot, flags, fdzero, 0 ); #else return (void *)-1;
--- wine/loader/preloader.c.orig 2006-01-27 04:58:29.000000000 -0900 +++ wine/loader/preloader.c 2006-01-27 05:00:46.000000000 -0900 @@ -109,8 +109,8 @@ static struct wine_preload_info preload_info[] = { { (void *)0x00000000, 0x00110000 }, /* DOS area */ - { (void *)0x7ffe0000, 0x01020000 }, /* shared user data + shared heap */ - { (void *)0x00110000, 0x1fef0000 }, /* PE exe range (may be set with WINEPRELOADRESERVE), defaults to 512mb */ + { (void *)0x80000000, 0x01000000 }, /* shared user data + shared heap */ + { (void *)0x10000000, 0x00f00000 }, /* PE exe range (may be set with WINEPRELOADRESERVE), defaults to 512mb */ { 0, 0 } /* end of list */ };
Mike Hearn wrote:
(yeah i'm bored :/)
Seems the WoW appdb page (apart from being a great example of what an appdb entry should be like!) recommends users patch their Wine to run WoW properly.
The patch is this one, which I am SURE we discussed before but I can't find the thread! So my questions are:
- Is this working around a bug in WoW? (my guess - almost certainly yes)
Speaking from my own experience with WoW bugs and Blizzard: Unless the bug affects Windows or MacOS users and you can prove and show the exact location of the bug (which functions are called, which arguments passed etc.) Blizzard has no interest in fixing the bug whatsoever.
To prove the 'targeting circle' bug was easy, WoW passed a negative value to an OpenGL function and the bug affected the game on all platforms when running in OpenGL mode (and thus all MacOS users). And yet Blizzard postponed the fix to the next major patch release (with at least two minor releases in between!), even though the patch probably was a one-liner.
I think Blizzard should test WoW under wine or cedega because I believe there are many bugs that are hard to track down and it would be easier to find them when running under another memory layout. I don't think they'll ever to that.
Hell, the guy at Blizzard didn't even want to give credit to the OpenSource community for finding that bug. And frankly, playing without the targeting circles was a major pain and I think many people were happy to see that bug fixed.
tom
On Monday 01 May 2006 20:59, Mike Hearn wrote:
- Is this working around a bug in WoW? (my guess - almost certainly yes)
Perhaps, but there are other problems with the Linux kernel not using the entire address space.
- What exactly is it doing?! No comments! It seems to be forcing the kernel to follow an NT allocation pattern.
Sort of. NT's allocation pattern is somewhat erratic. I started looking into it last weekend. The allocation pattern varies depending on the calls you make (GlobalAlloc and VirtualAlloc use address space in a different order, I have not checked file mapping yet).
However NT will start allocating at around 0x00100000, whereas Wine starts allocating in the 0x66000000 range, so this patch makes initial allocations appear much closer to the NT range than raw Wine.
The other problem is that the Linux kernel will not map anything below 0x40000000 unless an mmap call explicitly requests such an address, so after we lock out 0x80000000-0xe0000000 we are left with 1GB of usable address space for everything (Wine, native libraries, data) unless we decide ourselves where mappings without a start address should begin. The problem with that is that something else may have mapped stuff where we plan to map something.
- How should we fix this properly? Forcing the rtld to map every DSO in a predictable manner seems awfully hard work. Likewise, kernel patches would kind of suck ...Is this approach of a new preloader region and then doing manual mmap management going to work?
Mapping of DSOs is not the immediate problem, although it would be nice if we could force all native shared libraries above 0x80000000 (and above 0xc0000000 on architectures where address space above there is available) so that Windows apps have the largest possible address space available to them.
The solution is that we need to know about all memory allocations, which means hooking into mmap and related calls in libc and making the system call ourselves so that we have a record of "all" memory mappings other than those made by libraries that make their system calls directly (hopefully the intersection of this set with the set of libraries we use is empty). If we record the mappings, then ntdll could make the decision on where to map things based on Windows allocation patterns and knowledge of allocated space. If the allocation fails because something is mapped there already we would display a FIXME and then use a search algorithm to identify the allocated block (or grovel at /proc, but Alexandre has indicated before he prefers not to do that).
On 5/1/06, Mike Hearn mike@plan99.net wrote:
Seems the WoW appdb page (apart from being a great example of what an appdb entry should be like!) recommends users patch their Wine to run WoW properly.
The patch mentioned particularly causes problems on systems like Fedora with randomized prelinking and exec-shield.
On FC5 it took me some time to get the patched version to run and used: setarch i386 -L wine WoW.exe -opengl
This apparently enables support for a legacy address layout. Does anyone know how this would allow it to run?
Just curious, n0dalus.
Well ever since me, Mike and Alexandre did the preloader work a few years ago Wine itself has been execshield resistant, but the apps themselves may not be (my guess is that this is why Microsoft have not implemented it themselves ... that and they appear to be scared of their own dynamic linker code).
We could add the syscall to switch off execshield and get a legacy VMA layout to Wine itself, but Alexandre doesn't like it as the "ABI personality" syscall basically has no well defined behaviour at all and is used for all kinds of things, some of which may be useful. If there was an execshield/VMA randomization specific way to disable things on a per-process basis that'd be best. Otherwise I guess adding the personality syscall to the WoW patch wouldn't hurt, as it's already custom.
thanks -mike
On 5/2/06, n0dalus n0dalus+wine@gmail.com wrote:
On 5/1/06, Mike Hearn mike@plan99.net wrote:
Seems the WoW appdb page (apart from being a great example of what an appdb entry should be like!) recommends users patch their Wine to run WoW properly.
The patch mentioned particularly causes problems on systems like Fedora with randomized prelinking and exec-shield.
On FC5 it took me some time to get the patched version to run and used: setarch i386 -L wine WoW.exe -opengl
This apparently enables support for a legacy address layout. Does anyone know how this would allow it to run?
Just curious, n0dalus.
-
Mike Hearn -
n0dalus -
Tomas Carnecky -
Troy Rollo