On Sat, 7 May 2005 07:47 pm, Joris Huizer wrote: > Robert Lunnon wrote: > > I wish to propose two changes that I currently have in my Solaris > > patchkit. I'll use two separate e-mails here to avoid confusion. > > > > Both changes add environment variables controlling the way wine does > > things. > > > > > > The first patch addresses a problem I have found where Windows > > applications under wine exceed the allocated stack. By default wine > > allocates the same 1MB stack that windows does but wine has a different > > stack consumption that does windows, adding the wine translation layers, > > possibly OGL then X calls on top of this. > > > > The following patch allows an environment variable WINE_STACK to redefine > > the minimum stack to give applications and to add extra stack to that > > declared in the executables header to allow for additional stack > > consumption. Currently it works like this > > > > if WINE_STACK is not set the default semantics are used just like wine > > does today > > > > if WINE_STACK is set then wine allocates the maximum of the value given > > in the WINE_STACK env var or 1MB. 25% of the value specified in > > WINE_STACK is added to the value declared in the applications executable > > header to provide more headroom for wine/X calls. > > > > Please excuse the primitive debugging included for now, it'll have to be > > removed for primetime. > > > > Comments anyone ? > > I think this is a bit weird: > `wine prog.exe` > is not equivalent to: > `WINE_STACK=1M wine prog.exe` > -- it is equivalent to this weird thing: > `WINE_STACK=838860B wine prog.exe` > > Why wouldn't you simple add that 25% extra in every case? >
Well, that would be a solution but it doesn't allow a fallback to "Standard windows behaviour" I have no idea if there are any applications out there that are sensitive to the size of their stack segments Bob
