Pegasus Graphics Universe/Pegasus_Graphics_Universe.iso/support/fm46.exe/PATHINFO.TXT

Text File | 1992-04-06 | 6KB | 109 lines

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

          All versions of PC and MS DOS above 2.0 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 located 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 FMTMAS) 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.
         FormatMaster depends upon the presence of SYS.COM transfer system
     files to a freshly formatted diskette.  It calls SYS.COM by using the
     command sequence just described and therefore cannot transfer the
     files if DOS cannot find SYS.COM when called to load it.  Suppose
     SYS.COM resides in a directory named C:\DOS.  Placing the following
     command in your AUTOEXEC.BAT file and rebooting will ensure that
     SYS.COM can be found when needed:

                             PATH=C:\DOS

     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 FormatMaster loads it will search your system environment
     to find the location of COMMAND.COM.  This is automatic and requires
     nothing on your part.  The only problem that could occur is in a
     system that is using a command intreperter other than COMMAND.COM (a
     **very** rare situation).

     You may specify an exact location for FMTMAS.EXE by placing the
     following command in your AUTOEXEC.BAT file:

                          set FMLOC=C:\XXXX\...

     Where C:\XXXX\... should be replaced the the actual DOS path name
     of the directory in which FMTMAS.EXE is located.  Be SURE to
     place the drive letter and colon in the string!

     You may specify that FormatMaster use 9 sectors in lieu of 10
     sectors when formatting a 360K disk in a 1.2 drive.  This will
     force FormatMaster to format a 360K disk to 720K instead of 800K
     for those systems where the 800K option will not work.  Place the
     following command in the AUTOEXEC.BAT file:

                          set FMSEC=9

     NOTE:  It is **important** that DOS 2.x users use CAPS when entering
            path commands into the environment.  DOS 3.x automatically
            changes all characters to upper case but DOS 2.x does not.

     Copyright 1988/89/90 by New-Ware, All Rights Reserved.