4.1175 PCs: MS-Dos Environment (1/60)

Elaine Brennan & Allen Renear (EDITORS@BROWNVM.BITNET)
Tue, 26 Mar 91 00:18:37 EST

Humanist Discussion Group, Vol. 4, No. 1175. Tuesday, 26 Mar 1991.

Date: Thu, 14 Mar 91 18:59 EDT
From: DJBPITT@pittvms
Subject: Re: 4.1161 MS-DOS Environment

This may be getting overly technical for Humanist and there may be more
appropriate places to discuss such questions, but I think the following
recent comment on environment size is wrong:

>the other catch, -- relating to autoexec.bat -- is that
>no matter how big the environment started out to be, at
>the time the first TSR (terminate and stay resident) program
>is loaded the environment is frozen at the size of the
>environment _in_use_. Since MODE, PRINT, and network drivers
>go TSR many people have frozen environments without
>knowing it. To make space available, an inelegant hack
>is to put some fluff into the environment early, as:

[... fluff deleted ...]

>subsequently releasing the space used by the fluff, making it available
>for re-use for some serious purpose.

MS-DOS maintains a master environment and every program that is run
receives its own local copy of this environment. TSRs thus have two
properties:

1) They have no access to environment variables set after the TSRs
themselves have been initialized. That is, the environment values
available to the TSR are only those that were in the master environment
when the TSR was set. Change one of those values or add a new
environment variable and your TSR won't know about it. But this only
"locks" the size of the local environment; it does not limit the size of
the master environment or of the environment available to subsequent
programs, both TSR and regular.

2) They occupy memory both for the program itself and for the local
environment. That is, every TSR reserves (and keeps) memory for the
local environment in use when the TSR is initialized. The space kept
depends on the actual space occupied by environment data, not on the
space allocated in config.sys.

These properties suggest the following strategies:

1) The autoexec file normally sets environment variables and loads TSRs.
Always load TSRs before setting any environment variables (except those
that are specifically needed by the TSRs in question). That is, rather
than filling up your environment with fluff before setting TSRs, you
should empty it of all values except those specifically needed by the
TSRs.

2) To save even more space, reset to null those environment variables
that the system sets upon initialization (path, comspec) BUT don't
forget to reset them to the values you want them to have at the end of
your autoexec file.

The above strategies enabled me to free up several K of memory, since I
avoided having every TSR store a big environment that it didn't need.
Contrary to the posting to which I am responding, emptying my
environment before loading TSRs did not lock in the environment size at
zero; I have no trouble filling it up again at the end of my autoexec
file.

--David J. Birnbaum djbpitt@vms.cis.pitt.edu [Internet]
djbpitt@pittvms [Bitnet]