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 >
Text File  |  1992-12-21  |  10KB  |  172 lines

  1. COMPILE.DOS - Instructions for adapting BATch files for compiling.
  2.  
  3. Introduction.
  4.  
  5. Due to the different nature of .BAT and .COM or .EXE files batch scripts
  6. to be compiled should necessaryly undergo some specific changes in order
  7. to functionally work similar to the original .BAT. After these changes
  8. the programs do not necessaryly work correctly anymore as a .BAT file.
  9. That's why they should be renamed to another extension, e.g. .B2C.
  10.  
  11. The differences mainly concern the calling of other .BAT files from a .BAT
  12. file, either with or without using the CALL statement. (Instead of a CALL
  13. command, which was introduced with DOS version 3.3, the statement
  14. COMMAND/C might be used. For older DOS versions I have written an external
  15. program called CALL.COM that is functionally the same as the DOS CALL
  16. command and that may be used with older DOS version without changing
  17. 'CALL' in newer .BAT files into 'COMMAND/C'.)
  18.  
  19. If a .BAT file starts another one without a CALL prefix the called .BAT
  20. gets run, while the calling .BAT file will not be continued (returned into)
  21. after the second one finishes. Doing so from a compiled batch script
  22. causes the calling program to run further from the point the second
  23. one (a .BAT or .COM or .EXE) was started. This is the main difference.
  24.  
  25. If a .BAT file starts another one with a CALL prefix, intending to finish
  26. the first one after the second one, this will yield no difference between
  27. a batch file and a compiled one. But the CALL prefix is redundant and may
  28. be left out (it takes some memory), but that isn't quite necessary.
  29.  
  30. If a .BAT file calls a .COM or .EXE file it always continues from that point
  31. after the second program has finished. This also applies to a compiled batch
  32. script. A CALL prefix is not necessary in both instances.
  33.  
  34. If another .BAT file calls a .BAT file that has been compiled (thus in fact 
  35. calling the .COM file) this may have consequences for the other .BAT file's 
  36. course. If the called .BAT (now .COM) file originally was called with the CALL 
  37. prefix there is no difference, because in both cases control is returned to the 
  38. other .BAT file (though the prefix CALL might be removed). If the called 
  39. original .BAT was called without the CALL prefix, thus inducing no return to 
  40. the other .BAT file from the called one, a return will actually take place 
  41. after finishing the .COM file.  
  42.  
  43. Adaptation instructions.
  44.  
  45. 1. Regulating the course of a compiled batch file after returning to it from
  46.    calling another batch file or itself (%0) recursively:
  47.    (a .COM file will be continued after calling anything)
  48.    a. after the call (without the prefix 'CALL') add the command line
  49.       'GOTO EXIT' and include a label ':EXIT' at the very end of the file.
  50.     ┌ REM ---.BAT---                      REM ---.COM---
  51.     │ batch [arguments]                   batch [arguments]
  52.     │ .                                   GOTO EXIT
  53.     │ :                                   :
  54.     └                                     :EXIT
  55.    b. at 'FOR's and 'IF's where the second batch or %0 (itself) is called
  56.       (without 'CALL') change that into 'GOTO LABEL' (any choosen label) and
  57.       call the secondary one or %0 (etc.) from there (after defining the label)
  58.       and after that add the line 'GOTO EXIT' (':EXIT' label at the very end).
  59.     ┌ REM ---.BAT---                      REM ---.COM---
  60.     │ IF «cond» batch [arguments]         IF «cond» GOTO label
  61.     │ :                                   :
  62.     │ .                                   :label
  63.     │ .                                   batch [arguments]
  64.     │ .                                   GOTO EXIT
  65.     │ :                                   :
  66.     └                                     :EXIT
  67.     ┌ REM ---.BAT---                      REM ---.COM---
  68.     │ FOR %%f IN (set) DO batch [args]    FOR %%f IN (set) DO GOTO label
  69.     │ REM This command starts batch if    :
  70.     │ REM set is not empty for its first  :label
  71.     │ REM value.                          batch [args]
  72.     │ REM Thus batch is only run once     GOTO EXIT
  73.     │ REM (or even never).                :
  74.     └                                     :EXIT
  75.     ┌ REM ---.BAT---                      REM ---.COM---
  76.     │ FOR %%f IN (set) DO IF «cond» batch FOR %%f IN (set) DO IF «cond» GOTO lbl
  77.     │ REM This command starts batch if    REM Only useful if «cond» involves %%f
  78.     │ REM set is not empty and «cond»     :lbl
  79.     │ REM is true for the _first_ time.   batch
  80.     │ REM Thus batch is only run once     GOTO EXIT
  81.     │ REM (or even never).                :
  82.     └                                     :EXIT
  83.     ┌ REM ---.BAT---                      REM ---.COM---
  84.     │ IF...FOR...DO batch [arguments]     REM Similar to FOR...IF...DO etc.
  85.     │ REM Such a construct always can be
  86.     │ REM split (as well as the construct
  87.     │ FOR %%f IN (set) DO IF «cond» etc.
  88.     │ REM if «cond» does NOT involve %%f)
  89.     │ REM into:
  90.     │ IF «cond» GOTO FORlabel             IF «cond» GOTO FORlabel
  91.     │ :IFlabel                            :IFlabel
  92.     │ :                                   :
  93.     │ :FORlabel                           :FORlabel
  94.     │ FOR %%f IN (set) DO batch [args]    FOR %%f IN (set) DO GOTO label
  95.     │ GOTO IFlabel                        GOTO IFlabel
  96.     │ REM This command starts batch if    :
  97.     │ REM set is not empty for its first  :label
  98.     │ REM value.                          batch [args]
  99.     │ REM Thus batch is only run once     GOTO EXIT
  100.     │ REM (or even never).                :
  101.     └                                     :EXIT
  102.       This, however, is not possible if the call itself actually involves the 
  103.       variable used with the 'FOR', e.g. 'FOR %%F IN (*.BAT) DO %%F', which is
  104.       being resolved only once, for the first .BAT file found, if uncompiled,
  105.       but resolves to multiple commands, for every .BAT file, if compiled. But
  106.       this construct is not quite functional and hardly occurs. Besides, the
  107.       %%f variable gets lost outside a FOR.
  108.     ┌ REM ---.BAT---                      REM ---.COM---
  109.     └ FOR %%f IN (set) DO %%f [args %%f]  REM Incompatible, rare, run only once
  110.    c. at calls to other batch programs that include the prefix CALL that prefix
  111.       only may be removed; do _NOT_ follow these lines with 'GOTO EXIT'.
  112.     ┌ REM ---.BAT---                      REM ---.COM---
  113.     │ [FOR...DO][IF...] CALL batch [args] [FOR...DO][IF...] [CALL] batch [args]
  114.     └ REM Both batch or args may involve the %%f variable from the FOR.
  115.    With cases a. and b. the original calling .BAT file wasn't kept loaded in
  116.    memory after passing control to the called .BAT file. If compiled the
  117.    original calling .COM program remains loaded however (and will finally only
  118.    execute the 'GOTO EXIT' and ':EXIT' lines). This can not be altered and thus
  119.    running a compiled batch file may require more memory than an uncompiled one.
  120.    If it calls itself (or other compiled batch files) multiple times (originally
  121.    without the CALL prefix) this will require even a lot more memory because the
  122.    copies will be loaded on top of each other.
  123.  
  124. 2. Regulating the course of _another_ batch file calling a compiled one:
  125.    In order to (intentionally) cause the remainder of the other .BAT file not 
  126.    to execute its remainder a 'GOTO EXIT' line should explicitely be inserted 
  127.    after the calling line and an ':EXIT' label line at the very end of the 
  128.    other .BAT file. This is equivalent to the adaptations discussed under 1.  
  129.  
  130. 3. Other necessary adaptations depend heavyly on the compiler used. One of
  131.    them (BAT2EXEC vs. 1.5) shows some differences (and even unrecoverable
  132.    bugs) with the standard DOS batch language. These differences and their
  133.    consequences have to be taken into account when preparing .BAT files for
  134.    compiling. Specific differences are described in the document BAT2EXEC.BUG.
  135.  
  136. 4. In order to write always-compiler-compatible .BAT files one should always 
  137.    include the above mentioned adaptations, but leave the CALL prefix in its 
  138.    place. This has the additional advantage that the call to the other program 
  139.    is always performed from a separate line (not from the 'IF' or 'FOR' line), 
  140.    thus leaving more command line space for the call (especially important with 
  141.    long replaceable command line parameters).  
  142.    Alternatively programming the same algorithm may include the use of
  143.    the NOT operator with IF's (or exclude it if it was used already) for 
  144.    reversive branching, for example:
  145.     ┌ REM ---.BAT---                      REM ---.COM---
  146.     │ IF «cond» batch [arguments]         IF NOT «cond» GOTO label
  147.     │ REM The same example as the first   batch [arguments]
  148.     │ REM one under 1.b.                  GOTO EXIT
  149.     │ .                                   :label
  150.     │ :                                   :
  151.     └                                     :EXIT
  152.    This method (reversing an IF) may NEVER be combined with FOR (FOR...DO IF...)
  153.    because the reverse condition causes a jump out of the FOR, 
  154.    - which will never be continued to satisfy the original condition, upon 
  155.    which an action (the call) has to take place, while it should remain in the 
  156.    FOR with subsequent elements of a set until the original condition is being 
  157.    satisfied, or 
  158.    - which even continues while the original condition already has passed. 
  159.    This is furthermore not allowed, because after jumping out of a FOR the 
  160.    eventually involved %%f variable (in «cond» or batch or args) is lost.  
  161.  
  162.    With regard to specific compiler differences one should develop a specific 
  163.    algorithm that works identical with both a .BAT and a .COM file and avoid
  164.    incompatible differences.  
  165.  
  166. Centrum voor Medische Informatica TNO       <Email>              |  |  |\/|
  167. TNO Center for Medical Informatics | GROENEVELD@CMI.TNO.NL  |  \_/  |  |  |
  168. ( CMI-TNO )    | Y. Groeneveld     | GROENEVELD@CMIHP1.UUCP | Jim Groeneveld
  169. P.O.Box 124    | Wassenaarseweg 56 | GROENEVELD@TNO.NL      | Schoolweg 14
  170. 2300 AC Leiden | 2333 AL Leiden    | (21 December 1992)     | 8071 BC Nunspeet
  171. Nederland.     | (+31|0)71-181810  | Fax (+31|0)71-176382   | 03412-60413
  172.