Starcraft 2 needs ptrace

After watching some games on the live stream of the 2011 North American BattleNet Invitational I thought about returning to StartCraft 2 at least for some matches.
I started my SC2 installation and waited for various patches to be applied (Current version 1.3.6 ).

Unfortunately it dies even before showing the log in screen with:

ACCESS VIOLATION(0xC0000005)

Looking at the WineHQ App DB for SC2 I tried various options related to the simulated Windows Version, mmdevapi, pulseaudio, Direct3D registry settings, ...
Same error no matter what.

After poking around the web looking for the error message I luckily ran across https://sites.google.com/site/lightrush/random-1/howtomakestarcraftiinotcrashunderwineandubuntulucidmaverickonlogin
which sparked the idea of checking my gentoo-hardened kernel configuration regarding any ptrace restrictions.

linux # grep -i ptrace .config
CONFIG_GRKERNSEC_HARDEN_PTRACE=y

If you say Y here, TTY sniffers and other malicious monitoring programs implemented through ptrace will be defeated.

This option only affects the ability of non-root users to ptrace processes that are not a descendent of the ptracing process.
This means that strace ./binary and gdb ./binary will still work, but attaching to arbitrary processes will not.

I also read somewhere that SC2 uses the ptrace syscall to scan its own process for any hacks or modifications, so I disabled the according option:

Security options  ---> Grsecurity  ---> Executable Protections  ---> Deter ptrace-based process snooping

recompiled and rebooted.

StarCraft 2 works like a charm again on my box!

Wine patch to use 3GB userspace

Playing Everquest 2 using Wine, I suffered from the more and more often occurring "out of memory" crashes especially in new zones like RoK or TSO. After reading in the EQ2 forums about various remedies for Windows using the /3GB switch in boot.ini, I looked into Wine wether this could be done with linux too.

Wine is actually ware of the so called LARGEADDRESSAWARE flag, but these "out of memory" errors seem to originate from the nvidia or ati opengl driver allocationg texture memory. It is reserved directly within the driver via the C API and therefore not taken into account by wine.

The current Wine preallocates all memory between 2 and 4GB of the virtual address space in order to simulate the windows memory model. The OpenGL driver apparently can only get the memory below 2GB and therefore only 2GB are available for both, the application and the opengl textures.

The following hack modifies the preallocation to only block memory between 3 and 4GB. This probably leads to a slightly wrong memory model compared to a native Windows, but it gives at least EQ2 1GB more memory to be used by the OpenGL driver.

Since using this patch I have never seen any crash concerning "out of memory" anymore.

After all this is just a temporary workaround for the problem described in http://bugs.winehq.org/show_bug.cgi?id=13335, which will hopefully be fixed soon and my workaround is not needed anymore.

See U in Norrath ;-)

Updated patch, wine-1.3.33 

diff --git a/libs/wine/mmap.c b/libs/wine/mmap.c
index 63a597d..b892c43 100644
--- a/libs/wine/mmap.c
+++ b/libs/wine/mmap.c
@@ -343,7 +343,7 @@ void mmap_init(void)
     struct list *ptr;
     char stack;
     char * const stack_ptr = &stack;
-    char *user_space_limit = (char *)0x7ffe0000;
+    char *user_space_limit = (char *)0xbffe0000;
 
     reserve_malloc_space( 8 * 1024 * 1024 );