home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 9 Archive / 09-Archive.zip / COMPR412.ZIP / README < prev    next >
Text File  |  1992-07-18  |  8KB  |  178 lines
  1. Compress compresses files using a heavily modified version of the
  2. LZW algorithm as described in IEEE Computer, June 1984.
  3. See the comments in compress.c and the Usenet article at
  4. the end of this file for more details.
  5.  
  6. The "usermem" script attempts to determine the maximum process size.  Some
  7. editing of the script may be necessary (see the comments).  If you can't get
  8. it to work at all, just create file "USERMEM" containing the maximum process
  9. size in decimal.
  10.  
  11. The following preprocessor symbols control the compilation of "compress.c":
  12.  
  13.     o USERMEM        Maximum process memory on the system
  14.     o SACREDMEM        Amount to reserve for other proceses
  15.     o SIGNED_COMPARE_SLOW    Unsigned compare instructions are faster
  16.     o NO_UCHAR        Don't use "unsigned char" types
  17.     o BITS            Overrules default set by USERMEM-SACREDMEM
  18.     o vax            Generate inline assembler
  19.     o interdata        Defines SIGNED_COMPARE_SLOW
  20.     o M_XENIX        Makes arrays < 65536 bytes each
  21.     o pdp11            BITS=12, NO_UCHAR
  22.     o z8000            BITS=12
  23.     o pcxt            BITS=12
  24.     o SHORTNAMES        Disallow long filenames ( > 14 characters)
  25.     o BSD4            Call setlinebuf(stderr), lstat vs stat, etc.
  26.     o VOIDSIG        signal returns a void pointer
  27.     o DIRENT        use <dirent.h> instead of <sys/dir.h>
  28.  
  29. See the comments at the beginning of the Makefile.
  30.  
  31. The difference "usermem-sacredmem" determines the maximum BITS that can be
  32. specified with the "-b" flag.
  33.  
  34. memory: at least        BITS
  35. ------  -- -----                ----
  36.      433,484             16
  37.      229,600             15
  38.      127,536             14
  39.       73,464             13
  40.            0             12
  41.  
  42. The default is BITS=16.
  43.  
  44. The maximum bits can be overrulled by specifying "-DBITS=bits" at
  45. compilation time.
  46.  
  47. WARNING: files compressed on a large machine with more bits than allowed by 
  48. a version of compress on a smaller machine cannot be decompressed!  Use the
  49. "-b12" flag to generate a file on a large machine that can be uncompressed 
  50. on a 16-bit machine.
  51.  
  52. WARNING: compatibility with compress 3.0 has not been tested in
  53. the 4.1 release of compress.
  54.  
  55. The output of compress 4.0 is fully compatible with that of compress 3.0.
  56. In other words, the output of compress 4.0 may be fed into uncompress 3.0 or
  57. the output of compress 3.0 may be fed into uncompress 4.0.
  58.  
  59. The output of compress 4.0 is not compatible with that of
  60. compress 2.0.  However, compress 4.0 still accepts the output of
  61. compress 2.0.  To generate output that is compatible with compress
  62. 2.0, use the undocumented "-C" flag.
  63.  
  64. Check the Makefile, then "make".
  65.  
  66. Send comments, complaints and especially patches relating to
  67. compress4.1 to csu@alembic.acs.com.
  68.  
  69. Random comments: 
  70.  
  71. compress' handling of hard links has been criticized (it refuses to
  72. compress a multiply linked file.) In general, this is the correct
  73. thing to do. Hard links cannot cross file system boundaries, and if
  74. the objective of compressing files is to free disk space in a file
  75. system, compressing one link to a file won't help. Compress has no
  76. way of knowing where the other links are. If you REALLY want to
  77. compress a hard link, use the -f flag. Be aware that when it is
  78. uncompressed, the hardlink will not be recreated.
  79.  
  80. compress4.0's handling of symbolic links was (IMHO) incorrect.
  81. Uncompressing a collection of files should yield exactly what
  82. you had before you compressed them. This didn't happen with
  83. symlinks. Version 4.1 simply ignores attempts to compress
  84. symbolic links, along with anything else that isn't a regular
  85. file. If you're accustomed to using compress followed by tar
  86. to get everything that a directory references, both directly and
  87. indirectly, this may come as something of a disappointment.
  88.  
  89. The following article from James A. Woods, one of the earlier
  90. authors of compress, explains its relationship to the Unisys
  91. patent on the LZW compression method:
  92.  
  93. From uunet!zephyr.ens.tek.com!uw-beaver!mit-eddie!wuarchive!usc!ucsd!ucbvax!agate!riacs!jaw Wed Aug  1 15:06:59 EDT 1990
  94. Article: 1282 of gnu.misc.discuss
  95. Path: alembic!uunet!zephyr.ens.tek.com!uw-beaver!mit-eddie!wuarchive!usc!ucsd!ucbvax!agate!riacs!jaw
  96. From: jaw@riacs.edu (James A. Woods)
  97. Newsgroups: gnu.misc.discuss
  98. Subject: Sperry patent #4,558,302 does *not* affect 'compress'
  99. Keywords: data compression, algorithm, patent
  100. Message-ID: <1990Jul31.220935.1424@riacs.edu>
  101. Date: 31 Jul 90 22:09:35 GMT
  102. Organization: RIACS, NASA Ames Research Center
  103. Lines: 69
  104.  
  105. #  "The chief defect of Henry King
  106.     Was chewing little bits of string."
  107.  
  108.         -- Hilaire Belloc, Cautionary Tales [1907]
  109.  
  110.      As a co-author of 'compress' who has had contact with an attorney for
  111. Unisys (nee Sperry), I would like to relay a very basic admission from Unisys
  112. that noncommercial use of 'compress' is perfectly legal.  'Compress' is also
  113. commercially distributed by AT&T as part of Unix System 5 release 4,
  114. with no further restrictions placed upon the use of the binary, as far
  115. as I am aware.
  116.  
  117.      From conversations with Professor Abraham Lempel and others, it 
  118. appears that neither AT&T, Sun Microsystems, Hewlett Packard, nor IBM
  119. are paying any sort of license fees to Unisys in conjunction with patent
  120. #4,558,302.  It may be true that some organizations are paying fees for
  121. data compression technology licensed from one or more of the many holders
  122. of compression patents, but this is all independent from 'compress'.
  123.  
  124.      In particular, I received a letter at NASA dated October 1, 1987 from
  125. John B. Sowell of the Unisys law department, informing me for the first
  126. time that some form of LZW was patented.  I naturally expressed
  127. skepticism that an algorithm could be patented (a murky legal area
  128. which remains so), stated that 'compress' is not identical to LZW,
  129. and in fact was designed, developed, and distributed before the ink
  130. on the patent was dry.  Several telephone conversations later, Mr. Sowell
  131. intimated that they would *not* seek any fees from users of 'compress'
  132. but instead were signing licensees for hardware implementations of LZW.
  133.  
  134.      So, regardless of what you believe about a shady legal area, if anyone
  135. from Unisys contacts you to extract tribute for the use of 'compress', please
  136. tell them that, first, it is not theirs to begin with, and, second, there is
  137. someone who will testify in court about the conversation above.
  138. It is not even clear if anyone can "own" 'compress', since original developer
  139. Spencer Thomas, myself, and others placed the code in the public domain
  140. long before the adoption of the Berne copyright convention.
  141.  
  142.      In light of the events above, it seems that the Free Software
  143. Foundation is being unduly paranoid about the use of 'compress'.
  144. Now I can well believe that FSF is more likely to be a legal target
  145. than a behemoth like AT&T, but if they are simply redistributing
  146. untouched free software developed years ago in the public sector,
  147. I see no problem.
  148.  
  149.      Aside:  I am investigating, possibly for a case history to be
  150. recycled to USENET, the particulars of data compression patents.
  151. I am aware of the following patents: IBM's Miller-Wegman LZ variant,
  152. those of Telcor and ACT [losing candidates for the British Telecom modem
  153. standard], James A. Storer's work on limited lookahead as explicated in his
  154. text "Data Compression (methods and theory)", Computer Science Press, 1988,
  155. and the various patents pending associated with the Fiala and Greene
  156. CACM article of April, 1989 on textual substitution methods.
  157. If you have any lore, send it this way.
  158.  
  159.  
  160.  
  161.                     Sincerely,
  162.  
  163.                     James A. Woods
  164.                     NASA Ames Research Center (RIACS)
  165.                     jaw@riacs.edu (or ames!jaw)
  166.  
  167.  
  168. P.S.  The algorithm patent issue certainly is a "topic A" at the moment.
  169. One useful reference is the review article by Anthony and Colwell --
  170. "Litigating the Validity and Infringement of Software Patents" in
  171. Washington and Lee Law Review, volume 41, fall 1984.  I know Robert Colwell
  172. personally.  As a practicing patent attorney, he tells me that, at a minimum,
  173. use of an invention "for research purposes" is legitimate.
  174.  
  175.  
  176.  
  177.  
  178.