home *** CD-ROM | disk | FTP | other *** search
/ Simtel MSDOS 1996 June / Simtel-MSDOS-Jun1996-CD2.iso / disc2 / arcers / arc_file.inf < prev    next >
Text File  |  1988-03-01  |  8KB  |  163 lines
  1.      ARC-FILE.INF contains information extracted from UNARC.INF by
  2. Robert A. Freed (September, 1986) and from SQSHINFO.DOC by Phil Katz,
  3. (December, 1986).
  4.  
  5. Note: In the following discussion, UNARC refers to Robert A. Freed's
  6. CP/M-80 program for extracting files from MSDOS ARCs.  The definitions
  7. of the ARC file format are based on MSDOS ARC and PKARC/PKXARC
  8. programs.
  9.  
  10. ARCHIVE FILE FORMAT
  11. -------------------
  12.  
  13.      Component files are stored sequentially within an archive.  Each
  14. entry is preceded by a 29-byte header, which contains the directory
  15. information.  There is no wasted space between entries.  (This is in
  16. contrast to the centralized directory used by Novosielski libraries.
  17. Although random access to subfiles within an archive can be noticeably
  18. slower than with libraries, archives do have the advantage of not
  19. requiring pre-allocation of directory space.)
  20.  
  21.      Archive entries are normally maintained in sorted name order.  The
  22.  general format of the 29-byte archive header is as follows:
  23.  
  24.      archive mark, header version, file header, file data...
  25.  
  26. Byte 1:  1A Hex.
  27.  
  28.         This marks the start of an archive header.  If this byte is not
  29.         found when expected, UNARC will scan forward in the file (up to
  30.         64K bytes) in an attempt to find it (followed by a valid
  31.         compression version).  If a valid header is found in this
  32.         manner, a warning message is issued and archive file processing
  33.         continues.  Otherwise, the file is assumed to be an invalid
  34.         archive and processing is aborted.  (This is compatible with
  35.         MS-DOS ARC version 5.12).  Note that a special exception is made
  36.         at the beginning of an archive file, to accommodate
  37.         "self-unpacking" archives (see below).
  38.  
  39. Byte 2:  Compression version, as follows:
  40.  
  41.         0 = End of file marker (remaining bytes not present).
  42.         1 = Stored (obsolete).
  43.         2 = Stored - No compression.
  44.         3 = Packed - (non-repeat packing).
  45.         4 = Squeezed (Huffman squeezing, after packing)
  46.         5 = Crunched (Obsolete - 12-bit static LZW without non-repeat pack).
  47.         6 = Crunched (Obsolete - 12-bit static LZW with non-repeat packing).
  48.         7 = Crunched (Obsolete - after packing, using faster hash algorithm).
  49.         8 = Crunched (using dynamic LZW variations, after packing).
  50.                      (The initial LZW code size is 9-bits with a
  51.                      maximum code size of 12-bits.  The possibility of
  52.                      adaptive resets are implemented in this mode.)
  53.         9 = Squashed (The file was compressed with Dynamic LZW
  54.                      compression without non-repeat packing.  The
  55.                      initial LZW code size is 9-bits with a maximum
  56.                      maximum code size of 13-bits.  The possibility of
  57.                      adaptive resets are implemented in this mode.)
  58.  
  59. Bytes 3-15:   ASCII file name, nul-terminated.
  60.  
  61. (All of the following numeric values are stored low-byte first.)
  62.  
  63. Bytes 16-19:  File size of compressed file, in bytes.
  64.               (The number of bytes in the file data area following the
  65.               header.)
  66.  
  67. Bytes 20-21:  File date, in 16-bit MS-DOS format:
  68.               Bits 15:9 = year - 1980
  69.               Bits  8:5 = month of year
  70.               Bits  4:0 = day of month
  71.               (All zero means no date.)
  72.  
  73. Bytes 22-23:  File time, in 16-bit MS-DOS format:
  74.               Bits 15:11 = hour (24-hour clock)
  75.               Bits 10:5  = minute
  76.               Bits  4:0  = second/2 (not displayed by UNARC)
  77.  
  78. Bytes 24-25:  Cyclic redundancy check (CRC) value (see below).
  79.  
  80. Bytes 26-29:  Original (uncompressed) file length in bytes.
  81.               (This field is not present for version 1 entries, byte 2 = 1.
  82.               I.e., in this case the header is only 25 bytes long.  Because
  83.               version 1 files are uncompressed, the value normally found in
  84.               this field may be obtained from bytes 16-19.)
  85.  
  86. SELF-UNPACKING ARCHIVES
  87. -----------------------
  88.  
  89.      A "self-unpacking" archive is one which can be renamed to a .COM
  90. file and executed as a program.  An example of such a file is the MS-DOS
  91. program ARC512.COM, which is a standard archive file preceded by a
  92. three-byte jump instruction.  The first entry in this file is a simple
  93. "bootstrap" program in uncompressed form, which loads the subfile
  94. ARC.EXE (also uncompressed) into memory and passes control to it.  In
  95. anticipation of a similar scheme for future distribution of UNARC, the
  96. program permits up to three bytes to precede the first header in an
  97. archive file (with no error message).
  98.  
  99. CRC COMPUTATION
  100. ---------------
  101.  
  102.      Archive files use a 16-bit cyclic redundancy check (CRC) for error
  103. control.  The particular CRC polynomial used is x^16 + x^15 + x^2 + 1,
  104. which is commonly known as "CRC-16" and is used in many data
  105. transmission protocols (e.g. DEC DDCMP and IBM BSC), as well as by most
  106. floppy disk controllers.  Note that this differs from the CCITT
  107. polynomial (x^16 + x^12 + x^5 + 1), which is used by the XMODEM-CRC
  108. protocol and the public domain CHEK program (although these do not
  109. adhere strictly to the CCITT standard).  The MS-DOS ARC program does
  110. perform a mathematically sound and accurate CRC calculation.  (We
  111. mention this because it contrasts with some unfortunately popular public
  112. domain programs we have witnessed, which from time immemorial have based
  113. their calculation on an obscure magazine article which contained a
  114. typographical error!)
  115.  
  116.      Additional note (while we are on the subject of CRC's): The
  117. validity of using a 16-bit CRC for checking an entire file is somewhat
  118. questionable.  Many people quote the statistics related to these
  119. functions (e.g. "all two-bit errors, all single burst errors of 16 or
  120. fewer bits, 99.997% of all single 17-bit burst errors, etc."), without
  121. realizing that these claims are valid only if the total number of bits
  122. checked is less than 32767 (which is why they are used in small-packet
  123. data transmission protocols).  I.e., for file sizes in excess of about
  124. 4K bytes, a 16-bit CRC is not really as good as what is often claimed.
  125. This is not to say that it is bad, but there are more reliable methods
  126. available (e.g. the 32-bit AUTODIN-II polynomial).  (End of lecture!)
  127.  
  128. Notes:
  129.  
  130.      For type 1 stored files, the file header is only 23 bytes in size,
  131. with the length field not present.  In this case, the file length is the
  132. same as the size field since the file is stored without compression.
  133.  
  134.      The first byte of the data area following the header is used to
  135. indicate the maximum code size, however only a value of 12 (decimal) is
  136. currently used or accepted by existing ARC programs.
  137.  
  138.      The algorithm used "squashed" compression is identical to type 8
  139. crunched files with the exception that the maximum code size is 13 bits
  140. - i.e. an 8K entry LZW table.  However, unlike type 8 files, the first
  141. byte following the file header is actual data, no maximum code size is
  142. stored.
  143.  
  144. References
  145. ----------
  146.  
  147. Source code for ARC 5.0 by Tom Henderson of Software Enhancement
  148. Associates, usually found in a file called ARC50SRC.ARC.
  149.  
  150. Source code for general Ziv-Lempel-Welch routines by Kent Williams,
  151. found in a file LZX.ARC.  Kent Williams work is also referenced in the
  152. SEA documentation.
  153.  
  154. Source code and documentation from the Unix COMPRESS utilities, where
  155. most of the LZW algorithms used by SEA originated, found in a file
  156. called COMPRESS.ARC.
  157.  
  158. Ziv, J. and Lempel, A. Compression of individual sequences via
  159. variable-rate coding. IEEE Trans. Inform. Theory IT-24, 5 (Sept. 1978),
  160. 530-536.
  161.  
  162. The IBM DOS Technical Reference Manual, number 6024125.
  163.