Opening up the debate again on the World of Warcraft ( WoW ) memory patch.
Some facts about WoW that may explain why the AppDB page is pretty active and the wow patch for wine 0.9.12 was downloaded over 1000 times from the Appdb page during a 4 week period.... Wow has approximately 6 million players that each pay about $90/year for the priviledge of connecting to a WoW server (Realm). Assuming this figure is broadly correct, Blizzard therefore receives $500,000,000/year just from this game in subscriptions. ( This doesn't include the cost of buying the game in the first place ). Perhaps Blizzard would like to employee a programmer fulltime just to work on the wine project to help make Wow run 100% ?.
Anyway with the popularity of this game in mind, you can see why there is a lot of interest in making this patch a thing of the past, so the thousands of gamers who play this game on wine don't have to keep applying a special patch. I would be grateful for any suggestions as to how we could incorporate this patch so that it is no longer necessary. I know we can't simply include the patch, but there must be some way around this problem ?
Below is an email regarding this partiicular problem, I would be grateful for any comments that I can pass back to Jan Riewe. Thanks
Regards Nick Law Appdb Maintainer - World of Warcraft 1.10.x
Any feedback is much appreciated.
Comment for 'World of Warcraft 1.10.x' added by jan riewe ------------------------------------------------------- To reply to this email please use the link provided below. DO NOT reply via your email client as it will not reach the person who wrote the comment http://appdb.winehq.org/appview.php?versionId=4031&mode=nested#Comment-1...
Subject: RE: is this a workaround or a real patch?
is it posible to make a workaround with the user.reg? in the transgaming forum i`ve found something like : [Software\Wine\AppDefaults\WoW.exe\Memory] 1148134976 "MemoryLayoutOverride"="0x10000000"
does it make sense on wine? (i am not so familiar to the wine syntax *shame on me*) is this perhaps the key to get rid of the patches and make the binary build of wine working with WoW also fine? if this is a posibility perhaps you can post a full "user.reg" fix for those of us, who love the update feature.
and i just want to thank you ... your service this really great! wow is one of the biggest steps at the moment for gaming society to move more and more to an opensource system.
----
--- wine/libs/wine/mmap.c.orig 2006-05-11 17:02:13.000000000 +0100 +++ wine/libs/wine/mmap.c 2006-05-19 22:08:03.000000000 +0100 @@ -183,7 +183,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 * @@ -213,6 +232,8 @@ return start; #endif } + if ((start == NULL) && !(flags & MAP_FIXED)) + start = get_anon_mmap_null_address(size); return mmap( start, size, prot, flags, get_fdzero(), 0 ); }
--- wine/loader/preloader.c.orig 2006-05-11 17:02:13.000000000 +0100 +++ wine/loader/preloader.c 2006-05-19 22:14:22.000000000 +0100 @@ -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 */ };
On Mon, 22 May 2006 19:18:07 +0100, Nick Law wrote:
Below is an email regarding this partiicular problem, I would be grateful for any comments that I can pass back to Jan Riewe. Thanks
Hi Nick,
This has been discussed previously. It looks likely that to fix this so WoW works out of the box requires extensive and intricate changes to the core of either Wine or the kernel to provide a more accurate match to the NT memory layout model.
I rate the chances of this happening anytime soon as being low. It's not that people don't care, it's more that there are no developers with the time/motivation/skill hanging around who want to work on it, it seems.
It'd be better to get the bug in WoW fixed, whatever that is. I do not know how you might contact Blizzard.
Alternatively there could be (should be!) pre-built versions of Wine that run for all users customized for WoW specifically.
thanks -mike
On 5/30/06, Mike Hearn mike@plan99.net wrote:
This has been discussed previously. It looks likely that to fix this so WoW works out of the box requires extensive and intricate changes to the core of either Wine or the kernel to provide a more accurate match to the NT memory layout model.
I rate the chances of this happening anytime soon as being low. It's not that people don't care, it's more that there are no developers with the time/motivation/skill hanging around who want to work on it, it seems.
It would be really great if someone could document the patch and explain what exactly is stopping WoW from working (as well as which changes would cause problems for other programs). I think there would be more chance of getting developers working on the problem if the problems involved were clearer and easier to see/understand.
Alternatively there could be (should be!) pre-built versions of Wine that run for all users customized for WoW specifically.
Given the amount of users who use wine to run WoW, would it be possible to have the patch included with a compile-time option? Would it even be possible to make the patch a runtime feature?
n0dalus.
On 5/30/06, n0dalus n0dalus@gmail.com wrote:
It would be really great if someone could document the patch and explain what exactly is stopping WoW from working (as well as which changes would cause problems for other programs).
It's a bug in WoW itself, it relies upon the exact way NT maps memory which is different to how Linux does it. I guess they are storing information in the high bits of a pointer somewhere or some similar trick.
The patch is a hack that makes Wine follow the Windows method - unfortunately it will happily force an allocation to an area that is already allocated. Right now it relies on pure luck to avoid blasting a previous allocation. Expect random undebuggable failures with this technique.
I think there would be more chance of getting developers working on the problem if the problems involved were clearer and easier to see/understand.
The real issue is that it seems not many Wine developers play WoW themselves ;)
Given the amount of users who use wine to run WoW, would it be possible to have the patch included with a compile-time option? Would it even be possible to make the patch a runtime feature?
Doubtful. You'd have to ask Alexandre. He may know of a different solution also. Wine has a policy of not accepting application specific hacks though there are a few generic hacks in there.
You'd be better off IMHO by preparing your own Wine binary install that is specific to WoW itself.
thanks -mike
Mike Hearn wrote:
It's a bug in WoW itself, it relies upon the exact way NT maps memory which is different to how Linux does it. I guess they are storing information in the high bits of a pointer somewhere or some similar trick.
Since WoW also runs on MacOSX, how does the memory layout on MacOSX differ from NT and Linux? Maybe that's the reason why they won't do a Linux port: because they rely on a certain memory layout and the code can't be changed that easily.
tom
On Tue, 30 May 2006 16:08:42 +0200, Tomas Carnecky wrote:
Since WoW also runs on MacOSX, how does the memory layout on MacOSX differ from NT and Linux?
I have no idea, but the MacOS and Windows versions of WoW will be different; probably the bug is only in the Windows specific parts of the code.
Maybe that's the reason why they won't do a Linux port: because they rely on a certain memory layout and the code can't be changed that easily.
I suspect the real reason is the usual one: concern over profitability. They'd need to have a full time Linux dev team as well, because the code constantly evolves. The problems Second Life is having shows what happens when you don't do that :/
thanks -mike
Mike Hearn wrote:
It's a bug in WoW itself, it relies upon the exact way NT maps memory which is different to how Linux does it. I guess they are storing information in the high bits of a pointer somewhere or some similar trick.
One can never be sure, but I suspect this is not do to a bug but to a fixture. WoW Has a all chain of checks that go up all the way to rootkit reveler to make sure the user is not aided by an automatic system, Given the player an advantage other players do not have. The Memory layout checks is for making sure the program is not loaded by a Debugger of sorts. Or that core Dll(s) where not replaced/hooked/emulated.
It is possible that approaching Blizzard might be helpful. Is WoW supported by Cedega?
Free Life Boaz
WoW Has a all chain of checks that go up all the way to rootkit reveler to make sure the user is not aided by an automatic system, Given the player an advantage other players do not have. The Memory layout checks is for making sure the program is not loaded by a Debugger of sorts. Or that core Dll(s) where not replaced/hooked/emulated.
Yes, it could be the Warden, but I doubt it. If the Warden is triggered you get banned from the game yet this bug surfaces not as spurious bannings but some kind of mouse control/targetting problem. To be honest I'm amazed we haven't seen any reports of Wine triggering anti-cheat systems like Blizzards before, and I'm sure we'd hear about it if it did ....
It is possible that approaching Blizzard might be helpful. Is WoW supported by Cedega?
Yes, using a slightly more generic version of the same memory layout hack.
thanks -mike
-
Boaz Harrosh -
Mike Hearn -
n0dalus -
Nick Law -
Tomas Carnecky