The Explode Library in general terms. ------------------------------------- This directory contains the explode library. Copy it to the LIBS: directory of your system disk if you intend to use library imploded files. There are some things you should know before deciding to do so. Library imploded files do not need to contain a full copy of the decrunch code. Instead they use shared code from a disk based library. This makes them some 500 bytes shorter than normal imploded files. *** On the other hand: *** 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. While using library imploded files, a bug in the operating system surfaced. When a program being runned from the Workbench tries to open a disk based library before the WorkBench startup message has been replied, a guru will occur if this disk based library is not already present in memory and therefore must be loaded from disk. As always this bug is due to the DOS. If the library is present in memory, things work just fine (because the DOS is not needed). Because programs contain their own WorkBench message reply code, the library decruncher cannot reply this message for them. Thus the explode library must be opened whilst the workbench message has not yet been replied. *** Conclusion: *** Preferably do NOT use library imploded files. Using the Explode Library. -------------------------- Now if all this doesn't deter you, let's proceed to explain how to make the best use of the library and its associated programs. Using the explode library places certain restrictions on the kind of system you operate. It must never occur that you try to run library imploded programs from systems in which the library is not installed. Preferably you use only one or a limited number of system disks. Hard-drive owners will have little problem achieving this. Having made sure the library can be found in LIBS: at any time, we continue with making sure that the explode.library is present in memory before the WorkBench is up and running. This is needed because of the problem with disk-based libraries outlined in the previous section. The best way to do install the library, is to use at least one library imploded command in your startup-sequence before the LoadWB command. The explode library makes sure it remains resident after its first use so you can be sure it remains present in memory after having used any library imploded program or command. *** InitLib *** To aid you in the task of managing the presence of the explode library, we have included a little program called "InitLib" in this directory/drawer. It can report 3 possible situations back to you: 1. "Not Available" ; The library was not found in your current LIBS: directory and it was not present in memory 2. "Already Resident" ; The library was already present in memory 3. "Initialized" ; The library was found in LIBS: and initialized You may run InitLib from either CLI or WorkBench. Be sure not to library- implode this command or it won't be able to report "Not Available". To avoid confusion it must be said that InitLib does not initialize the library if it can't be found in LIBS:. Possible uses for InitLib are checking if the library is present when operating on a foreign system, or being the first command in the startup-sequence. InitLib does not need to be present in your startup-sequence for the explode.library to be initialized. An arbitrary library-imploded command will do. It does look neat though. InitLib is pure an may therefore be made resident. *** The Explode Library and pure commands *** Since version 1.3 of the Amiga O.S. the WorkBench includes the option to make pure programs resident. If a program is pure, its code and data remain constant throughout any operation conducted by the program. This allows the code (if present in memory) to be used by multiple processes. With the "Resident" command you can tell AmigaDOS to take a pure program/command and make it reside in memory. If you do this to f.e. Dir, and you simultaniously issue the Dir command from two separate shells, those shells's processes will both run the same memory resident code. Why is this useful? Commands treated in this way won't have to be loaded from your C: directory and only one copy of the code is needed in memory eventhough multiple processes use the code. A drawback is that resident commands do occupy memory even when they are not being used. So what does this have to do with the explode library? As you may have noted it pays to make small often used commands resident. These are precisely the kind of programs you might want to library-implode. But wait a minute, crunched programs decrunch themselves when being runned and are therefore self-modifying and thus not pure. What happens to library-imploded programs that are made resident is that when they are made resident, they are loaded into memory without decrunching. The first time they are used, the decruncher makes sure only one process can enter the code, and it starts decrunching. After decrunching the decrunch buffers are deallocated, and the code looks just as it would be after loading the not library imploded program version. The same goes for 'pure' imploded programs, apart from the fact that a small remainder of the appended pure decruncher (80 bytes) will remain resident too. So where is the problem? One generally uses the Resident command to make an entire list of commands resident at system startup time. Thus the make-things-resident batchfile, which contains this list (normally called "StartupII"), loads the specified commands into memory, one after the other . Some or all of these commands might be library imploded, and will therefore occupy about 1.6 times the amount of memory they actually need until they are decrunched. Decrunching takes place when you use the command for the first time. Until that time the memory won't be freed. OK, you say, but I'm sure to use my resident commands quite quickly so this problem is really very temporary, isn't it?. Well, it is in terms of absolute memory availability, but remember that a lot of these small library imploded programs are made resident in sequence, and when decrunched the commands will be separated by a lot of tiny holes of memory. These tiny holes contribute to the memory fragmentation inside your system. The more fragmented your memory, the less the chance of finding sufficiently large continuous chunks of memory for running programs and opening screens. The solution is to run library-imploded programs immediately after they are made resident. Part of your startupII might therefore be made to look something like this: Resident sys:c/Run run >nil: Resident sys:c/Path path >nil: Resident sys:c/List list >nil: t: * t: is empty so list executes quickly Resident sys:c/Dir dir >nil: t: Resident sys:c/FInf FInf >nil: t: Resident sys:c/Avail avail >nil: Resident sys:c/Info info >nil: Eventhough this method is far from being elegant, it does pay if you intend to make a lot of library-imploded commands resident. *** The Explode Library and LoadSeg *** The DOS provides a function that allows one to load executable files into memory. This function takes care of allocating memory, loading the program's segments and relocating absolute addressing commands. This function is called LoadSeg. When we created the explode library we reasoned as follows; When executable files are loaded, LoadSeg is used. If we put a wedge in the LoadSeg function to temporary reroute it to the library, we will be able to recognize and decrunch library-imploded executable files even when they are not subsequently runned. And thus we included this feature in the library. Now all those executable files that aren't runned from their first location such as libraries, devices and fonts could be library imploded. (Fonts!?) (Yes, fonts are executable files because they require relocation by LoadSeg) But wait isn't there a snag somewhere?. If the explode.library automatically decrunches all library-imploded files that are loaded into memory, all this trickery with the resident command shouldn't be necessary. The problem is that AmigaDOS and most CLI commands are written in BCPL, and BCPL uses weird vector tables instead of library jump tables to access DOS functions. So the LoadSeg function wedge, which is legally obtained by using the exec SetFunction call, does not work for executable files that are loaded by BCPL code (such as the resident command). Do NOT therefore start to library-implode all executable files you find in your system. Use the following checklist instead. 1. Fonts; Fonts are loaded by the graphics library when needed. Since the graphics library isn't BCPL, all fonts may be library imploded. 2. Libraries; Libraries are loaded by exec, and exec sure aint no BCPL. You may therefore library-implode all libraries in your LIBS: directory with the exception of explode.library for obvious reasons. 3. Devices; Same as for libraries. Your may library-implode all devices in your DEVS: directory So what about all those handlers in your L: directory? Well, these are generally loaded by the DOS or one of its accomplices so if you want to be on the safe side, let them rest in peace. There might just be the odd exception though. If you intend to library-implode fonts, libraries and the like, please note that this places additional constraints on the presence of the explode library. You now MUST make sure it is present in memory before the system even gets a chance to load a font or a disk-based library. Make sure that the very first command in your startup-sequence is library imploded or place InitLib there. During testing, it was noticed that one of these libraries or devices (can't remember which one) was a bit sensitive to merging. These oddly programmed things just might have disappeared since V1.3 has arrived, but I shouldn't count on it. You are therefore urged to be careful. Some of them, however, are just begging to be merged. (lots of hunks) Please take the information on merging as supplied in the manual into account. *** LibInfo *** To monitor libraries in general and the explode.library in specific, this directory contains the LibInfo command. Just type LibInfo followed by the name of the library you want some information on. The .library postfix may be omitted. LibInfo only runs from the CLI. LibInfo is pure an may therefore be made resident. *** Conclusion *** The explode library performs well and can create lots of extra space on your system drive, as long as you are prepared to live by the rules outlined in this document.