From 7e0f021a9aec35fd8e6725e87e3313b101d26f5e Mon Sep 17 00:00:00 2001 From: Tobias Klauser Date: Sun, 27 Jan 2008 11:37:44 +0100 Subject: Initial import (2.0.2-6) --- reference/C/CONTRIB/SNIP/environ.txt | 63 ++++++++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100755 reference/C/CONTRIB/SNIP/environ.txt (limited to 'reference/C/CONTRIB/SNIP/environ.txt') diff --git a/reference/C/CONTRIB/SNIP/environ.txt b/reference/C/CONTRIB/SNIP/environ.txt new file mode 100755 index 0000000..4c1862d --- /dev/null +++ b/reference/C/CONTRIB/SNIP/environ.txt @@ -0,0 +1,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. -- cgit v1.2.3-54-g00ecf