starr@shell.UUCP (10/26/83)
Subject : Re: Environment limitations in DOS 2.0
In response to my comment on the environment not being able
to expand beyond 128 bytes... I stand corrected, partially.
In the application I was developing, I wanted to create a
set of variables for the environment which would describe the
printer which was hooked to the user's system. A technique
like this would make it much easier for the user to reconfigure
his system for another printer type.
The idea was to have all printer attributes defined at boot
through a bunch of SET commands in AUTOEXEC.BAT. Since the printer
environment would be interrogated by several different programs
which needed to access the printer, I could write one chunk of
code to gather the printer info out of the environment.
I think it is pretty silly to expect the user to have to type
all of this in by hand merely because of problems with DOS
batch files.
It is also rather silly to expect (as one person suggested) that
you key in several dummy environment parameters merely to expand
the environment to the desired size, then delete them. I had thought
of this, and tried it out of a BAT file (which didn't work). If the
person who suggested this approach has nothing better to do than
key in long dummy environment strings, I feel sorry for him.
Microsoft gives us a KLUDGE, and then defends it. It seems to me
that a solution to the problem (easy) would be to allow the user to
say something like
set/5000
in his AUTOEXEC file, which would preallocate 5000 bytes for him to
do with as he pleased... no memory fragmentation problems, etc. It
was easy for me to write a UNIX-equivalent "getenv" routine. It
was much harder to write the "putenv" function. Questions like
"how long is the environment" tend to make the functions' implementation
kind of tricky. Thus, if I could do a set/5000 as mentioned above, it
would be nice if an environment variable were created by DOS which
told me this fact.
Don't get me wrong. I like MS-DOS, and think that Microsoft is a very
competent company. I do worry, however, when I hear that my current
(and probably future) versions of DOS will be designed to accomodate
bugs and drawbacks of the very first DOS release (1.0).
Using BIOS when you could use DOS is a bad (but usually necessary)
habit. Microsoft warns us against that (Bill Gates told me so).
Designing software around BUGS is sad, and for Microsoft to penalize
future users and underdesign the system to protect this BAD practice
is ludicrous.
RF Starr