** Features **

Library-imploding files is preferable, not only because the result is
smaller, but also because the library is faster, and able to patch the
AmigaDOS executable file loader (LoadSeg), thus decompressing ANY type
of load file as soon as it is loaded into memory, e.g. fonts, devices,
libraries, etc.

If you only library-implode program files, the library will be loaded
when you run a library imploded program for the first time. However if
you wish to implode non-program executables, you'll have to make sure
the library is already resident because these won't load properly until
LoadSeg has been wedged. If you're not yet using the 2.0 OS, there is a
slight complication explained in the section at the end of this document.

To make sure the library is resident, we've provided a small program that
can be run at the head of your startup sequence. It's called "ExpLoad"
and resides in the tools subdirectory. All it does is open the explode 
library. Once this is done, the library hooks itself into DOS and remains
resident, even when a system flush occurs.

Note that it suffices to run a library imploded program to make the
library resident, but this is less visible so you might forget about it
when you modify your startup-sequence later on.

Once you've made sure the library is resident, you may merrily go around
your system and library-implode libraries, devices, fonts and even keymaps!

By default the Imploder appends a foolproof piece of startup code to
library imploded files. This checks whether the library is present.
If not it will print an error. If started from the WorkBench a tiny
window will be opened to display the error message.

However this error checking takes up a bit of space, and is redundant
when you make sure the library is resident. For this reason you can
specify the SHORTROOT tooltype/switch. When set, the Imploder will
append only short startup code to library imploded files. This saves
about 250 bytes for every executable.

If library imploded programs with a short root 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.

Still, using the SHORTROOT switch has its advantages. The reason it is not
enabled by default is to make sure that people have read this document
first.


** Pre-2.0 problems **

If you are NOT using 2.0 or some newer OS, there are a few additional
problems related to BCPL braindeadness, so if you're still running 1.3 or
less, READ THIS!

Under a pre 2.0 OS, if you run a library imploded program generated with
the SHORTROOT option from the WorkBench, while the library hasn't been made
resident yet, the system will guru. This is a problem caused by the OS.
The default library startup code checks for this condition, and will exit
cleanly after reporting an error.

So under 1.3 or less it is advisable to make the explode.library resident
before the WorkBench is active, e.g. early in your startup sequence, even
when you're using library imploded non-program executables;
The first invocation of a library imploded program might happen from the
WorkBench.

In addition to this it is best not to library implode handlers under pre
2.0. See the Techno document for an in depth explanation of these issues.


** Conclusion **

Library implosion limits the possibility of passing on one's executables
to other people/systems who/that do not have the explode.library installed.
I think this doesn't really matter because I strongly believe people
should be left the option of deciding in what way, if at all, they are
going to compress/install executables. (See the "Philosophy" document
for a more extensive discussion of this issue).

Evidently, using library imploded files is the most transparent to the
system. We personally recommend using mostly library implosion, and only
in special cases normal implosion, or overlay implosion for the odd
overlayed file one might encounter.