Club Amiga de Montreal - CAM/CAM_CD_1.iso/files/607.lha/CFX_v5.115/CFX.DOC.pp/CFX.DOC

Text File | 1992-01-25 | 94KB | 1,945 lines

***************************************************************************
*                                          *
*              CFX 5.100 - Crunched File Xaminer              *
*                                      *
*              by BOB RYE and MARCUS MROCZKOWSKI              *
*                                      *
*              Public Release: Friday 14/01/1992                *
*                                      *
***************************************************************************
















                                  NOTICE
                                  ¯¯¯¯¯¯
THE  CFX  PROGRAM  AND  ITS  DOCUMENTS ARE COPYRIGHT BOB RYE 1988,89,90,91.
"CFX"  IS  *NOT* IN THE PUBLIC-DOMAIN.  THE "PUBLIC-RELEASE" VERSION MAY BE
COPIED  AND  DISTRIBUTED  MANUALLY OR VIA ELECTRONIC METHODS PROVIDING THAT
THE  ORIGINAL  CFX ARCHIVE IS NOT ALTERED, ADDED TO, OR DELETED FROM IN ANY
WAY.  MONEY MAY NOT BE GAINED FROM THE COPYING OF CFX, ALTHOUGH MEDIA COSTS
AND  A  SMALL  COPYING  FEE  (OF NOT MORE THAN $8 Aus) ARE ACCEPTABLE.  THE
REGISTERED VERSION OF THE CFX EXECUTABLE MAY NOT UNDER ANY CIRCUMSTANCES BE
COPIED,   (PIRATED)   DISTRIBUTED   OR   GIVEN  AWAY.   THE  CFX  CODE  AND
DOCUMENTATION  REMAIN  THE  PROPERTY  OF  BOB  RYE.  ANY PERSON(S) FOUND IN
BREACH OF THIS NOTICE WILL BE PROSECUTED TO THE FULL EXTENT OF THE LAW.


                                DISCLAIMER
                                ¯¯¯¯¯¯¯¯¯¯
ALTHOUGH  OUTSTANDING  BUGS IN THE CODE HAVE BEEN ELIMINATED, THERE REMAINS
THE POSSIBILITY OF UNFORESEEN PROBLEMS.  WE RESERVE THE RIGHT TO REFUTE THE
WORD  OF  THE  USER  AS TO THE EXTENT OF SUCH 'BUGS', BUT IF FOUND, WE WILL
ATTEMPT  TO FIX SUCH PROBLEM(S).  IF, HOWEVER, UNFORESEEN BUGS ARE FOUND TO
CAUSE  YOU  MENTAL  AND/OR  PHYSICAL  PAIN, THEN THAT IS AS THEY SAY IN THE
CLASSICS, BAD LUCK!  WE ACCEPT NO BLAME FOR ANY LOSS OR INCONVENIENCE FOUND
TO  ARISE  FROM  THE  (MIS)USAGE  OF THIS PROGRAM.  WE RESERVE THE RIGHT TO
WITHDRAW  SUPPORT AND UPGRADES AT ANY TIME.  WE PROBABLY WON'T DO THIS, BUT
WE HAVE THIS RIGHT.


ALL  INSTANCES  OF  COMPANY  AND/OR  PRODUCT  NAMES  ARE  (C), (R) AND (TM)
RESPECTIVELY, WHERE APPLICABLE.  "CFX" AND "CFX PRO" ARE COPYRIGHT BOB RYE,
1988 - 1991 INCLUSIVE.

CFX 5.100 has been extensively tested on:
    Amigas 500, 1000, 2000 (all vanilla PAL, 1.3 - 2.0)
    B2000 GVP 22mhz ALL-IN-ONE accelerator PAL 1.3 - 2.0

¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
                            CFX 5.100   Page 1





                            Table of contents:
                            ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

            1...... This page

            2...... Preview

            3...... Usages

            4...... Switches (filetypes)

            7...... Options

               13...... Bits and Pieces

               14...... CFX output

               15...... Brainfile Information

               31...... Correspondence

               32...... Registration (ho ho, I'm a cynic.)

               33...... Credits & Acknowledgments

               34...... Registered Users

                       35...... Registration form
                            CFX 5.100   Page 2

                                  Preview
                                  ¯¯¯¯¯¯¯
    CFX  was  written  to  enable  the  Amiga  user to identify certain
characteristics  of given files.  The file, let's call it 'TEST', is a file
that  you received from a BBS, but there were no accompanying docs with it.
The  file  is  executable,  but  you  have  a  feeling that it is crunched.
PowerPacker  doesn't  know  this  file's 'crunch' type, so you can't easily
identify  the  filetype.  You could use a debugger/monitor to find what the
filetype  is,  but the most you'll get out of that is to ascertain that the
file REALLY IS crunched.  Well, from my experiences on the Aust  Amiga Fido
Echo,  I know that there are a lot of you who don't like receiving crunched
files.   This  program attempts to let you know if it is crunched, and most
possibly,  what  it  is crunched with.  You can then decide what to do with
the mysterious file 'TEST'.  Keep it or trash it????

    Unlike  many other so-called 'file examiners' on the Amiga, CFX has
a  very large brainfile from which it can acknowledge a large percentage of
the  current  Amiga  filetypes.   It  will  then report to you what type of
cruncher  was  used to crunch the file, or, if it isn't crunched, what type
of  file  'TEST'  really  is.   The information that CFX gives isn't really
self-explanatory, so let's describe what the various displays mean.
                            CFX 5.100   Page 3

                                  USAGES
                                  ¯¯¯¯¯¯
Upon invocation with the standard "help" switch:
1> CFX ? {return}

CFX will show this screen:

 CFX Crunched File Examiner Pro
 © Bob Rye & Marcus Mroczkowski    Public
 Copyright (c) 1988, 89, 90, 91    68000
 VER 5.09d 07:33:49 Oct 28 1991    Version

Usage: CFX [<-f>switch] [-options] [file1,file2,,,]

 Switches: -f<?> where <?> =        Options:
    a    address crunched             -a      about CFX
    b    binary (non-exec) files      -b      brain-listing
    c    crunched (a+r+t) files       -c      checksum calculation
    i    IFF files                    -d      deep directory scan
    k    known files                  -e      extended hunk scan
    o    overlayed files              -h<=>#  files with <#, =# or ># hunks
    p    ILBM picture files           -i      integrity check of files
    r    relocator crunched           -l[f]   real file length [FFS]
    t    transmission archives        -n      no virus-requester warnings
    u    unknown files                -r [a]  requester usage
    v    viruses                      -s[l]   summary [LOUD]
    x    executable files             -u      deep uncrunch/virus check

As  you  can  see,  CFX  accepts switches and options, along with filenames
and/or  directory/device  names.   CFX  also examines the current directory
via:

1> CFX {return}

First,  let  us  explain the switches.  CFX's switches can be thought of as
"find"  switches.   When you use a particular switch, you are really asking
CFX  to  find a specific filetype.  Therefore, when using a CFX switch, you
must  prepend  the  action specifier with an immediate "-f".  Here are some
examples:

1> CFX -fa dh1: {return}

will  examine  the  root-level  of  DH1:   for  any  files  that are of the
address-crunched  type.  The action specifier in this case is the "a" after
the "-f".  The "a" of course stands for "address".  No other filetypes will
be  displayed other than address-crunched files.  By using this switch, you
are   effectively   filtering   out   every   other   filetype  other  than
address-crunched.  (See ADDRESS-CRUNCHED in the FILETYPES chapter)

1> CFX -ft MAIL: {return}

will examine the root-level of your MAIL:  directory for any filetypes that
fall  into CFX's "transfer archive" category.  (See TRANSFER ARCHIVE in the
FILETYPES chapter)

All  of  the  specific  filetypes  are  explained  in full in the FILETYPES
chapter.
                            CFX 5.100   Page 4

                           SWITCHES (FILETYPES)
                           ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

The  following  switches  must  be  immediately  appended  to the "-f" find
switch, thus:  CFX -fr dh0:  {return} (find relocator-crunched)

    a    address-crunched - this switch will force CFX to only display
files that have been output by an address-cruncher.  Address-crunchers tend
to be the scourge of the computing society, so these files shouldn't really
be  allowed to live, unless of course, you really need the file.  CFX knows
most  of  the  Amiga address-cruncher formats.  CFX doesn't currently check
the  uncrunched contents of these filetypes.  This switch cannot be used in
conjunction  with any other switch, although some options may be used.  See
BRAINFILE INFORMATION for more info on address-crunchers.

    b    binary (non-exec) files - when this switch is used, CFX will only
display  information  on  non-executable  files.   This filetype covers all
non-executable  filetypes,  including  transmission  archives,  text files,
picture  files  etc.  This switch may be used in conjunction with the "known
files"  and  "unknown  files"  switches,  and some options.  Obviously, you
cannot ask CFX to display only executable binary files, can you??

    c    crunched (a+r+t) files - this switch will allow CFX to display all
files  that  it  finds that have been crunched by something.  This includes
address-crunched   files,   relocator-crunched   files,   and  transmission
archives.   This  switch  cannot  be  used  in conjunction  with  any  other
switches, although it is possible to mix this switch and some options.

    i    IFF files - this switch allows CFX to find and display only IFF
format  files.   Practically  all IFF files are catered for in this switch.
If  CFX  finds an IFF file that it doesn't actively know or recognise, then
it will print "Unknown IFF format".  If this happens, please send us a copy
(or  the  first  4000 bytes) of the file(s) in question and we'll add it to
our  brainfile.   This  switch  cannot  be  used  in conjunction with other
switches, but may be used with some options.

    k    known files - this switch is for use in conjunction with one of
these other switches:  <NONE> <BINARY> <OVERLAYED> <EXECUTABLE>.  When used
without  another  switch  (ie.  CFX -fk {return} or CFX -fk dh3:  {return})
CFX  will  only  display files that it knows.  Considering that the list of
filetypes  that  CFX  knows  is  rather extensive, you should find a lot of
files!   When  used  with the binary switch (ie.  CFX -fk -fb {return}) CFX
will  only  display  files  of  non-executable type that it actively knows.
This  could  cover  filetypes  of  known  IFF's,  or  certain configuration
filetypes.  In conjunction with the overlayed switch, this switch will find
known  overlayed  files.   This  could  include  the  "DImp executable disk
archive" or the "PowerPacker 3 overlayed file crunched file".  Finally, you
may  use this switch with the executable switch.  This will ensure that CFX
only  displays  executable  files  of  known  type.  This could include all
crunched files that CFX knows.
                            CFX 5.100   Page 5

    o    overlayed files - this is a very handy switch that allows the user
to   find   overlayed  filetypes.   Since  it  may  be  difficult  for  the
non-technically  minded  user  to  find  the  overlay  id  long-word  in an
executable  file-header,  this  option  allows  you to find which files are
overlayed.   Overlayed  files  use a special technique for loading into the
Amiga's  memory.   Certain  software  producers use this technique on their
larger  files  so as to not rob the Amiga of vital memory during loads (ie.
instead  of  loading  a  340k  file  directly  into  the Amiga's memory, an
overlayed  file  may  only load in what parts of the file that they need at
any  one  time.   Therefore  this  file  may only load 50k at any one time,
thereby  freeing  about  300k  of  memory  for other uses.) Obviously, this
switch  finds executable files (only they can be overlayed!) Therefore, no
other  switches  work  with  this one, other than the "known" and "unknown"
switches, and some of the options.

    p    ILBM picture files - this is almost a subset switch of the IFF
switch.   This  allows  CFX to find and display ONLY IFF picture files, and
not  *ALL*  of the entire IFF gamut.  Also, all IFF (ILBM and ANIM) picture
files found will be displayed as normal and with additional information (if
possible.)  The  picture's  size  and  number  of  bitplanes  will  also be
displayed, making this switch an excellent tools in itself.  This switch is
mutually exclusive from other switches, but may be used with some options.

    r    relocator-crunched - CFX will display files of this type if this
switch  is  used.   Whilst  similar to address-crunched files in some ways,
relocator-crunched  files  tend  to  be  more  useful, and more kind to the
machine.    Some  of  these  relocator-crunched  files  actually  use  more
intelligent scatter-loading methods than AmigaDOS itself (wouldn't be hard,
though  *;-)  This  switch can only be used by itself, with a couple of the
options  thrown in for good measure.  After all, you don't want to find all
of the files that are address-crunched relocator IFF's, do you??

    t    transmission archives - this is another handy little switch for
finding   (and   examining,   to  an  extent)  files  that  are  considered
transmission  archives  by  CFX.   Since  most  of  you use these archiving
methods,  I won't go into the "Complete works of Lempel and Zev".  Instead,
let  it  suffice  to  say,  that CFX knows lots of 'em.  If you have any of
these  cute  archive  types that CFX doesn't know, then please let us know!
This switch is mutually exclusive with other switches, but some options may
be used with it.

    u    unknown files - see "known files" and reverse what has been said.
                            CFX 5.100   Page 6

    v    viruses - unluckily, the Amiga is following the rest of the
computer/PC cliques (or should that be cliches??) that have hordes of rabid
spotty  juveniles  writing  heroic  viruses.   These  authors are of course
witless  beyond  belief.   Luckily,  we have been allowed to obtain several
file-virus  filetypes  from Amiga Quarantine, in New South Wales.  The guys
at  A.Q.  (Richard and Brian Logan) were gracious enough to allow us access
to  some of the common (and some uncommon) nasties that might visit you, if
you're not careful!  With this switch, you can force CFX to ONLY check each
file  found  for  virus infection.  This will ensure that CFX ONLY displays
information  about files that are of a virus filetype.  You don't, however,
have  to  manually  use this switch for CFX to virus-check your files.  CFX
automatically  checks  each  executable file for infection EVERY time it is
run.   Since  CFX  is  a  hybrid  of assembly and C, the asm virus checking
routines  are  lightning  quick, hence the automatic checking.  When/if CFX
finds  a  virus-infected  file,  it  will  print its usual information, AND
display  a  requester  informing you of your infection (ooh, sounds nasty.)
CFX  doesn't  remove or disinfect infected files.  It is only there to find
such  infections.   So  far,  CFX  has  performed beautifully, and has even
outperformed most of the latter-day anti-virus utilities.  Another thing to
be  aware  of,  is  CFX's  built-in  anti-virus  protection.   CFX  has two
intelligent  routines that it performs every time CFX is invoked.  Firstly,
CFX  checks  it's  filename  (argv[0]) and if this isn't "CFX" then it will
bomb   out,   with  a  warning.   This  is  for  protection  against  those
"replacement"  viruses  which  rename  your original file to something like
"DEVS:   ".   Secondly,  CFX  performs  a  self-anti-virus  test  upon each
invocation.   If  CFX finds that itself has been infected, CFX will not run
further,  as  doing so may infect each and every file that CFX checks!  Not
good.   Therefore,  CFX  needs  to  be  able  to  find  itself  upon  every
invocation.  This means one of two things:  you MUST place your copy of CFX
in  a system-pathed directory (ie.  C:) or you must call CFX with it's full
pathname  (ie.  DH1:TOOLS/CFX.) The latter is cumbersome, so use the former
method.   If  CFX cannot find itself (through pathnames, or through tracing
its  own  argument vectors, then it will run without checking itself.  This
is  your  problem.   In  conclusion,  only  use -fv if you are specifically
looking  ONLY  for infected files, as CFX will always check ALL executables
for infection anyway.

    x    executable files - will force CFX to only display executable files
that  are  found during its scan.  This switch can be used with the "known"
and "unknown" switches.  You can't use this switch with many other switches
(other  than  find  unknown and known), but some options are available with
this  one.  This switch is useful for finding files which you can run on an
unknown  disk  (AND  CFX  performs a virus check on each executable that it
finds!)
                            CFX 5.100   Page 7

                                  OPTIONS
                                  ¯¯¯¯¯¯¯

CFX's  options  are  "support"  options, which should make your prospective
examinations easier.  Let's dissect the options singularly:

Options:

  -a      about CFX - this option shows one of two things. If you have paid
a  shareware  contribution  to  the  authors,  you  will receive a personal
version  of CFX.  This version will have your name and other information in
this screen.  Otherwise, if you are still using the public release version,
this  screen  will  explain the shareware concept, and give you information
about where to contact the authors.  (Surely for this much work, we deserve
something, don't we??) This option is best used by itself.

*-------------------------------------------------------------------------*

  -b      brain-listing - this option will print the names of filetypes
that CFX currently knows.  This information is always being updated, and if
we  gain  some  support from users (in way of new filetypes, crunchers etc)
then  we  will add that filetype ASAP.  We do need the support to keep this
program  the best!  This option is best used by itself, as it will override
most other options and switches.

*-------------------------------------------------------------------------*

  -c      checksum calculation - an option for the paranoid! In your
examination travels, you may feel like gaining a magic number for each file
that is examined.  This number shouldn't change between invocations of CFX.
It  is  a  little checksum of the file's header, and can show you whether a
filetype  has  changed  since you last CFX'd it.  To properly use this, you
should  redirect  CFX's  output  to  a  text  file, and store that textfile
somewhere  safe.   Later,  you can cross-reference another of these outputs
against  the  original.   Any changed files will have a different checksum.
Perhaps   later,   we   may   add  a  built-in  function  to  automatically
cross-reference  these  files.  This option can be used in conjunction with
most switches and other options.

*-------------------------------------------------------------------------*

  -d      deep directory scan - one of the most basic (and important)
options.  The "-d" will alow you to recursively enter directory levels.  If
you were to use:

1> CFX -d dh0: {return}

CFX  would  first  examine  the  root  level  of dh0:, and then each of the
sub-directories  from  the  root.   The  above  example  would  provide  an
examination  report  for  ALL  files  and  directories on drive dh0:.  This
option  can  be  used  to modify all action switches and options.  When CFX
outputs  its findings, it doesn't sort the directory entries in any way, as
this  would  entail  buffering  and sorting before output.  We believe that
reading  a  directory structure straight from the hashchain is the best way
to get to filenames, hence no sorting/pausing.

*-------------------------------------------------------------------------*
                            CFX 5.100   Page 8

  -e      extended hunk scan - another option for the technically minded.
This  allows  the  user  to FULLY examine the hunk structure of a specified
file(s).   Of course, this will only be effective with executable files, so
non-executable  files  won't  provide an extended-hunk report.  This can be
useful  for  checking  whether a file contains annoying debug hunks, symbol
hunks,  or  anything else hunk-oriented.  You can use this option with most
other  options  and  switches,  although extended hunk-information won't be
provided  for non-executable files (or any files filtered with a particular
"find" switch.)

*-------------------------------------------------------------------------*

  -h<=>#  files with <#, =# or ># hunks - this option is practically a
"find"  switch  camouflaged  as an option.  If you would like to know which
files on your disk contain a certain number of hunks, this is the option to
use.   Some  programmers  release executables containing innumerable hunks.
This  can  be  good  and  bad.  If your system contains severely fragmented
memory,  a  program  of  97  hunks  will probably scatter-load a bit easier
(memory  permitting)  than  a  2  hunk file of the same size.  Imagine your
Amiga's  memory  as  being a big box containing several pigeon-holes.  When
the  memory  isn't fragmented, there might only be 4 pigeon-holes, that are
quite  large.   When fragmented, the pigeon holes are more in number, and a
fair  bit smaller.  A large program of two hunks will need a certain amount
of  contiguous memory to scatter-load.  If fragmented, your machine may not
be able to load the file.  On the other hand, the fragmented machine may be
able to load the same sized program of 97 hunks, as each hunk is small, and
easily  fitted  into  the  "broken"  memory.  If you are an avid Imploder 4
user,  then you may want to "hunk-merge" such programs with huge numbers of
hunks.   If  you  need  to know whether your TOOLS:  directory contains any
files  of  more  than  10  hunks  (my personal cut-off level), then CFX the
directory with:

1> CFX -h>10 TOOLS: {return}

CFX  will then inform you of the files of more than 10 hunks in your TOOLS:
directory.   You  can also find files containing a specific number of hunks
by  using  the "=" operator, or files containing less than a certain number
through the "<" operator.  Hence:

1> CFX -h<3 TOOLS: {return}

will  find  files  of  less  than 3 hunks in TOOLS:.  Of course, you cannot
specify an illegal formula like:

1> CFX -h<1 TOOLS: {return} or

1> CFX -h<-10 TOOLS: {return}

as  executables cannot contain less than 1 hunk.  The numbers that you give
to  CFX for this option MUST BE positive decimals.  This option can be used
with  many  other  options  and  switches,  although  useless  if  used  in
conjunction with "-fb" for instance.  If you don't understand this concept,
Addison-Wesley print excellent books for the Amiga...

*-------------------------------------------------------------------------*
                            CFX 5.100   Page 9

  -i      integrity check of files - have you ever received a disk of
pictures  from  someone  and  noted that some of the files have disk-errors
right  in  the  middle  of them??  This can provide you with quite a lot of
teeth-gnashing.   The  "-i" option checks all specified files on a disk for
these  horrid  read/write errors.  If CFX finds a file that has compromised
integrity,  CFX  will  report  this  with  a flag in its output.  (See "CFX
OUTPUT"  later...)  You then know that this file is knackered.  This option
can be used with most other options and switches.

*-------------------------------------------------------------------------*

  -l[f]   real file length [FFS] - "Bob, I have a cunning plan." This
is  what  Brett  O'Callaghan  once  said  in  response  to  the  completely
blasphemous  way  that AmigaDOS handles filesizes.  I won't explain the way
that  DOS  handles  the  filesize  information, but suffice it to say, it's
stuffed  (just like Baldric's plans.) Brett came up with a plan so cunning,
you  could cut your lunch with it.  This involved asking DOS how big a file
is,  and  then  rolling  it in a cute little algorithm of mine.  Now, using
this  option, CFX will list filesizes CORRECTLY.  That is, instead of being
told  that your disk containing one hundred 3-byte files contains 300 bytes
of  information,  CFX  will  tell  you that you really have a lot less than
835.7  k  free.   Don't  forget,  that each of these 3-byte files is really
exactly  1-kilobyte  long  (one  parent block = 512-bytes, one data block =
512-bytes).  This option defaults to standardfilesystem sizes.  You can use
fastfilesystem sizes via:

1> CFX -lf ... {return}

I  don't  know  how  useful  this  option  is,  as it would be handier in a
directory-handling  program  (like  that  excellent  Australian  one.) This
option  is  also  safe  to use with most other options and switches, as its
actions are practically passive.

*-------------------------------------------------------------------------*

  -n      no requester-warnings - this is for those of you who like to
redirect  your  outputs.  When CFX finds a file-virus on a disk, it reports
this  via a big requester.  Since this requester will sit there on your CLI
for  an  eon  or two, you can turn off the requesters.  Now you can check a
disk  for viruses, whilst redirecting CFX's output, without having to worry
about clicking requesters every 7 seconds.  Another excellent idea by CFX's
co-author, Marcus Mroczkowski.  This option can be used in conjunction with
other  options  and switches, although you must be careful with its use, as
CFX would (by default) warn you that it has found a virus on your disk.  If
you   turn   off   the  requester-warning,  then  pay  attention  to  CFX's
file-information area.

*-------------------------------------------------------------------------*
                            CFX 5.100   Page 10

  -r [a]  requester usage: seeds = [path:|show|hide] - for those people who
like  to  point  and  click.   This  version  of  CFX  allows a much better
representation  of  a  file-requester,  using  Dawson  and  Fox's brilliant
REQ.LIBRARY  requester  (makes the ARP requester look very dense.) By using
the command-line:

1> CFX -r {return}

CFX  will  rack  up  the requester, and ask for your selection(s).  You can
either  change  directories  or  sit  where  you  are;  point and hit "OK";
double-click  a  filename;  or  extended-select  a group of files (thankyou
Brett!)  using  the  shift-key  for  the  extended-selection  modifier (ala
WorkBench);  or just hit "CANCEL" and do nothing.  Apart from these default
actions,  you can also give CFX extra "seed" information for the requester.
These "seeds" must be in correct order.  For example:

1> CFX -r dh0:c a* *x {return}

will  bring  up  the  requester,  with  the PATH field automatically set to
"dh0:c",  the  SHOW field set to "a*" and the HIDE field set to "*x".  This
will  force  the  requester  to only show files starting with "a", and will
hide  all  files  ending  in  "x".  If you want to use one of these pre-set
fields, you must use all preceding fields, hence:

1> CFX -r a* {return}

will  confuse  the requester.  If you want to use the hide field, but don't
want  to  specify a path or show field, then you MUST also specify the path
and show fields, hence:

1> CFX -r "" *.* *.info {return}

will  force CFX and the requester to use the current PATH, SHOW everything,
and HIDE only *.info files.

NOTE:   A  bizarre bug found when using the req.library under 1.3 is the "I
won't activate for you, you bastard" bug.  This is NOT a bug of req.library
or CFX.  To emulate it under 1.3, use

1> CFX -r {return}

and  then use the requester's menu to "LEAVE" the requester.  Your CLI will
probably  be  active  and not-active (??) To re-re-activate (sic) your CLI,
you  will  need  to  shrink  your CLI down a little, and then click on your
WorkBench  backdrop,  then  again activate your CLI.  You should be ok now.
This  doesn't  appear  to happen under 2.0 (37.175) of the OS.  This option
can be used with most other options and switches.

*-------------------------------------------------------------------------*
                            CFX 5.100   Page 11

  -s[l]   summary [LOUD] - when examining a whole directory tree, the user
may  not want or need CFX to display everything about the files found.  You
may  only  want  a  summary  of  valid  points  about  the  dir-tree.  This
information  can  be  very  interesting,  and  is  generally quicker than a
full-display  of  CFX's work.  Here is a summary of my DH1:  partition that
CFX gave me after the command line:

1> CFX -d -s dh1: {return}

 CFX Crunched File Examiner Pro
 © Bob Rye & Marcus Mroczkowski
 Copyright (c) 1988, 89, 90, 91
 VER 5.08p 14:53:02 Oct 20 1991

CFX Summary of "dh1:" (HD_1):

 -> Relocator-crunched.......: 74        Size :  1225988
 -> Address-crunched.........: 1         Size :     6164
 -> Other known executables..: 0         Size :        0
 ?? Unknown executables......: 115       Size :  4104876
                              ---------------------------
Executable files checked.....: 190       Size :  5337028

 -> Crunched data files......: 1         Size :    54708
 -> Other known data files...: 4         Size :    68606
 ?? Unknown data files.......: 0         Size :        0
                              ---------------------------
Data files checked...........: 5         Size :   123314

Acceptable files.............: 195       Size :  5460342
Compromised files............: 0         Size :        0
Directories found............: 7
FILE/LINK VIRUSES found......: 0

Total % of known files.......: 41.03%

The  only  other thing I should explain is the [LOUD] sub-option.  With the
above  example,  (and  as is usual) CFX used the default QUIET option.  You
can  force  CFX  to  print  it's usual information display whilst doing the
summary  scan.   The  LOUD  option  must be specified immediately after the
"-s".   (Thanks  again  to  Brett O'Callaghan for this little tidbit!) This
option  is  particularly  useful  when used in conjunction with some of the
"find"  switches.   Of  course, the percentage known total at the bottom of
the summary output can appear silly at times.  (For example:

1> CFX -fr -d -s dh0: {return}

will  search (deeply) through drive dh0:  for all relocator-crunched files,
and  then  display  a  summary screen on the found files.  Of course, the %
known  field will be 100% if any files were found.  If you can't figure out
why this is so, go back and use Whatis.

    One  thing  you should also be made aware of is the fact that CFX's
switches  and options are NOT case-sensitive.  So, either -FA, -Fa, -fA, or
-fa will gain the same action.  Another caveat is the argument positioning.
CFX  doesn't need arguments in any particular order, but for one exception:
if  you  are including a path in your command-line, then the path-specifier
must be the LAST argument in that line.  For example:
                            CFX 5.100   Page 12

1> CFX -s -d -fr dh0: {return}  is identical to:

1> CFX -d -s -fr dh0: {return}

1> CFX -d dh0: -s -fr {return}  is illegal.

    If CFX gives you this warning:

 CFX Crunched File Examiner Pro
 © Bob Rye & Marcus Mroczkowski
 Copyright (c) 1988, 89, 90, 91
 VER 5.08t 14:18:14 Oct 23 1991

Argument conflict: illegal combination of switches.

then you know that you have offended CFX's logic.  If you have a mixture of
switches  that  CFX  refuses  to  accept, that YOU think should be OK, then
please netmail me with your ideas.  I'll certainly have a look at them.

*-------------------------------------------------------------------------*

  -u      deep uncrunch/virus check - this is a new option which will
definitely  grow as we add more cruncher types to this function.  What this
does  is quite simple (from the user's viewpoint!) If CFX finds a file that
has  been crunched by a certain cruncher type that it can uncrunch, and the
-u  option  has been given, CFX will attempt to uncrunch the file, and then
scan  the  uncrunched  memory  for viruses.  Currently this option supports
these cruncher types:

ByteKiller 1.2-1.3
Tuff 1.0
All Imploders, 1.0-4.0 OTHER THAN S-Lib & L-Lib crunched, overlayed
crunched, and some mutants.

Technically speaking, ByteKiller usually stomps memory where it uncrunches,
but  CFX  doesn't  allow  this to happen.  CFX allocates a safe memory area
(memory  permitting)  and  allows  BK  to  uncrunch safely.  The uncrunched
programs in this mode DO NOT launch, so this function is fairly safe.  If a
virus  is  found  hidden  in a crunched file, CFX will give the appropriate
warnings.  Of course this option can take some time to fully execute if you
have 300 (supported) crunched files in a directory to check. Usage example:

1> CFX -u -d DH1: {return}

will  examine  ALL  directory levels of drive DH1:, and if CFX finds any of
the  supported crunchers, it will attempt to uncrunch them, check them, and
report it's findings.  Sometimes CFX may report that a file was too mutated
for  uncrunch-examination:   this  is  just  tough luck.  One file comes to
mind,  and  that  is  MandelMountains  2.1 (mutated like the be-jingos.) To
uncrunch  this file, run two copies of Zap, load in MM2.1 into one Zap, and
another  Imploder Normal file into the other Zap.  Now, after the longwords
$000003E9, $00000014 in MM2.1, copy Normal Imploder code into the MM2.1 Zap
window,  until  you  hit  the first $000003F2.  Now use PowerPacker 3.0+ to
uncrunch this file.  Experiment...
                            CFX 5.100   Page 13

                              BITS AND PIECES
                              ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
- CFX 5.100 requires the req.library in your LIBS: directory.
- The req.library accepts extended select (Brett's idea), so use it!
- Options and switches may be either case (upper or lower).
- Options and switches may be in any order (excluding pathnames/files).
- Filenames/directorynames may be stacked, for example:

    1> CFX -d dh0: dh1: dh2: {return}

will  recursively  enter and examine all files in ALL levels of drive dh0:,
then when finished, repeat the same for drives dh1:  and dh2:;

or

    1> CFX -d c:dir tools:CED dh2:MAIL/trapdoor {return}

will  examine  the  files  c:dir,  tools:CED and dh2:MAIL/trapdoor and then
recursively enter and examine all files in drive dh4:

What will happen if you type:

1> CFX -fr c:dir {return}

and the file c:dir ISN'T crunched with a relocator cruncher??  Check it and
see  if  you're  right.   This same thing will happen if you specify a find
switch  along  with  asking  for  the  requester.   Only specified ('find')
filetypes will be displayed if you ask for a specific find-mask.

Before  launching  its  activities,  CFX  checks  your  DOSBase vectors for
intrusion  by the Xeno file-virus.  This virus is very dangerous if running
in  a system that CFX is about to utilise.  If Xeno is running when you CFX
a  directory  (or if you launch a 'dir' command, or 'list' or ANYTHING that
examines  directory  trees)  there is a good chance that some or all of the
examined  files  will  be infected.  This is the reason that CFX checks the
system's  current  DOSBase.   If  there is a nasty wedged into DOSBase, CFX
will  refuse  to  run, and will explain its decision not to do so.  Believe
me, you don't want anything like CFX running alongside the Xeno virus.

CFX version 5.000 - 5.100 were (and will continue to be) developed with:
    - SAS C-compiler, versions 5.10 and 5.10a.
    - DevPac GenIm assembler version 2.14.
    - Cygnus Editor Professional version 2.12.
                            CFX 5.100   Page 14

                                CFX OUTPUT
                                ¯¯¯¯¯¯¯¯¯¯
For  the moment, if you think of CFX 5.100 as just a directory replacement,
then you shouldn't have any problems using it.  It's a very informative and
comprehensive replacement, however! The standard CFX output line format is:

<         filename         > < size > <flg> <hnk> <    file information    >

'filename'  is a 28-character field, which will automatically expand with a
bigger filename.

'size'   is  the  filesize  of  the  file  being  examined  (defaulting  to
standardfilesystem size.)

'flg'  is  the  important part here.  'flg' is a 5-character field of flags
which  tells you everything you needed to know about the file.  Let's check
what each of the flag-elements means:

  1 - the first element can be only one of two things:
  'X' or '-'
      'X' tells you that the file is 'eXecutable'
      '-' tells you that the file is NOT executable (ie. is binary)

  2 - the second element can only be one of two things:
  'O' or '-'
      'O' tells you that the file is 'Overlayed'
      '-' tells you that the file is NOT overlayed

  3 - the third element can only be one of four things:
  'A' or 'D' or 'R' or '-'
      'A' tells you that the file is of 'Address-crunched' type
      'D' tells you that the file is of 'transmission-archived' (DATA) type
      'R' tells you that the file is of 'Relocator-crunched' type
      '-' tells you that the file is NOT of any discernible type

  4 - the fourth element can only be one of three things:
  'M' or 'V' or '-'
      'M' tells you that the file is a 'Mutant' type
      'V' tells you that the file is a 'Virus' type
      '-' tells you that the file is NOT a known mutant or virus

  5 - the fifth element can only be one of three things:
  'F' or 'P' or '-'
      'F' tells you that the file FAILED a full integrity check
      'P' tells you that the file PASSED a full integrity check
      '-' tells you that a file integrity check was NOT performed

'hnk'  is the 'number' of hunks field.  This takes the form of 'Hxxx' where
'xxx'  equals  the  number  of  hunks  in  the file.  Only executable files
contain  hunks, so binary files won't feature this field.  CFX 5.100 should
handle files with as many hunks as is possible.

'file  information' is another crucial part of CFX's output.  This is where
you  receive  a  description  string  of the file in question.  This may be
'Unknown  executable  type'  or any of the other filetype descriptions that
CFX  currently  knows.   Here is the CFX output resulting from CFX checking
itself:

CFX                          48104    X---- H2    Unknown executable type

Obviously,  the  filename is 'CFX', its filesize is 48104 bytes (SFS), it's
an  eXecutable  file,  has  2  hunks, and is unknown (ie.  not a virus or a
crunched-file.)  Now  you  should  experiment  with CFX.  Check your entire
SYSTEM disk for viruses via:

1> CFX -d -fv SYS: {return} and ENJOY your program!
                            CFX 5.100   Page 15

Brainfile information:
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Below  are  the  5.100 brainfile entries, along with a brief description of
each. (The virus information provided here is only a cursory glance at each
virus, provided by Richard and Brian Logan from Amiga Quarantine.)

**  BRET_HAWNES  FILE  VIRUS:

**  BUTONIC  FILE VIRUS:  File virus, this one displays a simple alert.  It
infects via the startup-sequence.

**  CCCP  LINK  VIRUS:   Boot and Link virus, when this one is found on the
bootblock,  you  can guarantee that is has also infected at least one file.
It decides what file to infect by using the keys on the rootblock.

** CENTURION (SMILY CANCER) LINK VIRUS:

**   DISASTER-MASTER   FILE   VIRUS:    File   virus,   infects   via   the
startup-sequence and displays a simple alert.

**  IRQ LINK VIRUS:  Link virus, this virus can be reluctant to stay memory
resident,  but  once  they  do,  they infect files quite easily.  Can cause
gurus with infected files.

**  JEFF  FILE  VIRUS:   File virus, a close relative to Butonic, sometimes
called  Butonic  3.00.  Infects via the startup-sequence.  When the file is
written to the disk, it may have one of eleven filenames.

**  RETURN  OF  THE LAMER DISK-VALIDATOR VIRUS:  Disk-validator virus, very
similar to Saddam, possible by the same writers.

** REVENGE OF THE LAMER 1 FILE VIRUS:
** REVENGE OF THE LAMER 2 FILE VIRUS:  File viruses, both infect via the
startup-sequence and are both very destructive.

** SADDAM-HUSSEIN DISK-VALIDATOR VIRUS: Disk-validator virus, the first of
its type, and a real pain to kill.

** TERRORISTS FILE VIRUS: File virus, this performs the same functions as
the TTV1/BGS9 virus, but displays a different picture.

** TRAVELING JACK 1 LINK VIRUS
** TRAVELING JACK 2 LINK VIRUS:  Link viruses, uses a vector in dos.library
to stay resident, but is killed by a reset.  Links onto anything.

** TTV1 (BGS9) FILE VIRUS: Practically the same as Terrorists, but for the
different picture.

** XENO LINK VIRUS:  Link viruses, links onto absolutely everything!  Stays
resident  via  vectors  in dos.library.  Any program that uses the infected
vectors runs  the  chance of infecting other files.  This is why CFX doesn't
run while XENO is active in memory.
                            CFX 5.100   Page 16

ACTION  REPLAY  FREEZE  DATA:  The Action Replay cartridge, when activated,
spits  out compacted memory chunks to your disk.  This file contains active
game/program  data,  all crunched up into a gibbering mess.  Needs a loader
to get it back into the Amiga's memory in a meaningful way.  CFX relates to
this filetype as a data-archive, since it's non-executable compacted data.

ALCH:   A non-meaningful address-cruncher.  A typical address-cruncher, and
not decrunchable to boot!

AMIGA  FONT  BITMAP:  Inside your FONTS directory there are three different
types  of objects.  Firstly there are the FONTS home directories, where the
FONT  BITMAP FILES live.  Thirdly, and lastly, are the FONT FUNCTION FILES.
Inside  the  FONTS HOME directory you will find (usually) some files called
numbers  (the  numbers  tell you how big the font is SUPPOSED to be.) These
files  are  the BITMAP files that explain (among other things) the shape of
of  this  FONT.   CFX  picks up most of these BITMAP files, but some aren't
chosen rightly...

AMIGA  FONT FUNCTION:  Found inside your FONTS directory.  These files tell
the  Amiga all about the font, including different styles etc.  CFX appears
to pick up all of these filetypes...

AMOS  BASIC  FILE:   These files, unlike most other BASICs, aren't in ASCII
format,  and have a special format unto themselves.  CFX knows all of these
ones...

AMOS  ICON FILE:  AMOS creates its own icon types.  I don't know much about
AMOS,  so  I can't really stoop to great descriptive prose explaining these
ones!..

AMOS   MUSIC   FILE:    Again,  standard  AMOS  music  file  output.   Self
descriptive...

AMOS  SAMPLE/SOUND  FILE:   Special  AMOS sound sample format.  Practically
standard  samples, but for a different header.  The AMOS boys should go for
a  slot  in the IFF market, as they have solid filetypes to back them in an
argument...

AMOS SAMPLE/WORK FILE:  More AMOS specific output...

AMOS SPRITE FILE:  AMOS sprite format file...

ANC:  OK, we've made it to a cruncher.  The ANC cruncher was an early comer
to  the Amiga, not long after the crunching market opened.  The ANC isn't a
remarkable cruncher, its a mixture of a RELOCATOR, and an ADDRESS cruncher,
and generally should be decrunched (See PowerPacker docs...)

ARC  5.0  ARCHIVE:   One of the first archivers to make it to the Amiga, it
was  welcomed  to BBS users and data archivers alike.  Useful then, archaic
and  out-of-touch  now.   Best  unarchive this filetype and hit it with LZ,
LHARC, or ZIP...

ARC  5.0+  ARCHIVE:   A  new  version  of  the  above, along with an IBM PC
version.  Quite a boring archiver, really.

ARJ  ARCHIVE:  A new archiver to the Amiga platform, originally Un*x or I*M
based.   Fairly  good  compression  algorithm,  not too shabby in the speed
department.
                            CFX 5.100   Page 17

ART  DEPARTMENT DEFAULT FILE:  When exiting the new Art Department Pro, the
program  saves  its  current  configuration  setup to your ADPRO:  assigned
device/directory. This is THAT file!!!

ASCII TEXT:  ASCII text is....  ASCII text!????

BAMIGA/TKT  ADDRESS:  This appears to be a special cruncher written for the
occasion.   This  originated  from a special unison between the top Belgian
cracking  group,  BAMIGA, and the UK's top crack house, The Kent Team.  You
probably  won't find this one around much now, as the TKT people got sprung
at  a big copy-party a while back.  They have rejoined, but no new cruncher
has  surfaced as yet.  This cruncher is usually found on cracked games, and
is  a  quick  and  dirty  compacter.   Retains the usual ADDRESS-cruncher's
drawbacks, which are:
 -  they  MUST  decrunch  to  a  fixed spot in memory, often causing memory
problems (or just straight-out Amigacide.)
 - Lack of portability to other "non-standard" Amigas.

BYTEKILLER  ADDRESS  (OLD  &  NEW):   This  cruncher  was  one of the first
address-crunchers  around,  and  is  still  used  today,  even  though  its
crunching  depth  and speed let it down terribly Used mainly for demos, and
cracked  games, it too, causes memory problems whilst decrunching.  Best to
get  rid  of  this  filetype.   Generally  "address" crunched filetypes are
difficult, if not impossible, to decrunch to their original structure...

CCS/PHR  ADDRESS:   Came  about  after  a  unison  of  the two crack houses
ComputerBrains Cracking Service and someone or other.  Another fine example
of how not to treat your files.  Typically ADDRESS-cruncher in action.

COMPACKER:    Another  of  the  inimitable  address-crunchers.   Completely
useless  crunching algorithm, completely useless user-interface, completely
useless.  Not decrunchable, as usual.

CRUNCH  MASTER:  Another poxy cruncher with practically no use left in this
world.    Why   do   these   people  bother???   Causes  the  usual  memory
fragmentation and slow run-time of the crunched file.  Typical...

CYGNUSED  AREXX COMMAND FILE:  This is the file that Ced save out after you
make a few ARexx command installations in Ced.

CYGNUSED  DEFAULT  FILE:   The  default  file  saved  out  as  your default
configuration for a particular document type, through Ced.

CYGNUSED  MACRO  FILE:  The file containing all of those cute little sign-off
macros that the moderator hates so much, through Ced.

DEFJAM  3.2  ADDRESS:  God, this annoying!  You think that you have got all
of  the DefJam crunchers countered, and then they release twenty more!  I'm
not joking, this group writes a new cruncher for every game they crack, and
silly  people  tend  to  pick up their crunchers an then use them on decent
files.   Very  little difference between this ADDRESS-cruncher and the rest
of them.  Same memory corrupting problems...

DEFJAM2 ADDRESS:  Yes, another one...

DEFJAM  ADDRESS  (x5):   I'm being conservative when I estimate 5 different
ones of these.  CFX can pick up about 9 of them, depending on the season...
                            CFX 5.100   Page 18

DIMP < V2 ARCHIVE:   The  older  version of the executable Disk-Imploder
tracker.   I  could  never  get  this  version to work properly, so it went
completely untested.  This filetype is overlayed.

DIMP  ARCHIVE:   A  file  of this type is the output from the Disk-Imploder
tracker,  in  data  (binary/non-executable)  format.   Standard through all
versions of DImp (so far.)

DIMP  V2+  ARCHIVE:   The  new  version  of  the  executable Disk-Imploder,
overlayed filetype.  This works well, and is fun to use.  Doesn't appear to
crunch as well as DiskMasher, however.

DIRECTOR  ANIM:   Remember  Joel  Hagen's RGB animation?  You know, the one
that won the Badge-Killer comp.  in the States a few years back??  Well, he
did that animation on the Director system, and this is the filetype that it
outputs.

DISK-MASHER  STANDARD  ARCHIVE:   A  new  disk-tracker  on the scene, which
boasts better crunching and decrunching times than all of the rest.  I have
now   witnessed   the  "earth-shatteringness"  of  DMS,  and  I'm  suitably
impressed...
Cf. LHWARP

DISK-MASHER  ENCRYPTED  ARCHIVE:   The  same  as  above,  except  that  the
archive/tracker file has been encrypted for privacy reasons.
Cf. LHWARP

ELECTRONIC-WARPLOAD:   Ha!   There's  a  funny story behind this one, but I
won't  tell it to you.  All I will say, is ask Mike Hansell (FVS) about it.
This  program apparently speeds up disk-loading, and is quite popular on PD
disks,  and  cover-disks  (esp.   from  the  U.K.)  I  found  this  file to
completely wreck my floppies after extended use, so I would be wary of it.

FAST-FILESYSTEM  BOOTBLOCK:   CFX knows this file when you are spying on a
directory containing GRABBED bootblocks...

FLASH PACKER/RS1:  Another repulsive ADDRESS/RELOCATOR-cruncher, which does
nothing  but  knacker  your  memory,  and  make you furious when your Amiga
gurus.   The  RS1 cruncher is practically identical to the Flash Packer, as
it  was  supposedly  written  by the same person.  I always thought of this
cruncher  as  the  "RSI"  as  in  REPETITIVE  STRAIN INJURY, but I've since
thought  otherwise.  I now call it the "RS1" as in RED SECTOR ONE.  This is
a  fairly generic address-cruncher, and is so ineffectual as to be useless.
Generally not decrunchable however...

GIF  (COMPUSERVE) PICTURE:  The COMPUSERVE GIF picture format, as once used
almost exclusively on the IBM PC.  Now that people are trying to get the PC
files over to the Amiga, start watching this file format creeping into your
directories.   The  only  thing wrong with this file format is that its not
IFF, or remotely interesting...

GREMLIN  DISK  ZAP  ARCHIVE:  A funny little disk-tracker handed to me from
Brett  O'Callaghan.   'Twas  interesting  to  read  of its claims to be the
fastest  and tightest of the disk-trackers.  I think that LHWARP would have
something  to say about that.  Not a particularly good tracker, or fast for
that matter...
                            CFX 5.100   Page 19

HQC:   One  of  the  first  cracking/spreading  houses  to  write their own
semi-decent  cruncher,  even though it was pathetically loose in crunching.
Quite a lot of early Amiga files were bent with this cruncher, but nowadays
it seems to have gone away (thank goodness...)

HQC  COMPRESSOR:   A minor re-work of the above, with no redeeming features
whatsoever.  It caused memory fragmentation, but it was a good attempt...

IFF-8SVX  SOUND:   Interchange  File  Format  sound sample.  Typically (and
originally)  formed  by  an  8-bit  sampler,  and  is one of the 4 original
Electronic  Arts IFF standards.  The acronym 8SVX comes from "8-bit Sampled
VoX"...

IFF-ACBM  BITMAP:   A silly bitmap standard which tends to be used by BASIC
programmers.   The  acronym  stands  for "Amiga Contiguous BitMap" and is a
third party Public Registered IFF FORM, for AmigaBasic...

IFF-AIFF  APPLE-AUDIO  IFF:   This  is one of the "port-over" jobs from the
Apple  computer.   For  1  to  32 bit audio samples.  Originally (I think?)
formed   with  the  MacIntosh  in  mind  (they  thought  that  it  had  the
home-pc-audio  market  cornered.)  Apparently NOT subject to standard Amiga
IFF listing...

IFF-ANBM ANIM-BITMAP:  An original third party Electronic Arts Deluxe Video
"ANimated BitMap" FORM, a piece of history...

IFF-AVCF AmigaVision: A new IFF filetype supported by AmigaVision.

IFF-BANK   MIDI   DATA   DUMP:    SoundQuest  Editor/Librarian  format  for
MIDI-system exclusive dump...

IFF-CAT:   Don't get confused by this slight misnomer.  A CAT is a group of
IFF forms.  I included it in this format for completeness.

IFF-CL00 CLOANTO ITALIA TEXT:  This FORM is the PRIVATE output of a certain
large  word-processor/desktop-publisher,  called Cloanto Italia.  This FORM
is a PRIVATE REGISTERED THIRD PARTY FORM...

IFF-DMCS  DELUXE  MUSIC  SCORE:   The raw SMUS output from the Deluxe Music
Construction Kit, loadable ONLY by DMCS...

IFF-DTRK  ADRUM  PERCUSSION  TRACK:   Third party IFF FORM belonging to the
drum machine program ADRUM.  The acronym stands for "Drum TRacK"...

IFF-FANT  FANTAVISION  MOVIE:  A rather obscure animation output FORM, from
the equally obscure FANTAVISION.  has this been buried yet?  I hope so...

IFF-FNTR RASTER FONT: Umm, as it says, man!

IFF-FNTV VECTOR FONT: Like, check the above.
                            CFX 5.100   Page 20

IFF-FTXT  TEXT:   Standard  IFF text format file.  Output from some editors
and word-processors.

IFF-GSCR GENERAL SCORE: Umm, a general score IFF, like music!

IFF-HEAD  FLOW IDEA PROCESSOR:  The FORM output of the FLOW ideas processor
by New Horizons Software...

IFF-IAND  IMAGINE  ANIM  DATA:   The  brilliant  new Imagine raytracer from
Impulse outputs this IFF form.  This is actual animation data.

IFF-IANM  IMAGINE  ANIM  DEFN:   This  is  like  above, except that it is a
definition  for  a particular animation file.  This file describes what the
anim data is supposed to do.

IFF-ILBM   IMAGE:   Everyone  knows  this  one.   The  acronym  stands  for
"InterLeaved  BitMap"  and is one of the original descendants of the EA IFF
document.  This is the standard output of many a paint-program...

IFF-INST INSTRUMENT: Umm, a general IFF instrument, probably used with
samples.

IFF-ISTG  IMAGINE STAGE:  This IFF form describes where all of your objects
must go, and what they must do, inside an Imagine scene.  Almost synonymous
with Sculpt's SCENE files.

IFF-MIDI FORMAT:  The MIDI FORM, as proposed by Circum Design...

IFF-PBM  VGA  IMAGE:  The I*M version of Deluxe Paint II (Extended) outputs
this  filetype.   It's  just  a  semi-compatible type of FORM ILBM, only in
256-colour VGA.

IFF-PDEF  DPRINT PAGE DEFINITION:  Definition FORM from Deluxe Print.  This
FORM  is  apparently  a  PRIVATE  3RD  PARTY  REG'D  FORM.   The acronym is
self-explanatory...

IFF-PGTB  PRG  TRACEBACK  IMAGE:  The ProGram TraceBack FORM as proposed by
John  Toebes  of  SAS/LATTICE,  so  as  to have instant information about a
program, or a "diagnostic dump image", once written...

IFF-PICS  MACINTOSH  PICTURE:  Another platform's IFF type.  This time from
the  A**le  Mac.   I'm  not too sure whether you can do anything with these
filetypes  on  the Amiga, but then again, the Amiga probably eats these for
breakfast.

IFF-PLBM  --  OBSOLETE:   Apparently  a  now  obsolete Packed Leaved BitMap
picture  file.   We  couldn't find any real information on this one though.
If you find one, send it to us!

IFF-PREF  (OS  2.x):   A  bizarre and cunning plan from Commodore.  Why not
save all of your system-configuration into tiny little parts, each of which
is  a  part of your preferences??  That's what they did.  For example, your
pointer's  image is now stored as an IFF brush (tiny as it is!) Third party
programs  can  also  join  in  the fun, and have their configs saved to the
ENV-ARCHIVE directory.  Want a CFX IFF config??
                            CFX 5.100   Page 21

IFF-PTCH:   Appears  to  be  an  IFF  PaTCH  filetype,  as used by software
distributors/authors.   I recently got one on my 5.10a update disk from the
SAS  Institute.   When used in conjunction with a master program, the patch
will add parts to your older files, and update them there and then.

IFF-RGB4  4-BIT  RGB  PIXEL  INFO:   3RD PARTY REG'D bitmap FORM.  Contains
standard BMHD chunk, except that its stored differently...

IFF-RGBN  IMPULSE GRAPHICS:  This appears to Impulses' own IFF form for 18
or  24  bit images (or is it 12 or 9??) Can't remember, but it's a graphics
format, maybe similar to the above.

IFF-SAMP  DISSIDENT'S  SAMPLE:  16 or 32 bit SAMPle standard as proposed by
the DISSIDENTS, designed to work cohesively with the MIDI standard...

IFF-SC3D  SCULPT  3D/4D  SCENE:   Unregistered  3RD PARTY FORM, used by Dr.
Eric Graham's SCULPT 3D/4D to describe a "3-D SCENE"...

IFF-SHAK SHAKESPEARE PUBLISHER:  A PRIVATE FORM containing embedded ILBM's.
This is used by Shakespeare Publisher, by Infinity Software.

IFF-SMUS  MUSICAL  SCORE:  Simple MUsical Score FORM, one of the original EA
proposals...

IFF-SYTH  SOUNDQUEST  MIDI:   "SoundQuest  Master  Librarian  FORM for MIDI
system-exclusive driver"...

IFF-TDDD  TURBO  SILVER MODEL:  FORM for ray-tracing program Turbo Silver by
Impulse...

IFF-TERM  PREF  (OS  2.x):   One  of the third-party IFF prefs forms talked
about  above.   This  one  belongs  to  the terminal program 'TERM' by Olaf
'Olsen'  Barthel.  Not a bad program, but it don't like ANSI much (but then
again, neither do I.)

IFF-TEXT PLAIN TEXT: Umm, perhaps a plain-text IFF form??

IFF-USCR UHURU SCORE: Another of the IFF musical score forms.

IFF-UVOX  UHURU  MAC  SCORE:   As above, except that it is specifically for
that giant of machines, the MCA, sorry Mac.

IFF-VDEO  DELUXE-VIDEO:   This  (apparently undocumented?) FORM is from the
Deluxe  Video program, of which I know nothing about, except that it stores
its video (movie?) outputs in this format...

IFF-WORD  PROWRITE  TEXT:   Another  output type that I don't know anything
about,  as  I  don't  use programs that don't work, and that cost more with
every  bug  you find.  This (apparently) is the IFF FORM that Prowrite uses
to output your precious documents...

ILBM  MODULO  CRUNCHER (TTW):  If you know of the "Imploder" file cruncher,
then you know who the author of this program is:  Albert Jan Brouwer.  This
guy can really throw the machine code around.  This output type is from his
program  called  "ILBMMODULOCRUNCHER"  or something like that.  It takes an
ILBM picture file and splits its bitplanes, and then crunches each bitplane
using an OK number cruncher.  The output of this program is then stored and
can't  be  used until someone runs the VIEWER program over it, and it shows
your crunched  picture.   Slightly above average crunching of picture files
makes  this  program interesting, but little else.  Oh, by the way, the TTW
stands for "The Third Wave" (which is a software group (of some kind))...
                            CFX 5.100   Page 22

IMPLODER  4  L-XLIB  NORMAL:   The  new  version of Imploder (number 4) now
supports  a  cunning  new library-imploded implementation which is slightly
longer  than  the  old  Imploder  3 XLIB version.  This "LONG-XLIB" version
appends  a new library-loading routine to the uncrunch-header, which, if it
can't  find the explode.library already resident (in the liblist) complains
by  putting  up  a  console/message.   You really should make sure that the
explode-library   is   already   resident  by  running  "LOADLIB"  in  your
startup-sequence, before running XLIB crunched stuff.

IMPLODER  4  NORMAL:   The  standard Imploder 4 uncrunch-header is slightly
different  from  previous  versions,  so  is  not  uncrunchable by previous
versions.   This  version  no longer supports PROTECTED Imploder filetypes,
but will uncrunch PROTECTED Imploded files of previous versions.

IMPLODER  DATA  (FIMP):   This is output from the data-cruncher called File
IMPloder.   It is not necessarily data crunched from an executable file, it
can  be  data  of any kind (not unlike the PowerPacker data cruncher).  The
crunch  rates  of this cruncher do not reflect upon the brilliant crunching
algorithm  that  A.  J.  B.  used, but it's not too bad.  I'm not a real fan
of this however.

IMPLODER  FILE  (NORMAL):   Without  doubt  the premier file-cruncher to be
found  on  the Amiga.  It uses a GREAT crunching algorithm, which gets more
bytes  to  crunch  than  anything else.  The IMPLODER program crunches your
file  and  stores  it  in  an unconservative output file of this type.  The
reason I say unconservative, is that the output file is made of (a minimum)
of  5  hunks.   These  hunks  are  mostly BSS hunks so that the program can
expand the BSS area and have an already reserved spot in the Amiga's memory
for  decrunching.   The  NORMAL  in its name describes the crunching method
used  on the original file, and that you can DECRUNCH the file, so that you
can have it back running nice and quickly with no decrunch times!  IMPLODER
seems  to decrunch faster than just about everything else, and it certainly
crunched  better than everything (at the moment) although I have heard that
the  people  who  wrote  DMS  (DiskMaSher)  have  written  a very good file
cruncher  that  will give this IMPLODER a run for its money.  The sad thing
about  IMPLODER  is  that  everybody has got a copy of it, but it was never
(more rumours!) legally sold anywhere in the world.  Apparently the mob who
held  the  license  for  it went under (read:  bankrupt) before the program
could  be  sold.   Also, apparently, because the license went down with the
company  (DSI,  the  one's  who  did  Marauder)  anyone  can hold a copy of
IMPLODER without fear of retribution.  (I wouldn't think so however)...

IMPLODER  FILE  (OVERLAY  NORMAL):  If you were a fervent user of crunchers
from  the  year dot on the Amiga, then you will probably have tried running
The  New  Master's  Master Cruncher 1 over the top of Dpaint, or some other
"OVERLAYED"  program.   You would also have failed.  This is because of the
bizarre  file-structure  of overlayed files.  They are usually overlayed so
that  the  entire  program  doesn't have to load into memory, only the bits
that  it currently need are loaded.  When a new bit is need, more is loaded
etc.   The  annoying  thing  about overlayed files is that they are usually
ENORMOUS,  so  why  not  crunch  them?  Well, no-one had figured out how to
crunch  overlayed  files, until IMPLODER.  IMPLODER would load a portion of
the  overlayed file into memory and then crunch that portion only.  Then it
would  append the various "layers" of the remaining parts of the program to
the  bottom  of the crunched bit.  Very tricky stuff this.  This method did
allow  for  some  reduction  in  size  of the original program, but delayed
loading  times  awfully.   The  "NORMAL"  again specifies that IMPLODER can
DECRUNCH this type of file, so there is a way out...
                            CFX 5.100   Page 23

IMPLODER  FILE (OVERLAY PROTECTED):  This filetype is of the usual IMPLODER
overlayed type, but it is also PROTECTED.  Nothing will be able to DECRUNCH
this  filetype  (except  for  the new PowerPacker, version 3) So to cut a
long  story  short,  if you want this kind of filetype decrunched, then you
have to buy PowerPacker 3...

IMPLODER  FILE (PROTECTED):  Again, a standard IMPLODED file except that it
is protected.  See IMPLODER OVERLAY PROTECTED...

IMPLODER  FILE  (PURE/NORMAL):   This filetype is output by IMPLODER if the
file  that  crunched  has its PURE bit set (see the CLI "PROTECT" command).
IMPLODER   crunches   the   program   and   attaches   a   special   "PURE"
decruncher-header  to  the file, which allows it to be made RESIDENT, if so
wished.   This  would  increase  the  loading  time  of  the file, but with
decrunch  time  taken  into  account,  the speed increase would probably be
negligible.  Your memory would also suffer...

IMPLODER  FILE (PURE/PROTECTED):  The same as above except that the program
has also been protected.  See IMPLODER OVERLAY PROTECTED...

IMPLODER  S-XLIB  (NORMAL):   This  is a new concept altogether.  This is a
standard  crunched IMPLODER filetype, except that no REAL decruncher-header
has   been   prepended   to   the  crunched  program.   Instead,  a  little
library-loader  has been prepended, and the library is then run to decrunch
the  file.   This save about 600 bytes from the secondary crunched IMPLODER
file,  but  unless you are squeezing LOTS of disks, then you can do without
this one.  This filetype can be decrunched with IMPLODER.  To run this type
of  file,  however,  you  need  the  EXPLODE.LIBRARY  to  be  in your LIBS:
directory.  The S-XLIB stands for "Short eXplode LIBrary".

IMPLODER  S-XLIB  (PROTECTED):   The  same  for  the  above except that the
crunched program has been protected, so as to disallow decrunching.

JOHN_DOE  (CRUNCHED  BUT  UNKNOWN  x7):   All of these crunchers are of the
ADDRESS-CRUNCHER  type,  that is, that they decrunch the program to a FIXED
place  in  ram, and rarely do any of them check to see if they are going to
steamroll any other program in the process.  For this reason, it is best to
avoid the use of this type of cruncher if you want to feel safe, unless you
are having a "demo-viewing" session, where it doesn't really matter if your
machine  crashes  or not.  But for serious usage, files crunched with these
crunchers should be treated as lepers...

JR-COMM  DATA  FILE:   This  filetype  is  output  by  JRComm  as a type of
configuration  file.  This is for loading your saved configs into JRComm at
a later stage.

LHARC  CRUNCHED  ARCHIVE:  This is the standard filetype from the output of
the  LHARC data archiver.  The data in the archive has received a reduction
in  size,  (has  been  crunched)  thus  the  CRUNCHED  ARCHIVE  part of the
explanation.   This  filetype can be decrunched.  This is probably the most
popular  archiver used on the Amiga today, as it has relatively good speed,
and OK unarchiving times.  Thanks must go to Mike West for pointing out the
difference between CRUNCHED LHARC files, and DECRUNCHED. CFX 5.100 now also
picks ALL types of LH compression, including STORED, LH1, LH5, and anything
else that may come along. Also, there is apparently an old (??) compression
type called LZ4 compression. CFX 5.100 also know most of these filetypes.
                            CFX 5.100   Page 24

LHWARP  (DISK-TRACKER)  ARCHIVE:   This  archiver filetype is received from
output  from the LHWARP tracker.  This is archived data taken straight from
the  disk,  track  by track (hence tracker) and then (usually) crunched and
stored  in  a  file  for  modem  transfer.  I don't think that this one can
encrypt your data, but I could be wrong...
Cf. DMS

MANDELVROOM JULIA DATA (K.  CLAGUE):  This Kevin Clague filetype is for use
in  his  excellent  program for Mandelbrot freaks, MANDELVROOM.  This is of
course a data file for a Julia set...

MANDELVROOM  MANDEL  DATA  (K.   CLAGUE):   This is another of Kevin's data
output  types  from  his MANDELVROOM program.  This particular data type is
for a Mandelbrot set...

MASTER CRUNCHER 3 ADDRESS:  The second of the Master Crunchers to appear on
the  Amiga.   (I  say  second,  'cos  I've never seen, nor heard, of Master
Cruncher  2??) This Function of the MC3 was to crunch a block of executable
data and fix it to a certain address.  This had all of the address-cruncher
problems  also, so it didn't get much use, so you probably won't get to see
many of these filetypes.

MASTER  CRUNCHER 3 DATA:  The MC3 data cruncher was invariably useless, and
very  few people tended to use it.  I think they would have preferred "ARC"
over  this type, as it possibly wasn't trusted.  I've never personally come
across  this  filetype  in  all of my testing (apart from my own test data)
except  for one strange occurrence:  The data type of Soundtracker songs is
almost identical to the data type of MC3's data crunch format.  In fact I'm
quite  sure  that  the two are same.  Someone grabbed the MC3 data cruncher
code  from the MC3 file, and whacked it into their Soundtracker.  Oh, well,
each to his own...

MASTER  CRUNCHER  3  RELOCATOR:   This  cruncher  was  definitely better at
crunching  than its cousin, TNM's Master Cruncher 1, although it apparently
caused  SO  MUCH  memory  fragmentation that its use was discarded quickly.
Sounds  like another filetype to avoid like the plague.  The crunched files
from  this  cruncher could be decrunched, if you can get the MC3 to run for
more  than  5 minutes.  I couldn't, because I had a hard-drive, and the MC3
and   hard-drive  didn't  quite  get  along  (not  unlike  NoiseTracker  II
really)...

MEGACRUNCHER/SUPPLEX ADDRESS:  At first glance, this cruncher appears to be
just  another  yuck-o  address-cruncher.   But  NO!   This cruncher is just
another  file/address-cruncher!   It  claims to be an extension of the MC1,
but apart from them both being crunchers, there is little to compare.  This
cruncher  doesn't  do a great deal of *AMAZING* crunching, so I would leave
it  alone.   A  new  version  of  this cruncher (just hacked and wanked) is
called  the  SUPPLEX  cruncher.  This new version does nothing extra, apart
from  minimally  changing one of Megacruncher's output filetypes.  See also
SUPPLEX OBJECT.
                            CFX 5.100   Page 25

MEGACRUNCHER  OBJECT FILE:  This is the filetype output by the Megacruncher
program.   This is supposedly an "object" file cruncher, in other words, it
should  crunch  pre-linked  object  files.   I  would  find  this extremely
difficult to believe, and as my test copy wouldn't run properly, I wouldn't
really  know  anything much about this file except that it could be dodgey.
I don't even know if you can DECRUNCH these files...

MOST  DATA:   The  data  type  as  supplied  on  (amongst other things) the
MEGADISC  (disk  on  a magazine).  I refer to this data type as "MOST DATA"
because  I  don't  know the exact name of the cruncher used to compress the
data.   The file "MOST" that VIEWS the files has therefore lent its name to
this  data  type.   It is an adequate data cruncher, and is usually used on
text files, and some picture files so that the MEGADISC crew can pack a bit
more  data  on  their  release  disks  (usually  with  filenames like this:
"___T_H_E__P_I_C_T_U_R_E__F_I_L_E__I_S__H_E_R_E___._._.doc_".   Its  author
is Richard Wynn and he doesn't supply the names for the MEGADISC files...

MUTANT  IMPLODER:   For some reason, all of the loonies are crunching their
wares!   And  to  make  things even more annoying for us, they are mutating
most  of  these crunched files.  This means that none of the file-examiners
know  the  filetype of these files, and nothing can uncrunch them.  Now CFX
5.100  knows  hundreds of combinations of these mutations, so finding a lot
of  them  won't  be  so hard.  CFX doesn't uncrunch them (yet!?) Of course,
once  the wankers check out CFX, they will produce mutations that CFX can't
pick,  but  that's  just  too  bad.   If  you  find  unknown (but obviously
crunched)  filetypes,  then  get  them  to us, or else we can't update CFX.
Simple.

MUTANT POWERPACKER: See above.

MUTANT POWERPACKER 3: See above above.

MUTANT TITANCRUNCH: See above above above.

NOISETRACKER  SONG:   Again  just  the same format as the Soundtracker song
format.  The song data is crunched for efficient storage.  This filetype is
of  identical  format to the Master Cruncher 3 DATA output.  I wonder where
they got the routines from??...

OBJECT  MASTER:  Another mostly useless cruncher which has found its way to
the  bottom  of  the  heap.   Again, I know very little about this filetype
except  that  it  is  possibly  an attempt at a file cruncher, and that you
probably want to throw it away, don't you?...

OKTALYSER SONG:  The song output from this very obscure little music making
program  (have  you  ever  heard  8 simultaneous voices on the Amiga?) This
filetype is a format unto its own...

PAGEFLIPPER-PLUS   ANIMATION:   The  output  filetype  of  the  PAGEFLIPPER
animator package, which I must admit, I have never felt inclined to use, or
even acquire.  Probably incompatible with ALL other anim filetypes...
                            CFX 5.100   Page 26

PAGESTREAM  EXPORT  DRIVER:  For you PAGESTREAM freaks out there, I thought
that  I'd include these in case you got your directories mixed up.  I don't
know  anything about these PAGESTREAM filetypes except that PAGESTREAM uses
them.  Besides, if you use Pagestream, you'll know what these are...

PAGESTREAM FONT DATA FILE: See PAGESTREAM EXPORT DRIVER...

PAGESTREAM FONT MAP FILE: See PAGESTREAM EXPORT DRIVER...

PAGESTREAM IMPORT DRIVER: See PAGESTREAM EXPORT DRIVER...

PAGESTREAM PRINTER DRIVER: See PAGESTREAM EXPORT DRIVER...

PAK  ARCHIVE:  This is a self-unpacking archive filetype.  This is from the
"PAK"  program  (by  Mark  Riley??)  and  doesn't  offer  very  much in the
archiving line...

PC  EXECUTABLE  FILE:   Yuck!  At least we can find these, I suppose.  This
is,  as you guessed, an I*M PC executable (*.exe) file.  There doesn't seem
to  be  a regular pattern of bytes in the PC's *.com files, so I don't find
those.

PC  PAK  ARCHIVE:   A  new,  and fairly cunning archiver on the PC, which I
haven't  as  yet  seen  on  the  Amiga.   This  sports fairly comprehensive
compression, and good uncrunch speeds.  Don't get too excited, however.

PCX  IMAGE:   Yes,  another  alien  graphics  format!   This  is one of the
innumerable  PC  graphics  formats,  that we all love to try and convert to
HAM.

PKWARE  AMIGA  ZIP ARCHIVE:  An Intuition ZIP archiver filetype.  I haven't
personally  used  ZIP  (except  on  the AT) so I don't really know how much
better  than  LHARC  it  is,  if at all!?  Of course this is a decrunchable
filetype...

POSTSCRIPT  OUTPUT:   This is an output type of AdPro on the Amiga, but I'm
not too sure if this is a standard Adobe Postscript file.  It most probably
is,  I  think.   Therefore,  just  think  of  this as a standard Postscript
filetype.

POWER  WINDOWS  DATA:  One of the more useful programs to be written in the
past  decade,  this  output  data  type  is  from  the  POWER  WINDOWS, the
programmer's Intuition tool...

POWERPACKER  COMMAND  <3:   The  second  best  file cruncher around (at the
moment!)  that  I've personally seen.  Various "Turbo" versions have sprung
up  from  various  (dodgey)  sources  of late.  They all work the same, and
present  the  same  output,  which  this is a part of.  The "<3" part of my
description is to inform you that CFX will find PP filetypes BEFORE version
3  of  PP.   Nico Francois has written PP3, which looks like it should give
IMPLODER  a  run  for  the  top  cruncher  spot.  This filetype (again!) is
GENERALLY decrunchable, unless, of course, you run into the dreadful MASTER
crunch.   MASTER crunch is a standard crunch mode with (what appears to be)
two or three different machine-words of information in the decrunch-header.
This  allows  MASTER  crunched  files  to run perfectly well, but you can't
uncrunch  them  with  PowerPacker  (any versions) in normal mode.  When you
enter  MASTER  mode in PP, it says:  "Welcome to MASTER MODE, MASTER CRUNCH
activated!" Only then can you uncrunch MASTER crunched files.  I don't know
how to get into MASTER mode in a standard PP, so if you know, then tell me!
All  of the PowerPacker filetypes have a MASTER equivalent, except the data
modes.  CFX 5.100 (we hope) knows them all.
                            CFX 5.100   Page 27

POWERPACKER  DATA  <3:   This  is the PP data crunch filetype, which is
quite   reliable,   and   quite   popular.    Not  really  recommended  for
archival/xferral  work,  but useful for off-site storage.  Generally always
decrunchable...

POWERPACKER DATA-ENCRYPTION <3:  The same as above, except that you will
need a password to decrunch the data.  If you don't know the password I can
suggest a fix:  delete the thing...

POWERPACKER  3  COMMAND:   Still  the second best file-cruncher around.
This  release  of  PowerPacker, version 3, appears to have more features
than  previous  versions,  but the crunching power of the 3 ISN'T greatly
improved.   This  filetype can only be decrunched with version 3 of Power
Packer.   The  crunching method used is similar to before, but the decrunch
header  has  been  totally  rewritten.   There  aren't  many  more  changes
apparent, except for the built-in TURBO crunch.  Turbo Imploder wins again.

POWERPACKER  3 DATA:  This is the PP 3 data crunch filetype, which is
again  very similar to previous versions of the PowerPacker data cruncher.
The  decrunch header is exactly the same as previous versions of this type.
Data  is  most probably interchangeable between versions of this type.  This
is filetype is generally decrunchable...

POWERPACKER 3 DATA-ENCRYPTION:  The same as above, except that you will
need a password to decrunch the data.  If you don't know the password I can
suggest a fix:  delete the thing...

POWERPACKER  3  ENCRYPTED  COMMAND:  Appears to be standard PP command-
cruncher filetype except that to decrunch this file with PP again, you will
need the password, as in PP DATA-ENCRYPTION.  This file performs as desired
under  execution.   It's  just that you can't decrunch it easily unless you
have  the password.  The passwording technique used by the author is fairly
intricate,  but I wouldn't be surprised if someone writes a decoder for the
thing...

POWERPACKER  OVERLAYED  COMMAND:  Not to be out-done by the Imploders, PP 3
can now crunch overlayed files.  This type of file (overlayed) is displayed
by  CFX by having an "O" as the second flag in its listing.  Like Imploder,
PP  3  only  loads  the  initial  Reloc_32/16  hunks  into memory, and then
crunches  that  data.  It then appends the "overlayed" hunk sections to the
bottom  of  this  crunched  data,  and finally prepends its own decrunching
header  to  the file and saves it out for you.  Standard application of the
Imploder  idea.   I  don't know who thought of it first, but it's not a bad
idea,  but  not  too  effective really (as far as crunching overhead goes!)
This  filetype  cannot  be  ENCRYPTED  by PP 3 as yet, but don't worry, the
author will probably figure it out shortly...

PRE-LINK  OBJECT  MODULE:   This filetype is brought about by compilers and
assemblers  before  it  is  LINKED  to form an executable file.  It is also
sometimes used to make reference libraries for programmers...

RED  SECTOR  DEMOMAKER  DEMO:  This is a funny little filetype which should
prove  which coders are really coding their demos.  The RS Demomaker allows
the  user  to  make a demo and then save it out, as such.  This filetype is
the direct result of this output.

RELOKIT:  A truly wonderful piece of crap this program.  Use PowerPacker to
decrunch  and rebuild this poor file.  Relokit fools with the original file
and  outputs  this  garbage, which is neither crunched properly, or changed
significantly for the better...
                            CFX 5.100   Page 28

RESOURCE  .RS  MODULE:  The best Australian program ever written:  RESOURCE
by  Glen  McDiarmid, from Ipswich, QLD.  He has worked his butt off to make
this the best disassembler/debugger on the market.  It's workings are quite
unfathomable, as it is *SO* intelligent.  No, I'm not being sarcastic, this
is  the  real  thing.   This filetype is from this sublime program, and can
only be used with paid-registered original copies of RESOURCE...

SAS/C TRACEBACK DUMP: See IFF-PGTB.

SOFTWOOD FILER II PROJECT:  The very best small-end database for the Amiga.
This is the output from the SOFTWOOD FILER II database...

SOUNDTRACKER SONG: See NOISETRACKER II SONG...

STANDARD-FILESYSTEM BOOTBLOCK:  Just a normal "GRABBED" AmigaDOS bootblock,
generally  of  1024  bytes  length,  but  it  can be more, depending on the
program that it was grabbed with...

STONECRACKER:

SUPPLEX OBJECT:  This is the filetype output by the SUPPLEX cruncher.  This
is  supposedly  an "object" file cruncher, in other words, it should crunch
pre-linked  object  files,  much  like  the  MegaCruncher  (which this is a
hack-up version of.) The outputs from this cruncher (like MegaCruncher) are
so  ineffectual, and so lame that I cannot see why you'd use this cruncher.
I don't even know if you can DECRUNCH these files...

SYNCROPACKER  ADDRESS:   Practically  just  another  address-cruncher, with
nothing  special to contribute to the world of Amiga owners.  Has the usual
address-cruncher problems, and doesn't appear to be decrunchable...

SYNCROPACKER RAW:  The Syncropacker data filetype is like its crunched file
brother in that it is next to useless, and not decrunchable...

TEMP GIF FILE (M.  PODLIPEC):  This is the output of Mark Podlipec's GIF to
HAM program (or is it HAM to GIF?) I can't remember...

TETRAGON  'TETRAPACK':  Probably the best loved (and hated) of the address-
crunchers.   This  is  the  cornerstone of address crunchers, as it is very
good  for what it does.  It allows chunks of executable code to be crunched
and  fixed  to  a certain address, and then decrunched to the same address.
It is especially found in demos, and cracked games, as it rarely crashes if
it  is  the only thing running.  Tetrapack also has the capability of using
the  mega/pro decrunch mode, which allows it to start up games right at any
moment  inside  the  game's  code,  sort  of  like  a  software  version of
FreezeMachine.   Love  it or hate it, it's going to be around for some time
yet.  CFX 5.100 knows a few different versions of this cruncher.  Generally
not decrunchable...
                            CFX 5.100   Page 29

TIMECRUNCHER:   Another  address-cruncher  that does nothing but steamroll
certain memory areas.  Not decrunchable, however, so it's annoying.

TITANCRUNCH  'OVERLAYED':   This  is a new concept in crunching.  The title
may  suggest that this cruncher is FOR overlayed files.  Quite the opposite
is  true.   This cruncher takes NORMAL non-overlayed programs, and crunches
them,  then  writes  out  this output filetype which IS overlayed.  Because
overlayed  programs  are  hard  to get at (ie.  prying fingers) this offers
some  form  of primitive protection.  It also allows machines low on memory
to  load in a part of the program, decrunch it to memory, and then continue
on loading small parts of the program and decrunching, thus eliminating the
need  for  HUGE  memory  areas  for  decrunching.   The decrunching process
appears  to  takes  significantly  longer than other crunchers however.  To
decrunch this one, you will need the new PowerPacker, version 3...

TNM'S MASTER CRUNCHER 1:  Probably as close to the first file-cruncher that
we  will  get.   The  New  Masters  they  were  called.  This cruncher uses
classical crunching techniques, along with adequate crunching rate and byte
kill  factor.  The decrunching speed of this filetype is quite inoffensive.
Easily  decrunched  by  itself  (MC1)  or just about any PowerPacker.  This
probably  leads  to  memory  fragmentation, although I haven't witnessed it
first  hand.   Probably  the  overall  most-oft-used  file  cruncher in the
world...

TRISTAR  DOUBLE  ACTION:  The Double Action cruncher claims to be about the
best  cruncher  around.   I  found  otherwise.  It constantly crashed on my
2000.   I  didn't even get to benchmark it alongside IMPLODER and PP.  This
output  type is of the address-cruncher type, in other words, it decrunches
its  program  straight  to memory.  Probably not decrunchable.  It probably
has  many  different crunching modes, but as none of them would work, I was
hard-pushed to get a header file from any of them, but I did (just)...

TSK  (?):   This  little  beauty  just  kept  on  avoiding and avoiding.  I
couldn't  get  a  header file or anything from it.  Crash, crash, crash etc
etc.  Appears to be another address-cruncher, probably written to celebrate
that Lars had cracked his first copy-protected disk.  Good on you Lars...

TUFF  ADDRESS:  A nicely cleaned up version of Bytekiller, sporting a speed
increase  of  around  30%.  This speed increase is because of a shutdown of
just  about  all  DMA stuff, except the crunching routine.  Slightly better
crunching too, I must add.  How do I know this?  Because I wrote the thing.
It  is  essentially  another  address-cruncher,  with  the same problems as
before,  but  it  is  quicker.   Generally  not decrunchable, but with some
trickery can be decrunched...

TURBO SILVER OBJECT:  An output of this type is from Impulse's Turbo Silver
raytracing program.  This is a specific object ONLY, and not a scene file.

TURBOSQUEEZER:   From  the French:  TURBINE, generally accepted larrikinism
for  "SPEED"; also SQUEEZER, meaning to make smaller, to crunch.  How wrong
they  could  be.   This  cruncher  is neither TURBO (ie.  fast) nor is it a
squeezer,  as  it often makes your files BIGGER.  This is a hybrid cruncher
that  defies  explanation.   Generally not decrunchable, but you can try if
your brain can take it...

VIDEOSCAPE 3D CAMERA FILE:  Videoscape 3D output file for camera positioning
inside of animation "scenes"...

VIDEOSCAPE  3D  MODEL  FILE:   Output  file  describing  various parts of a
centralised  "OBJECT"  or  "MODEL"  to be placed inside of a scene, so that
Videoscape 3D can render the scene, complete with the model.  The model can
be designed with various "modeling" software (ie.  Aegis Modeler)...
                            CFX 5.100   Page 30

VIDEOSCAPE 3D MOTION FILE:  Videoscape output file describing the movements
of essential parts of a "scene" within a Videoscape 3D animation...

VIDEOSCAPE  3D SETTING FILE:  Output file from Videoscape 3D describing the
aesthetic parts of a Vscape animation scene...

WARP (DISK-TRACKER):  One of the first disk-trackers to be presented to the
Amiga.  It is the predecessor to DiskMaSher, and from the same company.  Of
course,  DiskMaSher  has  now made WARP redundant.  Used to archive certain
(or  all)  tracks  from a disk, crunch them, ready to send via modem, or to
store for archival purposes.  Of course this one is decrunchable...

WORKBENCH .info FILE: Just the usual icon files, really.

ZOO:   Another  interesting  Amiga file archiver, which was one of the best
until  the  spate of Lempel-Zev/Huffman encoding algorithms ended its reign
of  superior archiver.  Now LHARC and PKAZIP have taken over from this one,
but   you   will   probably   see   this   filetype   around  occasionally.
decrunchable...

ZOOM  (DISK)  ARCHIVE:   A  new  disk-tracker  from  Olaf Barthel, I think.
(Correct  me  if  I'm wrong!) I haven't really used it much, so I only know
that it crunches a disk, track by track.  That's it really, other than it's
generally decrunchable.
                            CFX 5.100   Page 31







               CORRESPONDENCE, BUG REPORTS, PRETTY POSTCARDS
               ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Mail:
¯¯¯¯
    BOB RYE
    4 COULTER STREET
    WENDOUREE
    VICTORIA
    AUSTRALIA
    3355



Don't  forget  to  include  your  FIDO Netmail address, and personal postal
address.



NetMail address (FidoNet):
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
  BALLARAT MAIL 3:635/509

  Phone: [Intl. [phone]] [National 053 420845] Line 1 (Up to 9600)
  Phone: [Intl. [phone]] [National 053 420807] Line 2 (Up to 2400)

  SysOp: Stephen Walsh

The  latest  PUBLIC version of CFX will always be available on this BBS, in
the Amiga files section.
                            CFX 5.100   Page 32

                          REGISTRATION = $25 AUS!
                          ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
If  you're  using  a  non-registered  version of CFX 5.100, and you like it
(let's  face  it,  what's  there  not  to  like??) then please register it.
Hundreds  of  hours, very long hours, have been put into this program.  AND
it's  the best of it's kind, worldwide.  Australians haven't really been at
the  forefront of anything for a while, so why not make this program one of
those great Australian things (like, umm, you know what I mean!)??  Support
us and we'll support you.  This is the ShareWare announcement straight from
CFX's "-b" option.  Please read it.

/*-----------------------------------------------------------------------*/
 CFX is a file examiner with a difference. It doesn't claim to be anything
 but a file examiner. Of course, something written today will be out of date
 tomorrow, but we are committed to making, and keeping, CFX the best file
 examiner that your precious ShareWare money can buy.

 This version of CFX is ShareWare, which means that if you use CFX, you
 really should provide a small contribution to the authors. We suggest a
 nominal fee of $25 AUS (See DOCS), which will not only endear you to us
 forever, but will also allow you free updates and upgrades whenever they
 are available. Be daring! Register this ShareWare product today!

 Registration/author contact:                       FIDONET:
                              BOB RYE                        3:635/509
                              4 COULTER STREET
                              WENDOUREE, VICTORIA
                              AUSTRALIA, 3355
/*-----------------------------------------------------------------------*/

What do you get for registering?? Here is the short list:

Personal  compiled  copies,  compiled  to  your  specifications (ie.  fully
optimised,    68000,   68010,   68020,   68030,   68040,   all   supporting
maths-coprocessors.

The  ability to utilise the "-u" option and fully virus-check and report on
crunched files.

A clear conscience.

Notification  of  updates,  upgrades  as  they happen.  I will be notifying
registered  users  through  Netmail,  so  you  should  include your Netmail
address  when  sending  in  your  registration  monies.   (Failing  Netmail
notification,   I  will  provide  snail-mail  notification.)  International
money-orders are fine, thanks.

Due  to  my unemployment, and the fact that I'm flat stoney broke, I cannot
cover  the  costs  of  postage  for  updates  and upgrades.  Your immediate
ShareWare  contribution does cover the primary media and postage cost, but,
unfortunately,  I cannot continue to supply a printed manual.  If you would
like  a printed manual, please enclose an additional $10 AUS.  For Air-Mail
postage,  please  enclose  an additional $10 AUS.  All registered users may
send  a stamped, self-addressed disk-mailer (please quote your registration
number)  to  me  at  any  time  and  they  will  receive the latest version
update/upgrade  for  no  cost.   To  register,  fully  complete  and sign a
printout  of  the registration form at the end of this document, and get it
to me, pronto!
                            CFX 5.100   Page 33



                         CREDITS & ACKNOWLEDGMENTS
                         ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯


Kim Benson       - for putting up with my very late nights and tangential
             thinking, and for feeding me and keeping me warm.
             There you go, Poss, you've now been read by at least
             5 users worldwide! You're famous!

Marcus Mroczkowski - for technical expertise, keeping my Amiga alive, ideas,
             manual filetype examination, ideas, beer, dim-sims,
             exhaustive virus-examination and infection,
             beta-testing, ideas and company. Want a sick computer
             fixed?? See Marcus.

Brett O'Callaghan  - one of THE beta-testers who also contributed positively
             to the development process, for brilliant ideas, for
             being intelligent, and for telling me about Larry
             Niven. (Anyone know where I can buy a Nessus doll
             from??)

Stephen Walsh       - another beta-tester and sysop of my favourite BBS, who
             made constant suggestions for improvement and who also
             made this file available to you through the ADS.

Brendan Pratt      - a beta-tester from Qld, with a big BBS to boot. Thanks
             for the access to SideCar, the files, and the testing!

Guns N' Roses       - another spectacular album (or two.) While I can't
             really admit that Axl actively beta-tested during the
             recording of UYI 1 & 2, I have heard a rumour that
             Slash did have a quick tinker during mixing...

Van Halen       - thank God Sammy didn't leave Van Halen. Otherwise I
             couldn't have cruised to 'Judgement Day' from 'For
             Unlawful Carnal Knowledge'. Could you imagine that
             pose David Lee Roth singing THAT?? And a word for
             Eddie, stick to the guitars, mate...

Brian and Richard  - thanks for the viruses, guys. I hope the program lives
             up to all expectations. Talk to you soon.

Martin Wicks       - where the f**k are my cheerleaders??

Darius Ignasiak       - who was my first "SHAREWARE" contributor, and who has
             continued to support the project. Darius, here is your
             5 minutes of fame: Darius is the first person in the
             WORLD to receive a registered (paid) copy of CFX 5.100.
             I hope it gets there on Friday! I hope you like this
             Darius...

Justin Downey       - who was the first to comment on the program, and who
             has dissappeared. Where are you, Justin??

Mike  West       - my friend from the center of Australia. Two questions
             remain on my lips. Where are you Mike?? Had your baby
             yet?? *;-)

SAS/C           - for providing an *awesome* compiler. Competition? What
             competition? The first supportive computer/software
             company that I've ever seen.

Commodore Amiga    - for OS 2.x. This is great. One thing though, where is
             my developers kit?? Surely you've seen my application
             by now??
                            CFX 5.100   Page 34





                      REGISTERED USERS AS OF 15/02/91
                      ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯


1. Darius Ignasiak


2. Mike West


3. Stephen Walsh


4. Brett O'Callaghan


5. Richard McElvenny


6. Justin Downey


7. Brendan Pratt






         Updates will be forthcoming as soon as changes are made.
MAIL TO:
    BOB RYE
    4 COULTER STREET
    WENDOUREE
    VICTORIA
    AUSTRALIA 3355


CFX  REGISTRATION:   I  (Bob Rye) will not accept monies from any person in
payment  for  registration of CFX if the person's signature is not included
on this form.  You have been warned.

Please read the registration page and this notice fully:

                                DISCLAIMER
                                ¯¯¯¯¯¯¯¯¯¯
ALTHOUGH  OUTSTANDING  BUGS IN THE CODE HAVE BEEN ELIMINATED, THERE REMAINS
THE POSSIBILITY OF UNFORESEEN PROBLEMS.  WE RESERVE THE RIGHT TO REFUTE THE
WORD  OF  THE  USER  AS TO THE EXTENT OF SUCH 'BUGS', BUT IF FOUND, WE WILL
ATTEMPT  TO FIX SUCH PROBLEM(S).  IF, HOWEVER, UNFORESEEN BUGS ARE FOUND TO
CAUSE  YOU  MENTAL  AND/OR  PHYSICAL  PAIN, THEN THAT IS AS THEY SAY IN THE
CLASSICS, BAD LUCK!  WE ACCEPT NO BLAME FOR ANY LOSS OR INCONVENIENCE FOUND
TO  ARISE  FROM  THE  (MIS)USAGE  OF THIS PROGRAM.  WE RESERVE THE RIGHT TO
WITHDRAW  SUPPORT AND UPGRADES AT ANY TIME.  WE PROBABLY WON'T DO THIS, BUT
WE HAVE THIS RIGHT.

If you would like to continue with registration, please fill in the below.
The registration fee is $25 Australian.

NAME:______________________________________________________________________


ADDRESS:___________________________________________________________________


        ___________________________________________________________________


        ___________________________________________________________________


MACHINE CONFIGURATION: (ie. 500, 1000, 2000, 3000, accelerator etc)


___________________________________________________________________________


___________________________________________________________________________


I  hereby  attest  to  my  understanding  of  the  above terms by giving my
signature:


SIGNATURE:____________________________________________


DATED:_____________________


Depending upon mode of mailing chosen (by you, read the registration page!)
please allow up to eight weeks for delivery of your copy of CFX.