🚀 go-pugleaf

In article <1990Mar8.162123.4418@cec1.wustl.edu> jcb2647@cec1.wustl.edu (James Christopher Beard) writes:
>some versions of DOS strip away all unused space from the copy of the
>environment they give you.  Thus you may have had only 188 bytes of
>a 512 byte environment used up, but when you shell out of Word (or
>whatever) you have 188/188 bytes taken.  

[set large variable, then delete and reuse space]

>PC-DOS 3.1 doesn't do the above squeezing of child environments, but
>PC-DOS 3.2 does.  Another reason to either upgrade (to 4.01) or
>downgrade (to 3.1) from 3.2.

Actually, 4.01 does squeeze child environments, but command.com is different
from most programs in having it's environment block follow it in memory. 
Command.com can therefore dynamically expand it's environment as needed, when
you set long strings in a child shell.  It chokes when it reaches the value
you specified on the SHELL= line.  Given this action, I don't know why the
/E:nnn is even needed, since the environment can always expand as needed.
Note that this behaviour is a function of command.com, not msdos as such.
Naughty programs which try to change the parent environment usually fail with
this scheme, since they cannot expand it.  The trick of creating a long dummy
string and then deleting it will allow such programs to function.

If you run "mem /debug", then set a long variable, then run it again, you
can see the environment block get larger by paragraphs.  If anyone really
needs a "global environment" writable and readable by all programs, DDJ
published one a few months ago, implemented as a device driver.

4dos puts the environment into the "swappable" code, then makes a shrunk
copy in low memory before running a program.  

Since I just mentioned 4dos, and rumors of v 3.0 are running around, I'll
just mention that among the new features I believe will be:
- redirectable i/o from batch files
- if .. elseif .... else ....  in batch files
- new kind of batch files executed enirely from memory (instead of re-reading
  the file for each line the way command.com does.)
This is not official in any way of course, but I exchanged e-mail with one
of the authors and he didn't say it was secret.  Personally I can't wait to
see what else is in there.

Richard Brittain,                   School of Elect. Eng.,  Upson Hall   
                                    Cornell University, Ithaca, NY 14853
ARPA: richard@calvin.spp.cornell.edu	
UUCP: {uunet,uw-beaver,rochester,cmcl2}!cornell!calvin!richard