home *** CD-ROM | disk | FTP | other *** search
/ ftp.whtech.com / ftp.whtech.com.tar / ftp.whtech.com / Geneve / 9640news / CAT10 / DRAMSEY.ARK < prev    next >
Text File  |  2006-10-19  |  9KB  |  190 lines
  1. ?
  2.  
  3.  
  4.  
  5.                       A Proposal for TI-DOS Archiving
  6.  
  7.  
  8.      In recent months, the TI community has begun to look at various means
  9. of storing programs and data in single files known as archives. This has
  10. created a number of problems, not the least of which is the fact that for
  11. each programmer who attempts to develop such an archiving method, there is
  12. likely to be several competing methods already released.
  13.  
  14.      I have prepared this short file to simply spur discussion over the
  15. questions that the subject of archiving raises. There are several ideas
  16. presented herein but none of them are cast in stone. Hopefully, they wil
  17. simply spur the inventive in the TI community to consider the questions
  18. and to develop solutions *now* instead of later when it will be much more
  19. difficult.
  20.  
  21.      The most well-known of the TI archive formats is the format developed
  22. by Barry Traver. It uses a simple 18 byte file header that simply
  23. summarizes the essential data for that file from the original TI-style
  24. file header. (The following information was extracted from the ARCDOC file
  25. prepared by Al Beard.) Its format is as follows:
  26.  
  27.  
  28.  
  29.            BYTE #         Description
  30.  
  31.             0-9         10 Character (MAX) file name.  Unused characters
  32.                         are space characters.
  33.  
  34.             10          File Status Flags:
  35.                                           Bit No   ON=1         OFF=0
  36.                            >00 Dis/Fix      0   Program File   Data File
  37.                            >01 Program      1   Internal       Display
  38.                            >02 Int/Fix      2   Reserved
  39.                            >80 Dis/Var      3   Write Prot     No Write Prot
  40.                            >82 Int/Var      4   Reserved
  41.                                            *5   Squeezed       Unsqueezed
  42.                          *Non-standard      6   Reserved
  43.                             meaning         7   Variable Len   Fixed Len
  44.  
  45.             11          Maximum Number of Records/Sector or AU
  46.  
  47.             12-13       Total Number of Sectors Used (unsqueezed archive) or
  48.                         Total Number of 128 byte Records Used (squeezed archive)
  49.  
  50.  
  51.             14          End of File Offset
  52.  
  53.             15          Logical Record Length
  54.  
  55.             16-17       Number of Fixed Length Records or Number of Sectors
  56.                         Used by Variable Length Records
  57.  
  58.         The last 128 byte header record contains the characters "END!" in
  59.         the last four bytes.  Unused header record slots (to fill out a
  60.         128 byte record) contain zeroes.
  61.  
  62.             These 18 byte mini file headers are packed fourteen to two
  63.             128 byte records (for a total of 252 bytes).  The remaining
  64.             unused four bytes per sector contain either zeroes (meaning
  65.             this is NOT the last header sector) or the characters END!
  66.             (meaning this is the last header sector).
  67.  
  68.          d. Following the header section of the archive is the data
  69.             section.  Each 256 byte sector of the file is packed as
  70.             two 128 byte records.
  71.  
  72.  
  73.      There are two fundamental problems with the Traver format when used
  74. for archiving. First, the minor point is that these mini-headers are not
  75. sized as powers of 2. This complicates (only slightly) the archive
  76. directory maintenance functions. More serious though, is that fact that it
  77. locks out any future expansion unless some contorted methodology is used
  78. to find "expansion haeders" and then to further decode these.
  79.  
  80.      To alleviate this, I suggest that a different format be used for each
  81. directory entry.
  82.  
  83.  
  84.            BYTE #         Description
  85.  
  86.             0-9         10 Character (MAX) file name.  Unused characters
  87.                         are space characters.
  88.  
  89.             10          File Status Flags:
  90.                                           Bit No   ON=1         OFF=0
  91.                            >00 Dis/Fix      0   Program File   Data File
  92.                            >01 Program      1   Internal       Display
  93.                            >02 Int/Fix      2   Reserved
  94.                            >80 Dis/Var      3   Write Prot     No Write Prot
  95.                            >82 Int/Var      4   Reserved
  96.                                            *5   Squeezed       Unsqueezed
  97.                          *Non-standard      6   Reserved
  98.                             meaning         7   Variable Len   Fixed Len
  99.  
  100.             11          Maximum Number of Records/Sector or AU
  101.  
  102.             12-13       Total Number of Sectors Used (unsqueezed archive) or
  103.  
  104.  
  105.             14          End of File Offset
  106.  
  107.             15          Logical Record Length
  108.  
  109.             16-17       Number of Fixed Length Records or Number of Sectors
  110.                         Used by Variable Length Records
  111.  
  112.             20-30       RESERVED FOR FUTURE EXPANSION
  113.                         (Preserve time/date stamps, etc.)
  114.  
  115.             31          Header Addendum Flag
  116.  
  117.  
  118. The effect of this directory structure will allow us to (a) meet future
  119. requirements, (b) add additional info to the archived files if needed,
  120. (c) greatly simplify archive directory management algorithms since each
  121. dirctory entry is exactly 32 bytes long.
  122.  
  123.      I also realize that the suggestion for the use of bytes 12-13 does
  124. not conform with Al Beard's current methods for squeezing files. However,
  125. it seems to me that there is a good reason to attempt to simplify the use
  126. of that field. If, however, Al can convince us otherwise, it might be
  127. possible to allow that field to have a dual nature.
  128.  
  129.      The RESERVED bytes provide area for immediate expansion if there is
  130. need. The header addendum flag is a simple zero/non-zero flag that will
  131. indicate whether additional header info is to be found with the actual
  132. archive file member. Since this need only be a bit flag, as is the case
  133. with the file status flags, the header addendum flag could also be
  134. designed to carry other information. If the header flag itself is set,
  135. then additional information will be found preceding the actual file in the
  136. archive. This additional information can be arranged in any number of
  137. formats but the essential item is the very first word. It will indicate
  138. how many additional bytes of data are associated with the file header
  139. addendum. Beyond that, I have not attempted to define the header file
  140. addendum area since I am not sure how it might be used or if it will ever
  141. truly be used.
  142.  
  143.      I realize that this proposal calls for a serious overhaul of the
  144. current archive format but I believe that the overhaul would be
  145. worthwhile. To perpetuate a less than optimal archive format will
  146. complicate our programming efforts and perhaps lock us into a system that
  147. is not as flexible or responsive to our changing needs.
  148.  
  149.      On the other hand, an optimal archive format will allow us to do a
  150. variety of things, such as writing utilities to let us run programs that
  151. are not frequently used from directly inside an archive or allow us to
  152. extract a particular file (compressed or not) for transmission over data
  153. lines, or to simply type to the screen.
  154.  
  155.      On yet another note, we might ask ourselves if we wish to design in
  156. the capability to expand an existing archive. There is precedent for this.
  157. In the CPM world, the library utilities allow the user to specify the
  158. numbe of library directory entries in the library at the time it is
  159. formed. This assumes that the creator has a reasonable idea of how many
  160. entries will be required since the archive directory fully precedes the
  161. files embedded in the archive. (NOTE: There is a way to avoid this. It
  162. involves using a header followed by the embedded file, followed by the
  163. next header and file, and so on. This requires that the header contain a
  164. pointer to the next header in the archive. The disadvantage of this
  165. technique is that the random access nature of the archive is destroyed.
  166. This is the sort of tradeoff that needs to be fully considered by the TI
  167. community before implementation.)
  168.  
  169.      Finally, there is one last issue that I wish to raise for
  170. consideration. I personally believe that we should separate the archiving
  171. process from the compression process totally. That is to say, a file in an
  172. archive can be extracted in a compressed form or in an uncompressed form.
  173. Likewise, a file can be compressed outside an archive and later added to
  174. the archive. I believe that by keeping the compression and archiving
  175. processes separate that we can not only enjoy them but can proceed to
  176. upgrade either one without directly impacting the other.
  177.  
  178.      The purpose of this short file is to get the TI community thinking
  179. about the archive problem. I hope that it helps accomplish that. Please
  180. not that all of the ideas presented herein are subject to change and
  181. improvement. They are presented simply as alternatives to the current way
  182. of doing things.
  183.  
  184. END END END END END END END END END END END END END END END END END END
  185.  
  186.  
  187. Download complete.  Turn off Capture File.
  188.  
  189.  
  190.