    FILEID.TXT v1.8 by Richard Holler [CIS 73567,1547]
    Last Revision 05/05/94

    This text file was prepared at the request of the ASP (Association of
    Shareware Professionals), but the information contained in it may be of
    value to any shareware author.

    FILE_ID.DIZ INFORMATION
    -----------------------
    Basically, the FILE_ID.DIZ file is a straight ASCII text file, distributed
    inside your distribution archive file along with your program files, which
    contains a description of your program. This file will be used by most BBS
    (Bulletin Board System) softwares for the online file description of your
    file. We recommend that the FILE_ID.DIZ file be used in all of your
    distribution archives.

    This text file contains a description of the FILE_ID.DIZ file, as well as a
    description of the recommended distribution archive format.

    WHY SHOULD YOU USE FILE_ID.DIZ?
    -------------------------------
    The use of this file will insure that the online description of your
    program will be in your own words (and who better to describe your program
    than yourself?), and that it will remain the same no matter how many
    different people upload your file to various BBS systems.

    As more and more BBS software makes use of this file, you can be assured
    that your own description will replace such online descriptions as "Cool
    Program" or "OK utility, but needs better ..."

    Please note that the ASP Hub Network, the Author Direct FDN (File
    Distribution Network), and the majority of other electronic distribution
    services *REQUIRE* that a valid FILE_ID.DIZ file be contained in your
    submitted distribution archive. If your file doesn't contain a valid
    FILE_ID.DIZ file, then it simply won't be distributed by these services.
    Furthermore, most BBS sysops will not accept uploads of files which do not
    contain a valid FILE_ID.DIZ file, so you automatically lose out on that
    distribution as well.

    DESCRIPTION:
    ------------
    FILE_ID.DIZ was created by Clark Development for use with their PCBDescribe
    utility, as a means for BBS callers to upload a file without having to
    manually type in a file description. It also ensures that the online
    description is always the same regardless of the number of different BBS
    systems the file is posted on. It has since been accepted by the BBS
    industry more-or-less as the "standard" file description source. (The
    extension of "DIZ" actually stands for "Description In Zip").

    NOTE: The FILE_ID.DIZ file *MUST* be named exactly that, and *NOT*
    something like <filename>.DIZ. It will *ONLY* be used if it is named
    FILE_ID.DIZ!

    The FILE_ID.DIZ file is nothing more than a straight ASCII text file which
    contains the full description of the archived file containing it. It is
    used by most popular BBS software to describe your program, rather than
    using the description supplied by the person that uploaded your file. It
    should be placed *INSIDE* your distribution archive file.

    The BBS software will "look" inside the archive file. If a FILE_ID.DIZ file
    is found, it will replace any existing online file description with the
    text contained in FILE_ID.DIZ. It is an excellent method for making sure
    that your program files are described the way that "you" want them
    described. Even sysops who's software can't automatically make use of the
    FILE_ID.DIZ file have found it to be an excellent source for their manually
    added file descriptions.

    STRUCTURE:
    ----------
    The file consists of straight ASCII text, up to 10 lines of text, each line
    being no more than 45 characters long. It should *NOT* contain any blank
    lines, any form of centering or formatting, or any Hi-ASCII or ANSI
    characters. (i.e. it should ONLY contain alpha & numeric characters).

    We recommended that it consist of 5 basic parts:

       1. the proper name of your program
       2. the version number
       3. the "ASP" identifier (optional, for ASP members)
       4. the description separator
       4. the description

    All of the above parts should be separated by a single "space".

    PROGRAM NAME: To set it apart from the rest, it is recommended that you use
    ALL CAPS for the program name.

    VERSION NUMBER: The version number should be in the form of "v12.34".

    ASP IDENTIFIER: If you are an ASP author, we recommend that an "<ASP>"
    identifying mark be added after the version number, to identify your
    product as an ASP-authored product.

    DESCRIPTION SEPARATOR: To separate the actual description text, insert a
    simple "-" (dash/minus) character after the ASP identifier (or version
    number, if not using the ASP identifier), and in front of the description
    text.

    DESCRIPTION: You should attempt to FULLY describe your product, including
    its most important functions and features. Be sure to include anything
    which will separate your program from it's competition, and make the BBS
    user want to download your file. Also try to include any hardware or
    software requirements that your product may have.

    You should try to use the first 2 lines of the text to give a basic
    description of your program. This is helpful for sysops who's BBS software
    limits them to less than 10 lines, 45 characters. Sysops who are limited to
    using shorter descriptions can simply use the 1st two lines and truncate
    the rest. Thus, you can basically still supply your own description for BBS
    software which does not actually utilize the FILE_ID.DIZ feature.

    The remaining lines of text can be used to elaborate on the programs
    features, enhancements from the prior version, information concerning
    multi-file sets. Please note that older versions of some BBS software can
    only use 8 lines of text. It is advisable that you create your FILE_ID.DIZ
    file so that the file can be truncated to various line lengths without
    destroying it's usefulness.

    EXAMPLE
    -------
    MY PROGRAM v1.23 <ASP> - A program which will
    do anything for anybody. Will run in only 2k
    of memory. Can be run from the command line,
    or installed as a TSR. Completely menu-
    driven. Version 1.23 reduces the previous 4k
    memory requirements, and adds an enhanced
    graphical user interface. Also, MY PROGRAM
    now contains Windows and DESQview support.
    Coming soon - an OS/2 version.
    From Do-It-All Software, Inc. $15.00

    MULTIPLE DISK INFO
    ------------------
    Please note that if your distribution archive requires multiple archive
    files, you should create a separate, specific FILE_ID.DIZ file for each
    archive. This can be utilized to describe the various contents of each
    archive, and to identify each disk in the set. For example, the FILE_ID.DIZ
    file for disk #1 could contain:

       "MY PROGRAM v1.23 <ASP> Program Executable
        Files - Disk 1 of 2"
        [followed by detailed description text]

    while the FILE_ID.DIZ file for disk #2 could contain:

       "MY PROGRAM v1.23 <ASP> Documentation Files -
        Disk 2 of 2"
        [followed by more detailed description text]

    Optionally, you could also create a "complete" FILE_ID.DIZ file for the
    first disk, which would fully describe the program in detail, and identify
    it as Disk 1 of x. Then, for each remaining file in the set, simply include
    the Program Name, version number, ASP identifier, and the disk number (i.e.
    "MY PROGRAM v1.23 <ASP> Disk 2 of x").

    ADDITIONAL INFO
    ---------------
    Please don't be tempted to use fancy graphic or ANSI sequences in the
    FILE_ID.DIZ file, as most BBS software will not allow this, and will render
    your FILE_ID.DIZ file useless. Also, don't be tempted to simply copy your
    program description file to FILE_ID.DIZ. Attempting to "format" your
    FILE_ID.DIZ file (i.e line centering, right & left justification, etc) will
    also cause unexpected results, especially for BBS software which re-formats
    descriptions to other than 10line/45char.

    Fred Hill <ASP> has written a freeware utility which interactively creates
    a valid FILE_ID.DIZ file. The file is called DIZGEN.ZIP and can be found on
    CompuServe (GO IBMBBS, Library 2) as well as on many fine BBS systems. I
    highly recommend that you download a copy of this wonderful utility for
    creating your FILE_ID.DIZ files.

    <*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*>

    The following is a recommendation for the structure and contents of
    distribution archives prepared for use on BBS systems.

    DISTRIBUTION DISK RECOMMENDATIONS
    ---------------------------------
    The following are recommendations for preparing your program files for
    distribution to Bulletin Board Systems (BBSs) via the ASP's distribution
    services, as well as other methods.

    Two varieties of program files are defined here:

    1) Program files which utilize an "install" utility and self-extracting
    program archives (later referred to as "Author-Installed Programs").

    2) Programs files which do not use install utilities or self-extracting
    archives (later referred 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 (SFX) 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, in order to allow
               them to be viewed/read by the various archive viewing utlities.
            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.TXT,
               SYSOP.TXT, etc.
            d. Any description or information file, such as DESCRIBE.TXT.
            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.TXT).

    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 most BBS systems
    will convert your 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 doesn'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 for CompuServe uploading by simply removing the 2-digit version
    identifier, to make the file compatible with CompuServe libraries.

    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
    ------------------------------
    At one time, it was recommended that your final distribution archive not be
    larger than 350k, so that it would 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). This
    limitation is slowly falling by the wayside as more and more computer
    systems have 3.5" floppy disk drives as standard.

    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). However,
    for CompuServe it is recommended that you simply create a single
    distibution file, and eliminate the multi-part file set.

    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 distribution disk simply contain a ZIPd version
    of your product. However, If you choose to supply "unarchived" files on a
    distribution disk for Disk Vendor use, it is _VERY_ important that you
    specify in your documentation a suggested archive filename, so that BBS
    sysops can create archived files with the proper author-specified
    filenames. This information should be contained in your SYSOP.TXT (or
    VENDOR.TXT) 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, and nearly every other electronic
    distribution service *REQUIRE* that your files be submitted as an archived
    file, using the ZIP format. Also note that many BBS sysops will not go to
    the trouble of ZIPing your unarchived files for you. If you don't supply
    them with an archived distribution version of your product, it might not
    get distributed by BBSs.

    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 to the various BBSs,
    distribution services, and Disk Vendors.

    You may choose to create a separate distribution disk for use by BBSs and
    Disk Vendors. However, if you follow the above steps in preparing your
    distribution archive file, a separate "Disk 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.

Go Back