home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Fish 'n' More 2
/
fishmore-publicdomainlibraryvol.ii1991xetec.iso
/
dirs
/
imploder_422.lzh
/
Imploder
/
Imploder.doc
< prev
next >
Wrap
Text File
|
1990-12-31
|
12KB
|
257 lines
------------
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 +<filename> 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