OS/2 Shareware BBS: 2 BBS/02-BBS.zip/gem250.zip/GOLDUSR.DOC

Text File | 1995-10-08 | 140KB | 3,361 lines

                   ────────────────────────────────────────────────


                                        ┌┐     ┌┐            ┌┐
                                        ││     ││            ││
                                        ││     ││            ││
                                        ││     ││            ││
                          ┌┬──┬┐ ┌┬──┬┐ ││ ┌┬──┤│ ┌┬──┬┐ ┌┬──┤│
                          ││  ││ ││  ││ ││ ││  ││ ││  ││ ││  ││
                          ││  ││ ││  ││ ││ ││  ││ ││  ││ ││  ││
                          ││  ││ ││  ││ ││ ││  ││ │├──┴┘ ││  ││
                          ││  ││ ││  ││ ││ ││  ││ ││     ││  ││
                          ││  ││ ││  ││ ││ ││  ││ ││  ┌┐ ││  ││
                          └┴──┤│ └┴──┴┘ └┘ └┴──┴┘ └┴──┴┘ └┴──┴┘
                              ││
                              ││
                      ┌┐      ││                    GoldED 2.50
                      └┴──────┴┘                    ───────────


                   ────────────────────────────────────────────────



                              Released October 8th, 1995


                                  Users Guide Manual


                     Program and manual written by Odinn Sorensen


            Copyright (C) 1990-1995 by Odinn Sorensen. All Rights Reserved










        ______________________________________________________________________

                                   Table of Contents
        ______________________________________________________________________


        1.  Notes About This Manual ........................................ 1

        2.  Legal Notes .................................................... 2

        3.  Entering Messages .............................................. 3

        4.  Userfile Considerations ........................................ 4

        5.  Using the Search Functions ..................................... 5

        6.  Using External Editors ......................................... 6

        7.  Quote Reflow ................................................... 8

        8.  Carbon Copy and Crossposting ................................... 9
            Carbon Copying ................................................. 9
            Crossposting ................................................... 9

        9.  Using the Tagline Support ..................................... 11

        10. Using the ISO 8859-1 ("Latin-1") charset ...................... 12

        11. Converting your highbit characters to ASCII ................... 13

        12. Encrypting Messages ........................................... 15

        13. Using the UUDECODE feature .................................... 16

        14. Nodelist Browse and Lookups ................................... 17

        15. User Database Lookup .......................................... 18

        16. Marking Messages .............................................. 19

        17. The File Request Feature ...................................... 20

        18. Using the Personal Mail Scan feature .......................... 21

        19. Using the Internet Features ................................... 23

        20. Using PGP as an External Utility .............................. 24

        21. Using the GIF Features ........................................ 26

        22. Using the QWK features ........................................ 27

        23. Using the SOUP features ....................................... 30

        24. Notes About Internet Character Translation .................... 36

        25. Sound Support in DOS - The Goldware Sound API ................. 39
        ______________________________________________________________________

        Table of Contents                           GoldED Users Guide, Page i


        26. Sound Support in the OS/2 Version ............................. 40

        27. Replacing DOS/4GW with PMODE/W in GoldED/386 .................. 41

        28. The Message Database Formats .................................. 42
            Opus/FTS1 (*.MSG) ............................................. 42
            Hudson ........................................................ 42
            Goldbase ...................................................... 43
            Squish ........................................................ 43
            Ezycom ........................................................ 44
            JAM ........................................................... 44
            PCBoard ....................................................... 44

        29. JAM Implementation Notes ...................................... 45
            General notes ................................................. 45
            File I/O checks ............................................... 45
            Message header revisions ...................................... 45
            Passwords ..................................................... 45
            Lastreads ..................................................... 46
            Size limits ................................................... 46
            ASCII 7-bit escaping .......................................... 46
            Date fields ................................................... 47
            Subfields ..................................................... 47
            Deleted msgs .................................................. 48
            Scanning files ................................................ 48

        30. PCBoard Implementation Notes .................................. 50
            Netmail ....................................................... 50
            Extended Headers .............................................. 50
            Long Names .................................................... 50
            Password ...................................................... 50
            Attributes .................................................... 50
            Double-Byte Characters (Foreign Systems) ...................... 51
            Message Index ................................................. 51
            Userbase ...................................................... 51

        31. Credits and Acknowledgements .................................. 52

        32. What YOU get when you register! ............................... 53
            Reminders disappear ........................................... 53
            The Plus! ..................................................... 53
            No "UNREG" watermark .......................................... 53
            Access to Alphas and Betas .................................... 53
            Happy author .................................................. 53
            License to use it ............................................. 53










        ______________________________________________________________________

        Table of Contents                          GoldED Users Guide, Page ii

        ______________________________________________________________________

                                Notes About This Manual
        ______________________________________________________________________


        The GoldED 2.50 Reference and Users Guide manuals are together the
        first "complete" manual since version 2.40 and it is long overdue,
        sorry. Well here it is at last - better late than never :-)

        The organization of this manual is not so good, sorry about that.

        If you find spelling, grammatical or factual errors, please let me
        know.

        If you think the wording is bad or confusing in some parts, please
        send me your improved version of the parts.

        If you would like to write entirely new chapters (especially for the
        Users Guide), please do and send them to me. Screen shots may be
        included, but should be edited to fit a 70 char wide page.

        I have limited time and would be very grateful for any help which can
        improve the quality and usefulness of the manual.

        TO TRANSLATORS: This manual is produced from ASCII text files with
        special codes and compiled to the release manual using a manual
        compiler I wrote myself. If you want to translate the GoldED manuals
        to any language, please contact me and I will make the raw uncompiled
        manual files and the manual compiler available to you.

        Odinn Sorensen, The GoldED Author.
























        ______________________________________________________________________

        Notes About This Manual                     GoldED Users Guide, Page 1

        ______________________________________________________________________

                                      Legal Notes
        ______________________________________________________________________


        Please read the file LICENSE.DOC for the complete shareware license
        agreement and limited warranty.
















































        ______________________________________________________________________

        Legal Notes                                 GoldED Users Guide, Page 2

        ______________________________________________________________________

                                   Entering Messages
        ______________________________________________________________________


        The process of entering a message deserves some description, because
        there are a number of steps that may be a bit hard to figure out
        directly.

        You start a message by using one the following commands:

          Key    Command keyword     Description

          Ins    READnewmsg          Start a blank new message.
          Alt-Q  READquotemsg        Quote-reply the current msg.
          Alt-G  READcommentmsg      Quote-reply the current msg to TO person.
          Alt-N  READmovequotemsg    Quote-reply in another area.
          Alt-B  READmovecommentmsg  Quote-reply in another area to TO person.
          Alt-R  READreplymsg        Reply to current msg, but don't quote.

        The first thing that happens is that the header display comes to life,
        and allows you to change the names and addresses of destination and
        origination. In netmail areas, the userlist lookup feature is in
        effect for the destination name field. You move around in the header
        with the arrowkeys. Pressing <Tab> or <Enter> moves to the next field.
        Pressing <Enter> in the subject field or <Ctrl-Enter> anywhere, ends
        the header editing. Pressing <Esc> drops the message. While editing
        the header, you can use the Alt-keys to toggle message attributes.

        After the header editing is done, a menu appears, allowing you to
        change the message attributes, origin, template, start the internal or
        external editor or quit it.

        When you select to start the editor, the template is processed and
        prepared for use.

        Safely back from the editor, you are presented with a menu where you
        can select to save the message, drop the message, continue editing,
        view the message, change origin or ROT13 crypt it.
















        ______________________________________________________________________

        Entering Messages                           GoldED Users Guide, Page 3

        ______________________________________________________________________

                                Userfile Considerations
        ______________________________________________________________________


        GoldED will by default always use the first entry in the userfile and
        the first lastread in the lastread file(s).

        In older versions GoldED would seek through the userfile for your name
        and use the lastread pointers that corresponded to the index of the
        userfile entry. This would normally work, but under some
        circumstances, GoldED might fail to find your name and therefore add
        you to the userfile. This could cause lastreads to suddenly appear to
        be reset to the first or last message in all areas.

        The solution of always using the first lastread is effective for
        single-user setups, but for users sharing the same msgbase using
        GoldED, each user MUST setup different user numbers if they want to
        keep their lastread pointers separate. These keywords are used to set
        the lastread pointer user number:

          EZYCOMUSERNO <number>
          FIDOUSERNO <number>
          GOLDBASEUSERNO <number>
          HUDSONUSERNO <number>
          PCBOARDUSERNO <number>
          SQUISHUSERNO <number>

        There is no JAMUSERNO, because the JAM format is cleverly designed
        to be independent of userfiles.

        The <number> defaults to 0 (zero). Set it to 1, 2, 3 etc. for each
        additional user that shares the same msgbase using GoldED.
        Alternatively, set <number> to -1 (minus one), which will tell GoldED
        to return to the old method of searching the userfiles to get the
        lastread indexes.



















        ______________________________________________________________________

        Userfile Considerations                     GoldED Users Guide, Page 4

        ______________________________________________________________________

                              Using the Search Functions
        ______________________________________________________________________


        The search function is activated using the Alt-F (header and body) or
        Alt-Z (header only) keys. This will bring up a popup entry field where
        you can enter several strings, separated by the '|' search string
        separator character like this:

          Odinn|GoldED

        By default, GoldED searches forward (next messages), but by preceeding
        the search string with a '-', the search goes backwards (previous
        messages).

        Besides the backward search, there are a number of other search
        command characters. Here is the complete list:

          -   Search backward.
          +   Search forward. (Just for completeness).
          <   Search the From: field.
          >   Search the To: field.
          :   Search the Subj: field.
          =   Case-sensitive search.
          !   Reverse - Stop/mark when the search string(s) are NOT found.

        By default the '<', '>' and ':' search commands are enabled, so that
        GoldED searches all header fields. However, when one of these options
        are actually used, the search is limited to those only.

        Examples:

          <Odinn      Searches in the From: field only.
          <>Odinn     Searches in From: and To:, but not Subj:.
          :tagline    Search for "tagline" in the Subj: field only.

        The search command characters are stripped before the search is
        started. If you need to search for a string that begins with a search
        command character, you must precede it with the search string
        separator, like this:

          -|++        Search for the string "++".

        All this also applies to the marking search function (Alt-S).










        ______________________________________________________________________

        Using the Search Functions                  GoldED Users Guide, Page 5

        ______________________________________________________________________

                                Using External Editors
        ______________________________________________________________________


        Like all message editors that allows the use of external text editors
        for writing messages, GoldED must deal with the problem of
        free-flowing text paragraphs versus hard-cr-terminated lines.

        Most text editors terminate *all* lines with a carriage return (CR,
        13d, 0Dh). Unless you use a fairly short right margin in the text
        editor, those lines can be very annoying to quote if the quotemargin
        is shorter. This usually results in "ragged" quotes, with a long
        quoteline alternating with a short leftover. This looks bad, and
        requires a lot of work to edit to a respectable shape.

        To solve this problem, GoldED treats the file from the text just as if
        text blocks doesn't have any hard-cr's in them - it "reflows" the
        text. Of course, this immediately creates another problem: If you
        include a cut from a log file, source code, table or other stuff that
        *requires* the text block to be aligned with itself. Those blocks
        would become scrambled and unreadable.

        GoldED recognizes a special control string, that tells the reflowing
        code to put hard-cr's on single lines or groups of lines. You define
        the string with the keyword "Hardline" in the configuration file. Here
        is an example of the use of the hardline string (in the example "<<"):

          <<
          ==== Log Cut ====
          + 22.24.31  Event 0-@
          - 22.24.42  Preparing outbound mail
          = 22.58.47  RING
          = 22.58.55  CONNECT 2400
          + 22.59.02  Incoming call at 2400 baud
          ==== Log Cut ====
          <<

        In this example, the hardline string on the lines before and after the
        cutting tells the reflower that all those lines must the hard-cr
        terminated. The hardline string must be the only characters on the
        line, and it must be placed on the *first* position. The reflow code
        looks for <string><cr>. The hardline string works as a "toggle".

        The hardline string also has another use: If you put the string as the
        last characters on a line, that line will also be hard-cr terminated.

        Example:

          Greetings...<<
            Odinn Sorensen<<

        The last << in this example was not really necessary, because a blank
        line always ends the preceding line or paragraph with a hard-cr. In
        any case, the hardline string is stripped off before the message is
        ______________________________________________________________________

        Using External Editors                      GoldED Users Guide, Page 6

        saved.

        Some lines are by definition always hard-cr terminated, and does not
        need hardline strings. Those lines are quoted lines and control lines
        such as kludges, tearlines and originlines. In addition, three
        identical characters at the beginning of a line also terminates the
        preceding paragraph.

















































        ______________________________________________________________________

        Using External Editors                      GoldED Users Guide, Page 7

        ______________________________________________________________________

                                     Quote Reflow
        ______________________________________________________________________


        When you quote a message that already contains quoted lines, those
        lines may be too long for your quotemargin. Most message editors would
        then just cut a bit off the end and put it on a line below. GoldED
        does it differently - it determines the quotestring of the line, and
        then "reflows" all the following lines with the same quotestring and
        puts the quotestring back on the reflowed lines. This usually works
        great and looks good. It can also fail miserably in some
        circumstances.

        The reflowing is in effect in both the message displaying and in
        quoting. If you want to observe the effects, try executing the
        READdecreasemargin or READincreasemargin commands (they don't have any
        default key assignments though).





































        ______________________________________________________________________

        Quote Reflow                                GoldED Users Guide, Page 8

        ______________________________________________________________________

                             Carbon Copy and Crossposting
        ______________________________________________________________________


        Carbon Copying

        Carbon copy (CC) is a way to send the same message to a number of
        people without the trouble of manually entering and copying a message
        for each of them. The CC works only in netmail or local areas. You can
        send any message, including fileattaches (in netmail) with the CC
        function.

        Carbon copies are created by putting the string "CC:" followed by one
        or more names or addresses, separated by commas, on one or more lines
        at the beginning of the message. The names and addresses must follow
        the same rules as when using the lookup function in the netmail
        header.

        Example:

          CC: 16, Joergensen, #236/512

        If you put a "#" in front of a name or address, that node will be left
        out of the list, but will still receive a carbon copy.

        You can also use address macros (see the NAMESFILE keyword) instead of
        names or addresses.

        If you often send carbon copies to the same people, it can get a bit
        tedious to type (and remember) every time. Therefore you can also
        specify a file with the names and addresses:

          CC: @TESTERS.LST

        Files names and addresses can be mixed on the same line. The lines in
        the file must be the same format as above. No nesting is allowed: You
        can't specify files within files.

        When you save the CC message, GoldED will scan the message text to
        find and process the CC: lines. When this is done, a menu will pop up
        and allow you change the format of the CC: lines, the attributes of
        the CC messages or drop the copies.

        When processing the CC list, GoldED will check each node in the
        nodelist and pop up the nodelist browser in case of more than one
        match or if the node was not found.


        Crossposting

        Crosspost is similar to Carbon Copy, except that instead of sending
        copies to a list of persons, it posts copies of a message in several
        different conferences. Typical usage is announcement of files, vital
        BBS information and other general interest info.
        ______________________________________________________________________

        Carbon Copy and Crossposting                GoldED Users Guide, Page 9


        To crosspost a message is simple - just add lines in this format:

          XC: <echoid> [echoid] [..]

        The "XC:" must be the first three characters on the line. The <echoid>
        must be valid echoid's defined in GoldED. Example:

          XC: GOLDED, NEWFILES_R23.PRO, ENET.SOFT

        This would produce the following output in the message:

          * Crossposted in GOLDED
          * Crossposted in NEWFILES_R23.PRO
          * Crossposted in ENET.SOFT

        And post it in the conferences.

        Please moderate your use of this feature - it adds duplicate
        information to the mail flow, and excessive use may be frowned upon by
        cost-sensitive individuals.

        TIP: If you want to keep copies of your messages in a separate
        "outbox" echo, add this line to your message template(s):

          xc: #@cecho, #outbox

        This will automatically crosspost your msg to the OUTBOX area (you
        must define or have an area with that echoid). The '#' tells GoldED
        that you don't want the crosspost to be noted in the msgs. The
        "@cecho" is a template token which is replaced with the current
        echoid.

        The only drawback to this tip is that there is no way to see what area
        the original msg was posted in when looking at the msgs in the OUTBOX
        area.




















        ______________________________________________________________________

        Carbon Copy and Crossposting               GoldED Users Guide, Page 10

        ______________________________________________________________________

                               Using the Tagline Support
        ______________________________________________________________________


        GoldED directly supports the popular taglines, which look something
        like this in messages:

          ... tagline
          --- GoldED 2.50
           * Origin: whatever (2:236/77)

        Taglines are usually one-liner jokes or wisdom or whatever. They serve
        absolutely no technical function and are considered by some to be
        waste of diskspace and modem time. In some conferences, they may even
        be forbidden by the moderator, so if you want to use this feature,
        check the conference rules first!

        The tagline support in GoldED is currently not very advanced. You can
        define some global taglines and manually select them from a menu, like
        you can with origins. Taglines can also be defined in random system
        groups, where they will be chosen randomly. For those with existing
        tagline collections, you can specify the filename of the tagline
        collection. Then a random tagline will be picked from the collection.

        Taglines in messages are detected and displayed in a different color
        (definable with COLOR READER TAGLINE).

        Here are the keywords for tagline support:

          TAGLINE <text> or @<filename>     Defines a tagline or file
          TAGLINECHAR <char>                Defines the tagline character
          TAGLINESUPPORT <yes/no>           Disable internal tagline support.

        If you define taglines globally, GoldED automatically adds extra menu
        items to the EDITMENU and EDITSAVEMENU, to allow you to manually
        select the tagline either before entering a message or when saving it.

        Like for origins, it is also possible to change the default tagline by
        using the READchangetagline command. Default key assignment is Ctrl-I.
        Example for GOLDKEYS.CFG:

          ^I  READchangetagline

        Future plans for the tagline function include: Command to "steal"
        taglines. Tagline collection file browser. Tagline "filters". Please
        note, however, that tagline features are generally low priority. So
        don't hold your breath.







        ______________________________________________________________________

        Using the Tagline Support                  GoldED Users Guide, Page 11

        ______________________________________________________________________

                       Using the ISO 8859-1 ("Latin-1") charset
        ______________________________________________________________________


        This chapter describes how to setup GoldED to use the ISO 8859-1
        character set in all or selected mail areas.

        The ISO 8859-1 character set seems to be the preferred standard for
        accented (highbit) characters in the Internet. It is also basically
        the same character set used in MS-Windows (code page 1252) and the
        Amiga.

        Add the following lines to the Random System groups you want to setup
        charset translation for. They can also be used globally in the main
        configuration if you want to ISO 8859-1 to be the default character
        set for all your mail areas.

          XLATIMPORT LATIN-1
          XLATEXPORT LATIN-1

        XLATIMPORT/EXPORT are used to translate characters to and from the IBM
        PC 8-bit (above ASCII) character set.

        The following lines need to be added to the main configuration:

          XLATPATH <path to the .CHS files>

        If your codepage is CP437 or CP865, use these two:

          XLATCHARSET IBMPC     LATIN-1   IBM_ISO.CHS
          XLATCHARSET LATIN-1   IBMPC     ISO_IBM.CHS

        Or if your codepage is CP850, use these three:

          XLATCHARSET CP850     LATIN-1   850_ISO.CHS
          XLATCHARSET LATIN-1   CP850     ISO_850.CHS
          XLATLOCALSET CP850

        The two .CHS files must be present in the XLATPATH. You can find them
        in the XLAT archive inside the advanced setup archive.

        GoldED will put a kludge "^aCHRS LATIN-1 2" or "^aCHARSET LATIN-1 2"
        into your messages so that other mail readers can translate to their
        native character set if necessary.

        That's it.








        ______________________________________________________________________

        Using the ISO 8859-1 ("Latin-1") charset   GoldED Users Guide, Page 12

        ______________________________________________________________________

                      Converting your highbit characters to ASCII
        ______________________________________________________________________


        If a conference moderator or network policy forbids the use of highbit
        characters such as your national accented letters, you must configure
        GoldED so that these characters are converted to acceptable ASCII.
        Fortunately there are at least three ways of doing this with GoldED.

        Let's say that you want to convert the characters Æ¥Åæ¢å (the most
        commonly used Danish national characters in codepages 865 and 850).

        You can convert the characters using EDITmacros by putting these lines
        in the GOLDKEYS.CFG file:

          Æ   EDITmacro "AE"
          ¥   EDITmacro "OE"
          Å   EDITmacro "AA"
          æ   EDITmacro "ae"
          ¢   EDITmacro "oe"
          å   EDITmacro "aa"

        An alternative way of doing this is by using the EDITCOMPLETION
        keyword like this in GOLDED.CFG:

          EDITCOMPLETION "Æ" "AE"
          EDITCOMPLETION "¥" "OE"
          EDITCOMPLETION "Å" "AA"
          EDITCOMPLETION "æ" "ae"
          EDITCOMPLETION "¢" "oe"
          EDITCOMPLETION "å" "aa"

        If you use one of these two methods to convert your highbit
        characters, that's it. There is no way to switch it to allow the
        highbit characters in some areas.

        The best method to convert characters is by using the character
        translation system and enabling it in just those areas where it is
        required. Setting this up is a bit more elaborate. When the character
        translation system is in effect, you simply enter your message using
        your national highbit characters. Then when you save the message,
        GoldED automatically converts it to ASCII.

        Add these lines in GOLDED.CFG:

          XLATPATH <path where IBM_ASC.CHS can be found>
          XLATCHARSET IBMPC ASCII IBM_ASC.CHS

        And add this line either globally in GOLDED.CFG or in specific groups
        in the random system:

          XLATEXPORT ASCII

        The IBM_ASC.CHS file can be found in the XLAT.ZIP archive within the
        ______________________________________________________________________

        Converting your highbit characters to ASCIIGoldED Users Guide, Page 13

        manual and advanced cfg archive.

        It should be noted that the IBM_ASC.CHS translation table converts
        from codepage 437 (actually 865) to ASCII. If your normal codepage is
        850, you should use the following XLATCHARSET instead:

          XLATCHARSET CP850 ASCII 850_ASC.CHS

        You will also need this line:

          XLATLOCALSET CP850

        The XLATLOCALSET keyword tells GoldED which codepage your computer is
        configured to use.










































        ______________________________________________________________________

        Converting your highbit characters to ASCIIGoldED Users Guide, Page 14

        ______________________________________________________________________

                                  Encrypting Messages
        ______________________________________________________________________


        GoldED allows you to en/decrypt messages encoded with the ROT13
        encryption method. ROT13 is very simple: It just swaps the letters
        "A-M", "a-m" with "N-Z", "n-z" and vice-versa.

        ROT13 is mostly used in Internet newsgroups where it is used as a
        "spoiler warning", so that game solutions, joke punchlines and other
        stuff is not read by accident. In those networks, most message readers
        have ROT13 de/crypting capabilities.

        In FidoNet, not all message readers have ROT13 capability, and the
        current policy (Policy 4) states:

            2.1.4  Encryption and Review of Mail

            FidoNet is an amateur system. Our technology is such that the
            privacy of messages cannot be guaranteed. As a sysop, you have the
            right to review traffic flowing through your system, if for no
            other reason than to ensure that the system is not being used for
            illegal or commercial purposes. Encryption obviously makes this
            review impossible. Therefore, encrypted and/or commercial traffic
            that is routed without the express permission of all the links in
            the delivery system constitutes annoying behavior.

        You will be able to encrypt your messages with ROT13, but you should
        not use the crypting facility of GoldED, unless your network allows
        it, and *never* in international echoes.

        See also the chapter about how to setup GoldED with PGP.






















        ______________________________________________________________________

        Encrypting Messages                        GoldED Users Guide, Page 15

        ______________________________________________________________________

                              Using the UUDECODE feature
        ______________________________________________________________________


        GoldED contains a built-in uudecode feature. It is keycommand
        READuudecode, which defaults to Ctrl-X.

        The uudecoder in GoldED is based on (but heavily modified from) some
        very old ('88), but good, C source (available as UUENUUDE.ZIP on my
        system), which claims to be based on the Berkeley original.

        No error checking is done during the uudecode.

        GoldED currently cannot handle uuencoded data which is split in
        multiple sections and/or multiple messages.







































        ______________________________________________________________________

        Using the UUDECODE feature                 GoldED Users Guide, Page 16

        ______________________________________________________________________

                              Nodelist Browse and Lookups
        ______________________________________________________________________


        When you write a netmail message, you must know the name and net
        address of the recipient. Unless you have a remarkable memory, this
        information can be a bit hard to remember. Therefore GoldED supports
        several different nodelist indexes: GoldNODE (a proprietary format),
        FrontDoor, Version 7 and FIDOUSER.LST.

        When you enter a name or address in the header (the TO: field) and
        press <Enter>, GoldED looks in the nodelist index to find the missing
        data. You can enter the address in the name field. Names to be
        searched for must be entered last name first (because of the way the
        index is structured). If you enter a partial name or address, GoldED
        will find the closest match. Addresses can be entered in short form,
        based on the current AKA, like .3 for the address of your third Point,
        or 33 for node 33 in your net.

        Before the nodelist is searched, the list of address macros are first
        scanned, and if a match is found there, the information there is used
        instead.

        When GoldED has found a match, it looks a bit further to see if there
        are more matches. If not, the matching data is inserted in the header,
        and you can continue editing. If more than one match was found, it
        starts the nodelist browser. Here you can browse around and find the
        correct destination node. When found, you select it with <Enter>. The
        full name and address of the node you selected is then placed in the
        appropriate fields in the header. Pressing <Esc> in the browser quits
        it without inserting any node information. While in the browser, you
        can press <Tab> to switch between name and address lookup.

        The list of nodes in the browser is sorted differently, according to
        what you entered. If you entered a name, the list is sorted
        alphabetically by last name. If you entered an address, the list is
        sorted ascending by address.

        The nodelist browser can also be accessed in other ways. The keys F10
        and Shift-F10 brings up the browser at the FROM and TO names (nodes)
        respectively, to let you inspect their nodelist data. It's quite
        handy, you will wonder how you could do without it - I did :-)

        The nodelist lookup feature can also be used when in the internal
        editor, but an even more useful key is available there. By pressing
        Alt-L, the browser will pop up for the name or address at the editor
        cursor position!







        ______________________________________________________________________

        Nodelist Browse and Lookups                GoldED Users Guide, Page 17

        ______________________________________________________________________

                                 User Database Lookup
        ______________________________________________________________________


        GoldEd has a special user database lookup feature for BBS sysops.

        In Hudson, Ezycom, Squish (and *.MSG, if you are using Maximus) type
        areas, GoldED can perform an additional type of name lookup, using
        wildcards.

        This form of lookup is triggered by using DOS/4DOS-style wildcard
        characters in the name you want to lookup. Examples:

          To: Joe*    Finds any name beginning with "Joe".
          To: *Blow   Finds any name ending with "Blow".
          To: Od?n*   Finds "Odinn", "Oden" etc.

        Depending on the size of your user database and the speed of your
        computer, the lookup may take a little while.

        As currently implemented, this user database lookup is only good for
        simple one-shot lookups - you can't bring up a browser to pick the
        user, or see his/hers other user data.































        ______________________________________________________________________

        User Database Lookup                       GoldED Users Guide, Page 18

        ______________________________________________________________________

                                   Marking Messages
        ______________________________________________________________________


        GoldED has a message marking system, which allows flexible
        manipulation with selected messages.

        You can either mark messages manually one by one using the
        READtogglemark command <Space>, or use the READmarkingoptions menu
        <Alt-S>. With the marking menu, you can for example mark all messages
        in a particular thread (replychain), or all messages that match a
        certain string or a number of other criteria.

        When you have marked the messages, you can then Copy, Move, Delete or
        Write them. Or you can switch to reading only the marked messages.

        The marks stay in position until removed (unmarked) or you exit
        GoldED. Marks are kept even if you leave the current area and do
        business in another for a while.

        Another, more volatile, form of mark is the "bookmark". Bookmarks can
        be used for returning to a certain position after a stroll out a long
        reply chain and stuff like that. There is only one bookmark, and it is
        reset when you leave the area. Using the Find function leaves a
        bookmark at the current message.





























        ______________________________________________________________________

        Marking Messages                           GoldED Users Guide, Page 19

        ______________________________________________________________________

                               The File Request Feature
        ______________________________________________________________________


        Often when you see a msg where new files are announced, you wish you
        could simply press a key and select files to request. Well, with
        GoldED you can!

        The file request function (default key Ctrl-F) will scan the current
        message and present you with a list of the requestable files it found.
        GoldED will even show the file descriptions if it can find one.

        You select the files by toggling marks with the Space key. A '+' will
        show in front of the selected files. The selections can be discarded
        by pressing Esc. When done with the selections, press Enter to
        continue.

        Now the destination area must be selected from the list. You have to
        pick a netmail area of the *.MSG type, since the Hudson and Squish
        netmail areas are currently not supported by most mailers today.

        After selecting the area, check that the header data (TO name etc) is
        correct. You can now go on to perhaps write a thank you note in the
        accompanying msg, or you can save (empty) your msg immediately (if you
        have the EDITMENU keyword set to Yes).

        At the moment you start editing the header, the filenames and
        descriptions are written to a FILES.BBS in the INBOUNDPATH. This can
        be very helpful if you are getting files for your own BBS and are
        tired of inventing or finding descriptions for all those files.. The
        fact that the FILES.BBS is written to disk before you even save you
        msg, can be used to get "free" descriptions later from the response
        msgs some mailers send back when you do a file request.

        There are currently a couple of limitations in the file request
        function:

        *   You can only request as many files as can fit in the subject line
            of one msg.

        *   GoldED recognizes several different types of file announcement
            formats, but some may not be fully supported. This means that
            legitimate descriptions may not be found by GoldED, or that some
            files are not recognized as requestable.

        *   If a msg does not conform to a known announcement format, it is
            instead (actually it is _also_) scanned for a number of standard
            archive extensions. These extensions are configurable with the
            FRQEXT keyword, which comes pre-defined with many common file
            extensions. Only one such file per line can be found by GoldED,
            and only if it is "straight" - no spaces between name and
            extension, and no "funny" characters in the filename. The
            description is simply the rest of the line.

        ______________________________________________________________________

        The File Request Feature                   GoldED Users Guide, Page 20

        ______________________________________________________________________

                         Using the Personal Mail Scan feature
        ______________________________________________________________________


        GoldED can scan for your personal mail (messages addressed to the name
        defined with the USERNAME keyword).

        NOTE: Personal mail scan is a very new feature in GoldED (introduced
        in 2.50.Beta4) and is likely to have plenty of rough edges, quirks and
        bugs. The current implementation is not set in stone. Please give me
        your comments on any problems or suggestions for improvements.

        The personal mail scan feature can be activated in two different ways:

        1.  Manually from the arealist using the personal mail scan menu on
            Alt-P (keycommand AREAscanpm). The menu contains the same items
            as the regular Alt-S scanning menu. Here you can scan all, marked,
            current, matching or unscanned areas for personal mail.

        2.  Automatically using the PERSONALMAIL keyword with the Startup
            parameter.

        If personal mail scan is activated from the menu in the arealist, then
        when the scan is completed, GoldED shows a window with a simple
        statistic about the personal mail (xx mails found in yy areas). The
        window will go away after a few seconds or by pressing a key.

        Areas with personal mail will be marked with a '+' after the message
        count in the Msgs column. In the statusline, the exact number of
        personal mails is shown for each area when you move the selection bar.

        To remove the personal mail mark from an area without reading the
        mail, re-scan the area with the normal area scan (Alt-S).

        To read personal mail, simply enter an area marked '+'. GoldED will
        automatically switch to "Read Marked" mode so that you only read the
        personal mail. When you exit the area after reading your mail, GoldED
        remembers the original lastread and sets it back where it was (this
        will only work when in Read Marked mode with personal mail).

        You can automatically sort areas with personal mail to the top of the
        arealist by adding the sort spec 'P' in front of your current
        AREALISTSORT string. Example: AREALISTSORT PTUE.

        Only messages after the lastread are scanned. The scan ignores
        messages that are marked received.

        The keywords AREAPMSCAN, AREAPMSCANEXCL and AREAPMSCANINCL work for
        personal mail like the AREASCAN, AREASCANEXCL and AREASCANINCL do for
        normal mail scans.

        The PERSONALMAIL keyword specifies options for the personal mail scan
        feature. With it you can tell GoldED to automatically scan for
        personal mail at startup and to look for mail to all your USERNAMES
        ______________________________________________________________________

        Using the Personal Mail Scan feature       GoldED Users Guide, Page 21

        (if you have more than one spelling of your name for example).

        Personal mail scan is currently only implemented for the JAM, Squish,
        Hudson, Goldbase and PCBoard msgbase formats. Personal mail scan
        support for *.MSG and Ezycom will be added in a future release.



















































        ______________________________________________________________________

        Using the Personal Mail Scan feature       GoldED Users Guide, Page 22

        ______________________________________________________________________

                              Using the Internet Features
        ______________________________________________________________________


        This chapter (which is not complete!) discusses how to use the
        Internet compatibility features in GoldED, implementation details,
        limitations etc.

        See also the "Using the SOUP feature" chapter.

        If you access Internet via a gateware running the GIGO gate program,
        you should ensure that the gate operator has the following lines in
        the GIGO HEADERS.CFG file:

        Allow_To:
        Allow_From:
        Allow_Newsgroups:
        Allow_Subject:
        Allow_Date:
        Allow_Message-ID:
        Allow_References:
        Allow_In-Reply-To:
        Allow_Organization:
        Allow_MIME-Version:
        Allow_Content-Type:
        Allow_Content-Transfer-Encoding:
        Allow_Sender:
        Allow_X-Newsreader:
        Allow_X-Mailreader:
        Allow_X-To:

        These are the Internet RFC header control lines that GoldED can put in
        your messages if you set INTERNETRFCBODY YES in your GoldED setup for
        your Internet areas.

        <chapter not completed yet>


















        ______________________________________________________________________

        Using the Internet Features                GoldED Users Guide, Page 23

        ______________________________________________________________________

                           Using PGP as an External Utility
        ______________________________________________________________________


        This chapter describes how to can install PGP as an external utility
        in the GoldED setup. The examples assume that PGP 2.3 or higher is
        installed in the directory C:\PGP.


        Add the following to your GOLDED.CFG:

          --- Cut ---
          EXTERNUTIL 1 -nokeepctrl -wipe c:\pgp\pgp.exe +force -sa @tmpfile -u
                       "@oname" -o @file
          EXTERNUTIL 2 -nokeepctrl -wipe c:\pgp\pgp.exe +force -sta
                       +clearsig=on @tmpfile -u "@oname" -o @file
          EXTERNUTIL 3 -nokeepctrl -wipe c:\pgp\pgp.exe +force -ea @tmpfile
                       "@dname" "@oname" -u "@oname" -o @file
          EXTERNUTIL 4 -nokeepctrl -wipe c:\pgp\pgp.exe +force -eas @tmpfile
                       "@dname" "@oname" -u "@oname" -o @file
          EXTERNUTIL 5 -nokeepctrl -wipe c:\pgp\pgp.exe +force @tmpfile -o
                        @file -u "@dname"
          EXTERNUTIL 6 -noreload c:\pgp\pgp.exe +force -ka @file -u "@dname"
          EDITSAVEMENU Yes
          EDITSAVEUTIL 1 "S PGP Sign the msg"
          EDITSAVEUTIL 2 "l PGP Clear-Sign the msg"
          EDITSAVEUTIL 3 "E PGP Encrypt the msg"
          EDITSAVEUTIL 4 "p PGP Encrypt & Sign the msg"
          EXTERNOPTIONS -Pause
          --- Cut ---

        NOTE: Some of the configuration lines were split in two due to the
        document margin. They must of course be on one line in the actual
        GOLDED.CFG.


        Add the following to your GOLDKEYS.CFG:

          --- Cut ---
          F11   ExternUtil03    ; F11       -> Encrypt message
          F12   ExternUtil05    ; F12       -> Decrypt message
          #F12  ExternUtil06    ; Shift-F12 -> Add public key to keyring
          --- Cut ---

        You need to have KEYBEXT Yes (the default) in GOLDED.CFG if you want
        to use the F11/F12 keys. You can of course assign other keys, just
        make sure they don't clash with already defined keys.

        The PGP commandlines are set up for multiple recipients, the TO: name
        and your own FROM: name. Otherwise you would not be able to decrypt
        your own msgs, and that could get a bit unpractical ;-)

        HOW TO USE IT:

        ______________________________________________________________________

        Using PGP as an External Utility           GoldED Users Guide, Page 24

        To sign, clearsign or encrypt a msg, simply select the appropriate
        menu item in the save menu. Another method is described below.

        To decrypt an encrypted msg, Press F12 while viewing the msg in the
        reader. After decryption, you can write the msg to disk/printer, reply
        to it, copy it, etc. The decrypted text will revert as soon as you
        move away from the msg, or after you perform any operation on it. To
        make a decrypted msg permanent (saved to disk in decrypted form), use
        the Change Msg command after decryption and then save the msg
        immediately, or use the copy function if you want to keep the original
        untouched..

        One thing to be aware of, is that the encrypted msg text does NOT
        contain kludges if it was encrypted from the EDITSAVEMENU. If you make
        such a text permanent, you would loose the kludges. Currently the only
        way to keep kludges in the encrypted text is to encrypt it "manually"
        after saving it, using F11, Change Msg, save immediately. If you do it
        this way, you should be careful in a multitask/network environment,
        where a mail scanner could scan out the unencrypted msg before you get
        a chance to encrypt it... I plan to fix this problem in a future
        release.



































        ______________________________________________________________________

        Using PGP as an External Utility           GoldED Users Guide, Page 25

        ______________________________________________________________________

                                Using the GIF Features
        ______________________________________________________________________


        This chapter discusses how to use the GIF features in GoldED.

        If the GIF kludge is found in a msg, the @gif token is filled with the
        filename from the GIF kludge. You can setup an external utility to
        view the GIF (if you have the file) like this:

          (In GOLDED.CFG:)
          EXTERNUTIL XX c:\utl\vpic.exe @gif

          (In GOLDKEYS.CFG:)
          key ExternUtilXX

        If the GIF kludge is found, the text "[GIF:filename]" is added in the
        lower-right corner of the header display so that you know that it is
        there without looking in the kludges.

        If you don't have the GIF, you can file request it by hitting Ctrl-F
        (the READfilerequest command).

        A note about the @gif token: It is replaced by the filename from the
        GIF kludge, if any. If a GIFPATH is defined, the path is prepended to
        the filename. A file extension is NOT added. This is so that you can
        convert the .GIF's to a smaller format with a different extension.

          Example: EXTERNUTIL XX c:\utl\vpic.exe @gif.jpg

        You can configure GoldED so that it inserts the GIF kludge in your own
        messages. See the GIF keyword for details.

        NOTE: The GIF kludge is not in wide use, and there is a very real
        possibility that some people might be annoyed about "yet another
        useless kludge" which increases the size of msgs (not much, max 16
        bytes). So I recommmend that you only use it in a few echoes and
        perhaps in netmail, if at all. It might be a good idea to ask the
        moderator of an echo before starting to use it in that echo. Use the
        GIF keyword in Random System groups instead of globally. See also the
        Message Kludge Lines chapter for information about the kludge.

        Planned:

        *   A specific GIFVIEWER keyword and READgifviewer command instead of
            having to use the external utility feature. GIFVIEWER would work
            like EDITOR and SPELLCHECKER - there will not be a built-in
            viewer.

        *   A menu to select the GIF just like origins etc.




        ______________________________________________________________________

        Using the GIF Features                     GoldED Users Guide, Page 26

        ______________________________________________________________________

                                Using the QWK features
        ______________________________________________________________________


        GoldED supports import and export of the QWK offline packet format for
        BBS conferences and Internet e-mail and newsgroups. Using this
        feature, you can use GoldED as QWK offline reader.

        A QWK packet consists of the files CONTROL.DAT, MESSAGES.DAT and
        possibly a number of other files. GoldED uses only the two files
        mentioned, other files are ignored.

        A QWK reply packet generated by GoldED consists of the file
        <BBSID>.MSG, which contains the messages that you wrote with GoldED.
        <BBSID> is the QWK BBS identification name of the BBS you use.

        GoldED currently doesn't support unpacking and packing of compressed
        .QWK and .REP packets. You must unpack and pack your QWK/REP packets
        manually or using a batchfile.

        When exporting message to QWK reply packetfiles, GoldED will
        *overwrite* any existing reply packet (<BBSID>.MSG), so you should not
        export until you are actually ready to upload your packet.

        After processing the CONTROL.DAT file, GoldED writes a file named
        <BBSID>.GLD in the GOLDPATH. The file is used by GoldED to store the
        relationship between conference numbers and conference names, for use
        when later replying or entering new messages. For QWK export to work,
        you must have previously imported a QWK packet so that the <BBSID>.GLD
        file is created.

        The QWK import/export features are currently activated from a submenu
        the arealist scan menu (Alt-S). The submenu item is only present if
        QWKIMPORTPATH and/or QWKEXPORTPATH is defined.

        Below are the keywords that are relevant for the QWK support as
        currently implemented:

          QWKIMPORTPATH <path>
              Path where incoming QWK packet files (CONTROL.DAT and
              MESSAGES.DAT) can be found.

          QWKEXPORTPATH <path>
              Path where outgoing QWK reply files (BBSID.MSG) can be placed.

          QWKBADMSGS <echoid>
              Specifies the area where messages in unknown conferences are
              put. If you get messages tossed here by accident, you must move
              them manually to the correct area. If the badmsgs area is not
              defined, the messages will silently disappear. Messages tossed
              to the badmsgs area will have the control line
              "AREA:<bbsid>_<confno>" at the top of the message.

          QWKCONFMAP <bbsid> ["]<confname>["] <echoid>
        ______________________________________________________________________

        Using the QWK features                     GoldED Users Guide, Page 27

              Defines the mapping between the BBSID and conference names in
              the QWK packets and the echoid name of the conference as
              required by GoldED. You MUST define a mapping for every
              conference that you subscribe to. If you don't, the messages
              will be tossed to the area defined by QWKBADMSGS or disappear.
              The <bbsid> is the name listed on line 5 in CONTROL.DAT after
              the comma. The <confname> is the conference names listed on line
              13 and on alternate lines onwards in CONTROL.DAT. If a
              conference name contains embedded spaces, the <confname> must be
              enclosed in double quotes, like this: "Main Board". The area
               <echoid> must be already defined either in an AREAFILE or using
               the AREADEF or AREA keywords.

          QWKTOSSLOG <file>
              Name of a file where GoldED puts the echoids of each area where
              articles have been imported. The tosslog file is intended to be
              used with a replylinker. If no path is given, it defaults to the
              GOLDPATH.

          QWKREPLYLINKER <cmd>
              Commandline for a replylinker program to call after QWK import.

          QWKOPTIONS <bbsid> <options>
              Defines various options for the QWK support.

          INTERNETRFCBODY <yes/no>
              Enable this in areas with Internet RFC headerlines at the top of
              messages. See the "Using the SOUP features" chapter for details.

          CTRLINFO <tearline/origin/no>
              Enables or disables tearline and/or origin in random system
              groups.

        In areas where INTERNETRFCBODY is enabled, or RFC headers are present
        as FTN kludges, GoldED will convert the RFC headers Message-ID,
        References and In-Reply-To to MSGID and REPLY kludges, so that
        MSGID/REPLY replylinkers can be used instead of dumb subject linkers.
        GoldED will also get the full-length To/From/Subject lines and store
        them in the messages instead of the short 25 character QWK fields.
        Finally if the INTERNETGATE keyword is defined, GoldED will add the
        FSC-35 kludges REPLYTO and REPLYADDR in the messages.

        Example setup in GOLDED.CFG:
        (for Internet setup, see also the SOUP chapter).

          // Basic QWK setup
          QWKIMPORTPATH C:\QWK\
          QWKEXPORTPATH C:\QWK\
          QWKBADMSGS BAD_QWK

          // Replylinking when using GEcho and Hudson areas:
          QWKTOSSLOG     C:\GECHO\IMPORT.HMB
          QWKREPLYLINKER C:\GECHO\MBUTIL Link

          // Replylinking when using GEcho and JAM areas:
          QWKTOSSLOG     C:\GECHO\IMPORT.JAM
        ______________________________________________________________________

        Using the QWK features                     GoldED Users Guide, Page 28

          QWKREPLYLINKER C:\GECHO\MBUTIL Link

          // Replylinking when using Squish and Squish areas:
          QWKTOSSLOG     C:\SQUISH\QWKTOSS.LOG
          QWKREPLYLINKER C:\SQUISH\SQUISH LINK -fC:\SQUISH\QWKTOSS.LOG

          // QWK conference mapping
          QWKCONFMAP GOLDWARE GoldED GOLDED
          QWKCONFMAP GOLDWARE "GoldED Beta" GOLDED.BETA
          QWKCONFMAP GOLDWARE "BBS Users" BBS.USERS
          QWKCONFMAP WHOKNOWS EMail EMAIL
          QWKCONFMAP WHOKNOWS dk.chat DK.CHAT
          QWKCONFMAP WHOKNOWS dk.test DK.TEST

          // Area definitions for the QWK conferences
          AREADEF BAD_QWK "Bad QWK msgs" 0 Echo Opus C:\QWK\CONF\BADQWK
          AREADEF GOLDED "GoldED support" 0 Echo JAM C:\QWK\CONF\GOLDED
          AREADEF GOLDED.BETA "GoldED beta" 0 Echo JAM C:\QWK\CONF\GOLDBETA
          AREADEF BBS.USERS "BBS Users" 0 Echo JAM C:\QWK\CONF\BBSUSERS
          AREADEF EMAIL "E-Mail" 0 EMail Opus C:\QWK\CONF\EMAIL
          AREADEF DK.CHAT "dk.chat" 0 News JAM C:\QWK\CONF\DKCHAT
          AREADEF DK.TEST "dk.test" 0 News JAM C:\QWK\CONF\DKTEST

          // Group for the EMAIL area
          GROUP EMAIL
            CTRLINFO        NO
            EDITHARDTERM    YES
            TEMPLATE        INTERNET.TPL
            INTERNETADDRESS [e-mail]
            INTERNETMSGID   YES
            INTERNETRFCBODY YES
          ENDGROUP

          // Group for the Internet newsgroups
          GROUP Newsgroups:
            MEMBER          dk.*
            CTRLINFO        NO
            EDITHARDTERM    YES
            INTERNETADDRESS [e-mail]
            INTERNETMSGID   YES
            INTERNETRFCBODY YES
            QUOTECHARS      ":;|"
            TEMPLATE        INTERNET.TPL
            WHOTO           All
          ENDGROUP


        Planned QWK features:

        * Support for BlueWave and perhaps other offline packet formats.
        * Support for compressed .QWK and .REP packets.
        * Built-in replylinker.
        * Your suggestions :-)



        ______________________________________________________________________

        Using the QWK features                     GoldED Users Guide, Page 29

        ______________________________________________________________________

                                Using the SOUP features
        ______________________________________________________________________


        GoldED supports import and export of the Internet SOUP packet format
        for e-mail and newsgroups. Using this feature, you can use GoldED as
        an offline reader for Internet. The SOUP packet format, version 1.2,
        is documented in the SOUP12.DOC document by Rhys Weatherley
        <[e-mail]>.

        A SOUP packet consist of a number of packet files with an extension of
        .MSG plus an AREAS file which tells where each .MSG packet belongs.
        Other files may be found in a SOUP packet, but they are not supported.

        A SOUP reply packet generated by GoldED consists of a GOLDMAIL.MSG
        packet file for e-mail and/or a GOLDNEWS.MSG packet file for
        newsgroups plus a REPLIES file which lists the .MSG packets.

        The SOUP import/export features are currently activated from a submenu
        the arealist scan menu (Alt-S). The submenu item is only present if
        SOUPIMPORTPATH and/or SOUPEXPORTPATH is defined.

        Below are the keywords that are relevant for the SOUP support as
        currently implemented:

          SOUPIMPORTPATH <path>
              Path where incoming SOUP packet files (AREAS and *.MSG) can be
              found.

          SOUPEXPORTPATH <path>
              Path where outgoing SOUP reply packet files (REPLIES and
              GOLD*.MSG) can be placed.

          SOUPEMAIL <echoid>
              Specifies the area where e-mails are placed.

          SOUPBADMSGS <echoid>
              Specifies the area where articles in unknown newsgroups are put.
              If you get articles tossed here by accident, you must move them
              manually to the correct area. If the badmsgs area is not
              defined, the articles will silently disappear.

          SOUPNEWSRCFILE <file>
              Name with full path of the NEWSRC file which lists the
              newsgroups you are connected to. GoldED uses the list to mark
              the matching areas as newsgroups. These will then be scanned for
              outgoing mail when starting a SOUP export.

          SOUPTOSSLOG <file>
              Name of a file where GoldED puts the echoids (newsgroup names)
              of each area where articles have been imported. The tosslog file
              is intended to be used with a replylinker. If no path is given,
              it defaults to the GOLDPATH.

        ______________________________________________________________________

        Using the SOUP features                    GoldED Users Guide, Page 30

          SOUPREPLYLINKER <cmd>
              Commandline for a replylinker program to call after SOUP import.

          INTERNETADDRESS <internet-address>
              Specifies your Internet address. This must be the address only,
              no name. The INTERNETADDRESS and USERNAME will be combined to a
              standard "From: internetaddresss (username)" headerline when you
              write e-mail or articles.

          INTERNETGATE [gatename<,>]<ftn-address>
              Specifies an FTN address which is used as the destination
              address in the FTN message header. It is also the address used
              in the FSC-35 REPLYTO/REPLYADDR kludges that are inserted in
              mail and news imported from SOUP packets.

          INTERNETMSGID <yes/no>
              Specifies whether the FTN MSGID kludge should contain an RFC1036
              compatible Message-ID or the normal FTS-9 format. Note that
              using the RFC1036 format in MSGID breaks the FTS-9 (version 001)
              specification, so please don't use this feature in FidoNet
              netmail or echomail. As a safeguard, GoldED will only use the
              RFC1036 format in areas specifically marked as e-mail or
              newsgroups, using the SOUPEMAIL and SOUPNEWSRCFILE keywords or
              using the Email and News area types with the AREADEF keyword,
              even when INTERNETMSGID is set to YES globally.

          INTERNETREPLY <yes/no>
              If set to yes (the default), GoldED uses the FSC-35 reply
              method, which puts UUCP in the to-field and a To: line at the
              top of the message. For use with SOUP, this is ugly, so it is
              recommended to set this keyword to NO. Note however, that due to
              limitations of the header field editor, there is currently a
              limit of 35 characters for the from and to headerfields.

          INTERNETRFCBODY <yes/no>
              Tells GoldED whether to look for and process RFC headerlines at
              the top of the message body, before the first empty line. Also
              tells GoldED to insert its own RFC headerlines at the top of the
              message body instead of as kludge lines. This option should only be
              used when receiving Internet mail as QWK packets where the
              RFC headerlines are usually found at the top of the messages, or
              when sending Internet mail via FTN packet to a gateway running
              GIGO. GIGO does not recognize RFC header in kludges, but it does
              recognize them at the top of the messages, if it is properly
              configured (with lines of "Allow_Xxx:" in GIGO's HEADERS.CFG,
              where Xxx are the RFC headerlines the gate administrator wants
              to allow).

          MAILINGLIST <echoid> <senderaddress> [contribution address]
              Defines one or more mailing lists. When importing e-mail from a
              SOUP packet, GoldED will look at the Internet address in the
              "Sender" header and if it matches one of the MAILINGLIST's, the
              e-mail will be tossed to the defined area. Note that GoldED
              supports only participation in, not hosting of mailing lists.
              The contribution address is the destination Internet address for
              mail you write to the mailing list - the address is typically
        ______________________________________________________________________

        Using the SOUP features                    GoldED Users Guide, Page 31

              given to you when you subscribe to a list. If the contribution
              address is not specified, the senderaddress is assumed.

        There are six different SOUP packet encoding formats. Four of those
        are supported by GoldED.

          u   USENET news articles                (import only)
          m   Unix mailbox articles               (import only)
          M   Mailbox articles in the MMDF format (not supported)
          b   Binary 8-bit clean mail format      (import and export)
          B   Binary 8-bit clean news format      (import and export)
          i   Index file only                     (not supported)

        The 'M' format is not yet supported. If you need support for this
        format, please let me know, and send along an example SOUP packet
        which uses the 'M' format. There are no plans to support the 'i'
        format in the near future.

        Articles are imported to the area matching the newsgroup name (for
        example "rec.humor.funny" is imported to an area with the echoid
        REC.HUMOR.FUNNY). E-mails are imported to the area named with the
        SOUPEMAIL keyword. If no matching area can be found, the articles are
        tossed to the area named with the SOUPBADMSGS keyword, with the
        newsgroup name in an AREA: line at the top. If no badmsgs area is
        defined, the articles will be silently thrown away.

        After import, the AREAS, *.MSG and *.IDX files are deleted from the
        SOUPIMPORTPATH. Be sure to keep backup copies when experimenting with
        the SOUP feature. Note that there is currently no dupe check.

        In the imported articles, the RFC headerlines are converted to
        kludges. The real names (if any) in the From: and To: headerlines are
        put into the message from/to header fields. If no To: line is found,
        "All" is used.

        When you write or reply to e-mail and articles, GoldED adds the echoid
        (newsgroup name) and message number to a file named GOLDSOUP.LST in
        the GOLDPATH. This file is used exclusively by GoldED to find outgoing
        mail when starting the SOUP export.

        There are three Internet specific template tokens:

          @oto          Original RFC "To:" headerline.
          @ofrom        Original RFC "From:" headerline.
          @omessageid   Original RFC "Message-ID:" headerline.

        With these tokens, it is possible to create templates which look like
        one of the defacto standard attribution lines used by other
        newsreaders. See the example NEWSGRPS.TPL file for examples.

        In e-mail and newsgroups, the ORIGIN keyword can be used to set the
        content of the "Organization:" headerline.

        The Martin Junius <[e-mail]> MSGID.DOC document is
        supported. This means that the Message-ID headerline is converted to a
        MSGID kludge and the References headerline is converted to one or more
        ______________________________________________________________________

        Using the SOUP features                    GoldED Users Guide, Page 32

        REPLY kludges. This makes MSGID/REPLY based replylinking possible
        using existing FTN-based utilities. The original Message-ID and
        References headerlines are preserved in the messages along with the
        MSGID/REPLY kludges.

        SOUP import and export is currently quite slow and a some things are
        hardcoded that should be made into options. There is a lot of room for
        improvements, but this is a nice start for those who want to read
        their Internet mail and news with their favorite program instead of
        the various SOUP offline readers out there.

        For people with the IBM OS/2 Internet Access Kit, I can recommend the
        "Souper" program which can make SOUP packets for offline consumption
        instead of the expensive online reading with NewsReader/2 and
        Ultimedia Mail/2. At the time of writing, the latest version was
        SOUPER12.ZIP, ftp'd from hobbes.nmsu.edu.

        The SOUP features SHOULD NOT be used with the GoldED DOS version. Use
        the 386 or OS/2 versions. The current implementation uses memory like
        a pig, and in any case, it is common that very large messages (>64K)
        are seen in Internet e-mail and newsgroups, and the DOS version does
        not handle very large messages well at all.

        It is recommended to use either the JAM or the Squish msgbase formats
        to store the Internet newsgroups. These two formats support tree-like
        replylinking. JAM supports it best, with unlimited links. Squish only
        supports up to 9 links. GoldED currently also only supports up to 9
        links, even for JAM.

        GoldED understands several character translation standards and
        non-standards for Internet e-mail and newsgroups. Please see the next
        chapter for details.

        PLEASE NOTE: GoldED can be used purely for Internet use as a SOUP
        packet reader, but there are still some FidoNet-specific keywords
        which must be setup for GoldED to operate correctly. The ADDRESS and
        INTERNETGATE keywords must be set to a FTN-compatible address. If you
        don't know or care about any such address, just use this:
        "2:236/77.999" (leave out the quotes).


        Example setup in GOLDED.CFG:

          // Minimum FTN setup
          USERNAME        Odinn Sorensen
          ADDRESS         2:236/77

          // Basic Internet setup
          INTERNETADDRESS [e-mail]
          INTERNETGATE    2:236/77
          INTERNETMSGID   YES
          INTERNETREPLY   NO

          // Basic SOUP setup
          SOUPIMPORTPATH  C:\SOUP\IMPORT\
          SOUPEXPORTPATH  C:\SOUP\EXPORT\
        ______________________________________________________________________

        Using the SOUP features                    GoldED Users Guide, Page 33

          SOUPNEWSRCFILE  C:\SOUP\NEWSRC
          SOUPEMAIL       NET_EMAIL
          SOUPBADMSGS     BAD_NEWS

          // Area definitions for e-mail and bad newsgroups
          AREADEF NET_EMAIL "E-Mail" 0 EMail Opus C:\SOUP\NETMAIL
          AREADEF BAD_NEWS  "Bad Newsgroups" 0 News Opus C:\SOUP\BADNEWS

          // Replylinking when using GEcho and JAM areas:
          SOUPTOSSLOG     C:\GECHO\IMPORT.JAM
          SOUPREPLYLINKER C:\GECHO\MBUTIL Link

          // Replylinking when using Squish and Squish areas:
          SOUPTOSSLOG     C:\SQUISH\SOUPTOSS.LOG
          SOUPREPLYLINKER C:\SQUISH\SQUISH LINK -fC:\SQUISH\SOUPTOSS.LOG

          // Setup of some mailing lists
          SOUPMAILINGLIST LIST.EMX  [e-mail]
          SOUPMAILINGLIST LIST.GIGO [e-mail] [e-mail]

          // Area definitions for the mailing list areas
          AREADEF LIST.EMX  "EMX mailing list"  0 EMail Opus C:\SOUP\EMX
          AREADEF LIST.GIGO "GIGO mailing list" 0 EMail Opus C:\SOUP\GIGO

          // Setup of character translation
          XLATPATH        C:\GOLDED\XLAT\
          XLATESCSET      MNEMONIC IBMPC    MNE_IBM.ESC
          XLATCHARSET     LATIN-1  IBMPC    ISO_IBM.CHS
          XLATCHARSET     LATIN1QP IBMPC    IQP_IBM.CHS
          XLATCHARSET     MAC      IBMPC    MAC_IBM.CHS
          XLATCHARSET     IBMPC    IBMPC    IBM_IBM.CHS
          XLATCHARSET     IBMPC    LATIN-1  IBM_ISO.CHS
          XLATCHARSET     IBMPC    LATIN1QP IBM_IQP.CHS
          XLATCHARSET     IBMPC    MNEMONIC IBM_MNE.CHS

          // Main group for Internet newsgroups
          GROUP Newsgroups:
            MEMBER        alt.*, comp.*, misc.* news.*
            MEMBER        rec.*, soc.*, sci.*, talk.*
            MEMBER        bad_news
            EDITHARDTERM  YES
            QUOTECHARS    ":;|"
            TEMPLATE      INTERNET.TPL
            WHOTO         All
          ENDGROUP

          // Main group for e-mail, mailing lists and some danish newsgroups
          // with character translation
          GROUP EMail:
            MEMBER        net_email, list.*
            MEMBER        pingnet.*, dknet.*, dk.*
            EDITHARDTERM  YES
            TEMPLATE      INTERNET.TPL
            WHOTO         All
            XLATIMPORT    LATIN-1   ; Assume ISO-8859-1 is in use
            XLATEXPORT    LATIN1QP  ; Use MIME quoted-printable encoding
        ______________________________________________________________________

        Using the SOUP features                    GoldED Users Guide, Page 34

          ; XLATEXPORT    LATIN-1   ; Use MIME 8bit encoding
          ; XLATEXPORT    MNEMONIC  ; Use RFC1345 character mnemonics
          ENDGROUP


        Example INTERNET.TPL:

          @moved* Replying to an article in @oecho.
          @moved
          @changed* Changed by @cname, @cdate @ctime.
          @changed
          @forward* Forwarded from @oecho by @cname.
          @forward* Originally by: @ofrom, @odate @otime.
          @forward* Originally to: @oto.
          @message
          @forward
          @new
          @reply@ofrom wrote:
          @reply@position
          @comment@ofrom wrote:
          @comment@position
          ;@quotedIn article @omessageid, @ofrom wrote:
          @quoted@ofrom wrote:
          @quoted@position
          @quotebuf
          @quotebuf@ofrom wrote:
          @quotebuf
          @quote

          --
          Signature Signature Signature Signature Signature Signature
          Signature Signature Signature Signature Signature Signature


        Planned Internet/SOUP features:

        * Killfile.
        * Addressbook.
        * Article cancel.
        * Improved thread navigation.
        * Built-in replylinker/threader.
        * Elimination of FTN-requirements, for pure Internet use.
        * Msgbase format designed optimally for Internet and threading.
        * Your suggestions :-)












        ______________________________________________________________________

        Using the SOUP features                    GoldED Users Guide, Page 35

        ______________________________________________________________________

                      Notes About Internet Character Translation
        ______________________________________________________________________


        Character Translation Issues:

        * MIME: From RFC1341/1521, charset=ISO-8859-1 and encoding
          quoted-printable or 8bit is supported both for ingoing and outgoing
          messages. The RFC1342/1522 header extensions are currently not
          supported.

        * X-Charset and X-Char-Esc: These experimental headers are supported
          for both ingoing and outgoing messages, using RFC1345 character
          mnemonics and escape character ASCII 29.


        Unresolved Issues:

        * In e-mail (netmail) areas, the charset translation features do not
          yet work correctly. Please avoid using non-ascii characters in
          message headers (to/from/subject).


        Using MIME Character Translation (RFC1341/1521)

          You must have these lines in your GOLDED.CFG:

            XLATCHARSET IBMPC   LATIN-1   IBM_ISO.CHS
            XLATCHARSET IBMPC   LATIN1QP  IBM_IQP.CHS
            XLATCHARSET LATIN-1 IBMPC     ISO_IBM.CHS

          The IBM_ISO.CHS, IBM_IQP.CHS and ISO_IBM.CHS files must be present in
          the XLATPATH.

          To use MIME charset ISO-8859-1 and encoding 8bit in your messages,
          you must have these lines in the appropriate group(s):

            XLATEXPORT LATIN-1
            XLATIMPORT LATIN-1

          This will add the following headers in your messages:

            MIME-Version: 1.0
            Content-Type: text/plain; charset=iso-8859-1
            Content-Transfer-Encoding: 8bit

          Note that 8bit encoded messages usually won't get through unharmed
          in e-mail, because the SMTP protocol is 7bit. In newsgroups the
          problem apparently isn't so bad. If you want your 8bit characters to
          get to the destination unharmed, you should use the quoted-printable
          encoding (see below).

          To use MIME charset ISO-8859-1 and encoding quoted-printable in your
          messages, you must have these lines in the appropriate group(s):
        ______________________________________________________________________

        Notes About Internet Character Translation GoldED Users Guide, Page 36


            XLATEXPORT LATIN1QP
            XLATIMPORT LATIN-1

          This will add the following headers in your messages:

            MIME-Version: 1.0
            Content-Type: text/plain; charset=iso-8859-1
            Content-Transfer-Encoding: quoted-printable

          When quoted-printable encoding is used, 8bit characters are
          translated to a three-character code starting with ASCII 61 ('='),
          followed by two hexadecimal characters that together form the
          hexadecimal value of the original character in the charset specified
          by the Content-Type header.

          Users must be aware that not all reader software recognize and
          support the quoted-printable format. The reader software may display
          the entire three-character code untranslated, or translate the code
          imcompletely. If the code is untranslated, the displayed result is
          usually not pretty.


        Using Character Mnemonics Encoding (RFC1345)

          You must have these lines in your GOLDED.CFG:

            XLATESCSET  MNEMONIC IBMPC    MNE_IBM.ESC
            XLATCHARSET IBMPC    MNEMONIC IBM_MNE.CHS
            XLATCHARSET LATIN-1  IBMPC    ISO_IBM.CHS

          The MNEMONIC.ESC, IBM_MNE.CHS and ISO_IBM.CHS files must be present
          in the XLATPATH.

          To use character mnemonics in your messages, you must have these
          lines in the appropriate group(s):

            XLATEXPORT MNEMONIC
            XLATIMPORT LATIN-1

          This will add the following headers in your messages:

            X-Charset: ISO_8859-1
            X-Char-Esc: 29

          When character mnemonic encoding is used, 8bit characters are
          translated to a three-character code starting with ASCII 29,
          followed by two characters that together form a standardized
          mnemonic of the original 8bit character.

          Users must be aware that not all reader software recognize and
          support this encoding format. The reader software may display the
          entire three-character code untranslated, omit only the escape
          character or translate the code incompletely. If the code is
          untranslated, the displayed result is usually not pretty.

        ______________________________________________________________________

        Notes About Internet Character Translation GoldED Users Guide, Page 37


        Choosing Between MIME and Character Mnemonics

          The safest choice for both e-mail and newsgroups is MIME with
          quoted-printable encoding.

          MIME is a fully documented standard (see RFC1522 or the older
          edition RFC1341) using standard headers. It is fairly widely
          supported by (newer) reader software.

          The character mnemonics are documented in RFC1345, but the "X-"
          headers are not documented (to the authors knowledge). The existence
          of the X-Charset/X-Char-Esc headers and the encoding method was
          found and deduced from sending e-mails with 8bit characters back and
          forth between different addresses and looking at the e-mail at the
          destination. The translation of 8bit e-mails and addition of the X-
          headers appears to be done by routing software before sending them
          using 7bit transfer protocols like SMTP. It is unknown what, if any,
          reader software that supports the character mnemonics.

          The main disadvantage of MIME 8bit and quoted-printable is that the
          character set is limited to the US-ASCII 7bit or ISO-8859-1 8bit
          sets. The character mnemonics support most or all of the 16bit
          unicode character set.
































        ______________________________________________________________________

        Notes About Internet Character Translation GoldED Users Guide, Page 38

        ______________________________________________________________________

                     Sound Support in DOS - The Goldware Sound API
        ______________________________________________________________________


        The DOS and 386 versions of GoldED support sound via sound cards by
        calling functions in the Goldware Sound API.

        The Goldware Sound API is a set of functions provided by an interrupt
        service function installed on the Alternate Multiplex Interrupt (AMI)
        2Dh. For full details on the Alternate Multiplex Interrupt, please see
        Ralf Brown's Interrupt List (INTER46*.ZIP), his AMI specification
        (ALTMPX35.ZIP) and/or his AMIS library (AMISL091.ZIP).

        I have implemented a program loader which provides the interrupt
        service function with the Goldware Sound API. The current version of
        the program loader is named GCTVSAPI 1.00 and may be found in the
        archive GCTV100.ZIP. The current version of GCTVSAPI loads the
        Creative Labs CT-VOICE.DRV file for playing of .VOC files. Full public
        domain C++ source code and the Goldware Sound API specification is
        included in the archive.

        I hope that others will write program loaders or TSR's that implement
        the Goldware Sound API for other sound cards than the Sound Blasters,
        or even an implementation that does not require CT-VOICE.DRV.

        If you have written a Goldware Sound API implementation, please let me
        know, so that I and the reg.sites can make it available for other
        users.


























        ______________________________________________________________________

        Sound Support in DOS - The Goldware Sound AGoldED Users Guide, Page 39

        ______________________________________________________________________

                           Sound Support in the OS/2 Version
        ______________________________________________________________________


        To support sound in the OS/2 version, GoldED requires the MMPM/2, the
        OS/2 MultiMedia Presentation Manager to be installed.

        GoldED sends commands to MMPM/2 using the mciSendString API function.
        Basically it send the following commands to play a sound file:

          open <filename> alias noise wait
          seek noise to start
          play noise
          (do other things until playing is complete)
          close noise wait

        These commands require that there is an association between the sound
        file and the appropriate sound device (typically waveaudio or
        sequencer). If you can't seem to get GoldED/2 to play your files, you
        should check in the Multimedia Setup if the Association tabs under
        Digital Audio and MIDI look correct.

        It works perfectly here. If GoldED/2 doesn't play your files, you have
        a setup problem somewhere. Try if entering "PLAY FILE=<soundfile>" at
        the OS/2 commandline works. The REXX program PLAY.CMD sends commands
        to MMPM/2 in almost the same way as GoldED/2.

        If you are trying to make GoldED/2 play .VOC files and it doesn't
        work, convert them to .WAV and try again.

























        ______________________________________________________________________

        Sound Support in the OS/2 Version          GoldED Users Guide, Page 40

        ______________________________________________________________________

                     Replacing DOS/4GW with PMODE/W in GoldED/386
        ______________________________________________________________________


        The standard release of GoldED/386 requires the Rational Systems
        DOS/4GW DOS extender runtime file DOS4GW.EXE. Many other programs use
        the same extender. However there is an alternative extender which can
        be used with GoldED. The alternative extender replaces a "stub" in
        GED386.EXE and eliminates the requirement of the big DOS4GW.EXE file
        as well as reducing memory requirements and increases speed.

        The alternative DOS extender is PMODE/W by Charles Scheffold and
        Thomas Pytel. At the time of writing, the latest version I know of is
        version 1.16, distributed in the archive PMW116.ZIP (75k), dated april
        18, 1995. By now there is probably already a newer version.

        If you want to replace DOS/4GW with PMODE/W, simply use the PMWBIND
        utility that comes with the PMODE/W archive, like this:

          PMWBIND /R GED386.EXE

        That's it!

        The PMODE/W manual recommends using the PMWSETUP program to adjust
        some PMODE/W parameters in the new GED386.EXE, but in my very short
        test period it worked fine without any adjustments, at least in a DOS
        box under OS/2 Warp.

        So, if PMODE/W is so great, why don't I use it in the standard release
        of GoldED/386?  There are several reasons:

        1.  For use in commercial/shareware programs, they want USD 500. I
            can't afford that.

        2.  During the beta test of GoldED 2.50 I tried to use version 1.12 of
            PMODE/W, but it turned out there were too many problems with it. I
            haven't checked if the newer versions are better.

        If you do replace DOS/4GW with PMODE/W and later experience odd
        problems, please don't report anything to me before you have tried
        going back to the standard release. You can do that by simply running
        GoldED/386 like this:

          DOS4GW.EXE GED386 [whatever parameters, if any]

        Good luck with it!








        ______________________________________________________________________

        Replacing DOS/4GW with PMODE/W in GoldED/38GoldED Users Guide, Page 41

        ______________________________________________________________________

                             The Message Database Formats
        ______________________________________________________________________


        GoldED supports many different message database formats. The following
        is a list of them all, with notes about their characteristics and what
        special quirks to look out for with each of them.


        Opus/FTS1 (*.MSG)

            These are two variants of the same type of msgbase. It works by
            using one physical file per message (1.MSG, 2.MSG etc.),
            collecting them in a directory for each area. Depending on the
            clustersize on the harddisk, this can be a very wasteful and slow
            way to store messages. With a clustersize of about 512 bytes, the
            waste may be acceptable, but the access speed can be dramatically
            slow if there are many *.MSG files, due to the DOS file system.
            Caches and BUFFERS adjustments can improve it, but there are
            limits.

            In echomail areas, this format has a special quirk: The first
            message (1.MSG) is normally used to store the so-called
            "highwatermark". The highwatermark tells the echomail processor
            where it should start scanning for new messages entered by users.
            By deleting (Zapping) the highwatermark, you can make the echomail
            processor re-scan the whole area again. This may cause messages to
            be sent out as "dupes", so this should be used sparingly and
            carefully, if at all!  The highwatermark can also be "Heated" -
            which means that it is set to the last msg in the area. This
            prevents the echomail processor from finding newly entered
            unscanned msgs. Use with care.

            The variants: The "Opus" format originated in the Opus BBS system.
            It put some Fido undocumented(?) fields to use as date/time
            stamps. The "FTS1" (defined in FTS-0001, revision 12 and later)
            format uses the undocumented fields to set the zone/point
            information for the msg. To the authors knowledge, the Opus
            variant is the dominant, and the FTS1 variant is doomed to
            oblivion. If in doubt, use the Opus format.


        Hudson

            This msgbase format was invented by Adam Hudson, and was first
            used in his QuickBBS package. Later several other BBS'es were
            cloned from QuickBBS (like RemoteAccess and SuperBBS).

            The basic format is built around 7 main files:

              MSGTXT.BBS    This contains the message text of all msgs in all
                            areas.
              MSGHDR.BBS    The headers for all the msgs in MSGTXT.BBS.
              MSGIDX.BBS    Index to MSGHDR.BBS.
        ______________________________________________________________________

        The Message Database Formats               GoldED Users Guide, Page 42

              MSGINFO.BBS   Tells how many msgs there are in each area.
              MSGTOIDX.BBS  Index that contains all the TO names.
              LASTREAD.BBS  Lastreads for all areas for each user in USERS.BBS.
              USERS.BBS     Contains a record for each user. Also the index to
                            LASTREAD.BBS.

            The format limits the total size of MSGTXT.BBS to a maximum of
            16MB, which translates to about 16000 msgs of "average" length.
            GoldED automatically warns you if the limit is close to being
            reached, and advises you to pack the msgbase.

            The first incarnations of QuickBBS did not support "sharing" of
            the msgbase. This became more and more important in later years as
            multitaskers and networks got cheaper. RemoteAccess BBS was the
            first to implement a useful method, and later a better method was
            evolved (known as "RA 1.01 or RA 1.1x"), which is now the standard
            for all modern software that supports msgbase sharing. GoldED
            fully supports the new standard of course.

            The main virtue of this format is that it is very fast to access
            the msgbase.

            The main disadvantage is that it can be very sensitive to disk
            problems, and it is a common horror story that people loose their
            entire msgbase because the disk developed bad clusters or some
            program went berserk and messed up the msgbase files.


        Goldbase

            This is an enhanced version of the Hudson format, introduced in
            QuickBBS 2.80 by the QuickBBS group.

            The Goldbase format removes the 16MB size limit and allows up to
            500 message areas instead of the 200 in Hudson. The filenames are
            the same, except that the extension is .DAT instead of .BBS.


        Squish

            The Squish format is relatively new. It was invented by Maximus
            BBS author Scott Dudley in 1991, and was first used in Maximus
            CBCS v2.00. Soon after, GoldED was among the first message editors
            to support this new format.

            Squish uses three files per area: A header/message text file
            (*.SQD), an index file (*.SQI) and a lastread file (*.SQL). The
            SquishMail echomail processor uses a fourth file (*.SQB) to hold a
            dup-database.

            The use of a database for each area - instead of one file per msg,
            or all msgs in one big database - makes this format fast, very
            safe and resistant to disk problems. Even if something messed up a
            Squish area, it can almost always be fixed and recovered, using
            the SQFIX or SQREIDX utilities that come with the Squish echomail
            processor.
        ______________________________________________________________________

        The Message Database Formats               GoldED Users Guide, Page 43


            A special feature of Squish areas is that they can be
            self-maintaining. You can setup a Squish area so that it may only
            contain a maximum of so-and-so many msgs, and then it will
            automatically re-use the space used by old msgs when the limit is
            reached, and so it will practically stop growing. It will still
            need packing, but not nearly as often as a Hudson msgbase has to.


        Ezycom

            <to be described>


        JAM

            The JAM format was invented by Joaquim Homrighausen, Andrew
            Milner, Mats Birch and Mats Wallin.

            JAM uses four files for each area: A header file (*.JHR), a
            message text file (*.JDT), an index file (*.JDX) and a lastread
            file (*.JLR). Most echomail processors support two additional
            files to aid scanning out messages: NETMAIL.JAM and ECHOMAIL.JAM.
            They are "global" files, located in the JAMPATH.

            See also the chapter "JAM Implementation Notes".


        PCBoard

            <to be described>

            See also the chapter "PCBoard Implementation Notes".























        ______________________________________________________________________

        The Message Database Formats               GoldED Users Guide, Page 44

        ______________________________________________________________________

                               JAM Implementation Notes
        ______________________________________________________________________


        This chapter describes details about the implementation of the JAM
        messagebase format in GoldED. Should be read in conjunction with the
        JAM specs for better understanding. A lot of technical terms will be
        used, so if you are not the technical type, just skip over it.


        General notes

        The first release of the JAM messagebase specifications (JAM-001,
        rev.1, dated 93-07-01) included an example implementation in the C
        language of a "JAM API".

        For the purpose of use in GoldED, the JAM API C implementation was
        both too complete and not complete enough. Therefore I developed my
        own specialized JAM msgbase handling code. My own code was of course
        designed be compatible with the original JAM API as well as the
        specifications, but some things are done slightly differently for
        various reasons.


        File I/O checks

        Reads and writes to the msgbase files are generally NOT checked for
        errors in GoldED. In contrast, the original JAM API checks everything
        and stores error values in the API, for the user to use or ignore.

        Full checking degrades performance a bit, adds more code to the EXE
        file, and most importantly, GoldED just doesn't have a safe way to
        recover from the detection of such errors anyway at this time.
        Assuming that your system is working well, there are no harddisk
        errors etc., this will normally not be a problem.


        Message header revisions

        The JAM message headers contain a field to indicate the revision
        number of the header structure.

        GoldED currently ignores this field and assumes that future revisions
        will remain backward compatible. When creating new msgs, GoldED uses
        the revision 1 header structure.

        When new revisions of the JAM specs are released, GoldED will be
        updated to handle these as quickly as possible.


        Passwords

        The JAM specs contain fields for passwords to access the msgbase
        and/or indiviual messages.
        ______________________________________________________________________

        JAM Implementation Notes                   GoldED Users Guide, Page 45


        GoldED currently doesn't support these passwords. When creating a new
        JAM msgbase and/or new JAM msgs, GoldED sets the password to
        FFFFFFFFh. If you change an existing msg which has a password, the
        password is NOT preserved, but reset to FFFFFFFFh.


        Lastreads

        The JAM lastread file is designed such that is has to be searched for
        a userid/usercrc, because one cannot assume that the records are in a
        specific order.

        The JAM API searches the userid field. However it seems more
        reasonable to search for the usercrc, because that is a value the
        program can calculate from the username without looking in other
        files. I'm not sure why the JAM API chooses to look in the userid
        field instead. GoldED searches for the usercrc, not the userid. In any
        case, it seems that RemoteAccess 2.x sets both the userid and usercrc
        to the same value.

        The specs state that the user's lastread record must be searched for
        both when retrieving it and storing an updated record. However, the
        JAM API seems to implemented slightly differently, because when it
        stores an updated record, it stores it at the same position as it was
        read *without* first searching for it.

        GoldED has been implemented to work in a similar manner. It searches
        for the user's lastread record when the msgbase is opened, and it
        assumes that it will remain in the same position as it was found,
        until the msgbase is closed.

        This is normally a quite reasonable assumption. The only circumstance
        where the lastread records might be re-ordered is when a msgbase
        maintentance utility cleans up or sorts, and such a utility is
        normally designed to open the msgbase files in exclusive mode, which
        it can't do when the files are already open. If it tries to re-order
        without exclusive access, the utility is badly designed and
        potentially dangerous in multitask/networking environments.


        Size limits

        The JAM specs allow msgbases and msgs of really huge sizes. The 16-bit
        DOS version of GoldED cannot handle the full extremes of this. The
        32-bit OS/2 and 32-bit protected mode DOS versions of GoldED can
        handle any size, only restricted by memory, disk space or unknown
        compiler or operating system limits.

        The internal limits for the 16-bit versions of GoldED means that they
        can only handle msgbases containing a maximum of 8191 msgs (including
        deleted msgs), and msgs a maximum of about 64k long. In theory at
        least. In practice the limits may be smaller due to lack of memory.


        ASCII 7-bit escaping
        ______________________________________________________________________

        JAM Implementation Notes                   GoldED Users Guide, Page 46


        GoldED currently doesn't support the escaping described in the JAM
        specs. The specs state that the current revision of JAM does not
        support it either, so I guess it's no great loss.


        Date fields

        GoldED currently doesn't display the DateReceived field, but it is
        updated on disk when a message is received (read) by the recipient.

        The DateProcessed field is set to the current date when a msg is
        writtten or changed with GoldED.

        All new dates are set to the system time and are not adjusted for
        timezone.


        Subfields

        The concept of the JAM subfields is difficult to support easily in a
        program like GoldED, which was designed to support the traditional
        fixed header formats and kludges in the msg body. Therefore the
        implementation in GoldED of the JAM subfields is not currently as
        complete as one might wish.

        However, it should be adequate for most purposes. I will of course do
        what I can to improve the JAM subfield support in future releases. The
        following is a list of the current limitations of the JAM subfield
        support in GoldED:

        *   Subfields are converted internally to the equivalent kludges for
            easy viewing, and to make it possible to copy JAM msgs to areas
            with other msgbase formats. Some subfields do not have equivalent
            known kludges defined. They are converted to kludges with names I
            have invented for the purpose. All subfields can be viewed if you
            hit the Alt-I key to display a hexdump of the message.

        *   The subfields with size limits (typically 100 chars) are not
            specifically checked for size. Since all other msgbase systems
            have much lower limits for the fields in question, this should not
            be a problem.

        *   Only one OADDRESS/DADDRESS is supported. When reading a message,
            only the _first_ OADDRESS/DADDRESS is used.

        *   None of the file attach or file request subfields are supported at
            this time. File attaches or file requests are stored in the
            subject field in a manner similar to other msgbase formats. This
            might not be supported by a fully JAM compliant mail processor,
            but IMHO a mail processor should use the subject field if it finds
            the file attach/request attributes set, but can't find any
            subfields for them.

        *   If you change a JAM message which is not from you, and save it,
            all unsupported subfields will be missing in the saved message,
        ______________________________________________________________________

        JAM Implementation Notes                   GoldED Users Guide, Page 47

            and some supported subfields may be changed in content (like the
            PID subfield).

        *   Currently unsupported message attributes:

            MSG_FPU     "Force pickup"
            MSG_NODISP  "Msg may not be displayed to user" (always displayed)


        Deleted msgs

        The original JAM specs has a fairly major problem when it comes to the
        specification for deleting msgs and in particular about _detecting_
        deleted msgs. The original specs do not define a fast way to detect
        deleted msgs from the index file alone.

        This may not be so important for a BBS or a mail processor, but it is
        absolutely vital for mail readers such as GoldED, which need a fast
        way to find out how many active msgs there are, and where the lastread
        is, and to calculate how many unread msgs there are. If GoldED had
        scan the header file to check a single bit in each header the area
        scanning would slow down dramatically, because the header file can
        easily grow to many megabytes and thousands of msgs.

        Fortunately there is a way out. The specs state that if the usercrc
        and header offset values in the index are both -1 (FFFFFFFFh), then
        "there is no corresponding header". Such a situation is IMHO highly
        unlikely, so I have proposed to use this to signify a deleted msg
        instead. This should be backward compatible with almost all JAM
        compatible programs, with the possible exception of msg undelete
        utilities.

        With the header offset set to -1 (FFFFFFFFh), there is of course no
        fast way to find the header of a deleted msg. A msg undelete utility
        would have to scan through the entire header file to locate the
        deleted header (or rather the last occurrence of it, because there can
        easily exist more than one deleted header with the same message
        number). This is IMHO a price worth paying for the performance gained
        by using by changing the specs to specify a deleted msg instead of a
        hypothetical non-existing header.

        When I brought up this subject in the JAMDEV echo, the developers who
        replied generally agreed that this was a good idea. At the time of
        writing, I don't know for certain that it will be changed in the
        specs, but I think so.

        GoldED optionally (since version 2.50.B0822) follows my proposed
        method when deleting msgs. The configuration keyword JAMHARDDELETE
        specifies which method to use. If set to Yes, my method is used. The
        default is No, but I recommend (and use myself) Yes.


        Scanning files

        The NETMAIL/ECHOMAIL.JAM files are written/updated when new messages
        are written or changed in JAM netmail/echomail areas. The files are
        ______________________________________________________________________

        JAM Implementation Notes                   GoldED Users Guide, Page 48

        written/updated in the JAMPATH. If you don't have a JAMPATH, it
        defaults to the HUDSONPATH. If you don't use a Hudson msgbase and
        haven't defined a HUDSONPATH, the HUDSONPATH defaults to the GOLDPATH.

        At the time of writing, the NETMAIL/ECHOMAIL.JAM files are not a part
        of the official JAM specs, but they are used in RA2 and most JAM
        compatible mail processors to specify the msgs that need to be
        exported from the JAM msgbase files.
















































        ______________________________________________________________________

        JAM Implementation Notes                   GoldED Users Guide, Page 49

        ______________________________________________________________________

                             PCBoard Implementation Notes
        ______________________________________________________________________


        This chapter describes details about the implementation of the PCBoard
        messagebase format in GoldED.


        Netmail

        GoldED supports FidoPCB-style netmail areas. According to the FidoPCB
        manual, netmail in PCBoard format is supported by specifying the first
        line of the msg to be the to- or from- address in parentheses and the
        second line to be flags (HOLD,CRASH,IMM,INTL) in parentheses.

        The first line can be either to- or from- address, but there is no
        rule to determine when it is what. Here is how GoldED deals with it:
        When you write a netmail, GoldED puts your own address in the
        parentheses. When reading a netmail, GoldED looks at the from-name and
        if it is the same as your first USERNAME, the address is taken to be
        the to-address (written by you). Otherwise it is taken to be the
        from-address (from someone other than you).

        Note that this fails if a netmail is found which is written by
        somebody on your BBS. Is there some way to reliably determine that a
        msg is written locally instead of being imported?


        Extended Headers

        GoldED is aware of PCBoard v15.x extended headers in the message text.
        The TO, TO2, FROM, FROM2 and SUBJECT extended headers are directly
        supported and "swallowed" when reading a msg. Other extended headers
        are currently treated like normal message text and is therefore not
        hidden to the reader. In a later release, I plan to internally convert
        the extended headers to kludges.


        Long Names

        Because of internal design limitations, GoldED only supports name
        fields up to 35 characters in length. Through the extended headers,
        there can be names up to 120 characters (TO+TO2 ext.hdrs). GoldED will
        simply cut them to 35 characters. In a later release, long names will
        be supported so they won't be cut off due to internal limits, but
        display and entry of long names will probably not happen anytime soon.


        Password

        Passwords are not supported in msgs.


        Attributes
        ______________________________________________________________________

        PCBoard Implementation Notes               GoldED Users Guide, Page 50


        Only the Pvt and Rcv message attributes are directly supported in
        PCBoard messages. Through the FidoPCB netmail extensions the following
        are also supported in netmail: Hld, Cra, Imm and Zon.


        Double-Byte Characters (Foreign Systems)

        GoldED reads the PCBOARD.DAT file to determine whether to use E3h or
        0Dh (CR) as the line/paragraph termination character when reading and
        writing message text.


        Message Index

        Only the new v15.x .IDX files are suppported. The old .NDX files are
        not supported in any way.


        Userbase

        GoldED does not search the userbase for your name to find the lastread
        pointer set. By default, the first set is used. If more than one
        person need to use GoldED on the same msgbase, the PCBOARDUSERNO
        keyword must be used to give each person separate lastread sets.































        ______________________________________________________________________

        PCBoard Implementation Notes               GoldED Users Guide, Page 51

        ______________________________________________________________________

                             Credits and Acknowledgements
        ______________________________________________________________________


        *   Squish and Maximus are Copyyright 1989, 1995 by Lanius Corporation
            (Scott J. Dudley).

        *   JAM(mbp) - Copyright 1993 Joaquim Homrighausen, Andrew Milner,
            Mats Birch, Mats Wallin. ALL RIGHTS RESERVED.

        *   Marcantonio Magnarapa made a manual compiler for the GoldED manual
            during the 2.50.beta phase. I have since made my own manual
            compiler.

        *   The EXEC v3.3 swapping spawn function by Thomas Wagner is used in
            the DOS version to minimize memory use while shelling to DOS and
            running other programs.

        *   Sourcecode for doing the WaZOO .REQ thing was kindly provided by
            Morten Baun.

        *   Udo van den Heuvel made the GoldPGP utility, which inspired me to
            make GoldED do the same internally.

        *   Nicolai Dufva (2:236/100.28) helped with coding for the sound
            support in the OS/2 version.

        [this list is incomplete]


























        ______________________________________________________________________

        Credits and Acknowledgements               GoldED Users Guide, Page 52

        ______________________________________________________________________

                            What YOU get when you register!
        ______________________________________________________________________


        *   Reminders disappear.
            The random pause at the startup goes away. The original screen
            will appear when you exit GoldED instead of the shareware
            reminder. Your name and key serial number is displayed in the
            startup screen.

        *   The Plus!
            A plus ('+') is added to the version number in the tearline and/or
            your serial number is added in the PID kludge.

        *   No "UNREG" watermark.
            The UNREG watermark on the tearline and in the PID will go away.

        *   Access to Alphas and Betas.
            Alpha and some Beta versions will only work with a key, so this
            provides free access to Alpha and Beta releases and through that
            all the new features before general availability!

        *   Happy author.
            You help and encourage the author to continue development on this
            user-supported program. Without support from users such as YOU,
            GoldED would not exist today.

        *   License to use it.
            You are allowed to use GoldED for more than 30 days.

























        ______________________________________________________________________

        What YOU get when you register!            GoldED Users Guide, Page 53