Tools en Utilities/CDASS_5.ISO/shell/comp/rcx10.arj/COMPILE.DOS

Text File | 1992-12-21 | 10.0 KB | 172 lines

COMPILE.DOS - Instructions for adapting BATch files for compiling.

Introduction.

Due to the different nature of .BAT and .COM or .EXE files batch scripts
to be compiled should necessaryly undergo some specific changes in order
to functionally work similar to the original .BAT. After these changes
the programs do not necessaryly work correctly anymore as a .BAT file.
That's why they should be renamed to another extension, e.g. .B2C.

The differences mainly concern the calling of other .BAT files from a .BAT
file, either with or without using the CALL statement. (Instead of a CALL
command, which was introduced with DOS version 3.3, the statement
COMMAND/C might be used. For older DOS versions I have written an external
program called CALL.COM that is functionally the same as the DOS CALL
command and that may be used with older DOS version without changing
'CALL' in newer .BAT files into 'COMMAND/C'.)

If a .BAT file starts another one without a CALL prefix the called .BAT
gets run, while the calling .BAT file will not be continued (returned into)
after the second one finishes. Doing so from a compiled batch script
causes the calling program to run further from the point the second
one (a .BAT or .COM or .EXE) was started. This is the main difference.

If a .BAT file starts another one with a CALL prefix, intending to finish
the first one after the second one, this will yield no difference between
a batch file and a compiled one. But the CALL prefix is redundant and may
be left out (it takes some memory), but that isn't quite necessary.

If a .BAT file calls a .COM or .EXE file it always continues from that point
after the second program has finished. This also applies to a compiled batch
script. A CALL prefix is not necessary in both instances.

If another .BAT file calls a .BAT file that has been compiled (thus in fact
calling the .COM file) this may have consequences for the other .BAT file's
course. If the called .BAT (now .COM) file originally was called with the CALL
prefix there is no difference, because in both cases control is returned to the
other .BAT file (though the prefix CALL might be removed). If the called
original .BAT was called without the CALL prefix, thus inducing no return to
the other .BAT file from the called one, a return will actually take place
after finishing the .COM file.

Adaptation instructions.

1. Regulating the course of a compiled batch file after returning to it from
   calling another batch file or itself (%0) recursively:
   (a .COM file will be continued after calling anything)
   a. after the call (without the prefix 'CALL') add the command line
      'GOTO EXIT' and include a label ':EXIT' at the very end of the file.
    ┌ REM ---.BAT---                      REM ---.COM---
    │ batch [arguments]                   batch [arguments]
    │ .                                   GOTO EXIT
    │ :                                   :
    └                                     :EXIT
   b. at 'FOR's and 'IF's where the second batch or %0 (itself) is called
      (without 'CALL') change that into 'GOTO LABEL' (any choosen label) and
      call the secondary one or %0 (etc.) from there (after defining the label)
      and after that add the line 'GOTO EXIT' (':EXIT' label at the very end).
    ┌ REM ---.BAT---                      REM ---.COM---
    │ IF «cond» batch [arguments]         IF «cond» GOTO label
    │ :                                   :
    │ .                                   :label
    │ .                                   batch [arguments]
    │ .                                   GOTO EXIT
    │ :                                   :
    └                                     :EXIT
    ┌ REM ---.BAT---                      REM ---.COM---
    │ FOR %%f IN (set) DO batch [args]    FOR %%f IN (set) DO GOTO label
    │ REM This command starts batch if    :
    │ REM set is not empty for its first  :label
    │ REM value.                          batch [args]
    │ REM Thus batch is only run once     GOTO EXIT
    │ REM (or even never).                :
    └                                     :EXIT
    ┌ REM ---.BAT---                      REM ---.COM---
    │ FOR %%f IN (set) DO IF «cond» batch FOR %%f IN (set) DO IF «cond» GOTO lbl
    │ REM This command starts batch if    REM Only useful if «cond» involves %%f
    │ REM set is not empty and «cond»     :lbl
    │ REM is true for the _first_ time.   batch
    │ REM Thus batch is only run once     GOTO EXIT
    │ REM (or even never).                :
    └                                     :EXIT
    ┌ REM ---.BAT---                      REM ---.COM---
    │ IF...FOR...DO batch [arguments]     REM Similar to FOR...IF...DO etc.
    │ REM Such a construct always can be
    │ REM split (as well as the construct
    │ FOR %%f IN (set) DO IF «cond» etc.
    │ REM if «cond» does NOT involve %%f)
    │ REM into:
    │ IF «cond» GOTO FORlabel             IF «cond» GOTO FORlabel
    │ :IFlabel                            :IFlabel
    │ :                                   :
    │ :FORlabel                           :FORlabel
    │ FOR %%f IN (set) DO batch [args]    FOR %%f IN (set) DO GOTO label
    │ GOTO IFlabel                        GOTO IFlabel
    │ REM This command starts batch if    :
    │ REM set is not empty for its first  :label
    │ REM value.                          batch [args]
    │ REM Thus batch is only run once     GOTO EXIT
    │ REM (or even never).                :
    └                                     :EXIT
      This, however, is not possible if the call itself actually involves the
      variable used with the 'FOR', e.g. 'FOR %%F IN (*.BAT) DO %%F', which is
      being resolved only once, for the first .BAT file found, if uncompiled,
      but resolves to multiple commands, for every .BAT file, if compiled. But
      this construct is not quite functional and hardly occurs. Besides, the
      %%f variable gets lost outside a FOR.
    ┌ REM ---.BAT---                      REM ---.COM---
    └ FOR %%f IN (set) DO %%f [args %%f]  REM Incompatible, rare, run only once
   c. at calls to other batch programs that include the prefix CALL that prefix
      only may be removed; do _NOT_ follow these lines with 'GOTO EXIT'.
    ┌ REM ---.BAT---                      REM ---.COM---
    │ [FOR...DO][IF...] CALL batch [args] [FOR...DO][IF...] [CALL] batch [args]
    └ REM Both batch or args may involve the %%f variable from the FOR.
   With cases a. and b. the original calling .BAT file wasn't kept loaded in
   memory after passing control to the called .BAT file. If compiled the
   original calling .COM program remains loaded however (and will finally only
   execute the 'GOTO EXIT' and ':EXIT' lines). This can not be altered and thus
   running a compiled batch file may require more memory than an uncompiled one.
   If it calls itself (or other compiled batch files) multiple times (originally
   without the CALL prefix) this will require even a lot more memory because the
   copies will be loaded on top of each other.

2. Regulating the course of _another_ batch file calling a compiled one:
   In order to (intentionally) cause the remainder of the other .BAT file not
   to execute its remainder a 'GOTO EXIT' line should explicitely be inserted
   after the calling line and an ':EXIT' label line at the very end of the
   other .BAT file. This is equivalent to the adaptations discussed under 1.

3. Other necessary adaptations depend heavyly on the compiler used. One of
   them (BAT2EXEC vs. 1.5) shows some differences (and even unrecoverable
   bugs) with the standard DOS batch language. These differences and their
   consequences have to be taken into account when preparing .BAT files for
   compiling. Specific differences are described in the document BAT2EXEC.BUG.

4. In order to write always-compiler-compatible .BAT files one should always
   include the above mentioned adaptations, but leave the CALL prefix in its
   place. This has the additional advantage that the call to the other program
   is always performed from a separate line (not from the 'IF' or 'FOR' line),
   thus leaving more command line space for the call (especially important with
   long replaceable command line parameters).
   Alternatively programming the same algorithm may include the use of
   the NOT operator with IF's (or exclude it if it was used already) for
   reversive branching, for example:
    ┌ REM ---.BAT---                      REM ---.COM---
    │ IF «cond» batch [arguments]         IF NOT «cond» GOTO label
    │ REM The same example as the first   batch [arguments]
    │ REM one under 1.b.                  GOTO EXIT
    │ .                                   :label
    │ :                                   :
    └                                     :EXIT
   This method (reversing an IF) may NEVER be combined with FOR (FOR...DO IF...)
   because the reverse condition causes a jump out of the FOR,
   - which will never be continued to satisfy the original condition, upon
   which an action (the call) has to take place, while it should remain in the
   FOR with subsequent elements of a set until the original condition is being
   satisfied, or
   - which even continues while the original condition already has passed.
   This is furthermore not allowed, because after jumping out of a FOR the
   eventually involved %%f variable (in «cond» or batch or args) is lost.

   With regard to specific compiler differences one should develop a specific
   algorithm that works identical with both a .BAT and a .COM file and avoid
   incompatible differences.

Centrum voor Medische Informatica TNO       <Email>              |  |  |\/|
TNO Center for Medical Informatics | [e-mail]  |  \_/  |  |  |
( CMI-TNO )    | Y. Groeneveld     | [e-mail] | Jim Groeneveld
P.O.Box 124    | Wassenaarseweg 56 | [e-mail]      | Schoolweg 14
2300 AC Leiden | 2333 AL Leiden    | (21 December 1992)     | 8071 BC Nunspeet
Nederland.     | (+31|0)71-181810  | Fax (+31|0)71-176382   | 03412-60413