Simtel MSDOS 1992 December/simtel1292_SIMTEL_1292_Walnut_Creek.iso/msdos/sysutl/env.arc/ENV.DOC

Text File | 1988-06-09 | 5KB | 132 lines

ENV.DOC

SUMMARY
=======
The file ENV.COM was written for use within .BAT files under MSDOS 3.20
on an XT clone. It has three uses:

   a) ENV PAD   fills the unused space in the current environment
                gracefully in 14-byte blocks with variables
                    ENV01=abcdefg
                    ENV02=abcdefg
                    ENV03=abcdefg
                      :  :   :
   b) ENV UNPAD removes ENV01, ENV02, ... from the current environment,
                (to which they have normally been carried by an
                 application call)
   c) ENV <anything else> displays a brief syntax reminder.

The parameters are case-insensitive.

ENV.COM works by tracing back through memory via particular bytes in the
chain of PSP's and the environments that precede them until it finds an
environment which is the one that will be carried upwards in an
application call.

ENV.COM has not been tested with other versions of MSDOS. Its use with
them depends entirely on whether Microsoft has maintained a consistent
definition of the use of bytes in PSP's and environments.

USE OF ENV.COM
==============
When an application is called, MSDOS carries upwards environments which
only have just enough segments to hold the variables which have been set
(and possibly a copy of the string calling the application).

Short of re-writing the ***logic*** of MSDOS, the only way to carry
upwards an environment of the size set in CONFIG.SYS by the /e: switch
of
                   SHELL=<drive><path>COMMAND.COM /e:nnnn
seems to be to stuff it full!  That is what ENV.COM does.

Unless your current environment is already full, you can see the effect
of ENV.COM very easily in direct mode by typing
                   SET
                   ENV PAD
                   SET
                   ENV UNPAD
                   SET .
In effect it is simply an automated version of
                   SET ENV00=abcdef
                    :    :      :
In order to do its job it has to trace back illegitimately far through
memory to find the environment that will be carried upwards by an
application. It then directly edits that environment segment.

I use ENV.COM in all my batch files just before and just after the main
application calls. The following three annotated fragments give the
general idea. In the fragments I use < > to indicate deletions of major
blocks of commands whose details are not relevant to this note, and
leading colons (:) for normal MSDOS comment lines.

  1. AUTOEXEC.BAT

     <Early parts of the start-up routine>
      PATH C:\DOS;C:\DOS\OWNTOOLS;C:\DOS\TOOLS;C:\BIN;
     :c:\bin contains all the batch files for calling applications
      ENV PAD
     <Calls of major TSR applications (for example PCTOOLS)>
      ENV UNPAD
     <Rest of autoexec.bat>

     It is some months since I installed this and at the time of
     preparing this note I can't remember whether this was in response
     to real trauma or whether it was a just-to-be-safe detail in
     installing the latest PCTOOLS!

  2. ANAGRAM.BAT - for WORD's anagram finder: this is an application
     from which further applications cannot be called. It need therefore
     only make room for itself if it is offered a fully-stuffed
     environment.

     <cosmetic headings>
     ENV UNPAD
     PATH=C:\WORD;
     APPEND=C:\WORD
     IF     %1@==@ C:\WORD\ANAGRAM
     IF NOT %1@==@ C:\WORD\ANAGRAM %1


  3. KERMIT.BAT,  above which further applications can be, and often
     are, called, and which therefore needs to pass upward a big enough
     environment.

     There is an additional problem to be dealt with. Microsoft left
     APPEND out of the environment structure. So although details of
     paths set by PATH are automatically restored after an application
     call, the paths set by APPEND are not restored unless *I* do
     something about them. So I find that every nestable application
     needs:

          to record its append-state and tell its children,
          to preserve the append-state of its own parent and restore it.

     In the annotations I pretend that KERMIT.BAT and KERMIT.EXE can
     speak for themselves

     <cosmetic header>
    :release the space we've been given
     ENV UNPAD
    :preserve a record of what our parent needs us to do for it
     SET OLDAPPEND=%APPEND%
    :preserve a record of what we will need any children to do just
    :  before they hand back to us
     SET APPEND=APPEND C:\KERMIT;C:\BIN;
    :do it for ourselves while we can
     %APPEND%
     PATH=C:\BIN;C:\KERMIT;C:\DOS;C:\DOS\TOOLS;C:\DOS\OWNTOOLS;C:\;
    :stuff environment space in case we have children
     ENV PAD
    :enter the main application
     C:\KERMIT\KERMIT %1 %2 %3 %4
    :having returned from the application, make room to tidy up
     ENV UNPAD
    :restore text file paths for our parent (command paths will be
    :  automatically restored by MSDOS when this batch file finishes)
     %OLDAPPEND%
    :End of KERMIT.BAT (and therefore hand back to parent)

--------------
End of ENV.DOC