home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The World of Computer Software
/
World_Of_Computer_Software-02-387-Vol-3of3.iso
/
r
/
rcx10.zip
/
COMPILE.DOS
< prev
next >
Wrap
Text File
|
1992-12-21
|
10KB
|
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 | GROENEVELD@CMI.TNO.NL | \_/ | | |
( CMI-TNO ) | Y. Groeneveld | GROENEVELD@CMIHP1.UUCP | Jim Groeneveld
P.O.Box 124 | Wassenaarseweg 56 | GROENEVELD@TNO.NL | 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