1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
|
Q. Why was only the DOS batch file and "Stuff-key-buffer method"
(SETENVAR.C) included in the original SNIPPETS?
A. The reason that I only included the "batch&stuff" method in my SNIPPETS
collection is simply that it's the *only* method you can rely on if your
program is going to be distributed. Quite simply, there is *NO* safe,
documented way under DOS to set an environment variable in the master
environment block - period! By back-tracking PSPs or MCBs, you can try
to locate the master environment and change it. You can also try to use
Int 2Eh, the command processor's "back door". But all of these methods
suffer from several shortcomings:
1) Someone using the program might be using 4DOS, COMMAND PLUS, or some other
COMMAND.COM replacement. These don't always do things the same way as
COMMAND.COM and the diferences can cause you to crash, roll, & burn! For
example, several COMMAND.COM replacements allow the master environment
block to be located in extended, expanded, or high memory. In such a case,
backtracking PSPs or MCBs is less than useless, they're guranteed to
yield undefined errors.
2) Int 2Eh seems to be the most universally supported, but cannot be used in
a program invoked from a batch file. The book, "Undocumented DOS" details
some procedures for making an Int 2Eh call safer but, again, these
techniques rely on implementation features of COMMAND.COM which might not
be available in alternate command processors.
3) Even if everything else is safe, you still need a way of error trapping in
case your new environment variable might overwrite the end of the
available master envirnment block. This error trapping in inherent in
COMMAND.COM and alternate command processors (one reason why using the
Int 2Eh back door is potentially the safest way to try), but if you try to
modify things manually, you're on your own. If you do overwrite the end of
the master environment block, you'll have automatically corrupted your MCB
chain and possibly set yourself up for some *really* nasty surprises!
4) Finally, there's the very fundamental question of which environment block
really is the master? Say you're in your comm program and hit the "shell
to DOS" key. A secondary copy of the command processor, be it COMMAND.COM
or whatever, is spawned and you're off and running. If you now run your
program from this secondary DOS shell, is its environment block the master
or is it the one from which you ran your comm program? Worse yet,
depending on how you set up CONFIG.SYS, the secondary shell may have a
considerably smaller environment block than the original. Despite having
set the "/E:" switch, your secondary shell will likely only have an
environment block whose size is equal to the current block size rounded
up to the next paragraph boundry. If you trace PSPs, you'll find the
secondary shell which you stand a good chance of over-running due to the
difference in the block size. If you trace MCBs, you'll find the real
master block, but then your changes will have disappered when you return
to your comm program, defeating the purpose of your program in the first
place.
The inability to alter a parent program's environment block isn't a DOS
exclusive, BTW - it's an inheritance from Unix where the same limitation
applies.
Finally, SNIPPETS now includes several of these alternate unsafe ways of
setting the master environment. INT2E.ASM & CCOMCALL.C together provide
access to the DOS command processor back door, GLBL_ENV.C provides means
for TC/TC++/BC++ and MSC/QC programmers to modify the master environment
by backtracking PSP pointers, and MCB_ENV.C serves the same purpose only
using the MCB tracking method.
|
