Figure 1: Imploder
In previous articles, I talked about renovating the Workbench in manners both practical (plumbing, wiring), and aesthetic (new coat of paint, what have you.) Well, now it's time to turn to that ever popular (and ever insufficient) closet space. I wish my Amiga were like Dr. Who's TARDIS. If you've ever watched the BBC SF serial Dr. Who, you'll know what I'm talking about. Dr. Who's Space/Time ship, the TARDIS (Time And Relative Dimensions In Space) had many fine qualities, but one of the most amazing was the fact that it was bigger on the inside than on the outside. From the outside, it appeared as a police call box, on the inside, however, it was seemingly boundless. Imagine the closet space!
My Amiga is most definitely not like the TARDIS (though it occasionally does require a good whack to get it started.) No, like most, my Amiga has a finite amount of hard drive space, which is crammed to bursting with programs, data, and an ever expanding array of system libraries, fonts, handlers, dos drivers, datatypes, and other essential byte-thieves. And I must confess, the icons alone consume an embarrassing amount of hard drive real estate.
The obvious solution is to buy a bigger hard drive, or maybe a Zip or
Jaz removable drive. For those without large Amiga expense accounts,
the hardware route to storage heaven may be impractical. What can you
do?
|
|
|
Figure 1: Imploder |
|
|
|
|
Figure 2: Powerpacker |
Well, there are inexpensive (and even free!) ways of getting extra storage space, if you're willing to put up with the occasional compromise. Using compression software, you can nearly double the apparent size of your hard drive.
If you've used computers for very long, you will have at least passing acquaintance with compression. Most commercial and PD software is compressed using LHA, LZX (a new version, lzx121.lha, was recently released on the nets) or similar program, and is uncompressed during the installation process. While LHA and LZX certainly compress files well, and save space on your backup media, they are not of much use for compressing programs and files you use on a regular basis.
Programs known as "crunchers" or "packers" were early attempts to solve this problem. There are dozens of different crunchers; Imploder (freeware) by Albert-Jan Brouwer, Peter Struijk, Paul van der Valk, and Erwin Zwart, and Powerpacker (commercial, w/ freely available demo, PWRPCKR.LHA,) by Nico François, are two of the more familiar. Both programs could compress data files, both had supporting utilities such as text readers to display this crunched data. But the more general usage for Powerpacker and Imploder (and other programs of this type) was to compress programs in such a way that they would be automatically decompressed when run. You could compress your programs, yet still run them as though they weren't compressed at all. To achieve this seeming magic, after compression, a "decrunch-header" was added to the program. This would (with the help of a library) decompress the program, load it into memory, where the Amiga would run it as any regular program. Crunchers went a long way toward solving the space problem, but still left much to be desired. Only program files could be crunched and decrunched automatically. Data files, libraries, fonts etc could only be compressed if the application you used understood the compression method. Aside from a few viewers, almost no applications could deal with crunched data. See Figures 1 and 2 for screenshots of Imploder and PowerPacker.
What is needed is a transparent way to compress and decompress files, handled automatically by the system. When you loaded a compressed file into your word processor, you wouldn't even need to know if it was compressed or not, the file would be decompressed on-the-fly, you would use your program as always.
One of the first programs to attempt this was Powerpacker Patcher, by Michael Berg, A small program which would allow most applications to load Powerpacked files transparently to the user. You could even powerpack your icons and fonts. A later more complete solution, again by Michael Berg, was PowerData. This program was more robust, corrected some of Powerpacker patcher's limitations, and allowed Applications to read and write Powerpacked data. Both these program served their purpose, but only worked with PowerPacked files.
It was about this time that one of the most useful compression utilities for the Amiga was released, XPK (XPK25usr.lha, freeware), created by Urban D. Mueller (of Aminet fame.) The XPK package, is a modular compression system, allowing users to choose from a variety of compression methods, and programmers to easily extend the system with new methods and other enhancements, such of data encryption. XPK con- sists of a master library, and various compression libraries. The real strength of XPK is it's extendability. As new compression methods are developed, they can easily be added to the existing XPK system. XPK is flexible enough that other tasks, such as data encryption, can also be implemented. The XPK package comes with several utilities for handling compression, including Martin A. Blatter's XDrop, a no fuss commodity with an AppIcon for Drag-n-drop (de)compression.
XPK comes with a number of compression libraries, and there are many
available. Several I'm familiar with:
XPKDMCB.LHA André Osterhues, shareware, powerful, 68020+, FPU, >2MB
XPKELZX.LHA Adam Przybyla, Piotr Kasprzyk, freeware LZX xpk libraries
(NOTE: incompatible with Shapeshifter!)
XPKHFMN136.LHA Martin Hauner, fast, average compression
XPKGZIP_1.0.LHA Antonio Schifano, Slow, but very good compression
XPKILZR.LHA Jose Renau Ardevol, Fast (Un)Packing Low Mem Requirements
XPKMASH-R4.LHA Zdenek Kabelac, Fast, pretty good compression
XPKPWPK10.LHA Michael Barsoom, freeware PowerPacker based xpk packer
XPKRAKE_V1.7.LHA Karsten Dageförde, freeware, My favorite for general use
XPKSHRI_V2.2.LHA Matthias Meixner, freeware, Excellent compression, slow
There are many programs which work with and support XPK and other forms of Amiga compression. While I can't list every one, here are a few you might want to check out.
XFD, (XFD114.lha, Freeware) by Georg Hörmann, is a system for
decrunching files, and features support for almost ever cruncher known
on the Amiga. (I'll have to take the authors word on that, since I've
never heard of most of the 45 included crunch formats.)
|
|
Figure 3: XPKatana |
Eric Sauvageau's XPKatana (XPKatana12.lha, shareware), is a front end for the XPK compression system. XPKatana allows you to pack, unpack, repack and test not only XPK compressed files, but (with XFD support) also many non-xpk crunchers. XPKatana has a full Arexx port, and script recording to make processing multiple files easier. XPKatana also can identify (via FileID.library) many filetypes, making it useful for deciding which packer to use. See Figure 3 for a shot of XPKatana.
|
|
Figure 4: XPK-Knight |
XPK-Knight, by A. Grossberger, is an even more extensive front end for XPK. XPK-Knight has powerful script capabilities for automating repetitive compression tasks, and also features a TRY mode, which will successfully compress a file using many packers, which could be useful for determining which packers are best at certain types of data. See Figure 4 for a screen shot of XPK-Knight.
|
|
Figure 5: XPK Archive Library |
Matthias Meixner's XPK-Archive Library (XPKArhivePack.lha, giftware) is an interesting program, which supports XPK for creating archive files. Rather than compress individual files, XPK-Archive bundles groups of files into a single compressed archive (rather like LHA or LZX.) One nice feature is an included utility, XArcTool, to browse through these archives, adding, extracting, deleting individual files, using a DOpus like interface. See Figure 5 for XPK-Archive/XArcTool in action.
Some other handy XPK utilities are Daniel Balster's XPACKGAUGE.LHA and XPKDOPUS.LHA, XPK compression w/ progress gauge for Directory Opus 4 and 5 respectively. Finally, XPKDT-1.0B.LHA, by Michal Letowski, is an XPK datatype.
|
|
Figure 6: XFH Commodity |
XPK in itself does not feature on-the-fly compression/expansion, but there are several companion programs which fit the bill nicely. XFH, by Kristian Nielsen, (XFH1_38.LHA, freeware) is what I use, and is an extremely useful and stable program. XFH also includes a commodity to control compression, written by Nicola Salmoria. XFH allows on the fly compression and decompression of both directories and partitions. Once XFH is installed and setup correctly, you will have access to a new pseudo drive, a sort of 'evil' twin of the drawer or partition you chose. If you chose HD1, you will normally have a drive named XHD1. Saving a file to HD1 will result in no compression, just as if XFH were never installed, while a file saved to XHD1 will be compressed. See Figure 6 for the XFH commodity.
|
|
Figure 7: DeepX task Setup |
DeepX (DEEPX12.LHA, freeware) by Adam Ciarcinski is another XPK compliant application which takes a different approach from XFH. Rather than basing compression/expansion on a particular partition or directory, Deepx acts as a sort of front end to allow any programs to use XPK compression. For instance, you could give Personal Paint the ability to load and save XPK compressed pictures. See Figure 7, for the DeepX Task setup Window.
Michael Berg's PowerData has reappeared, this time with full XPK support. Power Data Professional (PDPro1_0b.lha, shareware.) PowerData Pro is similar to Deepx in function and usage. (I'd say more, but I can't get the prefs program to run on my system. I ran it once, when I first installed it, but now it just crashes. No doubt some aversion to my odd system setup.
XFH is useful for most situations, but what if you want to compress only the seldom used programs in your C drawer, but leave the more frequently used ones alone? Since XFH works on entire directories or partitions, we need some other option.
Xloadseg, by Christian Schneider, is a small system patch (included with the XPK package) which allows programs, and even some libraries, drivers etc. to be crunched, then used as you would normally. When running a program, or when a program calls for a library, XLoadseg handles the decompression (via XPK) and the program, library, font carries on, all transparently. Except for a slight delay (and a bit more memory used during decompression), the user is unaware of Xloadseg's actions.
While using XPK and XFH or related utils to save HD space works well, there are pitfalls and cautions you should be aware of. If you have limited ram, you need to be careful crunching big files. The Nuke packer, for instance, needs about 200K (in addition to the actually file size) to de/compress a file. I have used XPK quite successfully on a stock 2 MB Amiga 1200, but XPK really fares better with more ram. Also, a faster processor will make XPK less noticeable.
Be especially careful with the ELZX packer! This actually packs files using LZX, which means it is fast and has excellent compression, but also requires a bit more care than most of the other XPK packers. More importantly, it appears to have a fatal conflict with Shapeshifter's PrepareEmul program. After using Shapeshifter, you will find that files packed with ELZX are inaccessible. Attempting to unpack these files will corrupt them. Shutting the power off and then rebooting without PrepareEmul is the only solution. I lost several files before I figured this one out.
Using Xloadseg can free up a tremendous amount of HD space, but not every program, library, font etc will work with Xloadseg. When you see the amount of space saved, it is tempting to go nuts and compress everything in sight! Resist this, start slowly, crunching and testing one file at a time. Be particularly careful when compressing libraries, devices etc. In course of this article, I inadvertently compressed the XPKMaster.library. DO NOT GO IN THERE! Next time I booted up, my Amiga came to a grinding halt. UH OH. In order to run, I needed to uncompress XPKMaster.library, but of course, you need XPKMaster.library to decompress anything. Well, at least I made a backup!
You can also get in a situation where a file is either packed or unpacked when it shouldn't be. For instance, if you copy an XPK packed file to an XFH autocompression volume, the file will be packed twice, making it unusable. Always remember which volume is compressing and which is the standard "Base" drive. This is actually the real heart of using XFH. For instance, if you use an entire partition, say HD1, then you will have two drive icons displayed on the workbench, HD1 and XHD1. Saving a file to HD1 will NOT compress the file, while saving a file to XHD1 will.
With the above caution in mind, XPK, XFH and related utilities are quite
useful for variety of compression uses. On my system, I've gotten on
average 50% compression ratios. That's quite a few megabytes of storage
I wouldn't otherwise have.
 |
||||||
|