home *** CD-ROM | disk | FTP | other *** search
/ Club Amiga de Montreal - CAM / CAM_CD_1.iso / files / 458.lha / TurboImploder_v3.1 / Imploder.doc < prev    next >
Encoding:
Text File  |  1990-12-28  |  11.4 KB  |  257 lines
  1.  
  2. ------------
  3. Introduction
  4. ------------
  5.  
  6. The Imploder allows you to reduce the size of executable files while letting
  7. them retain full functionality. There are other "crunchers" or "packers"
  8. available for the Amiga, but none are as mindful of the complexities of your
  9. Amiga system as the Imploder. In addition to this, its algorithms are more
  10. efficient, both in terms of speed, and size reduction. ¹
  11.  
  12. Basic operation is clicking and using pull-down menus. If you can't figure
  13. it out, you're not likely to be in need of using the Imploder anyway.
  14.  
  15. Though operating the Imploder isn't hard, the complexities of the Amiga
  16. give rise to the need for imploding different types of executable files in
  17. a number of different ways. This, and how to modify the various settings in
  18. order to effectuate proper behaviour is explained below.
  19.  
  20. Please note that not reading the manual won't inhibit you from using the
  21. Imploder; it automatically detects, and reacts to almost all exceptions,
  22. and for the vast majority files it suffices to just hit the "Proceed" gadget
  23. after loading has finished. However, if you want to make optimal use of the
  24. Imploder's capabilties, you should consult the section below. ²
  25. Also in this manual are datailed descriptions of the "explode.library" and
  26. the "FInf" utility. Enjoy.
  27.  
  28. ¹ IMHO
  29. ² preferably RTMF
  30.  
  31.  
  32. ------------
  33. The Imploder
  34. ------------
  35.  
  36. The implosion processing sequence consists of four steps;
  37. -Loading & Format Verification.
  38. -Hunk Merging & Reloc Table Cleanup.
  39. -Implosion.
  40. -Decrunch code installation, Overlay table adjustment and Saving.
  41.  
  42.  
  43. ** The Loader **
  44.  
  45. The Loader loads executable files you've specified into 1 big continuous
  46. buffer. I.a.w. in order to Implode a file, you'll need a continuous memory
  47. region as large as the file itself.
  48. During this loading process, the executable file is analyzed. Format defects
  49. cause the loader to either report an error, and abort processing, or to
  50. give a warning while ignoring or repairing the defect. The often reported
  51. warning "data hunk lengths don't match" is nothing to worry about, its given
  52. for programs that have a combined DATA & BSS hunk. This format is outside
  53. the executable file definition as given in the AmigaDOS manual, yet it is
  54. allowed by the DOS loader (which is much less critical about things).
  55.  
  56.  
  57. ** The Merger **
  58.  
  59. If selected, the merger will try to coalesce the hunks in a program. If used
  60. in a constrained manner, this will reduce the size of the program, and the
  61. chance of memory fragmentation. If you specify a large merge threshold, the
  62. resulting file will need large continuous regions of memory in order to
  63. load, thus reducing the chance of it being able to be loaded into a
  64. fragmented system.
  65. Note that the merger can be used independently of the implosion routine.
  66.  
  67. Merging an executable file might break it. This is because certain programs
  68. make assumptions about the format of their segment list. The most notable
  69. members of this group are BCPL programs and a few libraries and devices.
  70. Hunk merging is therefore automatically disallowed for these. Still, some
  71. other programs, especially selfdetaching programs might dislike being merged.
  72.  
  73. Regardless of whether a program has been merged or not, a reloc table
  74. cleanup routine is executed upon the file. This deletes empty reloc tables,
  75. coalesces matching reloc tables, and finally sorts the relocation offsets.
  76.  
  77. I've chosen for the imploder to process executables within a single
  78. buffer, without the need for additional backup buffers. Thus removing
  79. redundant information, and copying hunk data during the merging and
  80. reloc cleanup process involves moving or mirroring large parts of the
  81. buffer. This process might therefore take a while if the executable is
  82. large.
  83.  
  84.  
  85. ** The Crunch Routine **
  86.  
  87. The crunch algorithm can operate in turbo mode or in normal mode. The normal
  88. mode requires no additional memory, whereas the turbo mode needs some 300K of
  89. additional hashing buffers of which 256K must be continuous. The turbo mode
  90. kicks-in automatically whenever the required amount of additional memory can
  91. be allocated. It is about ten times faster than the normal implosion  mode.
  92. Note that the parameter window will report whether or not the current memory
  93. configuration allows the turbo to be enabled or not. You might try and free
  94. a few resources in order to make the target. Whenever you select a crunch
  95. mode (gadgets 0-8), your turbo capability will be reevaluated.
  96.  
  97. The crunch routine is responsible for the compression. The modes vary from
  98. 0 (Max. dist. = 128 bytes) to 8 (Max. dist. = 18K). The maximum distance
  99. related to each crunchmode specifies the maximum distance used when searching
  100. for redundant data. The larger crunchmodes therefore have a better chance of
  101. compressing data. As a rule of thumb, it can be said that the best results
  102. are obtained by selecting an as large as possible crunchmode given that the
  103. related maximum distance should not exceed about half the program's size.
  104. The time required to crunch a program increases proportionally to the maximum
  105. distance in case of non-turbo operation. The processing speed during turbo
  106. operation however, is only slightly affected by varying the crunch modes.
  107.  
  108.  
  109. ** Decrunch Code Installation, Overlay Table Adjustment and Saving **
  110.  
  111. The Imploder is able to install 4 different decrunch algorithms into imploded
  112. executables;
  113. Normal, Pure, Library and Overlayed.
  114.  
  115. NORMAL IMPLODED files are the default. They are generated when;
  116. -The "Crunch" gadget is enabled.
  117. -The "Library" gadget is disabled.
  118. -The program being processed is neither overlayed nor pure.
  119.  
  120. The decrunchcode of a normal imploded file scatter decrunches and relocates
  121. the program data into a collection of empty hunks that exactly resembles the
  122. hunk configuration (Segment list) of the original program (Supposing you have
  123. not applied hunk merging). The decrunching is done from a hunk containing
  124. the crunched data. This hunk is appended to the end of the segment list,
  125. and is freed when the decrunch process has completed. Thus an imploded file
  126. requires additional memory during decrunch time, yet this memory is freed
  127. after decrunching without causing memory fragmentation.
  128. Furthermore, the normal distribution of program-data across hunks is
  129. retained, thus allowing for the loading of imploded files into fragmented
  130. memory, and the proper distribution of hunks across chip and fast memory.
  131.  
  132. PURE IMPLODED files are generated when;
  133. -The "Crunch" gadget is enabled.
  134. -The "Library" gadget is disabled.
  135. -The program being processed is pure. (Has the pure bit set)
  136.  
  137. Pure imploded files are equivalent to normal imploded files, apart from the
  138. fact that the decrunch algorithm operates between a forbid and permit pair,
  139. thus preventing other processes to use the same code image before decrunching
  140. has completed.
  141.  
  142. LIBRARY IMPLODED files are generated when;
  143. -The "Crunch" gadget is enabled.
  144. -The "Library" gadget is enabled.
  145. -The processed executable isn't overlayed.
  146.  
  147. Library imploded files decrunch like normal or pure imploded files. Yet they
  148. have no decrunch code, but instead open a disk based library, and use that
  149. instead. The whole subject of the library and how it operates is rather
  150. complex. It will be described below.
  151.  
  152. OVERLAYED IMPLODED files are generated when;
  153. -The "Crunch" gadget is enabled.
  154. -the processed executable is overlayed.
  155.  
  156. Overlayed files are normal program files with additional appended hunks that
  157. are loaded during runtime. The mechanism for doing this is left upto the
  158. programmer, though a standard technique is specified in the AmigaDOS manual.
  159. The program therefore has to know at what offset in its executable the
  160. overlayed hunks start. This is communicated by means of an overlay table.
  161.  
  162. The imploder crunches the program part of overlayed files, and copies the
  163. overlay data at the end. It will try to adjust the offsets in the overlay-
  164. table accordingly. Note that because neither the format of the overlayed
  165. data nor the format of the overlay table are rigidly defined, this process
  166. might fail. If the imploder suspects that the overlay table wasn't adjusted
  167. properly it will give a warning.
  168. There is therefore no guarantee that imploding overlayed files will result
  169. in operative programs. Thus you should implode overlayed file only when you
  170. know what you are doing, and are willing to verify the results.
  171.  
  172.  
  173. -------------------------
  174. Using the explode.library
  175. -------------------------
  176.  
  177. Library imploding files is preferable, not only because the result is
  178. smaller, but also because the library is faster, and because it patches
  179. the AmigaDOS executable file loader, thus decrunching ANY executable file
  180. as soon as it is loaded into memory.
  181. Note that the Loadseg vector is patched in an "intelligent" manner; it
  182. will work for pre 1.4 kickstarts as well as BCPL free systems (1.4?)
  183.  
  184. There are a few problems though.
  185.  
  186. If library imploded files do not find the explode.library they will keep
  187. on trying to open it until they succeed. These programs will therefore
  188. hang until the LIBS: directory contains the library. A full piece of
  189. conditional startup and exit code would have nullified the advantage in
  190. using the library decruncher, which is its small size.
  191.  
  192. When a library imploded file is run from the WorkBench, and the
  193. explode.library isn't resident yet, exec will try to load the library
  194. from disk. The process's message port however is in use by the workbench
  195. reply message, and until it has been replied, it cannot be used by the
  196. DOS in order to send packets. Thus the DOS gurus.
  197.  
  198. Also, BCPL programs don't use the library jumptable. They therefore bypass
  199. the LoadSeg function patch. The result is that executables loaded from BCPL
  200. code are not automatically exploded.
  201.  
  202. Thus you should make sure the explode.library is always present in your
  203. LIBS: directory, and an early library imploded program is run in your
  204. startup-sequence in order to make sure the library makes itself resident
  205. before the WorkBench is active, or any non-program library-imploded
  206. executables are required.
  207. Also you should never crunch handlers if you don't have kick 1.4 or
  208. higher because handlers are still being loaded from BCPL code.
  209. Do not library-implode the explode.library! :-)
  210.  
  211. If you obey these restrictions, you may merrily go around your system
  212. and library-implode libraries, devices, fonts and even keymaps.
  213.  
  214.  
  215. ----
  216. DImp
  217. ----
  218.  
  219. Disk Implode can be used to crunch a subselection of tracks into a file.
  220. I will expand a bit on the meager information supplied in the info blurb.
  221.  
  222. The crunched tracks are checksummed, thus detecting errors. This checksum
  223. is done on a track by track basis, thus valid tracks can be undimped,
  224. and the originator can then select, dimp and transmit only the faulty
  225. tracks.
  226.  
  227. The track selection is done by specifying tracknumbers, separated by
  228. commas or minusses. A minus specifies a range, and commas separate
  229. individual tracks or ranges. Thus valid selections are;
  230.  
  231. "0" "0-79" "40-79,0" "0,2,4,8" or "0-39,41-79"
  232.  
  233. The crunchmode and implosion algorithm function in a similar manner to those
  234. in the Imploder. The turbo mode is enabled whenever the resources are
  235. available, dimping a normal disk in just a few minutes!
  236.  
  237. The -E options generates an overlayed executable file. This file can undimp
  238. itself by exploding and writing the track data present in its own  overlay
  239. section. People receiving files DImped in this manner need not possess a copy
  240. of DImp in order to recreate the tracks. Executable DImp files are about 3K
  241. longer than normal DImp files.
  242.  
  243. The +<filename> option allows you to include a readme message that is
  244. displayed when the file is undimped.
  245.  
  246. The INFO operation mode shows the contents, type and readme msg of a DImp
  247. file.
  248.  
  249. --------
  250. FInf
  251. --------
  252.  
  253. File Info .......
  254.  
  255.  
  256. #AJ
  257.