------------ Introduction ------------ The Imploder allows you to reduce the size of executable files while letting them retain full functionality. There are other "crunchers" or "packers" available for the Amiga, but none are as mindful of the complexities of your Amiga system as the Imploder. In addition to this, its algorithms are more efficient, both in terms of speed, and size reduction. ¹ Basic operation is clicking and using pull-down menus. If you can't figure it out, you're not likely to be in need of using the Imploder anyway. Though operating the Imploder isn't hard, the complexities of the Amiga give rise to the need for imploding different types of executable files in a number of different ways. This, and how to modify the various settings in order to effectuate proper behaviour is explained below. Please note that not reading the manual won't inhibit you from using the Imploder; it automatically detects, and reacts to almost all exceptions, and for the vast majority files it suffices to just hit the "Proceed" gadget after loading has finished. However, if you want to make optimal use of the Imploder's capabilties, you should consult the section below. ² Also in this manual are datailed descriptions of the "explode.library" and the "FInf" utility. Enjoy. ¹ IMHO ² preferably RTMF ------------ The Imploder ------------ The implosion processing sequence consists of four steps; -Loading & Format Verification. -Hunk Merging & Reloc Table Cleanup. -Implosion. -Decrunch code installation, Overlay table adjustment and Saving. ** The Loader ** The Loader loads executable files you've specified into 1 big continuous buffer. I.a.w. in order to Implode a file, you'll need a continuous memory region as large as the file itself. During this loading process, the executable file is analyzed. Format defects cause the loader to either report an error, and abort processing, or to give a warning while ignoring or repairing the defect. The often reported warning "data hunk lengths don't match" is nothing to worry about, its given for programs that have a combined DATA & BSS hunk. This format is outside the executable file definition as given in the AmigaDOS manual, yet it is allowed by the DOS loader (which is much less critical about things). ** The Merger ** If selected, the merger will try to coalesce the hunks in a program. If used in a constrained manner, this will reduce the size of the program, and the chance of memory fragmentation. If you specify a large merge threshold, the resulting file will need large continuous regions of memory in order to load, thus reducing the chance of it being able to be loaded into a fragmented system. Note that the merger can be used independently of the implosion routine. Merging an executable file might break it. This is because certain programs make assumptions about the format of their segment list. The most notable members of this group are BCPL programs and a few libraries and devices. Hunk merging is therefore automatically disallowed for these. Still, some other programs, especially selfdetaching programs might dislike being merged. Regardless of whether a program has been merged or not, a reloc table cleanup routine is executed upon the file. This deletes empty reloc tables, coalesces matching reloc tables, and finally sorts the relocation offsets. I've chosen for the imploder to process executables within a single buffer, without the need for additional backup buffers. Thus removing redundant information, and copying hunk data during the merging and reloc cleanup process involves moving or mirroring large parts of the buffer. This process might therefore take a while if the executable is large. ** The Crunch Routine ** The crunch algorithm can operate in turbo mode or in normal mode. The normal mode requires no additional memory, whereas the turbo mode needs some 300K of additional hashing buffers of which 256K must be continuous. The turbo mode kicks-in automatically whenever the required amount of additional memory can be allocated. It is about ten times faster than the normal implosion mode. Note that the parameter window will report whether or not the current memory configuration allows the turbo to be enabled or not. You might try and free a few resources in order to make the target. Whenever you select a crunch mode (gadgets 0-8), your turbo capability will be reevaluated. The crunch routine is responsible for the compression. The modes vary from 0 (Max. dist. = 128 bytes) to 8 (Max. dist. = 18K). The maximum distance related to each crunchmode specifies the maximum distance used when searching for redundant data. The larger crunchmodes therefore have a better chance of compressing data. As a rule of thumb, it can be said that the best results are obtained by selecting an as large as possible crunchmode given that the related maximum distance should not exceed about half the program's size. The time required to crunch a program increases proportionally to the maximum distance in case of non-turbo operation. The processing speed during turbo operation however, is only slightly affected by varying the crunch modes. ** Decrunch Code Installation, Overlay Table Adjustment and Saving ** The Imploder is able to install 4 different decrunch algorithms into imploded executables; Normal, Pure, Library and Overlayed. NORMAL IMPLODED files are the default. They are generated when; -The "Crunch" gadget is enabled. -The "Library" gadget is disabled. -The program being processed is neither overlayed nor pure. The decrunchcode of a normal imploded file scatter decrunches and relocates the program data into a collection of empty hunks that exactly resembles the hunk configuration (Segment list) of the original program (Supposing you have not applied hunk merging). The decrunching is done from a hunk containing the crunched data. This hunk is appended to the end of the segment list, and is freed when the decrunch process has completed. Thus an imploded file requires additional memory during decrunch time, yet this memory is freed after decrunching without causing memory fragmentation. Furthermore, the normal distribution of program-data across hunks is retained, thus allowing for the loading of imploded files into fragmented memory, and the proper distribution of hunks across chip and fast memory. PURE IMPLODED files are generated when; -The "Crunch" gadget is enabled. -The "Library" gadget is disabled. -The program being processed is pure. (Has the pure bit set) Pure imploded files are equivalent to normal imploded files, apart from the fact that the decrunch algorithm operates between a forbid and permit pair, thus preventing other processes to use the same code image before decrunching has completed. LIBRARY IMPLODED files are generated when; -The "Crunch" gadget is enabled. -The "Library" gadget is enabled. -The processed executable isn't overlayed. Library imploded files decrunch like normal or pure imploded files. Yet they have no decrunch code, but instead open a disk based library, and use that instead. The whole subject of the library and how it operates is rather complex. It will be described below. OVERLAYED IMPLODED files are generated when; -The "Crunch" gadget is enabled. -the processed executable is overlayed. Overlayed files are normal program files with additional appended hunks that are loaded during runtime. The mechanism for doing this is left upto the programmer, though a standard technique is specified in the AmigaDOS manual. The program therefore has to know at what offset in its executable the overlayed hunks start. This is communicated by means of an overlay table. The imploder crunches the program part of overlayed files, and copies the overlay data at the end. It will try to adjust the offsets in the overlay- table accordingly. Note that because neither the format of the overlayed data nor the format of the overlay table are rigidly defined, this process might fail. If the imploder suspects that the overlay table wasn't adjusted properly it will give a warning. There is therefore no guarantee that imploding overlayed files will result in operative programs. Thus you should implode overlayed file only when you know what you are doing, and are willing to verify the results. ------------------------- Using the explode.library ------------------------- Library imploding files is preferable, not only because the result is smaller, but also because the library is faster, and because it patches the AmigaDOS executable file loader, thus decrunching ANY executable file as soon as it is loaded into memory. Note that the Loadseg vector is patched in an "intelligent" manner; it will work for pre 1.4 kickstarts as well as BCPL free systems (1.4?) There are a few problems though. If library imploded files do not find the explode.library they will keep on trying to open it until they succeed. These programs will therefore hang until the LIBS: directory contains the library. A full piece of conditional startup and exit code would have nullified the advantage in using the library decruncher, which is its small size. When a library imploded file is run from the WorkBench, and the explode.library isn't resident yet, exec will try to load the library from disk. The process's message port however is in use by the workbench reply message, and until it has been replied, it cannot be used by the DOS in order to send packets. Thus the DOS gurus. Also, BCPL programs don't use the library jumptable. They therefore bypass the LoadSeg function patch. The result is that executables loaded from BCPL code are not automatically exploded. Thus you should make sure the explode.library is always present in your LIBS: directory, and an early library imploded program is run in your startup-sequence in order to make sure the library makes itself resident before the WorkBench is active, or any non-program library-imploded executables are required. Also you should never crunch handlers if you don't have kick 1.4 or higher because handlers are still being loaded from BCPL code. Do not library-implode the explode.library! :-) If you obey these restrictions, you may merrily go around your system and library-implode libraries, devices, fonts and even keymaps. ---- DImp ---- Disk Implode can be used to crunch a subselection of tracks into a file. I will expand a bit on the meager information supplied in the info blurb. The crunched tracks are checksummed, thus detecting errors. This checksum is done on a track by track basis, thus valid tracks can be undimped, and the originator can then select, dimp and transmit only the faulty tracks. The track selection is done by specifying tracknumbers, separated by commas or minusses. A minus specifies a range, and commas separate individual tracks or ranges. Thus valid selections are; "0" "0-79" "40-79,0" "0,2,4,8" or "0-39,41-79" The crunchmode and implosion algorithm function in a similar manner to those in the Imploder. The turbo mode is enabled whenever the resources are available, dimping a normal disk in just a few minutes! The -E options generates an overlayed executable file. This file can undimp itself by exploding and writing the track data present in its own overlay section. People receiving files DImped in this manner need not possess a copy of DImp in order to recreate the tracks. Executable DImp files are about 3K longer than normal DImp files. The + option allows you to include a readme message that is displayed when the file is undimped. The INFO operation mode shows the contents, type and readme msg of a DImp file. -------- FInf -------- File Info ....... #AJ