home *** CD-ROM | disk | FTP | other *** search
/ Club Amiga de Montreal - CAM / CAM_CD_1.iso / files / 118.lha / Rez.3 / REZ.doc < prev    next >
Encoding:
Text File  |  1986-11-21  |  9.8 KB  |  233 lines
  1. **************************************************************************
  2. ***************************************************************************
  3. *****                                                                 *****
  4. *****  REZ is Copyright (C) 1988 by Jim Goodnow II and the binary     *****
  5. *****  is freely redistributable except that it may not be included   *****
  6. *****  as part of any commercial software package without my express  *****
  7. *****  written permission.                                            *****
  8. *****                                                                 *****
  9. ***************************************************************************
  10. ***************************************************************************
  11.  
  12.  
  13.         REZ - a general purpose resident program command.
  14.         ---
  15.  
  16.                    Version 0.3
  17.  
  18.                  Copyright 1988
  19.                 by Jim Goodnow II
  20.  
  21.  
  22.                     BackGround
  23.                     ----------
  24.  
  25. Normally when programs are run on the Amiga, a copy of the program is
  26. read into memory from the appropriate file system. This is known as
  27. loading the program. Then the CODE and DATA segments are adjusted to
  28. reflect the actual location of the program in memory. This is known
  29. as relocating the program. Finally, the relocated program is allowed
  30. to execute.
  31.  
  32. This process is repeated each and every time a program is run, no matter
  33. how many times it is run. In addition, if the same program is started
  34. multiple times, like running several of the Boxes demos simultaneously,
  35. a copy of the program is made for each one run.
  36.  
  37. However, there is another way of loading and running programs that is
  38. much more efficient. It is called making programs resident. When a
  39. program is made resident, it is loaded into memory just once. Some or
  40. all of the relocation is performed at the initial load. Then, when
  41. the program is needed, it is used directly from memory, and when the
  42. program finishes, the program is left in memory for the next execution.
  43.  
  44. This explanation has been slightly oversimplified, and a more detailed
  45. explanation can be found in the technical section at the end of this
  46. document.
  47.  
  48.  
  49.                     OverView
  50.                     --------
  51.  
  52. The operation of REZ is very simple. A list is maintained in memory of
  53. the names of those programs which are desired to be resident. When any
  54. of the programs are first loaded into memory REZ automatically notices
  55. that the program being loaded is to be resident and does the special
  56. REZ load on it. Anytime after the first time, the resident version of
  57. the program will be used.
  58.  
  59. What this means is that you can tell REZ that you want a whole slew of
  60. programs to be in the resident list, but only those programs that you
  61. actually run will actually get loaded into memory. The first time you
  62. run each one it will load about as fast as it would without REZ, but
  63. every time after it will be almost instantaneous.
  64.  
  65. So, the simplest way to use REZ is to just execute (maybe in your
  66. s:startup-sequence file):
  67.  
  68.     REZ dir ls copy cd cc as ln make z
  69.  
  70. You can specify as many filenames as you want to since REZ maintains
  71. a linked list of the names.
  72.  
  73. You can see the status of the resident name list by typing REZ with no
  74. arguments. This will produce a display that looks like:
  75.  
  76. Name        Active  Status      Total  Pure  Share  Chk  Type
  77. cc             0    Loaded         7   No    Yes     OK  Aztec C 3.4/3.6
  78. as             0    Loaded        10   No    Yes     OK  Aztec C 3.4/3.6
  79. ln             0    Loaded         2   No    Yes     OK  Aztec C 3.4/3.6
  80. z              1    In Use         7   No    Yes     OK  Aztec C 3.4/3.6
  81. delete         0    Loaded         1   Yes   Yes*   > 0  BCPL
  82. copy           0    Not Loaded     0   ?     ?        ?  
  83. cd             0    Not Loaded     0   ?     ?        ?  
  84.  
  85. The first column displays the name of the program. The next two columns are
  86. related. The first shows the number of programs actively sharing the Code
  87. part of this program. The second one shows the status of the program which
  88. is either not loaded, loaded but not executing, or actually in use. The
  89. next column labelled Total shows the number of times this program has been
  90. executed since being made resident.
  91.  
  92. The next column indicates whether a program has any absolute references
  93. to Data from Code. If it does not, then it is considered Pure. This is
  94. important and is reflected in the next column called Share. Each program
  95. must have it's own individual Data area. If the Code contains absolute
  96. references to the Data area, it is not possible to use that Code with
  97. multiple Data areas. There are other restrictions as well, but normally
  98. if a program is Pure, it will also be Shareable.
  99.  
  100. Which brings us to the Share column. If a program is not Pure, then
  101. it can't be shared except for some special cases. REZ automatically
  102. detects these special cases and takes advantage of them and sets a
  103. Yes in this column. More detailed information can be found in the
  104. technical information section.
  105.  
  106. The other requirement for being Shareable is that the Code segment
  107. can not be modified. When a program is made resident, REZ computes
  108. a checksum for each Code segment in the program. When the list of
  109. resident programs is displayed, REZ recomputes the checksum and
  110. normally an OK is displayed.
  111.  
  112. However, if a segment has been modified,  then the number of the segment
  113. will be displayed followin a '>'. In addition, if the program is Shareable,
  114. REZ will automatically disable sharing which is indicated by an asterisk
  115. following the "Yes" in the Share column. (See the "-c" option for automatic
  116. checking.)
  117.  
  118. The final column makes an attempt to guess which language was used
  119. to produce the program and is not guaranteed to be accurate, it just
  120. seemed like useful information.
  121.  
  122. ******************** DISCLAIMER ****************************
  123.  
  124. Despite rumors to the contrary, REZ does not slow down, add
  125. bugs or in any way treat programs not produced with Aztec C
  126. in any special manner.  ;-)
  127.  
  128. ************************************************************
  129.  
  130.  
  131.                     Options
  132.                     -------
  133.  
  134. REZ has a number of options which can be referenced by using the "-?"
  135. option which will produce the following display:
  136.  
  137.   REZ   Version 0.1   2-10-88    by Jim Goodnow II
  138.  
  139.   <no args>  display the list
  140.   -a name    add name to list (default)
  141.   -c         toggle auto checksum
  142.   -f name    parse lines from file
  143.   -k         unload all programs
  144.   -l name    load name into memory
  145.   -n name    add name as non-sharing
  146.   -r name    remove name from list
  147.   -u name    unload name from memory
  148.   -?         display this message
  149.  
  150. REZ without any arguments shows the status display discussed in the
  151. overview. Otherwise, the remaining arguments can be mixed together
  152. and affect files until a different argument is detected. For example,
  153. the line:
  154.  
  155.     REZ f1 f2 -r x1 x2
  156.  
  157. will add the files "f1" and "f2" since -a is the default, and will
  158. remove files "x1" and "x2". We will now discuss each option in detail. 
  159.  
  160. The "-a" add option simply adds the name(s) to the in-memory list
  161. if not already on the list. Names should not contain '/' or ':'
  162. characters as they are not necessary and may prevent REZ from
  163. detecting the program load.
  164.  
  165. The "-n" add with no share option is the same as the "-a" option
  166. but it prevents the program from being marked as shareable.
  167.  
  168. The "-l" load option forces the program(s) named to be loaded but not
  169. executed. This usually requires that the program be in the current
  170. directory since REZ will not search the PATH. When a program is run,
  171. it is automatically loaded, so this option is not normally needed.
  172.  
  173. The "-u" unload option forces the program(s) named to have the memory
  174. associated with them freed up. However, the name will remain in the
  175. resident list. If the program is currently executing, the unload will
  176. be delayed until the last active copy is finished.
  177.  
  178. The "-r" remove option removes the named program(s) from the resident
  179. list. If the program is loaded, it is unloaded first. If the program
  180. is in use, unloading and removal are delayed until all active copies
  181. have finished.
  182.  
  183. The "-k" kill option does a remove on all the programs currently in
  184. the resident list.
  185.  
  186. The "-c" checksum option is a toggle which defaults to OFF. When
  187. enabled, it forces REZ to perform a checksum on the Code segments
  188. of each program when it finishes executing. This is important the
  189. first few times you make some new programs resident if you plan
  190. to run multiple copies of the programs simultaneously. It will
  191. disable sharing if it discovers that the Code segment has been
  192. corrupted.
  193.  
  194. The "-f" file option parses lines from the named file for options
  195. and names as described above. Files may not be nested, however
  196. multiple "-f" options may be given.
  197.  
  198.  
  199.                     Limitations
  200.                     -----------
  201.  
  202. There are only two limitations to REZ that I know of. First, programs
  203. that use the AmigaDOS overlay facility are detected by REZ and are
  204. not loaded. I now how to handle it, but it may wait till a later
  205. version.
  206.  
  207. Second, programs that are started by LoadSeg(), but don't use
  208. UnLoadSeg() to free their segments may cause trouble. This is
  209. because REZ doesn't know that the memory has been freed and
  210. will use the same memory for the next LoadSeg(). The most common
  211. examples of this are programs which detach from the CLI. Since
  212. these programs tend to be run once this is not a real problem.
  213. DB is another example that can be more problematic.
  214.  
  215.  
  216.                     Implementation
  217.                     --------------
  218.  
  219. REZ is implemented by replacing the internal LoadSeg() and
  220. UnLoadSeg() vectors of AmigaDOS. The replaced vectors point
  221. to a Exec type library which contains a loader and routines
  222. for managing the resident list. The REZ program performs most
  223. of its functions by making calls to the REZ.LIBRARY.
  224.  
  225.  
  226.                     Technical Information
  227.                     ---------------------
  228.  
  229. This information will be supplied with the official release of
  230. program.
  231.  
  232.  
  233.