home *** CD-ROM | disk | FTP | other *** search
/ ftp.barnyard.co.uk / 2015.02.ftp.barnyard.co.uk.tar / ftp.barnyard.co.uk / cpm / walnut-creek-CDROM / ENTERPRS / CPM / UTILS / A / CRLZH11.LBR / NOTES11.DYC / NOTES11.DYC
Text File  |  2000-06-30  |  12KB  |  210 lines
  1. CRLZH and UNCRLZH v1.1 are virtually identical to their 1.0 versions (the 
  2. Beta test versions) with the following exceptions:
  3.  
  4. 1) The version number placed in the LZH-Encoded file (part of the header) 
  5.    is now 11h instead of 10h (for 1.1 vs 1.0).  Other than that minor 
  6.    detail, the files produced by this official release and the Beta test 
  7.    will be identical.  (Files produced with the Beta version are acceptable 
  8.    to UNCRLZH v1.1).
  9.  
  10. 2) The CRLZH program is marginally faster.  Some small speed enhancements 
  11.    were made, but the algorithm is intrinsically slow.
  12.  
  13. 3) The UNCRLZH program has been changed to default to the file extension 
  14.    .?Y? when the extension .* is used (see CRUNCH 2.4 notes, below, under 
  15.    the heading: 4. DETAIL INVOLVING FORCED "?Z?" EXTENSION [UNCR only].) 
  16.    This means that to UNCRUNCH all ?Z? files, you must use .?Z? rather than 
  17.    .* (.* will only find .?Y? files).  HOWEVER, the character used has 
  18.    been made a configurable item (see patch information), so you can tailor 
  19.    it for your preference.
  20.  
  21. 4) The display format differs slightly (a few extra CR-LF sequences).
  22.  
  23. -----------------------CRLZH/UNCRLZH v1.0 notes follow---------------------
  24.  
  25. CRLZH and UNCRLZH v1.0 (Beta test versions) are based upon S. Greenberg's 
  26. CRUNCH and UNCRunch programs (v2.4).  The intent was to provide a user 
  27. interface identical to existing programs (similar function - similar 
  28. interface).  CRLZH and UNCRLZH differ from Steve's programs in the 
  29. following areas:
  30.  
  31. 1) CRLZH makes files with a 'Y' in the extension (as opposed to 'Z').  The 
  32.    UNCRLZH program recognizes this as the extension for LZH encoded 
  33.    files.
  34.  
  35. 2) CRLZH progressively changes the file extension of the crunched file, 
  36.    allowing for a bit more user insight into the original file name.  It  
  37.    operates upon file extensions as follows:
  38.  
  39.       BLANKS - converted to .YYY
  40.       .123   - converted to .1Y3
  41.       .?Y?   - converted to .?YY
  42.       .?YY   - converted to .YYY
  43.  
  44. There was no reason to tamper with the format CRUNCH uses on the output 
  45. file.  Therefore, with the exception of taking the 'next' file type in 
  46. sequence (SQueezed files begin with a 76h,FFh sequence; Crunched files with 
  47. 76h,FEh; so LZH encoded files begin with 076h,FDh) and setting the revision 
  48. levels in the header to 1.0, there's no difference in the output file 
  49. format.  You can probably coax your time/date stamping into operating 
  50. on LZH encoded files.
  51.  
  52. UNCRLZH preserves the capability to operate on CRUNCHED and SQueezed files, 
  53. so you can use it on your system as a replacement for UNCR.  There were no 
  54. changes to these features (Uncruncing and Unsqueezing was supplied in .REL 
  55. file form) so fear not!  The driving program was altered ONLY to recognize 
  56. the additional file type and branch to the new decompression code (version 
  57. number and sign-on message text was altered, too...but that's trivial.)
  58.  
  59. Since these programs are BASICALLY CRUNCH v2.4 and  UNCRunch  v2.4 the user 
  60. interfaces are the same.  The the version 2.3 internal revision information 
  61. in the CRUNCH program has been preserved so that the program can be 
  62. configured by the same programs (if any exist).
  63.  
  64. ----------------------CRUNCH/UNCRunch v2.4 notes follow--------------------
  65.  
  66. CRUNCH  v2.4 processes and generates files identical to v2.3. A  series  of
  67. enhancements  have been made, and are summarized below (additional  details
  68. can be found at the end of this document).
  69.  
  70. o  "TAG"  MODE: This new option lets you select any number of files from  a
  71.    group for processing. After all the selections have been made, the files
  72.    will be processed. Selections are presented and processed in  alphabeti-
  73.    cal order. Applies to both CRUNCH and UNCR. (Even when this mode is  not
  74.    active, all wildcard operations are sorted to proceed alphabetically).
  75.  
  76. o  STRAIGHT  COPYING: If CRUNCH ever creates a file larger than  the  orig-
  77.    inal,  the file will automatically be erased and replaced with a  direct
  78.    copy  of the original. If the original is already crunched or  squeezed,
  79.    or if the filetype matches a type on a [user configurable] filetype list
  80.    (eg  .LBR  or  .ARC), no attempt will even be made  to  compress  it;  a
  81.    straight  copy operation will be substituted. Thus ALL  specified  files
  82.    will transferred (in the most efficient manner), facilitating the use of
  83.    CRUNCH for the creation of LBR's or as a backup utility. Similarly, UNCR
  84.    will either uncrunch or direct copy all specified files for full restor-
  85.    ation.
  86.  
  87. o  "SPANNING"  DISKETTES: If CRUNCH ever fills an output diskette during  a
  88.    wildcard operation, the last [partial] file will be deleted and the user
  89.    will  be  prompted to change diskettes. Operation  will  then  continue,
  90.    starting  with that last file. This will work from the output of  either
  91.    CRUNCH or UNCRunch.
  92.  
  93. o  OPTION  "TOGGLES":  UNCRunch and CRUNCH take as many as three  and  four
  94.    (respectively)  command  line options in any  combination.  Each  option
  95.    corresponds  to  a mode which can be set to default to  a  user  defined
  96.    state; then the command line toggle will flip the state back on or  off.
  97.    The  option  toggles  include "quiet" / "verbose",  "tag  mode"  on/off,
  98.    "prompt before overwrite" on/off, and "archive bit" mode on/off.
  99.  
  100. o  OTHER  NEW MODES:   The "archive bit" mode toggle, when turned on,  will
  101.    only  crunch  files  that have changed since they were  last  backed  up
  102.    (based  on the CP/M directory archive bit). When running in  this  mode,
  103.    each input file will be flagged as archived as soon as the crunch  oper-
  104.    ation  for that file has completed. The "prompt before  overwrite"  mode
  105.    toggle allows command line control of whether the program stops to  warn
  106.    you each time it is about to overwrite a file with the same name.
  107.  
  108. o  UNSQUEEZING: UNCRunch now also unsqueezes as an added convenience! Usage
  109.    is  identical; UNCRunch will automatically recognize the  file's  format
  110.    and use the appropriate algorithm.
  111.  
  112. o  FASTER  OPERATION; MORE BUFFERING: Modest speed improvements  have  been
  113.    made  through a variety of techniques, including more data buffering  to
  114.    reduce disk activity. The extended buffers are dynamically allocated  to
  115.    take maximum advantage of currently available memory on your system.
  116.  
  117. o  INFORMATIVE:  Messages inform you when the programs are  crunching,  un-
  118.    crunching,  unsqueezing,  or copying and why (eg "Already  crunched"  or
  119.    "Zero length"). Includes the old in, out, & compression ratio reports as
  120.    well as a final figure on the total number of files processed.
  121.  
  122.                      DETAILED NOTES ABOUT NEW FEATURES
  123.  
  124. Some  of the new features mentioned above require, by logical necessity  or
  125. convenience,  that the programs respond differently to different  types  of
  126. command  line specifications; ie respond differently depending  on  whether
  127. the source and destination user areas and/or drives are different or wheth-
  128. er the program is invoked with a wildcard file specification. Following  is
  129. an itemization of these details:
  130.  
  131. 1. DIRECT COPY OVERRIDE [CRUNCH only]: If the source and destination drives
  132. AND  user areas are the same, then direct copying is inhibited  (ie  CRUNCH
  133. will  not  bother attempting to copy a file onto itself); in this  case  it
  134. will resort to the older method of asking the user whether he wants to keep
  135. the larger "crunched" file.
  136.  
  137. 2.  "SPANNING"  DISKETTE OVERRIDE [CRUNCH or UNCRunch]: If the  source  and
  138. destination  DRIVES are the same, then the prompt to change diskettes  when
  139. the  diskette fills up is inhibited, since by changing the output  diskette
  140. you  will  also be removing the input diskette from which  the  program  is
  141. reading.
  142.  
  143. 3.  EXCLUSION LIST OVERRIDE [CRUNCH only]: While it is generally useful  to
  144. have  CRUNCH  skip attempts to compress certain filetypes when  doing  bulk
  145. transfers,  there may be instances where, for example, you WANT to  create,
  146. say a ".LZR" (crunched library) file. Therefore  for CRUNCH will ignore the
  147. filetype  exclusion  list if a filename is fully specified.  The  exclusion
  148. list WILL be used whenever one or more wildcard characters ("?" or "*") are
  149. used in the command line.
  150.  
  151. 4.  DETAIL INVOLVING FORCED "?Z?" EXTENSION [UNCR only]: UNCRunch  used  to
  152. convert  the wildcard spec "*.*" to "*.?Z?" as a convenience feature.  This
  153. conflicts  with the symmetrical operation of the new programs, ie that  you
  154. can  transfer  all files from a disk or user area with,  for  example,  the
  155. command "CRUNCH  A:*.*  B:" & then restore them all with "UNCR  B:*.*  A:".
  156. Thus  the forced "Z" feature has been removed, and if such is  your  intent
  157. you will have to type "UNCR  B:*.?Z?  A:".  But in an effort retain maximum
  158. convenience  and compatibility with v2.3 where possible, the plain  command
  159. line "UNCR *.*", ie when uncrunching to the same drive and user area,  WILL
  160. automatically  be  converted to "UNCR *.?Z?" since direct  copying  is  not
  161. desired  or  possible in this case anyway. Also note an effect of  this  is
  162. that  a separate "UNCR *.?Q?" command would be required if  squeezed  files
  163. were  mixed  in the group, but if going to a different  drive/user  area  a
  164. single "*.*" specification would do everything.
  165.  
  166.                                MORE DETAILS
  167.  
  168. 1. MIXING /A and /C OPTIONS [CRUNCH only]: The /A, archive bit mode option,
  169. works  internally by "tagging" all files which do not have the archive  at-
  170. tribute  bit set, and thus crunching only those files. This is useful,  be-
  171. cause  if both options are specified, you will be presented with a list  of
  172. ALL  filenames, just as if you had specified the /C option alone,  but  you
  173. will  notice that all non-archived files have been pre-tagged for you.  You
  174. are then free to either tag additional files or untag "pre-tagged" files as
  175. you  wish.  You may wish, for example, to untag various .BAK  files  which,
  176. though not archived, you consider superfluous to backup.
  177.  
  178. 2. UNDOCUMENTED /T OPTION [CRUNCH and UNCRunch]: Though markedly  improved,
  179. the  new  tag  mode achieves the same desired effect as  the  old  v2.3  /C
  180. (Confirm) option, namely selective processing of files from a group. It  is
  181. therefore  still the "/C" option. But I personally always think of  it  and
  182. refer to it as "tag" mode, so I have allowed the programs to accept /T as a
  183. synonym for /C.  (Not really "undocumented", of course...)
  184.  
  185. 3. 255  MAXIMUM FILES [CRUNCH and UNCRunch]: Current  program  constraints
  186. limit  wildcard  operations to a maximum of 255 files. If a  wildcard  spec
  187. matches  more  than that many files, an appropriate error message  will  be
  188. given. In this case you will have to split your job into several operations
  189. by using using more selective wildcard specs.
  190.  
  191. 4.  CRUNCHED FILE OUTPUT [CRUNCH only]: v2.4 produces identical output  re-
  192. gardless  of  mode of operation (a few very observant people  noticed  that
  193. v2.3  could  output  valid, but different, files when  running  in  "quiet"
  194. mode).  The output of v2.4 should be identical to v2.3 running  in  verbose
  195. mode, except for the embedded revision level byte.
  196.  
  197. 5. "FILES PROCESSED" COUNT [CRUNCH and UNCRunch]: The v2.4 programs  output
  198. "<nn>  File(s)  Processed" each time they are run. The count  is  basically
  199. equal  to  the final number of output files  created.  A  crunch/erase/copy
  200. sequence  counts as one; A "no" answer to a "Overwrite existing  file?"  or
  201. "Save file anyway?" question counts as zero.
  202.  
  203. 6. ^C ABORTS, ^S PAUSES, ^W RESUMES [CRUNCH and UNCRunch]: Hitting ^C  will
  204. entirely  abort either program immediately. It may be issued any  time  the
  205. programs are waiting for input, or during actual operation. Use of ^C  dur-
  206. ing  operation will generally result in zero length output file.   Although
  207. probably  of  limited usefulness, it is noteworthy that ^S will  pause  the
  208. programs  (in verbose mode) since it will be intercepted by the system  and
  209. prevent the running console output from continuing. ^W will then resume.
  210.