home *** CD-ROM | disk | FTP | other *** search
/ Crawly Crypt Collection 1 / crawlyvol1.bin / bbs / makediz1 / fileid.txt < prev    next >
Text File  |  1993-03-11  |  17KB  |  357 lines

  1. FILEID.TXT v1.7 by Richard Holler [CIS 73567,1547]
  2. Last Revision 03/11/93
  3.  
  4. This text file is prepared primarily for use by ASP (Association of 
  5. Shareware Professionals) Author members, but the information contained 
  6. in it may be of value to any shareware author.
  7.  
  8. FILE_ID.DIZ INFORMATION
  9. -----------------------
  10. Basically, the FILE_ID.DIZ file is a straight text file which contains a 
  11. description of your program, and is used for online file descriptions on 
  12. BBS systems. We recommend that the FILE_ID.DIZ file be used in all of 
  13. your distribution archives. 
  14.  
  15. This text file contains a description of the FILE_ID.DIZ file, as well 
  16. as a description of the recommended distribution archive format.
  17.  
  18. WHY SHOULD YOU USE FILE_ID.DIZ?
  19. -------------------------------
  20. The use of this file will insure that the online description of your 
  21. program will be in your own words (and who better to describe your 
  22. program than yourself?), and that it will remain the same no matter how 
  23. many different people upload your file to various BBS systems. 
  24.  
  25. As more and more BBS software makes use of this file, you can be assured 
  26. that your own description will replace such online descriptions as "Cool 
  27. Program" or "OK utility, but needs better ..."
  28.  
  29. Please note that the ASP Hub Network *REQUIRES* that a valid FILE_ID.DIZ 
  30. file be contained in your submitted distribution archive.
  31.  
  32. DESCRIPTION:
  33. ------------
  34. FILE_ID.DIZ was created by Clark Development for use with their 
  35. PCBDescribe utility, as a means for BBS callers to upload a file without 
  36. having to manually type in a file description. It also ensures that the 
  37. online description is always the same regardless of the number of 
  38. different BBS systems the file is posted on. It has since been accepted 
  39. more-or-less as the "standard" archive file description. (The "DIZ" 
  40. actually stands for Description In Zip).
  41.  
  42. The FILE_ID.DIZ file is nothing more than a straight ASCII text file 
  43. which contains the full description of the archived file containing it.
  44. It can be used by certain popular BBS software to describe your program,
  45. rather than using the description supplied by the person that uploaded 
  46. your file to the BBS. It should be placed *INSIDE* your distribution 
  47. archive file.
  48.  
  49. The BBS software will "look" inside the archive file. If a FILE_ID.DIZ 
  50. file is found, it will replace any existing online file description with 
  51. the text contained in FILE_ID.DIZ. It is an excellent method for making 
  52. sure that your program files are described the way that "you" want them 
  53. described. Even sysops who's software can't automatically use the 
  54. FILE_ID.DIZ file have found it to be an excellent source for manually 
  55. adding their file descriptions.
  56.  
  57. STRUCTURE:
  58. ----------
  59. The file consists of straight ASCII text, up to 10 lines of text, each
  60. line being no more than 45 characters long. It should NOT contain any 
  61. blank lines, any form of centering or formatting, or any Hi-ASCII or 
  62. ANSI characters. (i.e. it should ONLY contain alpha & numeric 
  63. characters).
  64.  
  65. We recommended that it consist of 5 basic parts:
  66.  
  67.    1. the proper name of your program
  68.    2. the version number
  69.    3. the "ASP" identifier (optional, for ASP members)
  70.    4. the description separator
  71.    4. the description
  72.  
  73. All of the above parts should be separated by a single "space".
  74.  
  75. PROGRAM NAME: To set it apart from the rest, it is recommended that you 
  76. use ALL CAPS for the program name.
  77.  
  78. VERSION NUMBER: The version number should be in the form of "v12.34". 
  79.  
  80. ASP IDENTIFIER: If you are an ASP author, we recommend that an "<ASP>"
  81. identifying mark be added after the version number, to identify your
  82. product as an ASP-authored product.
  83.  
  84. DESCRIPTION SEPARATOR: To separate the actual description text, insert a
  85. simple "-" (dash/minus) character after the ASP identifier (or version
  86. number, if not using the ASP identifier), and in front of the 
  87. description text.
  88.  
  89. DESCRIPTION: You should attempt to FULLY describe your product,
  90. including its most important functions and features. Be sure to include
  91. anything which will separate your program from it's competition, and
  92. make the BBS user want to download your file.
  93.  
  94. You should try to use the first 2 lines of the text to give a basic
  95. description of your program. This is helpful for sysops who's BBS 
  96. software limits them to less than 10 lines, 45 characters. Sysops who 
  97. are limited to using shorter descriptions can simply use the 1st two 
  98. lines and truncate the rest. Thus, you can basically still supply your 
  99. own description for BBS software which does not actually utilize the 
  100. FILE_ID.DIZ feature.
  101.  
  102. The remaining lines of text can be used to elaborate on the programs 
  103. features, enhancements from the prior version, information concerning 
  104. multi-file sets. Please note that older versions of some BBS software 
  105. can only use 8 lines of text. It is advisable that you create your 
  106. FILE_ID.DIZ file so that the file can be truncated to various line 
  107. lengths without destroying it's usefulness.
  108.  
  109.  
  110. EXAMPLE
  111. -------
  112. MY PROGRAM v1.23 <ASP> - A program which will
  113. do anything for anybody. Will run in only 2k
  114. of memory. Can be run from the command line,
  115. or installed as a TSR. Completely menu-
  116. driven. Version 1.23 reduces the previous 4k
  117. memory requirements, and adds an enhanced
  118. graphical user interface. Also, MY PROGRAM 
  119. now contains Windows and DESQview support. 
  120. Coming soon - an OS/2 version.
  121. From Do-It-All Software, Inc. $15.00
  122.  
  123.  
  124. MULTIPLE DISK INFO
  125. ------------------
  126. Please note that if your distribution archive requires multiple archive
  127. files, you should create a separate, specific FILE_ID.DIZ file for each
  128. archive. This can be utilized to describe the various contents of each
  129. archive, and to identify each disk in the set. For example, the
  130. FILE_ID.DIZ file for disk #1 could contain:
  131.  
  132.    "MY PROGRAM v1.23 <ASP> Program Executable 
  133.     Files - Disk 1 of 2"
  134.     [followed by detailed description text]
  135.  
  136. while the FILE_ID.DIZ file for disk #2 could contain:
  137.  
  138.    "MY PROGRAM v1.23 <ASP> Documentation Files - 
  139.     Disk 2 of 2"
  140.     [followed by more detailed description text]
  141.  
  142. Optionally, you could also create a "complete" FILE_ID.DIZ file for the 
  143. first disk, which would fully describe the program in detail, and 
  144. identify it as Disk 1 of x. Then, for each remaining file in the set, 
  145. simply include the Program Name, version number, ASP identifier, and the 
  146. disk number (i.e. "MY PROGRAM v1.23 <ASP> Disk 2 of x").
  147.  
  148.  
  149. ADDITIONAL INFO
  150. ---------------
  151. Please don't be tempted to use fancy graphic or ANSI sequences in the
  152. FILE_ID.DIZ file, as most BBS software will not allow this, and will
  153. render your FILE_ID.DIZ file useless. Also, don't be tempted to simply
  154. copy your program description file to FILE_ID.DIZ. Attempting to 
  155. "format" your FILE_ID.DIZ file (i.e line centering, right & left 
  156. justification, etc) will also cause unexpected results, especially for 
  157. BBS software which re-formats descriptions to other than 10line/45char.
  158.  
  159. (LATE-BREAKING NEWS - Fred Hill <ASP> has written a freeware utility 
  160. which interactively creates a valid FILE_ID.DIZ file. The file is called 
  161. DIZGEN.ZIP and can be found on CompuServe as well as on many fine BBS 
  162. systems. I highly recommend that you download a copy of this wonderful 
  163. utility for creating your FILE_ID.DIZ files.)
  164.  
  165. <*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*>
  166.  
  167. The following is a recommendation for the structure and contents of
  168. distribution archives prepared for use on BBS systems.
  169.  
  170.  
  171. DISTRIBUTION DISK RECOMMENDATIONS
  172. ---------------------------------
  173. The following are recommendations for preparing your program files for
  174. distribution to Bulletin Board Systems (BBSs) via the ASP's Disk Mailing
  175. service, as well as other methods.
  176.  
  177. 2 varieties of program files are defined here:
  178.  
  179. 1) Program files which utilize an "install" utility and self-extracting
  180. program archives (later refereed to as "Author-Installed Programs").
  181.  
  182. 2) Programs files which do not use install utilities or self-extracting
  183. archives (later refereed to as "User-Installed Programs").
  184.  
  185.  
  186. AUTHOR-INSTALLED PROGRAMS:
  187. --------------------------
  188. These programs require a bit more work from the author, but will
  189. eliminate many user mistakes, especially in programs which require
  190. complicated setups.
  191.  
  192. Most "installation" utility programs will make use of program files
  193. which have been "archived" into Self-Extracting archives. We will
  194. attempt to define which files should be contained in the Self-Extracting
  195. archives, and which files should not.
  196.  
  197. 1. Files which should be contained in the self-extracting program file
  198. archive:
  199.  
  200.         a. All program-specific executable files.
  201.         b. Any required configuration and/or data files required by the
  202.            program.
  203.         c. Program documentation files. Optionally, these may be left
  204.            outside of the self-extracting archive, but they will not be
  205.            installed to the destination directory with the program
  206.            files.
  207.         d. Any other program-specific files that are required for the
  208.            operation of the program.
  209.  
  210. 2. The files described above should be compiled into a self-extracting
  211. archive file, which will then be extracted by the install utility.
  212.  
  213. NOTE: the author is required to abide by any distribution requirements
  214. specified by the archive utility author, and to obtain any required
  215. distribution rights necessary. Please check to see if distribution
  216. rights are required for your archive utility choice.
  217.  
  218. 3. Files which should NOT be contained in the self-extracting program
  219. file archive:
  220.  
  221.         a. The install utility itself (obviously).
  222.         b. The FILE_ID.DIZ file. (described in detail in the section
  223.            preceding this one)
  224.         c. Any distribution/information files, such as VENDOR.DOC,
  225.            SYSOP.DOC, etc.
  226.         d. Any description or information file, such as DESCRIBE.DOC.
  227.         e. A user file (such as README.1ST), which should explain how
  228.            to use the install utility, what the user should expect
  229.            during the installation, and any preparation that the user
  230.            should make prior to the installation. This file might also
  231.            contain a brief description of your program, in case the user
  232.            is able to read the documentation files in the distribution
  233.            archive prior to downloading (many BBS systems offer this
  234.            ability to the user).
  235.  
  236. 4. The actual distribution archive file (described below) should then
  237. contain the install utility, the self-extracting program archive, and
  238. the files described in #3 above.
  239.  
  240.  
  241. USER-INSTALLED PROGRAMS:
  242. ------------------------
  243. This type of distribution archive is much simpler than the
  244. Author-Installed variety. It should simply be an archive file,
  245. containing all of the files for the program described above.
  246.  
  247. Since this type of program requires the user to do all of the
  248. installation manually, it should contain very specific and detailed
  249. information regarding the installation requirements (such as
  250. INSTALL.DOC).
  251.  
  252.  
  253. THE DISTRIBUTION ARCHIVE FILE:
  254. ------------------------------
  255. The actual distribution archive file should merely be an archive file
  256. containing the files described above. For BBS distribution, this archive
  257. should be of the standard archive format, and -NOT- a self-extracting
  258. archive.  Many sysops will not allow self-extracting archives, and most
  259. BBS software will not allow self-extracting archives to be uploaded.
  260.  
  261. There are many popular archive utilities available, such as PKZIP, LHA,
  262. LHARC, ARJ, etc. Most BBS systems are capable of handling archives in
  263. virtually any format. However, you should be aware that some BBS systems
  264. will convert your chosen archive format to the format of choice by the
  265. sysop. By following the methods described above, this conversion process
  266. should not affect your program, or any self-extracting files which are 
  267. contained within your distribution archive file.
  268.  
  269. You should also retain the default archive file extension defined by the
  270. archive utility. For example, PKZIP uses a ".ZIP", LHARC uses "LZH",
  271. etc. Changing the file extension may cause the BBS software to delete
  272. your file because it won't recognize the format.
  273.  
  274. For the actual filename for your distribution archive, it is recommended
  275. that the program filename be limited to 6 characters to represent the
  276. program's name (i.e. MYPROG could represent "My Program"). This should
  277. be followed by 2 numeric digits which will represent the version number
  278. of your release. Even if this is your initial release it should include
  279. the version number in the filename (i.e. MYPROG10.ZIP would indicate the
  280. program called "My Program" version 1.0).
  281.  
  282. Please note that CompuServe limits filenames to only 6 characters. By 
  283. limiting the file "name" to 6 characters, you will easily be able to 
  284. rename the archive by removing the 2-digit version identifier, to make 
  285. the file compatible with CompuServe libraries (which will only allow 
  286. 6-character filenames).
  287.  
  288. By including the 2-digit version number in the archive filename, it will
  289. be very easy for both the user and the sysop (and yourself) to identify
  290. older versions of your program.
  291.  
  292.  
  293. MULTIPLE DISTRIBUTION ARCHIVES
  294. ------------------------------
  295. It is recommended that your final distribution archive not be larger
  296. than 350k, so that it will fit on a single 360k floppy disk and still 
  297. leave room for any distribution files necessary for Disk Vendors. (i.e. 
  298. Disk Vendors will often include their own GO.BAT file, or other various 
  299. small files to help their customers install the software).
  300.  
  301. If your program is large enough to require more than one distribution
  302. archive, it is recommended that your filename be limited to 5 characters
  303. rather than 6 as described above. Following the 5-character name should
  304. be the same 2-digit version number. Then, append a single "letter" to
  305. identify the disk (i.e. MYPGM10A.ZIP, MYPGM10B.ZIP, etc.). For uploading 
  306. to CompuServe, these filenames may then be shortened to 6 characters by 
  307. removing the version identifiers (i.e. MYPGMA.ZIP, MYPGMB.ZIP).
  308.  
  309. If your program requires multiple distribution archives, -BE SURE- to
  310. create separate FILE_ID.DIZ files for each distribution archive. Also,
  311. each FILE_ID.DIZ file should contain disk number information pertaining
  312. to each individual archive (i.e. Disk 1 of 3, Disk 2 of 3, etc.).
  313.  
  314.  
  315. THE DISTRIBUTION DISK
  316. ---------------------
  317. It is recommended that your final distribution archive file be under
  318. 350k in size, so that it will fit on a single 360k floppy disk. There is
  319. no need to include anything on the disk except the distribution archive.
  320.  
  321. However, you may want to include copies of your distribution text files
  322. (VENDOR.DOC, SYSOP.DOC, DISTRIB.DOC, etc.) so that the sysop (and/or disk
  323. vendor doesn't have to go inside the archive to gather information
  324. regarding your file.
  325.  
  326. If you choose to supply your files "unarchived" on the distribution 
  327. disk, it is _VERY_ important that you specify what the archive filename 
  328. should be, so that sysops can create archived files with the proper 
  329. author-specified filenames. This information should be contained in 
  330. your SYSOP.DOC (or VENDOR.DOC) file. If you don't supply a suggested 
  331. archive file name, the sysops will be forced to create the name 
  332. themselves, thus you may end up with thousands of versions of your 
  333. products on BBS systems all over the world, but all with different 
  334. filenames.
  335.  
  336. Please note that the ASP Hub Network *REQUIRES* that your files be 
  337. submitted as an archived file, using the ZIP format.
  338.  
  339. If you supply your own disk labels, it is recommended that the ASP logo,
  340. or at least the initials "ASP" be included on the label, so that anyone
  341. can immediately identify your disk as an ASP member's software.
  342.  
  343.  
  344. SUMMARY
  345. -------
  346. Your distribution disk should now be ready to submit for the ASP 
  347. Author's Disk Mailing, as well as any separate mailings that you want to
  348. do yourself.
  349.  
  350. Since the ASP Disk Mailing Service allows separate distribution disks 
  351. for BBSs and Vendors, you may optionally create a different distribution 
  352. disk for use by Disk Vendors. However, if you follow the above steps in 
  353. preparing your distribution archive file, a separate vendor disk is 
  354. probably not necessary. The majority of disk vendors will be able to 
  355. accept your distribution file/disk if it is prepared in the above 
  356. described format.
  357. ə