From: sandmann AT clio DOT rice DOT edu (Charles Sandmann) Message-Id: <9607281706.AA11871@clio.rice.edu> Subject: Re: Opinion To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii) Date: Sun, 28 Jul 1996 12:06:06 -0600 (CDT) Cc: djgpp-workers AT delorie DOT com In-Reply-To: from "Eli Zaretskii" at Jul 28, 96 01:32:18 pm Content-Type: text > I was thinking about environment variable because a command-line switch > requires CWSDPMI to be installed resident. It has to be run before the image, true, but it doesn't have to be resident. I quite often run it with the -sd:\a.swp type option just so I can check out the behavior on disks with different amounts of storage free. It goes away after one execution in this mode. So, you would get the same sort of behavior with the -o3 option (yeah, cryptic) which sets the options field (which is also cwsparam'able). > But if `getenv' bloats the code, then the switch is OK I guess. A little tidbit about TurboC - it copies the entire environment onto it's stack if you reference environment variables in the main() list or use getenv. So big environments can cause weird trashage in TC images. This was seen with GO32 at times. While I could write code to directly access the "far" real environment - I don't want to... > Please consider adding maximum memory usage tracking (just knowing what was > the largest usage during the client run is enough). That will be pretty easy to add.