Bicycle repair man (B)
Superman in need (SIN)
V: This man is no ordinary man. This is Mr. H. G. Superman.
To all appearance he looks like any other law-abiding
citizen. But Mr. F. G. Superman has a secret identity.
When trouble strikes at any time, at any place, he is
ready to become... BICYCLE REPAIR MAN!
SB: Hey, there's a bicycle broken, up the road.
B: <Hmmmmm. This sounds like a job for... Bicycle Repair
Man.... but how to change without revealing my secret
S1: If only Bicycle Repair Man were here!
B: Yes, wait, I think I know where I can find him. Look over
S1-3: Bicycle Repair Man, but how?
S1: Oh look...is it a stockbroker?
S2: Is it a quantity Surveyor?
S3: Is it a church warden?
S1-3: NO! It's Bicycle Repair Man!
SIN: MY! Bicycle Repair Man! Thank goodness you've come! Look!
SB <Oooh Err>
S2: Why, he's mending it with his own hands!
S1: See how he uses a spanner to tighten that nut!
SIN: Oh, Oh Bicycle Repair Man, how can I ever repay you?
B: Oh, you don't need to guv. It's all in a day's work
for...Bicycle Repair Man!
S1-3: Our Hero!
V: Yes! Whenever bicycles are broken, or menaced by
international communism, Bicycle Repair Man is ready!
Bicycle Repair Man Sketch, Mony Python
ST SOFTWARE REVIEW: "SQUISH II" BY TRACE TECHNOLOGIES
by Richard Karsmakers
Quite a while ago now, Double Click software went broke. Or
something similar at least. Some of the "DC-" programs will
probably never be heard of again, and some have had their rights
transferred back to the original author. The latter is the case
with a program like "DC Squish" - now called "Squish II". I
managed to procure a copy of this program and did the following
In the previous issue I got my hands on several screen speeders.
I did a most extensive test after which "Warp 9" turned out to be
the best selection on multiple grounds. This time I'd like to
take you along into the mysteriously ineffable world of packers,
crunchers, compressors, squishers, imploders, or whatever else
you may want to call them. A separate article, elsewhere in this
issue of ST NEWS, will cope with archive programs. This article,
however, is just a review of regular packers, small programs
which can take an executable file, make it smaller, write it back
to disk, and make sure that that program is automatically
decompressed whenever it is run again.
Although this article is based around "Squish II", what it
really boils down to is that I've taken multiple packer programs,
of which "Squish II" happens to be the commercial one that was
released most recently, and compared them with regard to their
efficiency and the time it took for them to be as efficient as
Benchmarks say it all, really. I've taken five different
programs and did the benchmark testing on them. These programs
were "PROTEXT.PRG" (the main file of "Protext" version 5.5,
400988 bytes, an example of an awesomely big file),
"GFA_V360.PRG" (version 3.6TT main program of "GfA Basic",
included also because it's known to cause problems with packers
here and there), "MUTIL.PRG" (a typical example of a medium-sized
utility, Michtron Disk Utilities version 1.1), "UVK_6_0B.PRG" (an
in-development version of the "Ultimate Virus Killer" version
6.0, which I included because, frankly, I was curious - as well
as far the fact that it's a compiled "GfA Basic" program which
can lead to some problems) and "MENU.PRG" (an example of a rather
tiny file, only 21140 bytes in size, which is the main menu shell
thing for the "GfA Basic" compiler).
The table below lists the original and compressed sizes of the
programs in question (in the left column). The fastest/worst
(cf0), supposedly ideal (cf6) and slowest/best compression
factors (cf9) were timed. The percentages indicate the percentage
of the original program size that is still left. The table below
was benchmarked with the "Squish II" 'turbo' option turned off.
Program |Original|SQII cf0 toff|SQII cf6 toff|SQII cf9 toff
GFA_V360.PRG| 104770 | 80064 (76%) | 76820 (73%) | 76732 (73%)
| Time ->| 00'10" | 01'02" | 06'50"
PROTEXT.PRG | 400988 |277942 (69%) |258830 (65%) |258160 (64%)
| Time ->| 00'31" | 03'32" | 23'01"
MUTIL.PRG | 69748 | 34656 (50%) | 30648 (44%) | 30388 (44%)
| Time ->| 00'06" | 00'34" | 03'04"
UVK_6_0B.PRG| 251972 |152936 (61%) |139184 (55%) |138626 (55%)
| Time ->| 00'19" | 02'02" | 12'10"
MENU.PRG | 21140 | 16628 (77%) | 16028 (76%) | 16024 (76%)
| Time ->| 00'03" | 00'13" | 01'21"
AVERAGE | | 67% | 63% | 62%
Conclusion: Packing with a very high packer rate is not worth
your while, nor the time invested in it (which is, as you see,
almost insanely considerable!). Such high compression factors are
perhaps useful only if you really want to get rid of an extra 100
or 200 bytes, due to space available on a disk or something. As
we will see later, the average compression factors outrank Keith
Gerdes earlier "DC Squish" even at the fastest/worst compression
factor. Needless to say, it may also be concludes that a higher
compression factor indeed gives smaller results, though more time
is needed. A compression factor of 6 is viable.
The following table lists the same, but now with the 'turbo'
option on. The percentages given at the program sizes, however,
are the differences between the 'turbo' and 'non-turbo'
compression taken as parts of the original program length, i.e.
an indication of how much less effective the packing is when in
'turbo' mode. The percentages given at the time specification
indicate how much of a speed increase the 'turbo' option gave in
that particular case.
Program |Original|SQII cf0 ton |SQII cf6 ton |SQII cf9 ton
GFA_V360.PRG| 104770 | 81446 (2%) | 79040 (2%) | 79038 (2%)
| Time ->| 00'07" (30%)| 00'47" (24%)| 05'30" (20%)
PROTEXT.PRG | 400988 |285792 (2%) |271684 (3%) |271616 (4%)
| Time ->| 00'21" (32%)| 02'29" (30%)| 17'05" (26%)
MUTIL.PRG | 69748 | 35444 (1%) | 32718 (3%) | 32694 (3%)
| Time ->| 00'04" (33%)| 00'17" (50%)| 01'41" (45%)
UVK_6_0B.PRG| 251972 |158366 (2%) |149574 (4%) |149556 (4%)
| Time ->| 00'12" (37%)| 01'17" (37%)| 08'32" (30%)
MENU.PRG | 21140 | 16840 (3%) | 16396 (2%) | 16396 (2%)
| Time ->| 00'03" (0%) | 00'11" (14%)| 01'07" (17%)
AVERAGE | | 2% less | 3% less | 3% less
| Time ->| 26% less | 31% less | 28% less
Conclusion: Between 26 and 31% worth of time can be saved,
therewith only losing about 2 or 3% of compression. The higher
the uncompressed program size, the highest the time gain - but
also the highest space loss. Switching 'turbo' mode on can be
compared with lowering the compression factor by about 4 or 5.
Yet another table below. It features the benchmarks to the same
programs, again with compressed size and time compression took,
as well as the percentage of the original program size that was
still left afterwards. Now, however, other packers were used:
"ATOM" version 3.5, "PACK ICE" version 2.40 (default settings,
time needed for verify is excluded), "PA PACK" version 1.01 and
the last original "DC SQUISH", version 1.4.
Program | Orig.| ATOM | PACK ICE | PA PACK | DC SQSH
GFA_V360.PRG|104770| 67352 64%| 71402 68%| 83644 80%| 83054 79%
|Time >| 01'48" | 00'40" | 01'07" | 00'29"
PROTEXT.PRG |400988|226330 56%|245654 61%|302284 75%|294264 73%
|Time >| 08'42" | 04'14" | 04'08" | 01'38"
MUTIL.PRG | 69748| 28104 40%| 29918 43%| 37468 54%| 36772 53%
|Time >| 01'35" | 01'00" | 01'00" | 00'14"
UVK_6_0B.PRG|251972|125458 50%|136088 54%|169518 67%|162396 64%
|Time >| 04'40" | 02'00" | 02'49" | 01'06"
MENU.PRG | 21140| 14476 68%| 14904 71%| 17252 82%| 17738 84%
|Time >| 00'15" | 00'08" | 00'14" | 00'06"
AVERAGE | | 57% | 59% | 72% | 71%
With this table it should be noted that the lightened turned out
to produce files that crashed when started. The bold entries, by
the way, comprise the best achievements, taking into
consideration (and thus ignoring) the lightened entries. Note:
"Atom" is normally OK in more than the 40% of all cases listed
When examining the information given in the above tables, it is
evident that "Squish II" is not actually the best packer there
is, in spite of the fact that (as you will be able to read below)
"Squish II" does not even contain the decompression routines
within the compressed program. "Atom" and "Pack Ice" are better,
and it only beats "Pa Pack" and, of course, the old "DC Squish"
(even at a compression factor of 0).
Let's have a look at the actual program to see if a
justification for purchase may be found.
In order for a packer to be any good it needs to have a good
compression factor, it needs to be compatible and, if you want to
put it to good use, it's pretty damn excellent if is has a tree
compress method. "Squish II" scores OK on all levels, and is a
definite improvement over "DC Squish" which had less of a
compression factor and no tree compress method, even though it
wasn't particularly less compatible.
"Squish II" has knobs on, too. You can exclude files (and even
root directory folders) from compression. You can have one of 10
different compression factors ranging from 'slightly better than
DC Squish' to 'quite good'. You can define which file extensions
should be regarded as executable ones (PRG, TOS, ACC, etc.). It
can be used as an accessory or as a program. It can multitask
when run with "MultiTOS" or as an accessory. It can recognize
various other packer formats ("Ba Pack", "Pack Ice", "PFX" and
some more) that it will decompress and then squish afresh. It's
pretty well thought out.
However, there are some wishes left. First of all you
currently need a resident program, preferably in your AUTO
folder. This program will handle decompression by hooking onto
the BIOS system vector. This program is copyrighted and may not
be spread. Of course I find it totally strange, there is no other
word for it, that it would be illegal to spread a compressed
program. With "Squish II", and with "DC Squish" apparently, this
is the case. Whereas I think there is no better advertisement for
any packer than to see lots of programs packed with it,
apparently Keith Gerdes has a different opinion. Whatever may be,
things are as they are and you can do doodly squat with the files
on any other systems unless that other person also has "Squish
II". There is nothing else you can do other than decompress the
stuff you need to exchange. This seriously decreases
userfriendliness. The manual claims that this is easier for
possible compatibility upgrades, where only the UNSQUISH resident
program would need to be replaced. Also, it claims that it saves
another 1 Kb off every compressed file. This may be so, but this
is not the way I would prefer it.
"Squish II" has a number of switches. For example there's one
that allows you to skip all squished files when doing a tree
compression. A lot of thought seems to have gone into the
program, but there is another thing I miss here. I would really
have liked a switch "save only if smaller than currently on
disk". This would have been handy in the case of a file already
having been packed with a good packer that is recognized by
"Squish II". Currently it will load it, decompress it, then
squish it, and save it. Especially if the packer used previously
was "Pack Ice", the size of the file on disk will invariable have
increased. "Squish II" is very smart and reports a rather OK
compression factor with lots of kilobytes gained - calculated
from the original file size (i.e. the uncompressed file size even
before "Pack Ice" touched it) and then checking how much "Squish
II" took off that.
One of the most important options, like I already mentioned
before, is the "exclude/include" option. As I have used the
program rather extensively ever since I got it, I think I can
already give you (a potential Trace Technology customer) some
guidelines as to which programs you should exclude (apart from
the ones mentioned in the "Squish II" documentation).
These programs fall in three categories: 1) Programs that save
parameters to themselves, 2) Programs that just refuse to run (or
almost refuse) when anything has changed to them, and 3) Programs
that are not loaded by GEM as such and that thus have to be left
1) "Squish II" supports a special offset protocol (as did "DC
Squish") that allows for programs to have a small part
uncompressed so that parameters can even be saved to it
anyway. A program that does support this is Bill Aycock's
Calendar accessory. Programs that do not support this and
that should thus not be compressed (with "Squish" nor any
other packer for that matter!) are FCOPYPRO ("Fastcopy
Pro"), D_EDGE ("Diamond Edge") and <5.3 (I think) versions
of "Ultimate Virus Killer".
Of course it's possible to unsquish these files, change
their configuration, and then squish them again (this works
with other packers, too, one would venture to say).
2) TEMPUS ("Tempus" editor - checks for possible link virus
infection. It does this by merely checking its file size.
The program still works, but you get a warning alert box
every time you boot).
3) CHBD.SYS (the Claus Brod Hard disk driver - this counts for
all hard disk drivers, including ICDBOOT, SHDRIVER, AHDI,
etc.), EXTOBFIX (the external object display module
belonging to the "Interface" resource editor).
In the end, there are a few conclusions one may draw from all of
the above. First, in spite of the fact that it isn't 100%
reliable, one should use "Atom" of course - as long as the
programs in question are not compiled "GfA Basic" stuff and they
don't have to function as accessories, that is. Keep a backup of
the original file until you've checked the compressed file to see
whether or not it works. "Atom" is the best (and faultless even
within accessories, etc.) with regard to data file compression,
too. Second I would advise "Pack Ice", which can be trusted
totally but which, like "Atom", prevents its compressed products
from functioning as an accessory. If you do want to use a file as
accessory, you either have to use "Pa Pack" or "Squish II".
"Squish II" sets you back an amount of money, it needs a resident
bit of program to be installed, and the resident bit as well as
the files compressed with "Squish II" may not be spread. "Pa
Pack" is shareware (so it's principally for free), needs no
additional bits, and the files made with it may be distributed.
On average it's 5-10% less effective than "DC Squish".
Personally I use "Pa Pack" to compress my "Ultimate Virus
Killer" program file (as it needs to work as an accessory and, of
course, I need to be able to spread it), whereas I use "Atom" to
compress the data file. "DC Squish" nor "Squish II" handle data
files - you are advised instead to check out the resident data
compressor and decompressor, "Data Diet" (also written by Keith
At home I have "Squish II" installed with with about 90% (I
think) of all accessories and programs on my hard disk
compressed. Why? Because it's better than "Pa Pack" (and I don't
need to spread the stuff on my hard disk anyway), it's highly
compatible (which "Atom" isn't), it's better than the old "DC
Squish" (so there goes that) and I need to do accessories as well
(so there goes "Pack Ice"). Additionally, decompression times are
much shorter than those of "Pack Ice" and "Atom" - and I don't
want to lose too much time each time when I'm loading something.
I have experienced practical whole-partition compression averages
of between 41 and 48%, with a particularly nasty one only getting
compressed by about 25%. Do note that these averages are
calculated from all the programs on which a compression attempt
has been successfully made. Some spectacular percentages happened
in the case of "Degas Elite" (60%), "Plutos" (70%) and
"Background Music Utility" (87%).
In case you're interested in obtaining "Squish II", which
is very well imaginable, you're advised to contact Trace
P.O. Box 711403
Houston, TX 77271-1403
United States of America
Tel. (713) 771-8332 (weekdays 1PM-5PM CT)
Stop press: The latest version of "Squish II" is now 2.11
(though 2.10 was used while testing). It has no speed
improvements over version 2.10.
The text of the articles is identical to the originals like they appeared in old ST NEWS issues. Please take into consideration that the author(s) was (were) a lot younger and less responsible back then. So bad jokes, bad English, youthful arrogance, insults, bravura, over-crediting and tastelessness should be taken with at least a grain of salt. Any contact and/or payment information, as well as deadlines/release dates of any kind should be regarded as outdated. Due to the fact that these pages are not actually contained in an Atari executable here, references to scroll texts, featured demo screens and hidden articles may also be irrelevant.