1 files changed, 63 insertions, 0 deletions
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.