Contents | < Browse | Browse >
/// Usenet Review: DiskExpander
By Njaal Eide (firstname.lastname@example.org)
A utility to expand your storage capacity on floppy and hard disks.
Name: Stefan Ossowski's Schatztruhe
Address: Veronikastrasse 33
SPECIAL HARDWARE AND SOFTWARE REQUIREMENTS
Any Amiga with Kickstart later than 1.2.
At least 1 meg memory is highly recommended.
DE is copy-protected. But as the original disk is only used when you
install DE, this is not a problem at all. Serious changes in your system,
or in DE's configuration, might make it necessary to use the original disk
again. The disk also contains a unprotected utility that lets you recover
your compressed data if your DE disk should get damaged.
MACHINE USED FOR TESTING:
Amiga 4000/030, 6M RAM.
80MB Seagate hard drive, 250MB Western Digital hard drive.
If you ever run out of storage-space for your files, you are faced
with three alternatives: buy more storage-space, delete files, or use more
efficient storage methods. DiskExpander is a product that takes the latter
approach to solving this problem. DiskExpander (or "DE" for short) is a
program that gives you on-the-fly compression/decompression of files. This
means that when DE is installed on a device, all files get compressed when
saved and uncompressed when loaded. This process is totally transparent to
all applications, as they will not even know that they are loading/storing
compressed data. This is a really great concept, but as with everything
great, it's got a catch to it: disk access gets slower (in most cases) and
can be demanding in memory terms. I will discuss this in more detail later
on in the review.
When I first opened the DE box, I got a little surprised that it
contained no less than three disks. Shouldn't this be a storage expander and
not a storage filler? Upon further inspection, I found that one of the
disks is a demo version of TurboCalc v2.0 and the other two are identical
copies of DE. I guess this was due to a packaging mistake at the
manufacturer, but a backup is nice anyway. Furthermore, the box contained
manuals in both German and English. The German manual was included probably
because the English manual was not completed. The latter came in the form
of a bunch of loose A4 sheets; but by the time you read this, it should have
been made into a proper manual. Anyway, the content of it turned out to be
clear and informative: no problems here. If it wasn't for the single phrase
"1.3 oder 2.0 style", I (a Norwegian) could have been fooled to believe it
was written by an Englishman.
DE uses the brilliant Installer program from Commodore, and the
installation works nicely indeed. The only problem occurs when you are
personalising your DE disk, as the installation script doesn't check the
protection state of your disk. So whatever you write will get lost if your
disk is write-protected.
When you have successfully installed DE on your hard disk, the first
thing you ought to do is to configure it as you please. There are several
ways to do this. You can manually edit your startup-sequence, or let a
configuring program do it for you. DE also supports various tooltypes in a
Project icon. So if you please, you can place DE icons, one for each device,
in the WBStartup drawer (Workbench 2.0 or later). I do not recommend the
latter approach, as it seems unreliable (DE doesn't recognise all the
tooltypes that it supposedly should). I also had problems using this method
on more than one device at a time. What happens is that DE functions like
an on/off switch. Run it once, and DE activates. Run it again and it dies.
This would have been nice if DE checked the state of the device you are
trying to activate. Instead, DE checks only if it is active on ANY device,
and if it is, then it disables itself completely. (Remember, this is only a
problem with two or more project icons in WBStartup. With scripts, there are
DE doesn't contain a fixed number of compression algorithms built
into the program. Instead, it uses external libraries for compression
purposes, including the widely available XPK standard and others. The use
of external libraries lets the user choose which algorithm is most suitable
for his/her needs. To add a new packing method, you just add a new library.
A user with little memory could choose a library which uses little of it. A
user with a fast, powerful machine could choose an algorithm that has very
good compression ratio, but is too slow on a less powerful machine. There
are libraries optimised for most needs (speed, compression-ratio, certain
file types, memory etc.), so most users will find something appropriate.
Lots of external libraries are supplied, and their pros and cons are
discussed in the manual. Still, it seems like SOS haven't been able to keep
up with the development of new XPK-libraries. I found that I had a newer
version of the XPK-library 'NUKE' on my hard disk than on the DE disk. Not a
big deal anyway as new libraries will be supplied to registered users.
Every other program that I have with XPK support expects to find the
XPK libraries in LIBS:compressors. DE expects to find then in LIBS:. This
means that I now must store them in both places and shows poor attention to
detail on SOS behalf. I tried the DOS-command
ASSIGN LIBS: SYS:libs/compressors ADD
which should assign both directories to LIBS, but this doesn't seem to work
with any program. Is this a bug in AmigaDOS?
Now we have come to the most interesting part. How is actually DE in
everyday use? I must admit that DE in the beginning was a real pain.
Programs was either crashing like mad, or they refused to load. I was
preparing for a long and harsh letter to the publisher. But by coincidence I
changed the settings for DE, and every problem vanished. Since then, I
haven't had a single problem with DE at all. This means six weeks of solid
use, and not a single crash due to DE. Excellent.
To save other users from the problems I had, here is what I found:
There are two options in DE called 'No Examine' and 'No ExNext.' DON'T USE
THEM! These two options determine how AmigaDOS finds the size of files. If
used, AmigaDOS calculates the physical size of the file. If not, AmigaDOS
calculates the uncompressed size. For a user (me at least), it is more
interesting to know the physical size than the virtual. For the Amiga, it's
definitely not. My theory why this is essential is as follows. When a
program loads a file, it first checks its size and allocates that amount of
bytes in memory. What happens then is that the uncompressed file occupies
more space than allocated, causing all sorts of problems/crashes. So
remember to use only 'Examine' and 'ExNext.'
I started out making some benchmarks that measured loading/saving
times with and without DE installed. But I've come to the conclusion that
benchmarks don't say much. It all depends on how powerful a machine you
have, how many tasks are running simultaneously, what pack library you are
using, your hard disk interface, file size, etc., etc. All I can say is that
my experience with DE is highly enjoyable. With my setup, the increased
loading time from hard disk is just noticeable, and only with large files.
With floppies, loading time actually decreases.
On average you will save about 30-40% disk space with the most
efficient pack library. For text files, expect 50-70% savings, and for
previously packed files (like GIF, JPEG, LHA etc.) you will not save a
single byte. So if you have a hard-disk full of packed pictures, you will
not save much. If you on the other hand are a programmer with lots of
include files and AutoDocs, then your savings will be enormous. So take a
look at your files before you decide if DE is for you.
With DE comes a utility that lets you pack or unpack a complete
partition. This is useful when you are installing DE for the first time, or
if you want to change pack libraries or remove DE. Another utility inspects
the files of your choice and gives you various information like
compression level, pack library used, file size, etc.
I'd really like to see DE transformed into a commodity. Right now, I
find it a little cumbersome to change parameters for DE. I guess this was
dropped in order to keep compatibility with Kickstart 1.3 (why do publishers
still make productivity software for 1.3?). It would also be nice to be
able to use different pack libraries on different directories or assigned
drives. Right now, all files on the entire partition use the same
algorithm. It should also been possible to mark files that DE should not
compress. That way it would be much safer to install it on a boot
partition. Right now, you can end up in great trouble if you compress some
of the files DE needs for itself. I would also like to see DE supporting
RAM: and PC0:. For some reason, RAM: is only supported on machines with
COMPARISON TO OTHER SIMILAR PRODUCTS
There are at least two similar products as shareware called EPU and
XFH. Both gives similar compression results as DE as they use the XPK
standard, but they are very unstable. I have tried them both, but I had to
give them up. By the way, EPU is written by the same author as DE.
When you first have got it properly installed, DE is really good. I
really recommend it. For those that really think loading times are
important, why not compress only the files you don't use very often?
This document is copyright 1993 Njaal Eide, but freely distributable.