home *** CD-ROM | disk | FTP | other *** search
/ Club Amiga de Montreal - CAM / CAM_CD_1.iso / files / 401.lha / LZ_v0.81 / LZ.doc < prev    next >
Text File  |  1990-07-27  |  12KB  |  255 lines
  1.  
  2.                                    LZ 0.81 BETA
  3.                                   29th June, 1990
  4.  
  5.                             Written by Jonathan Forbes
  6.                        Copyright © 1990, Xenomiga Technology
  7.  
  8.  
  9.    About LZ
  10.  
  11.    LZ is NOT freeware; if you use it and like it, please send a shareware
  12. registration of $10 (Cdn.$ or U.S.$) to the address given below.  If you send
  13. $25 and your address, you will receive the full source code to LZ on a disk.
  14. Send contributions to:
  15.  
  16.    Xenomiga Technology
  17.    1132 Bay Street, Suite #1101
  18.    Toronto, Ontario
  19.    M5S 2Z4
  20.    Canada
  21.  
  22.  
  23.    Distribution
  24.  
  25.    LZ is a freely distributable, copyrighted piece of software.  You may
  26. upload it wherever you choose, but you are not allowed to sell LZ for profit,
  27. or include LZ on a disk which is sold for profit, without the author's
  28. (Jonathan Forbes) permission.
  29.  
  30.    The LZ package (LZ081.LZH) consists of two files; LZ, and LZ.doc, neither
  31. of which may be modified in any way.  However, LZ081.LZH may be recompressed
  32. with another archiver such as Zoo, Zip (ugh), etc.
  33.  
  34.    And, as mentioned above, LZ is shareware.
  35.  
  36.  
  37.    Disclaimer
  38.  
  39.    I am in no way responsible for anything this program does; you are using it
  40. entirely at your own risk!  This is especially true for this 0.81 beta version.
  41. If you don't want to take any risks, then *don't* use it!
  42.  
  43.  
  44.    What is Lz?
  45.  
  46.    Lz (which I pronounce "el zed", but which you will probably pronounce
  47. "el zee") is the fastest .LZH archiver and extractor available for the Amiga!
  48. Lz is compatible with MS-DOS version 1.13c of Lharc and Amiga Lharc 1.0.
  49.  
  50.  
  51.    Acknowledgements
  52.  
  53.    The original Lharc (MS-DOS) was written by Haruyasu Yoshizaki.  I took his
  54. freely distributable source code "lzhuf.c", and rewrote it in assembly
  55. language.  I used "lharc.c" (which is full of MS-DOS specific code) as a
  56. reference, but did not use it as a base for the Amiga version, which I wrote
  57. from scratch.
  58.  
  59.    For testing purposes, I used Amiga Lharc 1.0, ported by Paolo Zibetti.
  60.  
  61.  
  62.    How fast is Lz?
  63.  
  64.    Lightning fast.  If you've been using Lharc to compress or decompress files,
  65. then you're in for a big surprise.  If you've been using Lhunarc 0.96 (also
  66. written by me), and thought that was fast, then prepare yourself for some major
  67. speed increases, because Lz is faster still!  Lz is between 16% and 25% faster
  68. than Lhunarc 0.96, and that's no joke in terms of speed!
  69.  
  70.    I have pushed the decompression algorithm almost to its limits.  No other
  71. .LZH extractor can even come -close- to Lz's decompression times.  Things
  72. simply can't get much faster.  Yes, I know I said that in the Lhunarc 0.96
  73. documentation too, but this time I'm pretty sure I'm almost at the limit!
  74.  
  75.    Here follows a small speed comparison.  The files being compressed and
  76. decompressed were those on Fred Fish disk #245.
  77.  
  78.                       * - Different algorithm/encoding scheme
  79.  
  80.                                            *        *
  81.              | (0.81)  | (1.0) | (.99d) | (1.01) | (1.40)
  82.              |   LZ    | Lharc | LharcA | PkaZip | Lhwarp
  83. Fish245.LZH  |  11:33  | 26:29 |    ?   |  10:31 |  13:43  <-- compressing
  84.              |   1:47  |  5:12 |   2:34 |   2:53 |   2:51  <-- decompressing
  85.  
  86.    LZ certainly kills everything else dead, but is it faster than PkaZip?
  87. Well, sometimes it is, but usually it isn't.  However, LZ (and Lharc, etc.)
  88. almost always compresses files better than Zip.  For example, "MegRyan.lzh"
  89. (a complete 655k digitised sound sample of the famous restaurant scene from
  90. When Harry Met Sally), compresses from 655302 bytes to 488679 when LZ is used,
  91. while the equivalent .zip file is 536773 bytes long.  LZ compresses the file
  92. faster than Zip, too.
  93.  
  94.    Anyway, enough of .lzh vs. .zip for now... it's up to you.
  95.  
  96.  
  97.    A Beta Version?
  98.  
  99.    Yes, this version is LZ 0.81 BETA.  Just over 80% of it has been done (how
  100. I came up with that figure I'll never know.)
  101.  
  102.    LZ has not been tested to exhaustion.  It compresses and decompresses files
  103. fine (and is far more intelligent than Lhunarc 0.96), but there's always the
  104. possibility of a bug or two remaining (although I seriously doubt there are
  105. any -dangerous- bugs remaining; i.e. bugs which produce corrupted archives.)
  106.  
  107.    Anyway, the practical upshot of all this is that if you want to play it safe,
  108. then use LZ only for decompressing; the algorithm has been sitting in Lhunarc
  109. 0.96 for months now, without any problems, and any bugs will show up as CRC
  110. errors.  Most people don't compress that many files, anyway.
  111.  
  112.    (Note:  I'm not saying the compression algorithm is buggy; just that it
  113. isn't as mature as the decompression algorithm.)
  114.  
  115.    LZ does not yet have all of its options implemented; the commands not
  116. implemented are: move, freshen, update, and fix (the latter is a nonstandard
  117. Lharc command which will rebuild corrupted archives.)  I've never used any
  118. of these commands before, anyway, so hopefully, most of you won't miss them.
  119.  
  120.    A quick summary of the implemented commands:
  121.  
  122.    a    Add file(s) to archive.  Wildcards accepted.
  123.  
  124.    e,x  Extract file(s) from archive.  If any filenames follow the archive name
  125.         then only those files will be extracted.  Wildcards are permitted.  If
  126.         any of the filenames have a '/' or ':' as the ultimate character, then
  127.         that directory will be used as the destination directory.  E.g.:
  128.  
  129.         Lz -x fish245.lzh generalinfo.info dh3:fishdir/ atof/atof vlt/.info
  130.  
  131.         will extract generalinfo.info, atof/atof, and vlt/.info to dh3:fishdir/
  132.  
  133.    l,v  View archive contents.
  134.  
  135.    d    Delete file(s) from archive.  Wildcards accepted.  To delete all .foo
  136.         files from all your .lzh files, type:  Lz d #? #?.foo
  137.  
  138.         Please note that items in subdirectories are also checked, so that
  139.         #?.info will delete *all* .info files in the archiver, wherever they
  140.         may be.
  141.  
  142.    When creating archives, individual files are compressed in the work
  143. directory, which defaults to T: if it exists or the current directory
  144. otherwise.  The work directory can be changed with the -w option.
  145.  
  146.    Like Lharc, LZ uses the decimal address of its task structure for creating
  147. temporary filenames, so that multiple copies can run simultaneously without
  148. conflict (and no, LZ is not reentrant; I *like* global variables.)
  149.  
  150.    What do the options do?  Well, first of all, if you're not familiar with
  151. Lharc by Paolo Zibetti, read his Lharc documentation files; I've tried to
  152. remain as compatible as possible with Amiga Lharc 1.0.  I'll write the
  153. documentation for LZ later on; I'm too busy right now.
  154.  
  155.    It is important to remember the behaviour of the -a (preserve file
  156. attributes) command; if this is not specified, then all files archived or
  157. extracted will be "rwed."  If this flag is used, then all attributes (rwedsaph)
  158. will be preserved.  When extracting, use -a only on files which have been
  159. compressed by Amiga .lzh archivers; if you don't, you'll end up with files with
  160. strange attributes (although no harm will be done.)  Similarly, if you know
  161. that your archive might be extracted on an IBM system, don't use the -a option,
  162. because they'll have similar problems.
  163.  
  164.    Here follows a quick reminder of how to archive subdirectories recursively:
  165.  
  166.    Lz -x -r a myarchive.lzh blah/#?
  167.  
  168.    Will archive everything (subdirectories and all) in blah/.  If you don't
  169. wish to archive subdirectories, then it's just Lz -x a myarchive.lzh blah/#?
  170. (which will still preserve the path name.)
  171.  
  172.    Options which I have added are:
  173.  
  174.    -c   confirm filenames; will prompt you with yes/no/all/quit for every
  175.         file to be added to or extracted from an archive.  Useful in
  176.         conjunction with wildcards.
  177.  
  178.    -i   set input buffer size to the number immediately following the option.
  179.         For example, -i32768 would give you a 32k input buffer.  Changing the
  180.         input or output buffer size on an 68000 Amiga when all work is being
  181.         done in a RAM drive doesn't speed things up; these options are mainly
  182.         for floppy drive users and 68020-68040 users.
  183.  
  184.    -o   ditto for the output buffer.  Both input and output buffers default
  185.         to 8192 (8k) bytes.  However, twice as much memory as specified is
  186.         allocated for the output buffer; this is because LZ originally wrote
  187.         data asynchrously until I found out that this doesn't speed things up
  188.         on a RAM drive.  It probably speeds things up on a floppy drive,
  189.         however, so I left the dual buffers in.  This version of LZ does NOT
  190.         write asynchrously, however; the extra output buffer just takes up
  191.         memory, for now.
  192.  
  193.    -z   zero compression; just store files in the archive.
  194.  
  195.    -Z   conditional zero compression; don't attempt to compress files ending
  196.         in .lzh, .lhw, .zip, .zoo, .arc, .pak, .wrp or .zap.  Useful for
  197.         compressing disks which already have archives on them.
  198.  
  199.    LZ saves and restores files to their proper dates and attributes, unlike
  200. Lhunarc.
  201.  
  202.    If you find yourself using certain options with LZ most of the time, you
  203. might want to make them an alias.  For example:
  204.  
  205.    alias lx lz -i32768 -o32768 -x []
  206.  
  207.    would make a new command called "LX" which would extract files with a 32k
  208. buffer.  Or, if you still find yourself typing "Lhunarc" all the time:
  209.  
  210.    alias lhunarc lz -i32768 -o32768 -x []
  211.  
  212.    The above two commands work only with shells which support aliases.  Your
  213. shell might have a different way of doing it; I use AmigaDOS 1.3 and Arp 1.3.
  214. The arp.library is required for LZ, by the way.
  215.  
  216.    So why am I releasing an incomplete, not fully tested version?  The reason
  217. is that I'm leaving for Winnipeg, Manitoba in two days, and that's where I'll
  218. be for the next month, at the Shad Valley programme.  I'm releasing this
  219. program, in part, to update Lhunarc 0.96.  I also don't want any other .lzh
  220. archiver to appear while I'm gone and render Lhunarc obselete; LharcA lags
  221. far far behind both Lhunarc and Lz, but it might get within 15%.  Lhunarc also
  222. had a couple of bugs (both were inconsequential; it couldn't handle certain
  223. combinations of deeply nested directories, and it created directories in view
  224. mode) which LZ fixes.
  225.  
  226.    Besides, I want this program to get around so that people will have compiled
  227. lots of revealing benchmarks by the time I get back ;-)  No one seems to have
  228. done this yet!
  229.  
  230.    Anyway, remember that this is a PRE-RELEASE of LZ, and it may contain a
  231. small bug or two.  I'll be gone from the 1st of July until the 28th, so you'll
  232. have to save your suggestions and criticisms for then.
  233.  
  234.    Thanks to Steve Tibbett for showing me how to speed up Lhunarc 0.96 by 3%
  235. (every percent counts), how to produce smaller executables using RawDoFmt() and
  236. __tinymain, for finding the bug in the view command, for sending me Raw() and
  237. Cooked(), and for informing me that the A3000 spends more time doing disk i/o
  238. than it does decompressing (hence a user configurable buffer.)
  239.  
  240.    I'll have another version of Lhwarp out in two months or so, which may or
  241. may not use Yoshi's new Lharc algorithm which is currently undergoing beta
  242. testing at version 1.90; it produces smaller files than the existing Lharc,
  243. and is quicker to boot.
  244.  
  245.    As an aside; thanks to all those who helped get Lhwarp off the ground to
  246. stable versions 1.30/1.31 and 1.40; if it weren't for Lhwarp, neither Lhunarc
  247. nor LZ would exist.  A big *HI* to Rob Collinsworth; thanks for all your
  248. invaluable help when I most needed it!
  249.  
  250.    Please excuse this document's complete lack of style and organisation;
  251. because it was done at the last minute, I didn't have the time to refine every
  252. sentence like I usually do.
  253.  
  254. --- EOF
  255.