Stack size allocations
bobl at optushome.com.au
Sat May 7 06:50:02 CDT 2005
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
More information about the wine-devel