From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Subject: Re: go32 stack size problem
To: A DOT K DOT Heath AT sheffield-hallam DOT ac DOT uk (Andy Heath)
Date: Sat, 9 Apr 1994 11:07:08 -0600 (CDT)
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu (DJGPP Mailing List)

> 1) the prog is running in a dos box (ie from windows 3.1)
> AND
> 2) there's an array of unsigned char or similar of size 524288 which is
> local to a function. (eg declared inside main).

The V1.11 DPMI implementation provides a 256Kb fixed stack space, unless
you change it with the stubedit program (min_stack) or the global variable
_stklen in your program.  The _stklen makes sure your program always 
works, but is less efficient than using stubedit since the 256K stack
originally allocated must be discarded.  Example:
  extern unsigned _stklen = 1048576;
The best bet is to do both - by setting the stklen in your program it
will insure it works, but by also stubedit a larger amount (by a few KB)
it won't have to be reallocated and you save the wasted memory.

> The problem goes away if I don't use windows or if I make the array
> global or if I use malloc to get the space.  Obviously I can get round
> it but it's annoying because I need to run the same progs on a sun.

The VCPI type GO32 implementation dynamically expands the stack, but
unfortunately this can't be done with DPMI, so you get the fixed stack
which occasionally causes problems.  Note that V1.10 used a 4MB - (code size)
stack, which caused many DPMI users to have insufficient memory problems.
This was one of the driving forces for moving to COFF image format.