Stack size allocations

[Robert Lunnon]

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