Games 1994/GAMES94.ISO/zm30/zm30.exe/PATHINFO.TXT

Text File | 1993-01-07 | 6KB | 101 lines

             INFORMATION ON THE DOS ENVIRONMENT PATH STRING
             ----------------------------------------------

        All versions of PC and MS DOS above 1.x maintain an area in
   memory called the environment.  The environment contains a series of
   text strings that are used by DOS and applications programs for
   various purposes.  You can see what strings are currently in the
   enviroment by typing SET and pressing <RETURN> from the DOS level.  As
   a minimum, the environment will contain the string COMSPEC= followed
   by a DOS directory path and (usually) COMMAND.COM.  Most hard disk
   equipped machines will show the following COMSPEC string:

                       COMSPEC=C:\COMMAND.COM

        Other strings that frequently appear in the environment are the
   PROMPT= and PATH= strings.  Control of the environment is effected
   through the DOS SET command, which may be entered at the DOS level or
   from a batch (like AUTOEXEC.BAT) file.  For example, if a user desired
   that DOS used a copy of COMMAND.COM that was in a directory named
   C:\DOS, he/she might place the command SET COMSPEC=C:\DOS\COMMAND.COM
   in the AUTOEXEC.BAT file.  After booting, DOS would load COMMAND.COM
   from C:\DOS each time it needed to reload the command interpreter.
   All other copies of COMMAND.COM in the system would be superfluous and
   ignored by DOS.
        One very useful string that can be placed in the DOS environment
   by the user is the PATH= string.  When the name of an executable file
   is issued from the DOS level, DOS will first look in the current
   subdirectory for the file.  If it finds it, it loads and executes it
   and all is fine.  If it cannot find the file in the current directory,
   DOS will search the environment for the PATH= designator.  If one
   exists, DOS will start searching the system directories that are in the
   PATH= string for the executable file.  For example, suppose that
   the AUTOEXEC.BAT contains the command SET PATH=C:\DOS;D:\UTIL;E:\JUNK.
   Note that directory path names are separated by semicolons and can
   (and should) include the drive designator.  Now further suppose that
   the user is in a directory named D:\SOMENAME and desires to run the
   program MYPROG.EXE but MYPROG.EXE is not resident in D:\SOMENAME.
   When the user enters MYPROG, DOS, unable find it in the current
   directory, starts searching the directories in the PATH= string
   starting with C:\DOS.  If MYPROG.EXE was in D:\UTIL, DOS would load
   and execute the program and D:\UTIL would be the active directory when
   the program received control from DOS.  Obviously, if DOS cannot find
   MYPROG.EXE in any of directories in the PATH= string, the message BAD
   COMMAND OR FILENAME will be displayed.
        The exact same sequence is followed if a running program calls
   DOS to execute a program but with one possible important difference.
   For technical reasons, some programs (like ZipMaster) need to load a
   secondary copy of COMMAND.COM and then pass the name of the program to
   be executed to COMMAND.COM.  This is accomplished by searching the
   environment string for the COMSPEC= string to locate COMMAND.COM,
   changing to that directory, and telling DOS to load COMMAND.COM.  The
   command passed to DOS might look somethin like this:

                         COMMAND.COM MYPROG.EXE

   This tells DOS to run COMMAND.COM and for COMMAND.COM to load and
   execute MYPROG.EXE.  Even if MYPROG.EXE were located in the active
   directory when the applications program passed this command to DOS,
   COMMAND.COM might not find MYPROG.EXE because the applications program
   switched to the directory where COMMAND.COM was located in order to
   start things rolling.  Therefore, unless MYPROG.EXE was in a directory
   contained in the PATH= string or in the same directory as COMMAND.COM,
   DOS would not find it.

        Each Identifier in the DOS path string MUST be unique.  For
   example, consider the path identifier C:\UTIL\DOS\MYDIR.  Placing
   this string in the DOS path string will NOT automatically place the
   the dirctories C:\UTIL and C:\UTIL\DOS in the DOS path.  Each must
   be uniquely identified by the correct path name.  For each of these
   directories to be identified in the DOS path, the following would
   be entered:

                    C:\UTIL;C:\UTIL\DOS;C:\UTIL\DOS\MYDIR

        ZipMaster depends upon the presence of an archive system's
   executable files (PKZIP.EXE, PKUNZIP.EXE, etc.). It calls these
   programs by using the command sequence just described and therefore
   cannot function properly unless these programs are in a directory
   specified in the PATH= string.  The simplest thing to do is to place
   your archive system files and LIST.COM in one subdirectory and place
   its DOS path name in the environment.  For example, suppose you are
   using PKWare and you place PKZIP, PKUNXIP, and LIST in a directory
   named C:\ARCUTILS.  Placing the following line in your AUTOEXEC.BAT
   file and rebooting will ensure that ZipMaster will function properly:

                           PATH=C:\ARCUTILS

   Obviously, the PATH= string can contain other directory path names and
   you may already have a PATH= command in your AUTOEXEC.BAT file.  If
   so, just add the directory containing the archive system files to the
   string.  For maximum speed, make it the first directory name in the
   string.

        When ZipMaster loads it will check your system environment
   to see if a PATH= string exists.  If so, it will search each
   directory in the string to see if any of the supported archive
   system files can be found in the directories defined in the PATH.