Squish II - Comparative Review

                                                      CHARACTERS:
                                                    Voiceover (V)
                                                         Boy (SB)
                                           Bicycle repair man (B)
                                                Supermen (S1...3)
                                           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
        identity?>
S1:     If only Bicycle Repair Man were here!
B:      Yes, wait, I think I know where I can find him. Look over
        there!
        (FLASH!)
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>
        (Clink!)
        (Screw!)
        (Bend!)
        (Inflate!)
        (Alter Saddle!)
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
review.

 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
they are.
 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
here.

 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
uncompressed.

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
Gerdes).
 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
Technologies.

 Trace Technologies
 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.