home *** CD-ROM | disk | FTP | other *** search
/ ftp.barnyard.co.uk / 2015.02.ftp.barnyard.co.uk.tar / ftp.barnyard.co.uk / robot-pd / 22300.ZIP / 22300B.DSK / notes20.doc < prev    next >
Text File  |  1998-05-08  |  31KB  |  573 lines
  1. CRLZH and UNCRLZH v2.0 are new releases of the LZH algorithm merged with 
  2. updates to the CRUNCH programs (thru v2.8):
  3.  
  4. 1) A new encoding algorithm is used.  This new algorithm COMPRESSES FURTHER 
  5.    than v1.1.  The UNCRLZH v2.0 program can detect files encoded with the 1.1 
  6.    algorithm and can automatically select proper decoding method.
  7.  
  8. 2) The LZH algorithm has been extensively re-coded for speed.  Test cases have 
  9.    shown decreases in compression time of 10% or more (times vary with type of 
  10.    material being compressed).
  11.  
  12. 3) The file limit has been changed back to 256 to reduce run-time space 
  13.    requirements.  If this is a problem, the limit can be changed by the user 
  14.    with re-assembly of the file(s).
  15.  
  16. -----------------------CRLZH/UNCRLZH v1.0 notes follow---------------------
  17.  
  18. CRLZH and UNCRLZH v1.1 are virtually identical to their 1.0 versions (the 
  19. Beta test versions) with the following exceptions:
  20.  
  21. 1) The version number placed in the LZH-Encoded file (part of the header) 
  22.    is now 11h instead of 10h (for 1.1 vs 1.0).  Other than that minor 
  23.    detail, the files produced by this official release and the Beta test 
  24.    will be identical.  (Files produced with the Beta version are acceptable 
  25.    to UNCRLZH v1.1).
  26.  
  27. 2) The CRLZH program is marginally faster.  Some small speed enhancements 
  28.    were made, but the algorithm is intrinsically slow.
  29.  
  30. 3) The UNCRLZH program has been changed to default to the file extension 
  31.    .?Y? when the extension .* is used (see CRUNCH 2.4 notes, below, under 
  32.    the heading: 4. DETAIL INVOLVING FORCED "?Z?" EXTENSION [UNCR only].) 
  33.    This means that to UNCRUNCH all ?Z? files, you must use .?Z? rather than 
  34.    .* (.* will only find .?Y? files).  HOWEVER, the character used has 
  35.    been made a configurable item (see patch information), so you can tailor 
  36.    it for your preference.
  37.  
  38. 4) The display format differs slightly (a few extra CR-LF sequences).
  39.  
  40. -----------------------CRLZH/UNCRLZH v1.0 notes follow---------------------
  41.  
  42. CRLZH and UNCRLZH v1.0 (Beta test versions) are based upon S. Greenberg's 
  43. CRUNCH and UNCRunch programs (v2.4).  The intent was to provide a user 
  44. interface identical to existing programs (similar function - similar 
  45. interface).  CRLZH and UNCRLZH differ from Steve's programs in the 
  46. following areas:
  47.  
  48. 1) CRLZH makes files with a 'Y' in the extension (as opposed to 'Z').  The 
  49.    UNCRLZH program recognizes this as the extension for LZH encoded 
  50.    files.
  51.  
  52. 2) CRLZH progressively changes the file extension of the crunched file, 
  53.    allowing for a bit more user insight into the original file name.  It  
  54.    operates upon file extensions as follows:
  55.  
  56.       BLANKS - converted to .YYY
  57.       .123   - converted to .1Y3
  58.       .?Y?   - converted to .?YY
  59.       .?YY   - converted to .YYY
  60.  
  61. There was no reason to tamper with the format CRUNCH uses on the output 
  62. file.  Therefore, with the exception of taking the 'next' file type in 
  63. sequence (SQueezed files begin with a 76h,FFh sequence; Crunched files with 
  64. 76h,FEh; so LZH encoded files begin with 076h,FDh) and setting the revision 
  65. levels in the header to 1.0, there's no difference in the output file 
  66. format.  You can probably coax your time/date stamping into operating 
  67. on LZH encoded files.
  68.  
  69. UNCRLZH preserves the capability to operate on CRUNCHED and SQueezed files, 
  70. so you can use it on your system as a replacement for UNCR.  There were no 
  71. changes to these features (Uncruncing and Unsqueezing was supplied in .REL 
  72. file form) so fear not!  The driving program was altered ONLY to recognize 
  73. the additional file type and branch to the new decompression code (version 
  74. number and sign-on message text was altered, too...but that's trivial.)
  75.  
  76. Since these programs are BASICALLY CRUNCH v2.8 and  UNCRunch  v2.8, the user 
  77. interfaces are the same.  The the version 2.3 internal revision information 
  78. in the CRUNCH program has been preserved so that the program can be 
  79. configured by the same programs (if any exist).
  80.  
  81. -------------------CRUNCH/UNCRunch v2.8 history follows-------------------
  82.  
  83.  
  84.                        CRUNCH/UNCR HISTORY
  85.  
  86.  
  87.      +--------------------------------------------------------+
  88.      | Previous versions of CRUNCH/UNCR included no history   |
  89.      | file, with the exception of partial histories accom-   |
  90.      | panying the DateStamper (2.3D) versions.  This history |
  91.      | file has been compiled by condensing the contents of   |
  92.      | release notes and other information included in previ- |
  93.      | ous distribution libraries available to me.            |
  94.      |                                       Gene Pizzetta    |
  95.      |                                       March 19, 1991   |
  96.      +--------------------------------------------------------+
  97.  
  98.  
  99. Version 2.8 -- May 5, 1991 -- Gene Pizzetta
  100.      Fix one bug and create another!  But this one is very minor: 
  101.      if the file was copied (rather than crunched) the date stamp 
  102.      was written to the destination file twice.  And if the A 
  103.      option was used, the  archive attribute was set twice on the 
  104.      source file (the latter dates from version 2.4).  Thanks to 
  105.      Howard Goldstein for finding that one.
  106.  
  107. Version 2.7 -- April 27, 1991 -- Gene Pizzetta
  108.      Implemented Bruce Morgen's suggestion for a ZCPR3-only 
  109.      version that would allow UNCR to be smaller than 8K and 
  110.      still uncrunch LZH files.  In the ZCPR3-only version the Z80 
  111.      CPU test is replaced with a Z-System check.  Also fixed a 
  112.      bug: Bruce Morgen reported that CRUNCH with the A option 
  113.      failed to set the archive attribute on the source file if 
  114.      the destination file was in a different user area.  Putting 
  115.      the call to DATSTP after the call to ARCIT fixed that 
  116.      problem.  Howard Goldstein reported that if either program 
  117.      aborted because of insufficient memory, an arbitrary number 
  118.      of "files processed" was displayed.  The file count is 
  119.      initialized later in the code, but zero files is now 
  120.      displayed in that case.  Minor screen format corrections: 
  121.      "[ file empty ]" message was flush left, instead of one 
  122.      space in, as it should have been; and the disk change prompt 
  123.      was being overwritten by the next file crunched, for lack of 
  124.      a carriage return/line feed.  ZMAC/ZML instructions added to 
  125.      TEC file.
  126.  
  127. Version 2.6 -- March 26, 1991 -- Gene Pizzetta
  128.      Failure to initialize TRPFLG for each file sometimes caused 
  129.      an extra null code to be inserted near the beginning of the 
  130.      crunched file.  This bug in no way affected the validity of 
  131.      the crunched file.  Also failed to include an LZH equate in 
  132.      CRUNCH.Z80 after adding LZH uncrunching to UNCR.
  133.  
  134. Version 2.5 -- March 21, 1991 -- Gene Pizzetta
  135.      When running under ZSDOS, now copies the source file date 
  136.      stamp to the output file when crunching, uncrunching, or 
  137.      just copying.  In addition, the date stamp is stored in the 
  138.      header of the crunched file, in the same manner as the 2.3D 
  139.      versions.  UNCR gives priority to the embedded date stamp, 
  140.      it it exists, for the output file.  In either case the 
  141.      current date will be used as the access date.  If the modify 
  142.      date is blank (a non-standard condition), it will be 
  143.      supplied from the create date.
  144.  
  145.      New S option toggles between including and excluding system 
  146.      (hidden) files.  As distributed, system files are excluded 
  147.      by default.  The old O option has been renamed the E option 
  148.      (erase existing files), and the old C option has been 
  149.      renamed the I option (inspect mode), for compatibility with 
  150.      other standard ZCPR3 utilities.  The old options still work, 
  151.      though, for those who have become accustomed to them.
  152.  
  153.      Now handles up to 512 matching files, if an ambiguous 
  154.      filename is given.  (The number of files can easily be 
  155.      increased, if anybody has need for it.)  Version 2.4 could 
  156.      handle 256 and version 2.3D only 127 matching files.
  157.  
  158.      UNCR now uncrunches LZH-encoded files, using the R. Warren's 
  159.      UNLZH.REL module.  It checks the header of LZH files for an 
  160.      embedded date stamp, although no LZH cruncher inserts the 
  161.      date at this time.  Nevertheless, we're ready if it ever 
  162.      happens.
  163.  
  164.      Screen displays have been compacted somewhat to allow 
  165.      display of more filenames on the screen (twice as many in 
  166.      quiet mode).  High bits are now filtered when displaying 
  167.      filenames so you won't see weird characters.  (For UNCR the 
  168.      quiet mode screen looks the same, no matter what kind of 
  169.      file is being decompressed.  Each file takes a single lines, 
  170.      unless it's a direct copy.)
  171.  
  172.      Under ZCPR3 the command processor parses the filespecs, so 
  173.      all permissible user areas are available.  Under ZCPR33 and 
  174.      above, invalid directory specs will generate an error rather 
  175.      than defaulting to the current directory.  The usage screen 
  176.      will also reflect the actual name of the COM file, even if 
  177.      re-executed with the GO command.
  178.  
  179.      All options are configurable as the default operating mode.  
  180.      The usage screen now reflects the current effect of the 
  181.      command line options, if they are used.  All configuration, 
  182.      including CRUNCH's exclusion list, can be done with ZCNFG.  
  183.      The same CFG file is used for both CRUNCH and UNCR, but some 
  184.      configuration options are not effective for both programs.  
  185.      See the ZCNFG help screens for full details.
  186.  
  187.      Other changes:  If the original file already has a "Z" as 
  188.      the middle character of its filetype (for example, "AZM"), 
  189.      CRUNCH will now change only the last character of the 
  190.      filetype to a "Z", unless that character is also already a 
  191.      "Z".  If either program is aborted with a ^C, the partial 
  192.      output file will be closed and erased, so zero-length files 
  193.      will no longer be left behind.  Incorporates routines from 
  194.      version 2.3D that traps and alters any occurrence of the 
  195.      command mode sequence used by Telenet and PC-Pursuit, so 
  196.      file transfers will not be aborted on those systems.  CRUNCH 
  197.      now recognizes LZH encoded files as already crunched.  
  198.      Various messages have been added or altered to be more 
  199.      specific or for aesthetic reasons.
  200.  
  201.      This version is a direct descendant of version 2.4.  Other 
  202.      than the TRAPIT routines, none of the version 2.5 code comes 
  203.      from the various 2.3D versions, although those versions 
  204.      originated the embedded date stamp idea incorporated herein. 
  205.      Many, many thanks go to Howard Goldstein for his ideas, his 
  206.      help, and his bug finding skills.
  207.  
  208. Version 2.4 -- September 15, 1987 -- Steven Greenberg
  209.      CRUNCH and UNCR 2.4 process and generate files identical to 
  210.      version 2.3 (except embedded revision level byte), 
  211.      regardless of mode of operation.  A few very observant 
  212.      people noticed that v2.3 could output valid (but different) 
  213.      files when running in "quiet" mode.  The output of v2.4 
  214.      should be identical to v2.3 running in verbose mode, except 
  215.      for the embedded revision level byte.  Some changes were 
  216.      made in the implementation of the "core" of the algorithms 
  217.      for both CRUNCH and UNCRunch -- in the case of CRUNCH, 
  218.      conditionals were removed by splitting into three separate 
  219.      loops.  In the case of UNCRunch, an unnecessary chase to the 
  220.      end of "virtual links" was eliminated by aborting the search 
  221.      as soon as an available reassignments lot is found.  Other 
  222.      performance improving changes include less time updating the 
  223.      screen and dynamic I/O buffer sizing.  Non-time-critical 
  224.      "user-interface" changes (e.g., the "tag mode" code, etc.) 
  225.      were coded in as straightforward a manner as possible, with 
  226.      little regard to code space minimization and even less to 
  227.      speed.  The great majority of the changes are user interface 
  228.      related:
  229.  
  230.      A new option lets you select any number of files from a 
  231.      group for processing.  After all the selections have been 
  232.      made the files will be processed.  Selections are presented 
  233.      and processed in alphabetical order.
  234.  
  235.      If CRUNCH ever creates a file larger than the original, the 
  236.      file will automatically be erased and replaced with a direct 
  237.      copy of the original.  If the original is already crunched 
  238.      or squeezed, or if the filetype matches a user configurable 
  239.      exclusion list, such as .LBR or .ARC, a straight copy 
  240.      operation will be substituted.  Thus all specified files 
  241.      will be transferred in the most efficient manner, 
  242.      facilitating the use of CRUNCH for the creation of .LBR's or 
  243.      as a backup utility.  Similarly, UNCR will either uncrunch 
  244.      or direct-copy all specified files for full restoration.
  245.  
  246.      If CRUNCH or UNCR fills an output diskette during a wildcard 
  247.      operation, the last (partial) file will be deleted and the 
  248.      user will be prompted to change diskettes.  Operation will 
  249.      then continue, starting with that last file.
  250.  
  251.      UNCR and CRUNCH take as many as three or four (respectively) 
  252.      command line options, in any combination.  Each option 
  253.      corresponds to a mode which can be set to default to an 
  254.      user-defined state.  The command line toggle will then flip 
  255.      the state back on or off.
  256.  
  257.      The archive mode toggle, when turned on, will only crunch 
  258.      files that have changed since they were last backed up 
  259.      (based on the CP/M directory archive bit).  When running in 
  260.      this mode each input file will be flagged as archived as 
  261.      soon as the crunch operation for that file has completed.  
  262.      The "prompt before overwrite" mode toggle allows command 
  263.      line control of whether the program stops to warn you each 
  264.      time it is about to overwrite a file with the same name.
  265.  
  266.      UNCR now also unsqueezes as an added convenience!  Usage is 
  267.      identical.  UNCR will automatically recognize the file's 
  268.      format and use the appropriate algorithm.
  269.  
  270.      Modest speed improvements have been made through a variety 
  271.      of techniques, including more data buffering to reduce disk 
  272.      activity.  The extended buffers are dynamically allocated to 
  273.      take maximum advantage of currently available memory on your 
  274.      system.
  275.  
  276.      Messages inform you when the programs are crunching, 
  277.      uncrunching, unsqueezing or copying and why (e.g., "Already 
  278.      crunched" or "Zero length").  Includes the old in, out, and 
  279.      compression ratio reports as well as a final figure on the 
  280.      total number of files processed.
  281.  
  282.      Current program constraints limit wildcard operations to a 
  283.      maximum of 255 files.  Hitting ^C will entirely abort either 
  284.      program immediately.  Although probably of limited 
  285.      usefulness, ^S will pause the programs (in verbose mode).  
  286.      ^W will then resume.
  287.  
  288. Version 2.3D3 -- August 25, 1989 -- Howard Goldstein
  289.      This version fixes a bug which resulted in failure to 
  290.      recognize a datespec if a destination du was entered.  
  291.      Changes in the COMMON routines fix problems concerning the 
  292.      correct drive for the !!!TIME&.DAT file when running under a 
  293.      non-ZCPR3 system.
  294.  
  295. Version 2.3D2 -- November 7, 1988 -- Carson Wilson
  296.      Previous versions set the UNCRUNCHed file's Last Access 
  297.      stamp to the Last Access stamp of the original file.  This 
  298.      version sets the Last Access stamp of UNCRUNCHed files to 
  299.      the current time and date if a DateStamper compatible clock 
  300.      is available via BDOS function 12 (Return Version).  All 
  301.      changes are to this file and are marked "2.3D2" for 
  302.      reference.
  303.  
  304. Version 2.3D1.1 -- August 2, 1988 -- Carson Wilson
  305.      Changes in COMMON.LIB:  Replaced 8080 opcodes with Z80 
  306.      opcodes for Z80ASM.  Added code to close !!!TIME&.DAT file 
  307.      at label RETCCP:.  This was the only way to ensure that the 
  308.      file is always closed and set to R/O.  T&D file is only 
  309.      closed if we were writing to it.  Modified CLOSTD and OPENTD 
  310.      to preserve the T&D file's original archive bit.
  311.  
  312. Version 2.3D1 -- July 20, 1988 -- Carson Wilson
  313.      UNCRUNCH version 2.3D did not set the !!!TIME&.DAT file to 
  314.      read/only on exit.  UNCRUNCH v. 2.3D1 corrects this error.  
  315.      The version name was decided upon to avoid confusion with 
  316.      UNCRUNCH version 2.4, which adds several features not 
  317.      available in 2.3, but does not support DateStamped files.  
  318.      UNCR23D1 is released with the approval of Bridger Mitchell, 
  319.      author of UNCR23D.  CRUNCH23D remains unchanged.
  320.  
  321. Version 2.3D -- March 14, 1987 -- Bridger Mitchell, Plu*Perfect Systems
  322.      CRUNCH and UNCRUNCH support DateStamped files.  CRUNCH 
  323.      includes the original file's datestamp data in the header of 
  324.      the crunched output file.  UNCRUNCH v2.3D uses these data to 
  325.      replace the datestamp of the uncrunched file after it has 
  326.      been closed.  This means that the uncrunched file will have 
  327.      its original time and date.  CRUNCH also supports an 
  328.      additional optional field -- a datespec -- which may be used 
  329.      to specify a temporal class of files to crunch, for example, 
  330.      all files more recent than a specified date and time.
  331.  
  332.      CRUNCH now monitors the output for the first two bytes of 
  333.      the sequence: 00dh, 040h, 00dh (with hi bits possibly set).  
  334.      If detected, it inserts the CRUNCH NULCODE.  This prevents a 
  335.      crunched file from triggering Telenet/PC-Pursuit's command- 
  336.      mode, which can abort a file transfer.  Code is derived from 
  337.      C. B. Falconer's CRN v2.5., 86/12/19.
  338.  
  339. Version 2.3 -- November 15, 1986 -- Steven Greenberg
  340.      The core of this source code is pretty much unchanged since 
  341.      the original conception and refinement of CRUNCH v2.0.  
  342.      Though attention was made in selecting an algorithm which 
  343.      could be implemented in a relatively efficient manner, and 
  344.      some care was taken to keep the 'innermost' loops fairly 
  345.      streamlined, there is no doubt room for improvement in terms 
  346.      of the optimally efficient implementation.  This simply 
  347.      means that future releases may run even faster than the 
  348.      current one.
  349.  
  350.      The programs now can be configured for ZCPR use.  To support 
  351.      the Z3 environment descriptor, the patch byte locations have 
  352.      been shifted up.  If you are going to be patching these 
  353.      bytes yourself, refer to the new PATCH23.DOC, included.  
  354.      (Note: while the location of these bytes has changed, their 
  355.      function has not).  If you are going to use the install 
  356.      program CRINSTAL.COM, just make sure to use v2.3 of that 
  357.      program, included.  If you make a mistake and use the wrong 
  358.      install with the wrong program, you will simply get a 
  359.      "Invalid or Incompatible CRUNCH.COM" or some similar 
  360.      message.  Usage of v2.3 is identical to that of v2.1.
  361.  
  362.      Acknowledgements:  ZCPR3 Consultant: Bruce Morgen.  Also 
  363.      thanks to (continued from last release): Keith Peterson, Jon 
  364.      Schneider, Jay Sage, Gary Inman, Steve Russel, Terry 
  365.      Carroll, George Peace, Pete Zuroff, and many others.
  366.  
  367. Version 2.2 -- November 3, 1986 -- Steven Greenberg
  368.      This library contains version 2.1 of the CRUNCH and UNCRunch 
  369.      data compression utilities.  CRUNCH21.LBR, as originally 
  370.      released, contained an installation program CRINSTAL.COM.  
  371.      This was created as a last minute after-thought, because the 
  372.      number of available "patch bytes" was getting out of hand 
  373.      (also past experience has shown that people tend to ignore 
  374.      patch bytes, which is understandable).  Unfortunately, the 
  375.      last minute nature of the program (and its apparent 
  376.      simplicity) allowed it to slip by normal multi-system, pre- 
  377.      release testing channels.  While the install program worked 
  378.      fine under CP/M 3, it worked only on CP/M 3.  I don't know 
  379.      why DRI chose to change the operation of low# system calls 
  380.      (namely "6"), but the bottom line is that the program would 
  381.      not accept any input as a "Yes" response, including the 
  382.      answer to the question "Do you want to continue?" (This made 
  383.      the program quite difficult to run).
  384.  
  385.      Though it has been less than 24 hours since the release of 
  386.      CRUNCH21.LBR, their is no recalling in this "business" (I 
  387.      use the term loosely).  CRUNCH22.LBR contains a modified 
  388.      CRINSTAL v2.2 (which uses good old fashioned BDOS #1 calls).
  389.  
  390. Version 2.1 -- November 2, 1986 -- Steven Greenberg
  391.      Main change from version 2.0:  Provides full "DU:" support 
  392.      for source and destination files.  Drive, User, neither, or 
  393.      both in either order will be accepted for either the source 
  394.      or destination.  Particularly useful for backup (e.g., 
  395.      "CRUNCH <file> B0:") when working with a hard drive.  The 
  396.      display format has been correspondingly updated to always 
  397.      show source and destination drive and user codes, whether 
  398.      they are specified or not.
  399.  
  400.      You can now type CRUNCH *.* or UNCR *.* in mixed groups of 
  401.      files and get the desired results.  CRUNCH *.* will 
  402.      automatically not attempt to crunch files which are already 
  403.      crunched (or squeezed!).  This decision is made after 
  404.      opening the input file and analyzing the first few bytes, 
  405.      not by using the middle letter of the filename extension (so 
  406.      .AZM files, etc.  will still be crunched).  This complements 
  407.      the UNCR v2.0 feature of only uncrunching crunched files 
  408.      when *.* is specified, though that is achieved more 
  409.      expediently by filename extension analysis.
  410.  
  411.      Error recovery:  Put half a crunched file in, get half an 
  412.      uncrunched file out!  While this is not a recommended mode 
  413.      of operation, it is illustrative of a somewhat more 
  414.      intelligent handling of various error conditions.  If errors 
  415.      are detected within a crunched file, the maximum amount of 
  416.      information accumulated will be written and the file closed. 
  417.      Furthermore, almost all errors pertaining to a single file 
  418.      will not result in an abort of the entire wildcard operation 
  419.      -- the program will continue with the rest of the files.  
  420.      Major errors, (e.g., destination disk full), will of course 
  421.      abort the whole operation.
  422.  
  423.      Minor changes were made to provide more useful error 
  424.      messages (e.g., "Disk Full" for disk full, and "Output 
  425.      error" for other, less common output related errors.  The 
  426.      usage message has been significantly expanded:  type CRUNCH 
  427.      or UNCR with no filename specified to see it.
  428.  
  429.      Corrected a one count error on input records displayed when 
  430.      uncrunching a version 1 crunched file with the version 2 
  431.      program.  Big file fans:  an extra decimal place provided on 
  432.      the final input K ---> output K to correctly display file 
  433.      sizes even if they exceed 1 megabyte.  Note that all four 
  434.      "running displays" are in 4 digit fixed format fields, and 
  435.      will loop back to zero after 9999.  This is not too uncommon 
  436.      on the "cr" column, and would happen on the input or output 
  437.      recs columns if a file size exceeded 1.25 megabyte.  This is 
  438.      nothing to be concerned with.  Certain other very technical 
  439.      internal corrections have been made -- it is recommended 
  440.      that you replace your version 2.0 programs with these 2.1 
  441.      versions to maintain utmost reliability under all possible 
  442.      circumstances.
  443.  
  444.      The "running displays" update slightly less often now when 
  445.      crunching, as it was determined that a non negligible amount 
  446.      of time was being wasted updating the screen.  It may appear 
  447.      CRUNCH is running slower, but rest assured it's actually 
  448.      running faster.
  449.  
  450.      More user configurable options, plus an install program!  A 
  451.      provision to eliminate the 'Result not smaller than 
  452.      original.  Save it anyway?' question has been provided.  
  453.      When this situation occurs, it is often on very small files 
  454.      -- some people prefer unattended wildcard operation which 
  455.      will not stop to prompt for user input, even if at the 
  456.      expense of a few extra resulting records.  This, along with 
  457.      three other options provided as "patches" in v2.0 ( 
  458.      "Quiet/Verbose", "Prompt before overwrite", and "Defeat 
  459.      multi-sector I/O" [see accompanying TURBODOS.WRN for a full 
  460.      description of that one]) can now be quickly changed (in 
  461.      CRUNCH and UNCR simultaneously) by running CRINSTAL and 
  462.      answering a few self-explanatory questions.  See 
  463.      CRINSTAL.DOC for simple instructions on how to fire up this 
  464.      installation program.  (Note to more technical users: the 
  465.      one byte patches can still be made using a debugger.  A few 
  466.      additional patches, which the install program does not 
  467.      support, can be made as well; these are probably only of 
  468.      interest to more technical users anyway).
  469.  
  470.      Acknowledgements:  The flexible drive/user command line was 
  471.      made possible thru use of Jim Lopushinsky's "PARSEFCB.REL" 
  472.      module.  Many thanks to Paul Foote & Richie Holmes who have 
  473.      been supporters of CRUNCH since its inception; to Bob Freed 
  474.      for technical asides; and to John Stensvaag for CRUNCH.BG2.
  475.  
  476. Version 2.0 -- September 2, 1986 -- Steven Greenberg
  477.      CRUNCH v2.0 embodies all of the concepts employed in the 
  478.      UNIX COMPRESS-ARC512 algorithm, but is additionally enhanced 
  479.      by a "metastatic code reassignment" facility.  The code 
  480.      reassignment is augmented with a refined incremental 
  481.      compression ratio analysis for adaptive reset.  This 
  482.      provides additional improvement, especially on files with 
  483.      certain structural variations.  (It is ironic to note that 
  484.      if the file ARC512.EXE is CRUNCHed, the resulting file is 
  485.      nearly 14% smaller than the file produced when that program 
  486.      is used to compress itself).  Although short files will 
  487.      generally produce the same results as the above mentioned 
  488.      utilities, CRUNCH saves a few extra bytes by eliminating 
  489.      zero fill between code length changes.  Other improvements 
  490.      include:
  491.  
  492.      Use of multi-sector I/O when running in a CP/M 3.0+ 
  493.      environment (automatically selected when appropriate).  May 
  494.      be permanently deactivated if desired.
  495.  
  496.      Relaxed restrictions on filenames (e.g., files with a "Z" as 
  497.      the middle extension character, such as .AZM files, are not 
  498.      a problem).
  499.  
  500.      Improved wildcard operation -- non-critical errors will 
  501.      abort only the current file, not the entire operation.
  502.  
  503.      "Verbose" and "Quiet" modes of operation.  The former gives 
  504.      full running progress reports while compressing, including 
  505.      number of input and output records, compression ratio, 
  506.      "codes assigned" and "codes reassigned".  Although some of 
  507.      this information has limited usefulness, it is amusing to 
  508.      watch.  "Quiet" may be preferred when using slow (or 
  509.      printing) terminals, and will allow the results of up to 24 
  510.      wildcard operations to remain on the console.
  511.  
  512.      Optional prompt before erasure of pre-existing files.  A 
  513.      warning will be issued if an existing file is about to be 
  514.      over-written.  This feature can be deactivated if desired.
  515.  
  516.      Full compatibility with all crunched files.  UNCR 2.0 will 
  517.      uncrunch all "crunched" files, regardless of which version 
  518.      of CRUNCH was used to create them.  CRUNCH v2.0 will always 
  519.      use the improved algorithm to create new files.
  520.  
  521.      "Confirm" mode of operation.  Used in conjunction with a 
  522.      wildcard filespec, this option allows selectively crunching 
  523.      or uncrunching a subset of all files matching the spec.  The 
  524.      user will be prompted (Y/N) for each file matching file; a 
  525.      response of "N" will simply move on to the next file.
  526.  
  527.      Continuous checking for ^C abort.
  528.  
  529.      Inclusion of a "NOP" code.  In addition to the normal 
  530.      special EOF and RESET codes, the new structure sets aside 
  531.      two additional codes as reserved (one "NOP", one "SPARE").  
  532.      The "NOP" code can be inserted into the data stream at any 
  533.      point and will always be ignored by the uncruncher.  One 
  534.      possible use of this would be a "Telenet Trap" -- where the 
  535.      CRUNCH program would monitor its output and insert a NOP 
  536.      code if it saw that the output would otherwise produce an 
  537.      undesired sequence (ref: R. Freed's PCP-WARN.MQG and PCP- 
  538.      FIX.MQG), thus producing files guaranteed to be 
  539.      transmittable while using PC-PURSUIT.  Although the current 
  540.      CRUNCH program does not yet monitor for this, the structure 
  541.      is already set up so this (or any other sequence) could be 
  542.      inhibited at any time, yet all files would remain 
  543.      upward/downward compatible.  Other data compression schemes 
  544.      do not have this flexibility.
  545.  
  546. Version 1.2 -- June 16, 1986 -- Steven Greenberg
  547.      Existing v1.0 and v1.1 versions of these utilities should be 
  548.      replaced with v1.2.  A few minor bugs have been corrected, 
  549.      including one which could cause a possible file error when 
  550.      crunching numeric data files or object code.  In addition, 
  551.      these versions are up to 20% faster, take source as well as 
  552.      destination drive specs, and are still under 2k each.
  553.  
  554.      The source has been provided for the first time, due to 
  555.      quite a number of requests (please read the copyright 
  556.      message).  All source code is crunched, by the way.  The 
  557.      programs are standalone assemblies, but two "include" files 
  558.      are used due to the large overlap between programs.  CRUNCH 
  559.      or UNCRunch can be assembled with M-80 by just making sure 
  560.      "INCLUDE1.INC" and "INCLUDE2.INC" are on the same drive/user 
  561.      area.
  562.  
  563. Version 1.1 -- no information.
  564.  
  565. Version 1.0 -- no information.
  566.  
  567. Original author:
  568.  
  569.      Steven Greenberg
  570.      203 S. Van Dien Ave
  571.      Ridgewood, NJ  07450
  572.      Voice: (201) 447-6543
  573.