From: sandmann AT clio DOT rice DOT edu (Charles Sandmann) Message-Id: <9602190316.AA10476@clio.rice.edu> Subject: Re: Segmentation problem in DJGPP v2 To: oandico AT eee DOT upd DOT edu DOT ph (Orlando Andico) Date: Sun, 18 Feb 1996 21:16:05 -0600 (CST) Cc: djgpp AT delorie DOT com In-Reply-To: from "Orlando Andico" at Feb 19, 96 10:56:31 am Content-Type: text Content-Length: 1498 > Yep; increasing the stack size to 4MB seemed to fix these problems. And > yes, the 1.12m4 version was crashing under Windoze too. But didn't I hear > that DJGPP v1 had an infinite stack? so what gives? It has a 1Gb potential stack if *NOT* using a DPMI provider. It's a DPMI 0.9 design problem more than anything else. > Also: if I give it a 4MB stack, will that all be used? will it be paged? > ie can this program still run on a low-memory machine? Only what your program needs will be used. It depends on the DPMI provider on if it gets paged or not (cwsdpmi doesn't commit pages to memory until they are touched, but others do). It may have problems on a low memory machine depending on the DPMI provider, the amount of free disk space, etc. With lots of free disk, it doesn't matter much with CWSDPMI. But it would be better to trim the 4Mb stack to something less if you can easily figure out what that something less should be. I have a subroutine that determines the maximum observed stack usage you could link in to find out; I also have a go32-v2 like program someplace that does this without linking. But I'm too busy to find them right now, maybe later this week. > How common are these stack problems anyway? This should be in the new FAQ. Well, the number of bitches in V1.x under DPMI and the beta was zero from what I remember, so I am somewhat confused at the new flurry of problems. But as long as we have an easy fix, I guess we can live with it for a while.