ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ The following comes intact and unchanged from the Assoc. of ³ ³ Shareware Professionals and applies to programs distributed ³ ³ by the ASP. (The prose begs for editing but we didn't.) ³ ³ All shareware authors - but especially authors of Windows and ³ ³ OS/2 programs - would do well to follow these guidelines no ³ ³ matter how their programs are distributed. ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ DISTRIBUTION DISK RECOMMENDATIONS --------------------------------- The following are recommendations for preparing your program files for distribution to Bulletin Board Systems (BBSs) via the ASP's Disk Mailing service, as well as other methods. 2 varieties of program files are defined here: 1) Program files which utilize an "install" utility and self-extracting program archives (later refereed to as "Author-Installed Programs"). 2) Programs files which do not use install utilities or self-extracting archives (later refereed to as "User-Installed Programs"). AUTHOR-INSTALLED PROGRAMS: -------------------------- These programs require a bit more work from the author, but will eliminate many user mistakes, especially in programs which require complicated setups. Most "installation" utility programs will make use of program files which have been "archived" into Self-Extracting archives. We will attempt to define which files should be contained in the Self-Extracting archives, and which files should not. 1. Files which should be contained in the self-extracting program file archive: a. All program-specific executable files. b. Any required configuration and/or data files required by the program. c. Program documentation files. Optionally, these may be left outside of the self-extracting archive, but they will not be installed to the destination directory with the program files. d. Any other program-specific files that are required for the operation of the program. 2. The files described above should be compiled into a self-extracting archive file, which will then be extracted by the install utility. NOTE: the author is required to abide by any distribution requirements specified by the archive utility author, and to obtain any required distribution rights necessary. Please check to see if distribution rights are required for your archive utility choice. 3. Files which should NOT be contained in the self-extracting program file archive: a. The install utility itself (obviously). b. The FILE_ID.DIZ file. (described in detail in the section preceding this one) c. Any distribution/information files, such as VENDOR.DOC, SYSOP.DOC, etc. d. Any description or information file, such as DESCRIBE.DOC. e. A user file (such as README.1ST), which should explain how to use the install utility, what the user should expect during the installation, and any preparation that the user should make prior to the installation. This file might also contain a brief description of your program, in case the user is able to read the documentation files in the distribution archive prior to downloading (many BBS systems offer this ability to the user). 4. The actual distribution archive file (described below) should then contain the install utility, the self-extracting program archive, and the files described in #3 above. USER-INSTALLED PROGRAMS: ------------------------ This type of distribution archive is much simpler than the Author-Installed variety. It should simply be an archive file, containing all of the files for the program described above. Since this type of program requires the user to do all of the installation manually, it should contain very specific and detailed information regarding the installation requirements (such as INSTALL.DOC). THE DISTRIBUTION ARCHIVE FILE: ------------------------------ The actual distribution archive file should merely be an archive file containing the files described above. For BBS distribution, this archive should be of the standard archive format, and -NOT- a self-extracting archive. Many sysops will not allow self-extracting archives, and most BBS software will not allow self-extracting archives to be uploaded. There are many popular archive utilities available, such as PKZIP, LHA, LHARC, ARJ, etc. Most BBS systems are capable of handling archives in virtually any format. However, you should be aware that some BBS systems will convert your chosen archive format to the format of choice by the sysop. By following the methods described above, this conversion process should not affect your program, or any self-extracting files which are contained within your distribution archive file. You should also retain the default archive file extension defined by the archive utility. For example, PKZIP uses a ".ZIP", LHARC uses "LZH", etc. Changing the file extension may cause the BBS software to delete your file because it won't recognize the format. For the actual filename for your distribution archive, it is recommended that the program filename be limited to 6 characters to represent the program's name (i.e. MYPROG could represent "My Program"). This should be followed by 2 numeric digits which will represent the version number of your release. Even if this is your initial release it should include the version number in the filename (i.e. MYPROG10.ZIP would indicate the program called "My Program" version 1.0). Please note that CompuServe limits filenames to only 6 characters. By limiting the file "name" to 6 characters, you will easily be able to rename the archive by removing the 2-digit version identifier, to make the file compatible with CompuServe libraries (which will only allow 6-character filenames). By including the 2-digit version number in the archive filename, it will be very easy for both the user and the sysop (and yourself) to identify older versions of your program. MULTIPLE DISTRIBUTION ARCHIVES ------------------------------ It is recommended that your final distribution archive not be larger than 350k, so that it will fit on a single 360k floppy disk and still leave room for any distribution files necessary for Disk Vendors. (i.e. Disk Vendors will often include their own GO.BAT file, or other various small files to help their customers install the software). If your program is large enough to require more than one distribution archive, it is recommended that your filename be limited to 5 characters rather than 6 as described above. Following the 5-character name should be the same 2-digit version number. Then, append a single "letter" to identify the disk (i.e. MYPGM10A.ZIP, MYPGM10B.ZIP, etc.). For uploading to CompuServe, these filenames may then be shortened to 6 characters by removing the version identifiers (i.e. MYPGMA.ZIP, MYPGMB.ZIP). If your program requires multiple distribution archives, -BE SURE- to create separate FILE_ID.DIZ files for each distribution archive. Also, each FILE_ID.DIZ file should contain disk number information pertaining to each individual archive (i.e. Disk 1 of 3, Disk 2 of 3, etc.). THE DISTRIBUTION DISK --------------------- It is recommended that your final distribution archive file be under 350k in size, so that it will fit on a single 360k floppy disk. There is no need to include anything on the disk except the distribution archive. However, you may want to include copies of your distribution text files (VENDOR.DOC, SYSOP.DOC, DISTRIB.DOC, etc.) so that the sysop (and/or disk vendor doesn't have to go inside the archive to gather information regarding your file. If you choose to supply your files "unarchived" on the distribution disk, it is _VERY_ important that you specify what the archive filename should be, so that sysops can create archived files with the proper author-specified filenames. This information should be contained in your SYSOP.DOC (or VENDOR.DOC) file. If you don't supply a suggested archive file name, the sysops will be forced to create the name themselves, thus you may end up with thousands of versions of your products on BBS systems all over the world, but all with different filenames. Please note that the ASP Hub Network *REQUIRES* that your files be submitted as an archived file, using the ZIP format. If you supply your own disk labels, it is recommended that the ASP logo, or at least the initials "ASP" be included on the label, so that anyone can immediately identify your disk as an ASP member's software. SUMMARY ------- Your distribution disk should now be ready to submit for the ASP Author's Disk Mailing, as well as any separate mailings that you want to do yourself. Since the ASP Disk Mailing Service allows separate distribution disks for BBSs and Vendors, you may optionally create a different distribution disk for use by Disk Vendors. However, if you follow the above steps in preparing your distribution archive file, a separate vendor disk is probably not necessary. The majority of disk vendors will be able to accept your distribution file/disk if it is prepared in the above described format.