ڿ     ڿ            ڿ
                          ¿ ¿  Ĵ ¿ Ĵ
                      ڿ                         GoldED 3.0.0
                                  Users Guide Manual
                     Program and manual written by Odinn Sorensen
                      Copyright (C) 1990-1998 by Odinn Sorensen

                                   Table of Contents                          

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

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

        3.  Support and Development Philosophy ............................. 3

        4.  Entering Messages .............................................. 4

        5.  Userfile Considerations ........................................ 5

        6.  Using the Search Functions ..................................... 6

        7.  Using External Editors ......................................... 7

        8.  Quote Reflow ................................................... 9

        9.  Carbon Copy and Crossposting .................................. 10
            Carbon Copying ................................................ 10
            Crossposting .................................................. 10

        10. Using the Tagline Support ..................................... 12

        11. Using the ISO 8859-1 ("Latin-1") charset ...................... 13

        12. Converting your highbit characters to ASCII ................... 14

        13. Encrypting Messages ........................................... 16

        14. Using the UUDECODE feature .................................... 17

        15. Using the UUENCODE feature .................................... 18

        16. Nodelist Browse and Lookups ................................... 19

        17. User Database Lookup .......................................... 20

        18. Marking Messages .............................................. 21

        19. The File Request Feature ...................................... 22

        20. Using the Personal Mail Scan feature .......................... 23

        21. Using the Internet Features ................................... 25

        22. Using PGP as an External Utility .............................. 26

        23. Using the GIF Features ........................................ 28

        24. Using the QWK features ........................................ 29

        25. Using the SOUP features ....................................... 32
        Table of Contents                           GoldED Users Guide, Page i

        26. Notes About Internet Character Translation .................... 38

        27. Sound Support in DOS - The Goldware Sound API ................. 41

        28. Sound Support in the OS/2 Version ............................. 42

        29. Replacing DOS/4GW with PMODE/W in GoldED/386 .................. 43

        30. The Message Database Formats .................................. 44
            Opus/FTS1 (*.MSG) ............................................. 44
            Hudson ........................................................ 44
            Goldbase ...................................................... 45
            Squish ........................................................ 45
            Ezycom ........................................................ 46
            JAM ........................................................... 46
            PCBoard ....................................................... 46

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

        32. PCBoard Implementation Notes .................................. 52
            Netmail ....................................................... 52
            Extended Headers .............................................. 52
            Long Names .................................................... 52
            Password ...................................................... 52
            Attributes .................................................... 52
            Double-Byte Characters (Foreign Systems) ...................... 52
            Message Index ................................................. 52
            Userbase ...................................................... 53
            Mail Waiting Flag ............................................. 53
            Changing a Message ............................................ 53

        33. AdeptXBBS Implemenation Notes ................................. 54

        34. WildCat! 4.x Implementation Notes ............................. 55

        35. Win32 Implementation Notes .................................... 56

        36. Linux Implementation Notes .................................... 57

        37. Thank you's, Credits and Acknowledgements ..................... 59

        Table of Contents                          GoldED Users Guide, Page ii
                                Notes About This Manual                       
        The organization of this manual is not so good, sorry about that.
        If you find spelling, grammatical or factual errors, please let me
        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 (gmanual). If you want to translate the GoldED
        manuals to any language, please copy the manual source, translate the
        copy and compile it using gmanual for distribution to others.
        You must also contribute your translated manual source to the
        community for futher use and improvement.
        NOTE: The manual source should be transformed into SGML, so we can get
        ASCII, HTML, PostScript or whatever versions. Any takers?
        Odinn Sorensen, The GoldED Author.

        Notes About This Manual                     GoldED Users Guide, Page 1
                                      Legal Notes                             
        GoldED and the Goldware Utilities are covered by the GNU General
        Public License (GPL). For details see the file COPYING.
        This program is free software; you can redistribute it and/or modify
        it under the terms of the GNU General Public License as published by
        the Free Software Foundation; either version 2 of the License, or
        (at your option) any later version.
        This program is distributed in the hope that it will be useful,
        but WITHOUT ANY WARRANTY; without even the implied warranty of
        GNU General Public License for more details.
        You should have received a copy of the GNU General Public License
        along with this program; if not, write to the Free Software
        Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

        Legal Notes                                 GoldED Users Guide, Page 2
                          Support and Development Philosophy                  
        Besides working on GoldED, I am studying to become an electrical
        engineer. For this and other reasons, I don't have much time for
        individual support, particularly not for helping beginners with setup
        problems etc. Please seek help in the support conferences on FidoNet
        or Internet or ask your friends.
        I will do my best to be available in the support conferences, but I
        can't guarantee replies to all questions. There may even be times when
        apparently urgent or important questions seem to be ignored. Please
        don't take this personally. It may be that I simply have no time in
        those periods. And later when I do have time, it may be several weeks
        later and I may decide to skip lightly over the hundreds of messages
        that piled up in the echoes. In that case, try to repeat your question
        regularly and eventually you should be able to get a reply from me.
        GoldED was a closed-source user-supported shareware program until
        november 1998, when it was transformed into an open source GPL'ed
        program with myself as primary maintainer and final judge of official
        patch acceptance. In addition to myself, there is a core team of
        developers, currently consisting only of Dirk A. Mueller, but
        hopefully soon others, which have full access to committing changes
        directly to the development CVS tree.
        I was very happy about every single registration I got in the past,
        because it gave me incentive to keep on working on GoldED, and
        gave me additional economical freedom - something which is important
        to anyone who studies without other economical backing. In the summer
        of 1998 I was fortunate enough to get a job (currently as part of my
        studies, but will likely continue for quite some time), which gave me
        economical independence of shareware income from GoldED. This gave me
        the opportunity to fulfill a promise I made myself long ago - that I
        would not allow GoldED to die, just because I lacked the time to
        support it properly. I would rather release the source code and let
        interested users carry it onwards at their own pace. So after careful
        examination of the variety of open source compliant licenses out
        there, I chose GPL and LGPL.
        Thank you for your support and understanding.
        Odinn Sorensen.

        Support and Development Philosophy          GoldED Users Guide, Page 3
                                   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
        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  or  moves to the next field.
        Pressing  in the subject field or  anywhere, ends
        the header editing. Pressing  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 4
                                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:
        There is no JAMUSERNO, because the JAM format is cleverly designed
        to be independent of userfiles.
        The  defaults to 0 (zero). Set it to 1, 2, 3 etc. for each
        additional user that shares the same msgbase using GoldED.
        Alternatively, set  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 5
                              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:
        By default, GoldED searches forward (next messages), but by preceeding
        the search string with a '-', the search goes backwards (previous
        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.
          &   Separator - Reserved for future use with logical "and" searches.
        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.
          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 6
                                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 . 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.
            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 7
        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 8
                                     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
        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 9
                             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
        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
          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.
        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 10
        To crosspost a message is simple - just add lines in this format:
          XC:  [echoid] [..]
        The "XC:" must be the first three characters on the line. The 
        must be valid echoid's defined in GoldED. Example:
        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
        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

        Carbon Copy and Crossposting               GoldED Users Guide, Page 11
                               Using the Tagline Support                      
        GoldED directly supports the popular taglines, which look something
        like this in messages:
          ... tagline
          --- GoldED 2.51
           * 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  or @     Defines a tagline or file
          TAGLINECHAR                 Defines the tagline character
          TAGLINESUPPORT            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 12
                       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
        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/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:
        If your codepage is CP437 or CP865, use these two:
        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 13
                      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:
        And add this line either globally in GOLDED.CFG or in specific groups
        in the random system:
        The IBM_ASC.CHS file can be found in the XLAT.ZIP archive within the
        Converting your highbit characters to ASCIIGoldED Users Guide, Page 14
        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:
        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 15
                                  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 16
                              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. Only uuencoded data is
        supported, not MIME Base64 or other encodings.

        Using the UUDECODE feature                 GoldED Users Guide, Page 17
                              Using the UUENCODE feature                      
        GoldED contains a built-in uuencode feature, which is available when
        importing a file in the internal editor.
        To uuencode a file while importing it, simply put a '#' character in
        front of the filename.
        Example: #WHATEVER.ZIP    - Will import as:
          begin 644 WHATEVER.ZIP
          [uuencoded data]
        NOTE: This is a very simple implementation of uuencode. It cannot
        split large files over several messages. The file mode number 644 is
        hard-coded and has nothing to do with the actual file mode.
        WARNING: Due to memory constraints, the standard 16-bit DOS version of
        GoldED is usually not able to deal with messages much larger than
        about 10-16k. You can very quickly reach that size when uuencoding
        files. For this reason, you should not use this feature unless you are
        running one of the 32-bit versions (DOS-386, OS/2 or Win32).
        GoldED currently only supports the uuencoding type, not MIME Base64 or
        other encodings.

        Using the UUENCODE feature                 GoldED Users Guide, Page 18
                              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 , 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
        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 . The
        full name and address of the node you selected is then placed in the
        appropriate fields in the header. Pressing  in the browser quits
        it without inserting any node information. While in the browser, you
        can press  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 19
                                 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
        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 20
                                   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 , or use the READmarkingoptions menu
        . 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 21
                               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
        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
        *   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 22
                         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
        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
        Only messages after the lastread are scanned. The scan ignores
        messages that are marked received.
        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 23
        (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 24
                              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:
        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.

        Using the Internet Features                GoldED Users Guide, Page 25
                           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
        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 26
        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
        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

        Using PGP as an External Utility           GoldED Users Guide, Page 27
                                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.
        *   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
        *   A menu to select the GIF just like origins etc.

        Using the GIF Features                     GoldED Users Guide, Page 28
                                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
        .MSG, which contains the messages that you wrote with GoldED.
         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 (.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
        .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 .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:
              Path where incoming QWK packet files (CONTROL.DAT and
              MESSAGES.DAT) can be found.
              Path where outgoing QWK reply files (BBSID.MSG) can be placed.
              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:_" at the top of the message.
          QWKCONFMAP  ["]["] 
        Using the QWK features                     GoldED Users Guide, Page 29
              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  is the name listed on line 5 in CONTROL.DAT after
              the comma. The  is the conference names listed on line
              13 and on alternate lines onwards in CONTROL.DAT. If a
              conference name contains embedded spaces, the  must be
              enclosed in double quotes, like this: "Main Board". The area
                must be already defined either in an AREAFILE or using
               the AREADEF or AREA keywords.
              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
              Commandline for a replylinker program to call after QWK import.
              Defines various options for the QWK support.
              Enable this in areas with Internet RFC headerlines at the top of
              messages. See the "Using the SOUP features" chapter for details.
              Enables or disables tearline and/or origin in random system
        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
          // Replylinking when using GEcho and Hudson areas:
          // Replylinking when using GEcho and JAM areas:
        Using the QWK features                     GoldED Users Guide, Page 30
          // Replylinking when using Squish and Squish areas:
          // QWK conference mapping
          // 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 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 odinn@whoknows.where
          // Group for the Internet newsgroups
          GROUP Newsgroups:
            MEMBER          dk.*
            CTRLINFO        NO
            EDITHARDTERM    YES
            INTERNETADDRESS odinn@whoknows.where
            QUOTECHARS      ":;|"
            TEMPLATE        INTERNET.TPL
            WHOTO           All
        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 31
                                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
        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:
              Path where incoming SOUP packet files (AREAS and *.MSG) can be
              Path where outgoing SOUP reply packet files (REPLIES and
              GOLD*.MSG) can be placed.
              Specifies the area where e-mails are placed.
              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.
              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.
              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 32
              Commandline for a replylinker program to call after SOUP import.
              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<,>]
              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.
              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.
              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.
              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   [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 33
              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  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 34
        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 odinn@ibm.net
          INTERNETGATE    2:236/77
          // Basic SOUP setup
        Using the SOUP features                    GoldED Users Guide, Page 35
          SOUPEMAIL       NET_EMAIL
          // 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:
          // Replylinking when using Squish and Squish areas:
          // Setup of some mailing lists
          MAILINGLIST LIST.EMX  emx-list@eb.ele.tue.nl
          MAILINGLIST LIST.GIGO gigo-owner@gigo.com gigo@gigo.com
          // 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\
          // Main group for Internet newsgroups
          GROUP Newsgroups:
            MEMBER        alt.*, comp.*, misc.* news.*
            MEMBER        rec.*, soc.*, sci.*, talk.*
            MEMBER        bad_news
            QUOTECHARS    ":;|"
            TEMPLATE      INTERNET.TPL
            WHOTO         All
          // Main group for e-mail, mailing lists and some danish newsgroups
          // with character translation
          GROUP EMail:
            MEMBER        net_email, list.*
            MEMBER        pingnet.*, dknet.*, dk.*
            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 36
          ; XLATEXPORT    LATIN-1   ; Use MIME 8bit encoding
          ; XLATEXPORT    MNEMONIC  ; Use RFC1345 character mnemonics
        Example INTERNET.TPL:
          @moved* Replying to an article in @oecho.
          @changed* Changed by @cname, @cdate @ctime.
          @forward* Forwarded from @oecho by @cname.
          @forward* Originally by: @ofrom, @odate @otime.
          @forward* Originally to: @oto.
          @reply@ofrom wrote:
          @comment@ofrom wrote:
          ;@quotedIn article @omessageid, @ofrom wrote:
          @quoted@ofrom wrote:
          @quotebuf@ofrom wrote:
          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 37
                      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
        * 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:
          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 38
            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:
          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):
            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 39
        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 40
                     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

        Sound Support in DOS - The Goldware Sound AGoldED Users Guide, Page 41
                           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  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=" 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 42
                     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.23, distributed in the archive PMW123.ZIP (132k), dated june
        24, 1996. By now there is probably already a newer version. Try
        checking their website at http://www.dorsai.org/~daredevi/pmw.
        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 43
                             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
            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.
            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
              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 44
              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
            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.
            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.
            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
            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
        The Message Database Formats               GoldED Users Guide, Page 45
            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.
            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".
            See also the chapter "PCBoard Implementation Notes".

        The Message Database Formats               GoldED Users Guide, Page 46
                               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.
        The JAM specs contain fields for passwords to access the msgbase
        and/or indiviual messages.
        JAM Implementation Notes                   GoldED Users Guide, Page 47
        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.
        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 48
        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
        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 49
            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
        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 50
        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 51
                             PCBoard Implementation Notes                     
        This chapter describes details about the implementation of the PCBoard
        messagebase format in GoldED.
        GoldED 2.50 supported FidoPCB-style netmail areas, where the first and
        second line of the msg had special meaning as FidoNet address or
        attributes. This is no longer supported from version 2.51. Instead,
        the official method used by PCBoard itself is supported. This should
        be transparent to you.
        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
        GoldED 2.51 supports the long names that are possible with PCBoard.
        You can both enter and edit them. GoldED 2.50 was limited to 35 chars.
        Passwords are not supported.
        The Private, Received, Crash and Direct attributed are supported.
        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.
        PCBoard Implementation Notes               GoldED Users Guide, Page 52
        By default, the first set of lastreads is used. But if you set
        PCBOARDUSERNO to -1, GoldED searches the userbase for your name to
        find the lastread pointer set. If GoldED does not find you name, it
        will NOT add a new userbase record for you, but instead uses the first
        set of lastreads.
        Mail Waiting Flag
        The mail waiting flags are updated when you write to people that are
        named in the userbase.
        Changing a Message
        When changing a message, the new edition is saved as if it were a new
        message, with a new message number, and then the old edition is
        deleted. This behaviour is consistent with the way PCBoard itself
        works when changing a message. NOTE: The old edition will still be
        visible with the DEL attribute until you exit the area.

        PCBoard Implementation Notes               GoldED Users Guide, Page 53
                             AdeptXBBS Implemenation Notes                    
        This chapter describes details about the implementation of the
        AdeptXBBS messagebase format in GoldED. The implementation is based on
        the documentation in version 1.05, experimentation and questions to
        the authors. Thanks go to Frank Jacobberger for the initial testing
        and prodding of the authors to answer my questions :-)
        The AdeptXBBS format does not have a quick method of finding deleted
        messages via the index file. This means that deleted messages will
        still be visible, but marked with the DEL attribute. When GoldED
        deletes a message, it will at first seem to be gone, but after the
        next scan, it will be back again, with the DEL attribute.
        Mixing of netmail and echomail or other types of mail in the same area
        is not directly supported. If an area is setup as both netmail and
        echomail, GoldED will treat it as netmail. If an area is neither
        netmail nor echomail, GoldED wil treat it as a local area.
        GoldED detects Usenet (newsgroup) and Internet E-Mail areas in
        the AdeptXBBS setup and uses them as such, but it has not yet been
        tested if GoldED and AdeptXBBS are compatible in the way they store
        and process Internet header information.
        The AdeptXBBS personal mail feature (the index in the Personal_Mail
        directory) is supported for mails you write to other users on the BBS.
        However, personal mail for you via this feature or by other means is
        not yet supported.
        The replylinking method used by AdeptXBBS (whatever the method is??!)
        is not yet supported. This means that links to other messages are
        The AdeptXBBS messagebase format is only supported in the OS/2 version
        of GoldED, because AdeptXBBS requires HPFS. In the other versions, the
        AdeptXBBS code is not included in the EXE file and therefore doesn't
        use additional memory or EXE disk space.

        AdeptXBBS Implemenation Notes              GoldED Users Guide, Page 54
                           WildCat! 4.x Implementation Notes                  
        This chapter describes details about the implementation of the
        WildCat! 4.x messagebase format in GoldED.
        The WildCat format does not have a quick method of finding deleted
        messages via the index file. This means that deleted messages will
        still be visible, but marked with the DEL attribute. When GoldED
        deletes a message, it will at first seem to be gone, but after the
        next scan, it will be back again, with the DEL attribute.
        WildCat features which are not supported yet:
        - The userbase.
        - The message unread chain.
        - The message from/to title.
        - The message network name.
        - The message internal and external attach.
        There is not yet any AREAFILE WildCat. You must define the areas by
        hand using the AREADEF keyword, like this:
          AREADEF MYTEST "My Test" 0 Echo WCat  etc.
        There is a keyword WILDCATUSERNO, which works just like the other
        USERNO keywords. By default GoldED will use the first record
        in the lastread file (*.LRD), so if you are not the first person in
        the userbase, or you are sharing the messagebase with others, you may
        have to change this user number. The userbase is currently not
        supported (ie: you can't set the number to -1 to let GoldED find the
        correct user and lastread automatically).
        NOTE: The WildCat support is currently not very well-tested, so use
        it with caution. In my limited testing, I have not found it to be
        damaging the messagebase, but you should probably test it on less
        important areas and/or make backups until it is determined that it
        is safe.

        WildCat! 4.x Implementation Notes          GoldED Users Guide, Page 55
                              Win32 Implementation Notes                      
        A new Win32 API based console (text) mode version has been added to
        the GoldED family: GoldED/W32. It will run under Windows NT and
        Windows 95 as a textmode application. Note that the screen update
        speed and keyboard response may be slow, especially under Windows 95.
        This is because screen and keyboard access has to go through some
        fairly complex (Win32) API functions, which are designed to hide the
        underlying hardware access method and thus have a lot of overhead
        compared to direct hardware access under DOS or even the simpler API
        under OS/2.
        Known limitations/problems/bugs in the Win32 version:
        - Can't change the screen mode (like from 25 to 43/50 lines).
        - Can't change the border (overscan) color.
        - Can't switch between blinking and intense colors.
        - Can't change the palette.
        - Shelling to the OS may not work.
        - Standard beeping effects may not be working under Windows 95.
        - Possible minor keyboard quirks.
        On the whole, I am not very happy about the Win32 versions performance
        when running on Windows 95. However, I am certain that I can put a lot
        of blame on the poor implementation of the console mode in Windows 95.
        It runs more smoothly in Windows NT, even the old NT 3.1 that I tested
        it on in the beginning. I would like to hear from users how it runs
        under NT 4.0.
        Some of the limitations and problems with the Win32 version are caused
        by limitations or peculiarities in the Win32 console mode API.

        Win32 Implementation Notes                 GoldED Users Guide, Page 56
                              Linux Implementation Notes                      
        There are some things you must know before trying out the Linux
        version, especially if you are used to the DOS, OS/2 or Win32
        * You should be familiar with GoldED for the other operating systems
          and know your way around at least a basic golded.cfg.
        * Linux is an OS with CASE-SENSITIVE file systems. GoldED now uses
          lowercase filenames internally, because this is costumary for Unix.
          When accessing msgbases on case-insensitive file systems such as FAT
          or HPFS under Linux, filenames might not be lowercase on the disk.
          If this is the case, you must rename them so that they are (and hope
          they stay lowercase).
          This will probably be the part that will give you the most grief if
          you try to run a system with a mixture of Linux, DOS, OS/2, and/or
          Win32 software.
        * The directory separator (slash) char is '/', not '\'. However,
          GoldED automatically translates the "wrong" slash char to the
          "right" slash char in most cases, so you probably won't notice it.
        * Unix has no drive letters (C: etc), and GoldED for Linux currently
          can't map DOS-style paths to Unix-style paths. This means that 
          AREAFILE's won't work unless paths are specifically written in
        * If you want to use the same golded.cfg file for all platforms, you
          can use the conditional statement "IF LINUX" or "IF UNIX" around
          Linux specific parts of it, typically paths or filenames.
        * I recommend to start with a tiny golded.cfg (see below) with only
          the basic setup and a few areas that you have a backup of. The
          msgbase support of GoldED for Linux should work exactly as
          3.00.Alpha5, which is NOT known to trash msgbases, but it's compiled
          and built with a compiler and tools that I'm not very familiar with,
          and there may be compiler quirks and flaws introduced in the porting
          which may have affected otherwise working code.
        * Currently only the *.MSG, JAM, Squish and Hudson formats have been
          tested, but it should work with the other formats too.
        * There is not yet any support for Unix-style mailboxes or news
          spools. If you want to access those, you need to use a utility that
          can create/unpack SOUP packets. GoldED can import/export those to
          the msgbases that are supported (JAM or Squish is recommended for
        Linux Implementation Notes                 GoldED Users Guide, Page 57
        * File attach probably does not work well (it's not been tested).
        * Characters with ASCII values 0-31 are currently remapped to 'x' or a
          visually similar character before being written to the screen.
          Characters in the range 128-159 are remapped from CP865 to Latin-1.
        * The default XLATLOCALSET is LATIN-1 for the Linux version, as
          opposed to IBMPC for the other OS'es. You should setup character
          translation between IBMPC and LATIN-1 and use the correct XLATEXPORT
          for each echo. See the GoldED manual for details. Most FidoNet
          echoes assume IBMPC or another IBMPC-based sets as default if there
          is no CHRS or CHARSET kludge. For areas where IBMPC is assumed, you
          should set both XLATIMPORT and XLATEXPORT to IBMPC or CP850.
        * Screen color changes and cursor movements are made with ANSI
          sequences. GoldED for Linux will also work in X terminals, but this
          is not recommended because of keyboard limitations. Telnet sessions
          should work, if they support the ANSI sequences and produce usable
        * Standard distributions of Linux do not define all the keys that are 
          usually available on DOS, OS/2 and Win32. Specifically, cursor
          movement (arrows, page, home/end) keys don't have separate keycodes
          when combined with the shift, control or alt keys. It is possible
          (in the keytable maps in /usr/lib/kbd/keytables) to define
          non-standard keycodes to make Ctrl-PageUp, Alt-Left etc. work, but I
          haven't had time to do this yet.
        * There may be odd quirks in the keyboard handling. Please report if
          you find any.
        * The "DOS shell" probably doesn't work. Not tested.
        * The printing feature prints to "/dev/lp". Not tested.
        Please report only problems that are specific for the Linux version.
        General problems have already been reported to death since april '97
        and may already be fixed in the next versions.
        === Cut, a basic golded.cfg ===
        username Odinn Sorensen
        address 2:236/77
        areadef netmail "Netmail" 0 net opus /usr/ftn/netmailx . (loc)
        areadef net.fidoz2 "FidoNet Z2" 0 net squish /usr/ftn/fidoz2 . (loc)
        areadef zzz.jtest1 "JAM test" 0 echo jam /usr/ftn/jtest1 . (loc)
        === Cut ===

        Linux Implementation Notes                 GoldED Users Guide, Page 58
                       Thank you's, Credits and Acknowledgements              
        *   All GoldED users, for their endless patience and support through
            the years.
        *   Dirk A. Mueller has been very helpful in all kinds of ways. I just
            can't thank him enough!
        *   Squish and Maximus are Copyright 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, for which I was very grateful.
            However, 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.
        *   Bob Stouts C/C++ SNIPPETS have been a source and inspiration for a
            number of functions and classes in my Goldware library.
        *   The Free Software Foundation for GPL and LGPL.
        *   Linus Torvalds for Linux.
        [this list is incomplete]

        Thank you's, Credits and Acknowledgements  GoldED Users Guide, Page 59