environ.txt

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.