home *** CD-ROM | disk | FTP | other *** search
/ Liren Large Software Subsidy 7 / 07.iso / c / c019 / 1.ddi / ARC521_C / ARCINFO < prev    next >
Encoding:
Text File  |  1988-08-01  |  5.4 KB  |  125 lines
  1.  
  2. ARC-FILE.INF, created by Keith Petersen, W8SDZ, 21-Sep-86, extracted
  3. from UNARC.INF by Robert A. Freed.
  4.  
  5. From:     Robert A. Freed
  6. Subject:  Technical Information for ARC files
  7. Date:     June 24, 1986
  8.  
  9. Note: In the following discussion, UNARC refers to my CP/M-80 program
  10. for extracting files from MSDOS ARCs.  The definitions of the ARC file
  11. format are based on MSDOS ARC512.EXE.
  12.  
  13. ARCHIVE FILE FORMAT
  14. -------------------
  15.  
  16. Component files are stored sequentially within an archive.  Each entry
  17. is preceded by a 29-byte header, which contains the directory
  18. information.  There is no wasted space between entries.  (This is in
  19. contrast to the centralized directory used by Novosielski libraries.
  20. Although random access to subfiles within an archive can be noticeably
  21. slower than with libraries, archives do have the advantage of not
  22. requiring pre-allocation of directory space.)
  23.  
  24. Archive entries are normally maintained in sorted name order.  The
  25. format of the 29-byte archive header is as follows:
  26.  
  27. Byte 1:  1A Hex.
  28.          This marks the start of an archive header.  If this byte is not found 
  29.          when expected, UNARC will scan forward in the file (up to 64K bytes) 
  30.          in an attempt to find it (followed by a valid compression version).  
  31.          If a valid header is found in this manner, a warning message is 
  32.          issued and archive file processing continues.  Otherwise, the file is 
  33.          assumed to be an invalid archive and processing is aborted.  (This is 
  34.          compatible with MS-DOS ARC version 5.12).  Note that a special 
  35.          exception is made at the beginning of an archive file, to accomodate 
  36.          "self-unpacking" archives (see below).
  37.  
  38. Byte 2:  Compression version, as follows:
  39.  
  40.          0 = end of file marker (remaining bytes not present)
  41.          1 = unpacked (obsolete)
  42.          2 = unpacked
  43.          3 = packed
  44.          4 = squeezed (after packing)
  45.          5 = crunched (obsolete)
  46.          6 = crunched (after packing) (obsolete)
  47.          7 = crunched (after packing, using faster hash algorithm) (obsolete)
  48.          8 = crunched (after packing, using dynamic LZW variations)
  49.  
  50. Bytes 3-15:  ASCII file name, nul-terminated.
  51.  
  52. (All of the following numeric values are stored low-byte first.)
  53.  
  54. Bytes 16-19:  Compressed file size in bytes.
  55.  
  56. Bytes 20-21:  File date, in 16-bit MS-DOS format:
  57.               Bits 15:9 = year - 1980
  58.               Bits  8:5 = month of year
  59.               Bits  4:0 = day of month
  60.               (All zero means no date.)
  61.  
  62. Bytes 22-23:  File time, in 16-bit MS-DOS format:
  63.               Bits 15:11 = hour (24-hour clock)
  64.               Bits 10:5  = minute
  65.               Bits  4:0  = second/2 (not displayed by UNARC)
  66.  
  67. Bytes 24-25:  Cyclic redundancy check (CRC) value (see below).
  68.  
  69. Bytes 26-29:  Original (uncompressed) file length in bytes.
  70.               (This field is not present for version 1 entries, byte 2 = 1.  
  71.               I.e., in this case the header is only 25 bytes long.  Because 
  72.               version 1 files are uncompressed, the value normally found in 
  73.               this field may be obtained from bytes 16-19.)
  74.  
  75.  
  76. SELF-UNPACKING ARCHIVES
  77. -----------------------
  78.  
  79. A "self-unpacking" archive is one which can be renamed to a .COM file
  80. and executed as a program.  An example of such a file is the MS-DOS
  81. program ARC512.COM, which is a standard archive file preceded by a
  82. three-byte jump instruction.  The first entry in this file is a simple
  83. "bootstrap" program in uncompressed form, which loads the subfile
  84. ARC.EXE (also uncompressed) into memory and passes control to it.  In
  85. anticipation of a similar scheme for future distribution of UNARC, the
  86. program permits up to three bytes to precede the first header in an
  87. archive file (with no error message).
  88.  
  89.  
  90. CRC COMPUTATION
  91. ---------------
  92.  
  93. Archive files use a 16-bit cyclic redundancy check (CRC) for error
  94. control.  The particular CRC polynomial used is x^16 + x^15 + x^2 + 1,
  95. which is commonly known as "CRC-16" and is used in many data
  96. transmission protocols (e.g. DEC DDCMP and IBM BSC), as well as by
  97. most floppy disk controllers.  Note that this differs from the CCITT
  98. polynomial (x^16 + x^12 + x^5 + 1), which is used by the XMODEM-CRC
  99. protocol and the public domain CHEK program (although these do not
  100. adhere strictly to the CCITT standard).  The MS-DOS ARC program does
  101. perform a mathematically sound and accurate CRC calculation.  (We
  102. mention this because it contrasts with some unfortunately popular
  103. public domain programs we have witnessed, which from time immemorial
  104. have based their calculation on an obscure magazine article which
  105. contained a typographical error!)
  106.  
  107. Additional note (while we are on the subject of CRC's): The validity
  108. of using a 16-bit CRC for checking an entire file is somewhat
  109. questionable.  Many people quote the statistics related to these
  110. functions (e.g. "all two-bit errors, all single burst errors of 16 or
  111. fewer bits, 99.997% of all single 17-bit burst errors, etc."), without
  112. realizing that these claims are valid only if the total number of bits
  113. checked is less than 32767 (which is why they are used in small-packet
  114. data transmission protocols).  I.e., for file sizes in excess of about
  115. 4K bytes, a 16-bit CRC is not really as good as what is often claimed.
  116. This is not to say that it is bad, but there are more reliable methods
  117. available (e.g. the 32-bit AUTODIN-II polynomial).  (End of lecture!)
  118.  
  119.                            Bob Freed
  120.                            62 Miller Road
  121.                            Newton Centre, MA  02159
  122.                            Telephone (617) 332-3533
  123.  
  124.  
  125.