PC-Online 1998 February/PCOnline_02_1998.iso/filesbbs/dos/nbeta087.exe/STUFF.EXE/BETA77.NFO

Text File | 1996-06-19 | 100.6 KB | 2,027 lines

94/10/30
NBETA000: The prototype beta envelope, never released.

94/10/31
NBETA001: The first released beta.  Several bugs reported within hours,
          including:

           - The MORE in displaying the file menu help (and I assume in
             many other places) wouldn't abort.  This was due to a logic
             bug in the USEND routine.  Fixed 94/11/01.

           - Someone got a Runtime 003 when trying to insert a new user in
             the user editor.  Runtime 003 is a "path not found" error, and
             indicates that a path the BBS was trying to access does not
             exist.  So the problem was chalked up to a lack of proper
             pathing after I managed to duplicate it.  However, sysops
             who unpack the archive into a direcory other than C:\BBS would
             have a helluva time grappling with this same bug so I added code
             to: make sure the system and temporary paths exist each time the
             BBS is called (and create them if not), and: move all the
             files to C:\BBS (creating if needed) before proceeding with
             initial installation.  I agree that this is a patchwork
             solution, and I actually have sketchy plans underway
             already to implement a full-featured installation program
             like those used by Apogee games some time prior to release,
             possibly in the marketability-testing phase between Nov.21
             and Nov.30.

           - An observation has been made that in local logons the last-8
             log showed a baud rate of "115200" instead of the proper
             "Local".  I was actually aware of this for a long time, and
             never was bothered by it enough to do anything about it.
             Nevertheless, it's fixed.

        Thanks go to John Richards for pointing out all of these and
        several other things which I will address later.

94/11/01
NBETA002:

        I have added support for read-only message bases and a
        [readpriv] UFO keyword which returns an error code if the user
        is NOT allowed to post in the current area (insufficient access
        or read-only area).  Also I have added support for exit
        semaphores as a way to interface NanoBBS to external mail
        processors through creative batch hacking.  I will document the
        black art of batch file writing in detail in the release docs,
        but the basic semaphores are listed in the docs.

        Also added to the doc file is a brief listing of keys you can
        hit while the user is online.  Alt-C to chat and so forth.

        NBETA002 addresses all the bugs and "features" listed above in
        NBETA001.

94/11/02
NBETA003:

        A comment from one of my users prompted me to do some cosmetic
        cleanup in flagging files during a search or list.  I wasn't
        happy with the appearance there anyhow.  I also noticed that
        flagging was impossible during new file scans and partial
        filename searches - seems the moretype variable wasn't being set
        properly before the high speed searches were invoked. This is
        fixed as of this beta.

        Also, I have added support for file-attach messages.  Any area
        can be defined as a file-attach area and can have its own
        file-attach directory.  File attach access requirements are also
        definable on an area by area basis.  File attachment is
        super-easy in the local mode: all you do is specify the filename
        and path of the file you want to send the user, and the whole
        uploading process is skipped.  For remote users using
        file-attach is just like uploading and downloading files only
        it's done in conjunction with a message, so that files can be
        sent privately from user to user.  This is one of those creature
        comforts that users just _adore_...

        As always, let me know how it works for you.  I have no path
        enforcement code yet so I suspect the unprepared may get a
        runtime 003 when the BBS tries to write or read a nonexistent
        path...

94/11/03
NBETA004:

        In the echo, B.J. Verruyt has pointed out a few bugs; this
        release fixes them.

        I have also done some more cosmetic cleanup.

94/11/04
NBETA005:

        On THC Freedom Online BBS, I set my adult cutoff at 18 years; I
        think this is the legal age to buy adult stuff in BC.  Anyway I
        had an 18 year old user point out a problem in the age
        calculating code that prevented him from accessing the "fun"
        doors at certain times of the month.  This was due to a logic
        bug and is fixed for NBETA005.ZIP.

        I have installed a vastly improved swap routine that will swap the
        BBS lock stock and barrel to EMS if available, or to a swap file
        on the defined RAM disk.  It should leave you with LOTS more
        memory to run doors or external archivers (and external
        protocols when they are implemented).  In theory it is supposed
        to leave you with only a few k resident, but I would be very
        interested to know exactly how much memory the resident part of
        NBBS occupies after it's been swapped.  I would appreciate it if
        the OS/2 testing platoon would let me know how this works in a
        DOS box...

        I have also noticed that I'd forgotten to update the version
        number display with each beta.  I have properly set this
        constant with this release and will try to be more vigilant from
        now on [sheepish look].

        One last note for this beta: I have tightened one of the units
        by over 10k.  This is to shrink the size of the overlay and
        reduce overall memory requirements, and this will be repeated
        for all the units by release time.  However it's possible that
        in some places efforts to tighten the code may introduce new
        bugs.  Please let me know if you encounter any!  The unit
        tightened today was the one concerned witb processing UFO
        keywords, so if you have been hacking in UFO keep it up!

94/11/05
NBETA006:

        Sure enough the code-tightening campaign created some new bugs.
        String comparisons in UFO (in the IFEQ, IFNE, etc keywords)
        suddenly became case sensitive.  RAID!  These keywords (should)
        work again with this release.

        An earlier beta accidentally shut off displaying message text.
        This is fixed.

        I have finally tackled some very elusive, but very annoying bugs
        in the message reading code, particularly regarding the personal
        new scan at login and reading messages in reverse order.  I
        -think- these functions are smooth now; before today they were
        useless.  These bugs had been with me for a very long time.

        I have also fixed a bug in the full screen message editor where
        if you hit the end of a line and it wrapped, and the character
        you happened to be typing at the moment was a space, the space
        wouldn't be continued on the next line and your typing
        afterwards would be concatenated to the previous word. This bug
        has been fixed.

        I have added a hot key to invoke the user editor while the user
        is on.  The key is Alt-E.  If you edit the user who is online,
        his online parameters are also affected, so that the change
        takes effect immediately.

        At the request of a user, I have added options in the user
        [O]ptions off the main menu to set a default archiver and
        default protocol.  If a default is set, the BBS doesn't ask for
        protocol or archiver when downloading, uploading, or assembling
        QWK packets.  I will add UFO keywords for these later.

        There is now a relatively pain-free way to have file
        descriptions of virtually limitless length.  Read Nanobbs.Doc
        for the details.  I will likely add another mechanism for the
        same thing in order to have plug-and-play compatibility with a
        CD I happen to have (Night Owl 13 has FILES.BBS with a
        continuation mechanism different from mine).

94/11/08
NBETA007:

        A couple of days hiatus from coding was due to some hardware
        problems here.  All is temporarily OK, and some new code is now
        available.

        I have added another mechanism for continuing file descriptions.
        See NANOBBS.DOC.

        I have also added automatic FILE_ID.DIZ importation: if NanoBBS
        is able to extract a FILE_ID.DIZ from an uploaded file using any
        of the archivers defined in the config file, it will do so and
        will import it to the FILES.BBS description instead of asking
        the user for a manually entered description.

        This uses the same code as the QWK upload processor.  If QWK
        works so should this.  If this works, so should QWK.  Let me
        know if either doesn't.

94/11/10
NBETA008:

        I have added some automatic path detection code which should
        address problems reported by several testers.  As long as there
        is a valid compiled config file and language file in the same
        directory as the executables, NanoBBS should run fine even with
        invalid paths specified.

        I am now working on adding a full RIPscrip suite to UFO (about
        50 commands) and this will consume a great deal of time, so the
        new betas will be pretty sparse for the next week or so.  I will
        continue to attempt to address bugs as they are reported but the
        next "new feature" will be a kickass RIP interface which is
        several days off.  I wish there were more hours in a day.

94/11/15
NBETA009:

        I am still working on adding RipScrip graphics to NanoBBS, which
        is why the long delay since the last beta.  Unlike most BBSes,
        NanoBBS's RipScrip will not be limited to a built in detector
        and a bit to set to determine whether to use a .ANS or a .RIP
        file.  NanoBBS will have full plaintext command support for the
        entire protocol built into both the language files and the UFO
        language.  In fact the UFO RIP support allows the use of
        iterated commands and variables integrated into the RIP support
        to provide effects and interactivity of a calibre that is simply
        impossible under BBS systems that use static RIP files only!  Of
        course, support for static RIP files still exists as it should.
        The protocol is now implemented but I am still working out some
        picky bugs and will document the protocol when the bugs I find
        are gone; this should be no more than a couple more days.

        Don St. Germain has reported trouble with the BBS hanging up at
        the end of a call; I have noticed this on THC also and I have
        added a 20 second timeout in the hangup code, and a slight
        modification to the sequence of the DTR drop which is supposed
        to cause the hangup.  Hopefully this should fix the problem.

        I have also (in the process of adding RIP) made NCOMP several
        times faster - it compiles to memory instead of disk and saves
        the whole enchilada at once.  Much faster!  And easier on the
        hard disk.  I think I'll add this feature to UFO.EXE and make it
        faster than Mecca - which is written in the allegedly-faster
        Watcom C!

        There are also a few new (documented) UFO verbs; INC, DEC, SHL1,
        SHR1, SHL and SHR.  These perform increments, decrements and
        bitwise shifts left and right on variables in UFO.

        The debug code which printed out those C:\BBS\ type directories
        at user logon has been eliminated.  It was never visible to
        users anyway.

        Oh yeah, for those of you running Rancho Nevada, I took a little
        time out this evening to fix a couple of bugs there too.
        $RN332.ZIP can now be file requested from me at 1:340/26.  The
        FEATURES.TXT file in the archive explains the fixes.

        One last thing, I would remind everyone on the beta team that
        there is an echo whose purpose is reporting of bugs - and it's
        the deadest echo on my system, while my netmail area is crammed
        with bug reports!  Please, use the echo to report bugs so that
        other testers experiencing similar problems can pipe up and
        offer more details.  The quality of this BBS is equal to the
        quality of the problem reporting each of you gives!  In order to
        make a top-quality BBS I need top-quality feedback, so please
        make this easier and use the echo!

94/11/16
NBETA010:

        Some of the RIP stuff is now documented.  Check out UFO.DOC.  I
        have made improvements to NCOMP.EXE, and added totally
        transparent RIP language support - each language has an
        ASCII/ANSI language source file (ending in .TXL) and a RIPscrip
        source file (ending in .RXL).  Very few other BBSes have this
        level of RIP integration available, let alone the RIP UFO
        scripting ability.  If both are present NCOMP compiles both.  If
        a user has a language selected and is using RIP and a RIP
        version is available the RIP version is used, otherwise the
        ANSI/ASCII version is used.

        It's worth noting that the [rip_pixel] keyword is considered a
        sort of "junk" command by the very people who designed the
        specification for RIP; this is because they expected RIP to be
        used in a static fashion as ANSI is today.  One of the .UFO
        examples, RIPSTARF.UFO, uses this so-called "inefficient"
        command to very good effect, and I am sure the imagination of
        other sysops will give birth to much more spectacular results!

        I have included a couple of .UFO files which illustrate RIP UFO
        tokens.  It's really cool (IMNSHO) to be able to do RIP in
        near-plain English without buying an expensive paint program,
        but I have already noticed several syntactic bugs and I assume
        that there are more.  The chief symptom is that a command will
        simply not execute or will execute totally wrong.  If this
        happens to you you may have found a command which is not parsing
        enough parameters; please let me know which command did this and
        include a copy of your UFO source if possible.

        I have also made some refinements to the RIP detection sequence.
        It still occasionally registers a false negative, but apparently
        the timing of Desqview is more to blame than anything else.  I
        will experiment with some special timeslice forfeiture
        techniques RSN if this keeps up...

        Note: if RIP is detected NanoBBS will expect .RIP files in
        certain places!!!  I have not yet built any .RIP files for these
        but if you copy the .ANS versions to .RIP the users will be able
        to use the system normally until I get some nice RIP.  Or, you
        can build your own, whichever suits you after all it's YOUR BBS.

        The sample .UFO rip files are in the /misc directory...

        In other news, there are a couple of new UFO keywords; ADD and
        SUB will quickly and efficiently add and subtract nouns.  This
        is more convenient than using the mathematical adjectives (which
        are still useful as they are more flexible).

        Also I have been informed that some users are getting no
        linefeeds.  I still do not know if this is because they have
        turned off their linefeeds (and couldn't figure out how to turn
        them back on after the screen turned to mush) or due to a bug,
        but I have taken two steps to solve the problem anyway:
        Firstly, there is now an idiotproof subroutine which asks the
        user how many rows of dots they see, and if they only see one
        row they need linefeeds (and are told to respond that way).  The
        other step I took was to add redundant code in several places to
        force linefeeds on until the user has actually logged on.  This
        may screw up some non-IBM types but they are a tiny minority
        who can still turn the linefeeds off after they're logged in
        anyhow.

        A cosmetic bug in the wait-for-call has been fixed.  It used to
        not properly reset the "rings" counter to zero when an incoming
        ring failed to produce a connection.  This is expected fixed
        with this release.

94/11/19
NBETA011:

        I should clarify that the INSTALL procedure is for NEW
        INSTALLATIONS ONLY.  DON'T RUN INSTALL EVERY TIME OR IT WILL
        OVERWRITE YOUR EXISTING CONFIGURATION!

        The files PROGS.EXE and STUFF.EXE are self-extracting archives.
        It should be safe to run PROGS.EXE every time (and you should).
        You should run STUFF.EXE in a scratch directory and copy any new
        files you need from that - like this one.

        The RIP tokens in UFO are now fully documented - they can also
        all be used in language files exactly as they are in UFO except
        that Nouns cannot be used - all embedded language RIP commands
        must have constant parameters!  The syntax for RIP in the
        language files is otherwise the same.  I should mention that
        there are a few picky arcana in the RIP protocol which I was
        unable to decipher from the Telegrafix spec sheet; in these
        cases I have put in a comment like "please see the original
        RIPscrip spec from Telegrafix for more information" - which you
        should in those cases, as you likely will learn more than I know
        about RIP by doing so.  I should mention that a week ago I
        knew virtually squat about the technical end of the RIP
        system... I have had to "grow up fast" on that one so there may
        be BUGS, let me know...

        The language files now come with two sources: one for ASCII/ANSI
        which ends in .TXL and one for RIP which ends in .RXL.  The
        version of NCOMP released in NBETA010 compiles both in sequence.

        I have added support for a Time Bank to the BBS.  You can set
        the maximum allowed withdrawal and deposit amounts in the
        general config file using the MAX DEPOSIT {amount} and MAX
        WITHDRAW {amount} keywords as illustrated in the example
        NODE1.CTL.  It is fairly self explanatory for the users.  I
        think I have it smooth, so that withdrawal limits are enforced
        and the user is properly docked his time when he deposits.  Any
        bugs, you know where to post...

        I have also added the ability to pass a time-to-next-event
        parameter.  The /T{minutes} command line parameter can be tied
        into your BBS batch files called up by Binkley or Frodo to force
        the user into a time limit that may be shorts than he's
        otherwise entitled to.  This can be used, for example, to ensure
        that your mailer is available at the beginning of ZMH.  I have
        not tested this feature in conjunction with the time bank at
        all, and I suspect that the user may be able to defeat this
        using the time bank if he has an existing balance.  Let me know
        what happens.

        I have also fixed a long running bug in the code that
        compensates users time for their uploads.  It now properly adds
        time to the current call and properly reports this time to the
        user when it is awarded.

        I have also added another security feature, the "barricade"
        file.  This lets you selectively bar individual users from
        specific message bases without otherwise affecting their access,
        providing an unobnoxious way of complying with echomail
        moderators' enforcement directives.  The NANOBBS.DOC file now
        contains what will likely by the final form of the chapter on
        this feature.

        I have improved the intelligence of the time warnings, so that a
        five-minute warning that occurs two minutes before the user is
        due to be axed does not tell the user falsely that s/he has five
        minutes left.  There are many reasons (doors, external programs,
        downloads) why a user might get the first time warning late, but
        now it tells the user how many minutes s/he's REALLY got.  Ditto
        the final warning; it no longer is fixed to 60 seconds (but
        still displays its warning in seconds).

        Last update I reported a cosmetic bug fixed where the number of
        rings received by the WFC screen was incorrectly reported.  That
        bug was only made weirder and not fixed by NBETA010 but is fixed
        (and I have personally tested it) with this version.

        Lastly, now that the gargantuan task of implementing a RIP
        scripting language is substantially behind me, the updates
        should start coming on a nightly or almost-nightly basis again.

94/11/20
NBETA012:

        What was to be whipped up in an hour ended up taking eleven
        hours today.  But, the EVENTS are now coded!  See the new
        NODE1.CTL for a set of examples; NanoBBS events are EASY to set
        up!  Events can be forced or relaxed, and have great day/time
        flexibility!

        I have fixed a rather horrific bug in the Alt-E user editor - it
        would remain in local mode and the user would be unable to
        resume his/her session after you returned from the editor!  This
        is now confirmed fixed (I checked).

        I have twiddled with the low level comm code some more in an
        effort to fix the problem where the carrier isn't dropped on
        hangup (sometimes).  I am using an extremely straightforward
        FOSSIL call so this shouldn't be happening.  However I have put
        in some debug code to help me identify the problem when it
        occurs.  The little blue hangup window will be a bit ugly for a
        few days, sorry.  There -is- a timeout in place now so that your
        whole system won't be brought to its knees when the program
        can't drop DTR.

        I have added a neat feature that I used to enjoy in my Maximus
        days: There are now 40 sysop-definable function keys.  The keys
        F1 thru F10 will cause the compiled UFO files F1.BBS thru
        F10.BBS to be run according to the key pressed.  This allows the
        sysop to display a UFO file to the user at almost any point
        within the user's call.  The example files F1.UFO, F9.UFO and
        F10.UFO are included.  F1 simply sets the user's time left to
        60 minutes.  F9 is my legendary(????) "Idiot User" key (grin)
        and F10 is a key I used to love way back in the dark ages when
        Blue Board had a function key to drop the user to a 5 minute
        warning no matter how much time actually remained...
        The other 30 keys are Ctrl-F1...Ctrl-F10 (filenames CF1.BBS to
        CF10.BBS), Shift-F1...Shift-F10 (SF1.BBS to SF10.BBS) and Alt-F1
        to Alt-F10 (AF1.BBS to AF10.BBS).

        I also found to my horror today that I had neglected to include
        a [timeleft] noun in UFO - this unspeakable situation has been
        ameliorated with the addition of a read/write [timeleft].  It is
        used in more than one of the example F-key files!

94/11/24
NBETA013:

        Lucky 13!  A bug that was only visible thanks to a faulty
        motherboard on my end is now fixed.  I'll explain the problem.
        Every now and then, the tick interrupt would simply stop
        occurring, and with that so would the DesqView timeslices and
        the real time clock.  Usually it would come back within a couple
        of seconds and if a user was online he could continue as if
        nothing happened (and in fact might not even notice at all if
        he's using a slow modem, thanks to buffer lag).  But sometimes
        it would stay frozen long enough for the user to assume the BBS
        had crashed and hang up.  When this happened in a file list, it
        would cause the BBS to lock up tight.  I couldn't figure out why
        until I decided the problem might be in the code that actually
        writes out the file descriptions (since that's where the lockups
        occurred).  Sure enough, there was NOTHING to prevent a loop
        which writes the spaces that tab out the formatted description
        from continuing should the user hang up.  Worse, with no carrier
        it would wait on a dead com port for input, by now at a no
        longer valid baud rate, never to recover.  Sometimes this loop
        would actually tight-lock the whole system although I still
        don't know why -that- happened.  Anyway, I added some extra
        carrier checks to that part of the code and it should no longer
        be a personal problem on my own BBS, nor for any other sysop
        experiencing similar hardware trouble.

        This might possibly be related to a long-standing bug in Rancho
        Nevada which Allen Walker and Don St. Germain have long
        reported.  I will keep you posted on the RN situation.  RN and
        NanoBBS share a lot of code; much of Nano's code was originally
        developed for use in my doors, and many of Nano's code
        improvements have been re-integrated into Rancho.  The two
        products are as intimately related as if they were sisters.
        That's why I am mentioning Rancho problems in the NanoBBS echo
        and in this file.

        A few logic bugs have been fixed, and I have re-organized memory
        usage such that you should have close to 80k more memory
        available, or better yet it can run in windows as much as 80k
        smaller than before!

        I have implemented a full internal TommCHAT in this version.  I
        will be adding some UFO tools and canned main menu options to
        work with the chat before release, but for now if you enable the
        "multinode" keyword in the config file and specify a valid IPC
        path your users will be able to chat with each other (assuming
        you have 2 or more lines).  There is a new "/" command at the
        main menu for the main chat system and a "W"ho's online command.

94/11/27
NBETA014:

        Time is now frozen in chat mode!  This is a rather important
        feature if, like me, you sometimes get into REALLY long
        protracted chats with users.  I was getting fed up with having
        to manually give users time back, now you don't have to as time
        spent in chat "doesn't count".

        A bug reported a few weeks ago by Don St. Germain, that global
        newscans would go round in circles and never terminate, has also
        shown up in downloading .QWK packets.  The cause is the same as
        that of the global newscan bug, and the fix is exactly the same
        as was the global newscan fix.  I have also made the packet
        assembly procedure more informative for the user - if it turns
        out that there is still an endless loop in QWK (which is very
        unlikely now) at least users will know!

        I have also added the key code, node limits and the two
        unregistered limitations.  Without a key, NanoBBS will only
        allow two copies of the BBS to run with the same system
        directory.  It also limits all calls - even for the sysop - to a
        maximum of 60 minutes.  You will each be receiving a USL
        (unlimited site licence) key within a day or so of receiving
        this beta.  You'll also be getting a copy of the legalese that
        goes with the key; it applies to all keyholders including the
        beta team so read it!

        Another bug reported by Don is being investigated.  What happens
        is that sometimes "K"ill defaults to an invalid message number.
        I have added code to read in a valid current message, but I
        somehow don't think this will solve the problem.

        There is now an option to blank out a user record in the user
        editor.  As a safety feature, the user must be "deleted" with
        the [Del] key first!  Use Alt-B to blank out users and remember
        blanked users are NOT recoverable!

        IMPORTANT: I have changed the syntax of the SYSOPKEYS and
        NEWKEYS keywords in the NODE1.CTL file!!!  THE OLD SYNTAX IS
        GONE!

        Example of old syntax:

           ;This indicates that flags D, E and F must be set for sysop
           ;functions!
           SYSOPKEYS -------------XXX

        Examples of new syntax:

           ;Same thing!
           KEYS SYSOP DEF

           ;No keys set for new users
           KEYS NEW



        Also, the undocumented "plaque" command ($ at main menu) has
        been enhanced.  It had been very buggy but was fixed around
        NBETA007 or so... I had forgotten to mention this...

        Overall, I am noticing fewer and fewer problems.  As release
        approaches, NanoBBS is looking more and more like a finished,
        market-ready product.  Keep the quality bug reports coming,
        guys!

94/11/28
NBETA015:

        The product is still getting smoother and smoother.  I'll be
        able to see my face in it pretty soon...

        I have updated some of the user booleans and completely
        documented their UFO syntax equivalents.  All user booleans are
        now fully implemented.

        I have also fixed a few little problems I've noticed in NanoCHAT
        and added a generic QUIT, HELP and EXIT command (with no slash)
        so that NanoCHAT is more familiar to users who call Galacticomm
        systems.  I think I may also add a super-k-neet0 /GO command
        feature as well; this would be incredibly powerful and would
        only take a little more extra code.  I'll work on it after
        release... And maybe a clone of Galacticomm's Registry feature.

        I have fixed the problem where the screen is full of overwritten
        diarrhea after returning from a door.  Seems it was
        repositioning the cursor at (1,1) on the nicely saved and
        swapped video screen.  This fault is no longer possible.

        I have added UFO keywords to deal with frozen time - the
        [freezetime] and [unfreezetime] keywords do what their names
        imply, while the [iftimefrozen] keyword processes to the next
        mark if time is frozen.

        A problem with ANSi and RIP autodetection had been caused by
        placing the detect routines in a little-used overlay whose
        overlay overhead was too high for the timing required.  This has
        been fixed by putting those two routines back where they came
        from, which unfortunately increases the .EXE size a bit.  I have
        also increased the size of the overlay buffer by 4272 bytes in
        an effort to prevent future such problems.

        Don has noticed a few more bugs with the global new scans, and
        in my efforts to fix them I have also noticed a couple of logic
        bugs in the "S"etup Scans code.  I am pretty sure that it is now
        impossible for the endless area scan loop to occur, and the bugs
        in the lastread code which caused some weirdness in repeated
        newscans are also fixed.  The "S"etup Scans are also
        (apparently) fixed.

        NOTE: My BBS is 100% Squish based.  I have not tested NanoBBS
        with *.MSG or JAM on any more than a trivial basis.  I have been
        operating on the assumption that Mark May's MKMSG units are
        uniform over each format and I realize that this may not be a
        valid assumption.  However, since I don't run *.MSG or JAM I am
        not able to exhaustively test these formats myself, therefore I
        must rely on the beta team to provide me with -quality- bug
        reports, meaning every little inconsistency between Squish and
        *.MSG and JAM that you can find needs to be reported as
        completely as you can.  I have the source - I can fix May's bugs
        if need be.  I just hope I don't have to...

        Several picky NanoCHAT bugs are fixed.

94/11/29
NBETA016:

        No longer are "spaces" (actually nulls) displayed when using
        sysop keys in chat mode.  Also it is no longer possible to
        recursively invoke chat when you're already in chat.  No-one had
        reported problems with this but it could get annoying and may
        have caused a stack error if allowed to recurse too many times.

        There is now a freeze-time sysop key.  Hit Alt-F to toggle
        frozen time.

        There is now a drop-to-DOS sysop key.  Alt-J swaps out the BBS
        (giving you the maximum size window possible) and gives you a
        real live honest to Gh0d DOS prompt!  Kool!

        I have also added the Alt-Z sysop key which switches between the
        three video modes (TTY, ANSi and RIP).  It's still a bit buggy
        but I'm working on it...

        When you edit a user online, if you change his access level, his
        time limit is now immediately updated to reflect the change.

        I have added a %c parameter to the doors.  You can use %c in
        place of the commmand.com comspec.  A use for this is if you
        want to call up a door using a batch file (as is required by BRE
        and some others).  Your COMMAND parameter would look like this:

                command %c /c bre.bat

        This is documented in the DOORS.CTL file that comes with the
        distribution archive.

        NanoBBS now attempts to auto-detect ANSi -before- the [Hit
        Enter] prompt whose purpose is to swallow spurious connect
        strings before they can fuck up the ANSi detector.  If ANSi is
        not detected the BBS tries again after the [Hit Enter] and
        before the licence banner... It is at this point that the line
        is assumed to have settled down, and an attempt is made to
        auto-detect RIPscrip.

94/11/30
NBETA017:

        I have added some improvements to Doors.  For starters, you can
        now specify a "bogus" last name to be used when a user is using
        a one-word pseudo.  You can also make NanoBBS use a user's real
        name when calling doors instead.  I have also fixed a bug which
        wrote a "local baud" instead of the proper "0 baud" to
        DORINFO1.DEF.

94/12/04
NBETA018:

        Now working full time on the docs.  I will fix any more bugs
        that are reported but all "new" features are finished!

        I have noticed that users can post to a real name message base
        using a pseudonym via the QWK channel.  This is no longer
        possible, doubtless to the delight of Scott James.  QWK uploaded
        messages will now be posted with the real name or username as
        apropos.

        I think I have fixed an undefined variable in the wait for
        caller code which forced Nano to dump the user as soon as the
        connection was complete.

        Runtime errors are now written to the NANOBBS.LOG file.

        NANOBBS.LOG now reports node numbers for multi-node installations.

        It is now logged when you enter and exit chat with a user.

        You can now log all text seen in SysOp chat.  Just hit Alt-L at
        any time during chat to toggle SysOp chat logging.  This can be
        useful if a user has been abusive or threatening in chat, or if
        you want to save a phone number or some other piece of
        information the user gives you in chat.  You could even capture
        a text file this way although it'd be slow and inefficient.

        I have also fixed a bug in the NIDX / BBS/F code which would
        abort with a runtime error after a certain number of file areas
        had been processed.

94/12/04
NBETA019:

        I have added code to check for the presence of the IPC directory
        and try to create it if it doesn't exist.  This is for when
        you've specified a subdirectory of a RAM disk - which would not
        exist at system startup and needs to be created.  I think this
        is the cause of a Runtime 003 reported by John Richards.

        I have also located an undefined boolean (LOCALMODE) which caused
        NanoBBS to write a baud rate of 0 to DORINFO1.DEF and DOOR.SYS
        no matter what the user's baud rate was.  I run mostly my own
        doors (and Allen Walker's) which aren't affected by this so I
        hadn't noticed, but Don St. Germain pointed out that this causes
        some doors to just sit there forever.  I am sure that it is
        fixed now.

        The UFO syntax docs are finally complete!  This beta comes with
        a comprehensive description of the UFO lexicon in UFO.DOC.

94/12/06
NBETA020:

        I have made major changes to the installation system.  It will
        now -update- your language files, not overwrite them, preserving
        your custom strings while adding in new ones.  If your
        NODE1.CTL, MSGAREA.CTL, or FILEAREA.CTL files already exists it
        will not overwrite ANY config files.  If any of the WELCOME.*,
        BYE.* or LOGO.* files exist, it will not overwrite any of the
        MISC directory files.  It will now always overwrite all of the
        executables and overlays - this is important as a mismatched
        version between the executable and overlay would cause an
        immediate crash and probably a system lockup.

        It should be -safe- to install updated betas using INSTALL now!

        Some improvements have been made to the message base code.  I
        have reduced the memory size for the message objects to just
        above the maximum amount that Squish will toss.  JAM is
        unaffected by this as it was already more memory efficient than
        Squish or *.MSG.  It should be possible to get more message
        objects into memory at once if need be, thus reducing the
        possibility of an out-of-memory error...

        I have fixed a cosmetic bug in the sysop bar (it'd display
        "ANSI" even if the user had RIP or TTY until an Alt-S).

        I have also fixed a couple of places in NanoCHAT where a user
        who was not in chat could have actions and messages sent to them
        - this is no longer possible.

        Until such time as I find a truly bulletproof way to handle the
        .NNS (Nanobbs Node Stat) files in the event of a crash, I have
        disabled rigid licence enforcement.  Better business to err on
        the side of trust, and all that.  I will actually likely release
        the software without fixing this.

        When will the software be released?  My "bug board" is empty and
        I have no new features to code.  Barring any catastrophic
        failure reports from any of you guys, the BBS will be released
        to the public as soon as I get the docs done.  That means all I
        have to do is finish NANOBBS.DOC as the UFO.DOC file is now
        complete.  I should also create a shareware licence doc and
        order form, I spoze.  Maybe a NanoBBS RIP icon too.  I am going
        to release NanoBBS, and THEN I am going to hoist a Christmas
        tree.  That's my general (revised) schedule.

94/12/08
NBETA021:

        Some long-standing logic bugs in the message reading code that
        have plagued me since I first coded Nano back in February are
        now FINALLY fixed!  I tested it using various usernames and
        access levels and it is now smooth and stable and secure.  This
        should address those message reading bugs reported by Don some
        time ago.

        I have also noticed that File Attach messages weren't working -
        it would let you upload the file but wouldn't attach it.  This
        is also fixed.

        I have also fixed a logic bug in the ANSi detection - if ANSi is
        not detected on the first go, the user is no longer asked TWICE
        if s/he wants to proceed with ANSi anyway.

94/12/09
NBETA022:

        Several people have reported a runtime 158 copying various $I
        files during INSTALL... err... MPATH shouldn't have been copying
        those in the first place!  I have fixed a string compare which
        caused this.  I am just amazed no-one lost all their BBS files
        as a result, as that's what happened to me when I tried to
        duplicate the scenario!  Good thing I was only using a test
        scratch dirctory...

        I have also improved the intelligence and appearance of the
        UPDLNG program which updates the language files.

        There is some debug code in the file search code.  If you're
        running in debug mode, I expect file lists and such will be very
        ugly for a little while.  I'll take this out in a release or
        two, if it bothers you simply don't use debug mode.

        Most of today's effort has been in docs writing.  NANOBBS.DOC
        is much improved with extended descriptions of all of the
        NODE1.CTL parameters and about half the MSGAREA.CTL parameters
        likewise better documented (with detailed examples) then those
        found in the file itself.

94/12/12
NBETA023:

        I have been struggling with a bug in the code that gets a file
        description.  Sometimes it would just lock right up!  This
        occurred in file searches and new-file scans, and the fault was
        damned intermittent.  But take heart; I have FINALLY pinpointed
        this most irritating bug (which has caused me to wake up to a
        frozen BBS many times) and the fix is included in this release!

        A temporary bug in which the 5 minute warning would tell you you
        had 300 minutes is fixed (i.e. it's back to displaying it in
        minutes, not seconds).

        John Richards has reported that /? in NanoCHAT doesn't offer a
        More prompt as it should - this is due to earlier efforts at
        removing such prompts from the automatic /m commercials.  It is
        now fixed!

        The docs are getting there...

94/12/15
NBETA024:

        This will likely be the last beta before public release.

        I have noticed maybe two times in the past eleven months, and
        again last night, a sharing violation in the code that updates
        the NANOBBS.SYS file.  Although this is a near-freak occurrence,
        I have added code that actually checks to see it it's alright to
        open NANOBBS.SYS before updating it.  If not it retries up to 25
        times.  This is code originally developed for TommCHAT/NanoCHAT
        and is well tested, so the error should not occur any more.

        John Richards pointed out a problem where the User Editor screen
        binary is not shown.  Additional path checking has hopefully
        fixed this.

94/12/15
NANO100B/
NBETA025:

        This beta is issued concurrent to the public release.  Last
        night you got NANO100A; it's a non-beta and a non-release.  Nuke
        it and use this.

        I have performed a number of cosmetic cleanups and added a
        feature to compensate for the lack of .RIP files: if a .RIP is
        not found, NanoBBS will try to fall back on a .ANS and then a
        .ASC before giving up.  I'll make some nice RIP stuff in
        January.

        The docs are complete.  They print fine on my Dataproducts 8070
        printer.  Users of some HP printers may need to force 62 line
        (or longer) pages.  Pages are 60 lines long.

        This is the last official beta until January.  If any emergency
        bugs that cause your BBS to not work pop up I will fix them, but
        otherwise I am taking two weeks off for the holidays, and to
        write the THC Xmas Demo III.  Feliz Navidad!

94/12/17
NBETA026:

        Jerry Driscoll reports that his key no longer works.
        Interesting, since I haven't changed the key encryption
        algorithm at all.  However, the ubiquitous path error leapt to
        mind as a likely culprit, so I added code to first check the
        SYSPATH path, then the path where the executable actually runs,
        then the current directory, and finally the root directory
        before giving up and declaring the key nonexistent.  Jerry, let
        me know if your key works now.

94/12/18
NANO100C/
NBETA027:

        Although I am not officially developing right now, the bug
        reported by Ryan Clifford (not a tester) of a runtime 003 was
        deemed today to be too detrimental to post-release marketability
        to leave to an information report, therefore an emergency
        maintenance release has been issued.  The runtime in question
        was caused by NanoBBS trying to write to a non-existent IPCPATH
        directory.  Additional checking is now in place to disable all
        multi-line communications in the event the IPC path does not
        exist and cannot be created (as in the case of a non-existent
        drive).

94/12/27
NBETA028:

        A problem reported by Don St. Germain has been fixed.  Seems
        NanoBBS wasn't checking to see if the caller is local before
        trying to upload or download.  The protocol engine has horrible
        DCD checking (which I cannot fix without violating copyright) so
        I added code to disallow uploads in all protocols, and downloads
        in protocols other than ASCII, in local-mode logons.  Your
        remote callers will be unaffected.  I should point out that this
        is how Maximus behaves.

        An extremely unimportant cosmetic fix: when you go into
        NanoCHAT, it now says "¡Hola!" (properly punctuated Spanish)
        instead of "Hola!" (poorly anglicised).  This will only take
        effect if you manually update your language files.  If you want
        to do it yourself, the upside-down exclamation point is ASCII
        173.

        RIPscrip parsing has been improved.  NanoBBS will try to keep
        all lines of RIPscrip code to 65 characters or less, where
        practical, and there is now only one "!" per line.  Should be a
        bit faster on the user's end, and there should be less problems
        with less-than-perfect emulations of RIPscrip on the terminal
        end.

        I now have a NANOBBS_.ICN file - it's a really slick looking RIP
        Icon of the NanoBBS graphic logo...

        A [rip_fill_pattern] example in UFO.DOC had several incorrect
        decimal representations of the binary fill pattern (the sort-of
        hexagonal pattern in particular).  This documentation error has
        been corrected.

        Several RIP colour parameters were not being properly parsed by
        NCOMP.EXE.  This is now fixed.

        Don reports that the BBS has frozen a couple of times at
        the get-filenames prompt when downloading.  This prompt uses the
        same input routine used throughout the BBS for string entry, so
        I find it incredible that a bug should cause it to only freeze
        at that one prompt.  I suspect it may be due to a user hanging
        up at that prompt, possibly not knowing what to type there, and
        the input routine may not be handling all carrier-loss
        scenarios.  I have added additional DCD checks and a line of
        code which prevents FOSSIL I/O calls when the carrier has been
        lost.  If this clears the problem up, great, but I still
        haven't duplicated it here.

        I have also added code to explain two common runtime errors and
        how the sysop can resolve them without calling on me for
        support.  Runtime 003 is a path not found error - this is
        usually because of pathing problems, and although I have added
        much code recently to compensate for sysop confusion over paths,
        the possibility of some arcane pathing causing a problem will
        always exist, so a reminder has been added when this error
        occurs to check the paths in the config.  Similarly, Runtime 100
        is an attempt to read past the end of a file, usually caused by
        running a new version without running CONFIG first.  A reminder
        is also displayed (and logged) when this happens.

95/01/02
NBETA029:

        I have added a new feature: "File Groups".  It is a convenient
        way to classify groups of file areas by general fields of
        interest, to make it easier for users to find a particular file.
        This feature has been added in response to criticism from some
        of my BBS's users that THC's 250+ file areas can be confusing to
        wade through in search of files of interest.

        I have also sped up the behind-the-scenes login code quite a
        bit.  By that, I mean the code that updates the user, updates
        the logs, loads up the user's limits definitions, and a slew of
        other necessary things that both user and sysop are blissfully
        unaware of.  There is still a way to go on this, but I should
        have truly fast logons by the end of January.

95/01/03
NBETA030:

        A cosmetic blemish in the language files has been fixed.  SysMsg
        687, which informs the user that the BBS is searching for a file
        (in a find-file search) now has a couple of carriage returns
        after it, giving a neater appearance.

        Another item of concern was that the backspace key didn't go up
        to the next line if it occurred at the beginning of the line, as
        is expected in a screen editor.  This little featurette has been
        added for your convenience...

95/01/06
NBETA031:

        I have added a debug line which displays when the hot-keys
        handler has been invoked.  I would like to find out if a
        rarely-occurring flaw in the hotkey handler (or routines that
        call it) might be responsible for occasional lockups such as
        those experienced by both Don and myself.  No other new items
        are in this release.  If the BBS locks on your user, see if the
        last thing the BBS wrote to the screen was "Hotkey Handler
        Called" or something like that...

95/01/09
NBETA032:

        I have added much code to make it easier to handle the external
        ASCII, ANSI, RIP and compiled UFO files that NanoBBS uses.  In
        addition I have expanded the random welcome screen concept
        sixfold to allow random ANSI, ASCII and RIP in both the logo and
        post-logon welcome screens.  I have added a section to the
        NANOBBS.DOC documentation file explaining all the files in the
        /MISC directory.  Hopefully this will help...  And, the
        practical upshot of all this is that the problem mentioned earlier
        in this file (for NBETA010) about missing RIP files causing an
        error and user confusion, can not exist anymore if an ANS or ASC
        file is available!

        I have greatly streamlined the code which sets up NanoCHAT upon
        a user's logon.  Once a valid password is received, users should
        be logged to the system in about 1 second, not 10.  Much faster!

        If a .RIP file is being displayed, it is now "non-stop" so that
        spurious "more" prompts will not spoil long displays.

        I have created BYE.RIP.  I think it looks pretty cool.

95/01/15
NBETA033:

        Most of this beta's accomplishments are infrastructural, to
        increase speed, stability and sysop convenience.

        Some more RIP improvements include code to always start a .RIP
        file on a new line, and two new languagefile entries for the RIP
        languagefile only which reset the windows at strategic places.

        I have streamlined the efficiency of the ASCII/ANSI/RIP/UFO file
        output by about 50% on heavily-ANSI-laden files, and by much
        more than that on files with little or no ANSI.  It should be
        noticeably faster now, especially in local mode!

        I have modified the same routine so that when it is aborted with
        a hotkey, the colour is always reset to light gray.  Of course,
        subsequent language stuff will probably change this right away
        but at least you won't be stuck with an unwanted background
        colour if you should happen to abort an ANSi with a background
        other than black.

        I have also added code to automatically select a memory-based
        rather than a disk-based text file output wherever possible.
        This will further speed things along and add UFO syntax
        capability to many more files.

        Fixed a runtime that could occur if the "Use FileGroups" option
        is enabled but no file groups dat file exists... it will now
        instead do a normal file area list instead.

        Fixed a bug that would cause a runtime if FILES.BBS exists but
        has a length of zero.

        Added the following Sysop file-area functions: Adopt/Redescribe
        (with auto-DIZ extraction), Global adopt, hide, raw directory,
        override path.

        If you have sysop access you can now download any file on the
        system no matter where it is, so long as it exists.  It doesn't
        even have to be in files.BBS.  Just use the override.  I'll add
        move and kill later.

        I have completely re-written the QWK scanner to be tighter, and
        to leave the message base "open" during the scan instead of
        opening and closing it for each message.  QWK packing should be
        MUCH faster now, even faster than most Fidonet message packers
        on a per-message basis.  By the way, the dots you see during QWK
        packing use a dot to represent four messages.  So if you see
        five dots, 20 messages have been packed.  This has been reduced
        from 10 messages per dot to increase the psychological illusion
        of speed, further enhancing the real speed improvements.

        A little while ago, in an effort to improve speed, I created a
        LIMITS.DAT file which is derived from LIMITS.CTL and compiled
        when CONFIG.EXE is run.  Unfortunately, it's not intuitive that
        changes to LIMITS.CTL are not automatic so I have added code
        which will detect when LIMITS.CTL has a newer filedate than
        LIMITS.DAT, and will recompile it automatically when the user
        logs on if this is the case.  Prettycoolhuh!

        I'm late for my January 15th release.  If you notice any new
        bugs PLEASE let me know RIGHT AWAY so I can get them fixed and
        get 1.01a out to the public SAP!  If I don't receive any
        non-trivial bug reports by the 19th I will place 1.01a (which
        will be this beta plus any minor bugs fixed in the interim)
        on THC and on several FTP sites on Friday, the 20th.

95/01/16
NBETA034:

        OK, Don has pointed out a very nasty bug, which I have noticed
        on my own system, i.e. it took no effort at all to duplicate.  A
        new feature I had added, code named "Gerg Yur Up" (from a
        message generated by an external program by Greg Shergold which
        does the same for QuickBBS) would cause the BBS to go into
        ignore-carrier and out of dump-the-user-cause-he's-out-of-time
        mode, putting him back at the main menu, with a ridiculous time
        left (6:25:and change) and unable to function because the BBS
        was in local mode, as it should be after it thinks it has turfed
        the user.  However, GergYurUp wasn't working properly either,
        and as a result it was leaving the BBS in local mode where it
        wouldn't hang up the phone.  Big problem.  FIXED!  I hope.

        BTW, it's not documented yet, but Alt-G toggles GergYurUp.  I
        will probably call it "Sysop Waiting".  What it does is, after
        the user has logged off, the BBS will play a PagePlay tune to
        signal that the BBS is available, and it will wait for the sysop
        to hit a key, or for 5 minutes, whichever is sooner, before
        re-cycling.  This is to give the sysop a chance to log on or do
        important maintenance on a busy day without having to commit the
        social faux pas of throwing a user off...  When Sysop Waiting is
        active, a flashing black colon ":" on a cyan background appears
        in the lower left corner of the screen.

        Also, I am pretty sure that if, for any reason, a user ends up
        with negative time left, the BBS will always display 00:00:00
        instead of the negative time.  This used to cause serious
        cosmetic problems as the resultant time remaining would scroll
        off the screen, which in the sysop bar is one line long, and,
        well, if it's happened to you, you know what it looks like.

95/01/19
NBETA035:

        This will most likely be NANO101A.

        As requested by Don, a NEWS.* file has been added.  It is
        displayed immediately following the WELCOME.* file.  The docs
        (NANOBBS.DOC) have been updated to explain this.  It's intended
        as a general system news file, and it follows the same general
        rules as most other system textfiles: first it looks for .BBS,
        then (.RIP/.ANS/.ASC) as apropos, .TXT, no extension, and so
        forth.

        The GergYurUp problem wasn't fixed after all.  Now it is.

        I have greatly streamined the process of checking for new email
        at logon.  I used to get mystery lockups during this, I think
        these are gone now.

        Additional new system textfiles: ULPOLICY.* and DLPOLICY.* are
        displayed prior to uploads and downloads, respectively.  Sample
        .TXT files are included.  They are used to indicate system
        policy regarding uploads and downloads, for the user's
        re-edification.  In terms of encouraging adherence to the BBS's
        rules, these work well in WildCat and other BBSes which use
        them.  So now we've got 'em.

        I am still chasing a really mysterious bug where the BBS
        sometimes won't drop DTR to hang up.  It should be; I have debug
        code in this beta which shows that the INT 14 drop DTR call -is-
        being executed.  I have temporarily killed the non-FOSSIL
        version of the DTR drop and the if-then which decides which
        method to use; I suspect I could solve the problem better the
        other way around, by not using the FOSSIL at all...

95/01/23
NBETA036/
NANO101A:

        This finally fixes the bug where the BBS would go into local
        mode and stay there forever (until the sysop logs the user off
        manually) after a user runs out of time.  This is the
        "mid-January" official release.

        There's also a new "S"earch command off the files menu.  It is
        like "F"ind but it searches description strings, at a bit of a
        premium in speed.

        There have also been a couple of minor bug fixes in NEd.  Sysop
        keys are now properly trapped without generating phantom
        characters, and ^Y will no longer let you delete a line when you
        are already on the last one.

95/02/05
NBETA037:

        I have made some improvements to the Account Expiry code, in
        order to facilitate some policy changes on my own BBS.

        The Alt-G SysopNext feature now works properly.

        I have modified logic somewhat such that "hidden" files
        (actually, files with no FILES.BBS listing including .QWK
        packets) are "free" - ratio is not updated, time is not
        affected, and download limits are ignored.  This should fix the
        problem where users exhaust their ratio downloading QWK packets,
        plus allow sysops to have free hidden files, for whatever
        nefarious purposes this will serve.

95/02/18
NBETA038:

        I have added much to this beta, and I will give plenty of time
        to work the bugs out before I release.

        Firstly, Nano now has a "Chat Prompt" mode for multinode use, in
        which most prompts in the BBS will allow display of
        current-channel chat traffic (silencable) and even participation
        in chat from a prompt!  The /M auto messages can now be silenced
        by users of a specific access level, so that you can make this a
        "registered users only" feature if you want.  I'll release this
        feature to Joe Q. Public when I have it integrated with the UFO
        syntax...

        Secondly, there is now a "Review New Users" mode.  Hit Alt-R at
        the User Editor screen and any user the BBS quasi-intelligently
        deems non-validated is displayed for you to consider, nuke,
        edit, or quickly promote to a preset access level.

95/03/15
NBETA039:

        Some users reported new-email check not finding their email.
        This is fixed.

        I think I have also fixed some sticky mystery crashes.  Hotkeys
        oughta work better now.  They DON'T work at the logon prompt,
        and this is deliberate - I want any extra connection characters
        to be swallowed before the user is expected to input anything!

        In addition, abortability of lists and other output with respect
        to NanoCHAT prompt messages is now considerably improved.

95/03/20
NBETA040:

        A really weird lockup has been isolated and, we hope, fixed.  It
        seems to only affect multi-node installations.

        I am going to attempt to refine and debug the transfer
        protocols.  Please report in detail any problems you or your
        users have with file transfers that cannot be explained by user
        dummkopf error ;-)  In particular I need to know which terminal
        programs are giving users the most problems, especially in
        Zmodem, so that I can modify Nano's Zmodem to be more friendly
        with not-quite-perfectly-compliant terminals... And I am the
        first to acknowledge that the Zmodem in Nano itself may be
        deficient; this is what I most want to address and fix at all
        costs!

95/03/22
NBETA041:

        There is extensive debug messaging in the logon procedure so I
        can ensure that I have really gotten rid of that lockup bug at
        logon - it'll be gone in another beta or two.

        I have also added two UFO verbs and a UFO adjective.  See
        UFO.DOC for updates - the verbs are [ghostpost] and
        [ghostpostp], and the adjective is [creditcard].  It is now
        possible to write a UFO script that accepts credit cards,
        upgrades the user's access based on this, logs the fact, and
        informs the sysop BY EMAIL!  Try THAT with an external Visa
        door!!!  I will be writing such a script for my own use before
        next beta and will include it in the distribution archive.

95/03/30
NBETA042:

        A crash on my machine forced me to fall back on a backup of
        source from before [ghostpost] therefore it will not work as
        documented for a beta or two.  This has also given me the chance
        to identify some inefficiencies in code and clean them up, so
        all is not disaster and chaos.  (on a personal note, I know what
        caused my crash.  I'd like to tell you where NOT to buy an IDE
        multi-I/O card but I don't feel like being sued today...)

        I have added a little code to the chat system code which will
        prevent a rare runtime error from occuring when two nodes try to
        write to the same temporary filename simultaneously.  If a
        collision is detected the later task (meaning: the one which
        would have crashed before this mod) will try again with a
        different filename, preventing the BBS from booting the user off
        with a Runtime Error 5.

        A new "post rewards" system has been implemented.  When a user
        enters a message, a variable amount of time is deposited to the
        user's time bank balance.  There are two tiers so you can reward
        posters of long messages more than for trivial posts, and you
        can also set the cutoff of what counts as a "long" message.
        This does not count for QWK uploads (yet).

        Another new feature, related to the above, is the capacity to
        "freeze" time during message posts.

95/04/30
NBETA043:

        After a month of poring over the Zmodem code (which I did not
        write) I believe that I have successfully identified and
        eliminated the problems some users have been experiencing in
        downloading with Zmodem.  With that, this Public Beta is
        released.

        The UFO [creditcard] token now recognizes Discover cards.

95/05/02
NBETA044:

        NEd (NanoBBS Full Screen Editor) now has a Ctrl-A key which
        inserts a space into the current line at the cursor position.

        A runtime PagePlay and a bunch of page tunes are now included.
        PAGEPLAY.DOC explains how to create the tunes and use
        PAGEPLAY.EXE to test them without having to load up the whole
        BBS.  PagePlay itself is a stand-alone utility which, in its
        full implementation, can also play and convert tunes for other
        BBS software.  The two hardcoded tunes are PAGE.PPL (played when
        a user pages) and SOS.PPL (played when a fatal error occurs).
        Any other PagePlay tune can be played most anywhere through the
        use of the [pageplay] UFO keyword.  TUNES.ZIP contains the tunes
        that come with PagePlay.  Give them a try, some are very good,
        others are quite short and designed specifically to be used as
        sysop pages or error/warning messages.

        The UFO [ghostpost] and [ghostpostp] keywords are back!

95/05/09
NBETA045:

        There was a place in the QWK packer where it could possibly hang
        if the user got impatient and dropped carrier while the packet
        was assembling.  (I hope) this is now fixed...

        A new CONFIG token has been added - SHOWUPLOADER, when active,
        will tell NanoBBS that, after a user uploads and describes a
        file, the user's username should be added to the end of the
        description, e.g. "Uploaded by: {UserName}".

95/05/13
NBETA046/
NANO110:

        This is a public general release.  A freak hangup bug has been
        corrected.  A new config token "HIDESYSOP" which refrains from
        including sysop logons in user-viewable logs, has been added.
        The docs have been updated.  Some default textfiles have been
        changed (un-THC'd).  The NNS files and bogus licence violations
        are toast - I've gone to a completely different, much more
        stable licence enforcement system!  Also all of the cosmetic
        features (such as the $ info) which had been lost in the crash
        last month are now restored!

95/05/27
NBETA047:

        MFB now supports an INCLUDE parameter, making it much easier to
        rotate CD-ROMs.  MMB and CONFIG also include this parameter.
        Several include files are, well, included as examples.  This
        should greatly simplify configuring multi-node systems.

        Formerly, when you went /ks in NanoCHAT, it would report -1
        bytes free on the IPC drive.  This has been corrected.  This
        problem also existed in the TommCHAT product and has been
        corrected there too.

        Four new UFO tokens have been added which will enhance
        flexibility for sysops who want to have multiple logons per
        online session.  The [logoff], [bye_nohangup], [donthanguponbye]
        and [hanguponbye] tokens let you control whether the BBS
        actually hangs up after a logoff.

95/06/03
NBETA048:

        I have improved the intelligence of the line counter quite a bit
        - it now detects unintentional line wraps and bumps the counter
        so that More prompts occur like clockwork even when some lines
        are longer than the screen!  Likewise, the message headers now
        stay on the screen 'til the first More prompt, instead of the
        BBS displaying the full 24 lines of a message's text and shoving
        the header into limbo...

        I have also finally solved the last of the problems with
        searching new e-mail at logon.  Note that this feature only
        searches the private email area; to scan all areas users must do
        a global new scan (which can be time consuming).

95/08/07
NBETA058:

        There have been a great number of fixes since NBETA048, so many in
        fact that there hasn't been time to type them all out here.  The
        bug where the last message area defined would not show up in a
        global scan or QWK scan is now eliminated.  The bogus "Missing"
        files are gone.  A number of very silly defaults in the
        distribution archive have been corrected.  The BBS will no longer
        crash on account of your not having run BBS /F beforehand.  There
        are now 32 user keys.  And yes, Don, you can now select whether you
        want new-personal-mail scans to include all areas in the user's
        scan list or just the defined private area.

95/08/08
NBETA059(b): (Some testers may have 059, no letter, which lacks a few of
              the release 1.12 features)

        There is now true support for non-disclosed gender.  Assuming you
        have set gender as an optional user field, users may choose, during
        the new-user application process, to protect the privacy of that
        information by not disclosing the gender.  Non-disclosure is
        treated by NanoBBS as a third gender.  Thus, undisclosed users
        cannot access message areas that are restricted to women only or to
        men only.  You may want to apprise your callers of this fact before
        they apply for access.

        The docs have also been overhauled.  To be different (NOT to be
        politically correct!), all personal pronouns are now in the female
        gender (grin).  I did a series of search-replace macros, so it's
        unlikely I missed anything, but if you notice any serious
        grammatical or spelling errors (NOT stylistic warts) let me know.

        An inconsistency in the JAM code (versus the Squish and *.MSG code)
        has been detected that would cause, in JAM areas only, the BBS to
        fail to display the last line of each message.  This is now fixed.
        Also apparently affecting JAM areas only was that it was possible
        to create a message -20 if it was the first message.  Only problem
        was, NanoBBS chokes on negative numbered messages.  Both the
        illness (the negative numbered messages) and the symptom (Nano's
        tendency to choke on them) have been cured.

        The non-FOSSIL serial support has finally been added!  So far, beta
        testing has been done only with a USR Sportster V.32bis internal
        modem, but the results are very solid.  NanoBBS supports up to
        COM16 by itself; my alpha testing so far has encompassed COM1 and
        COM2 only.  You can set non-standard addresses and IRQs for any of
        the 16 ports.  If no port config has been set (i.e. if you're using
        a NODE1.CTL that came with an earlier version) NanoBBS will default
        to using settings that will work with virtually every COM1 and COM2
        in the world and with many internal modems on COM3 and COM4
        (assuming their IRQs mirror those of COM1 and COM2).  See the docs
        and NODE1.CTL for configuration examples and information.

        New code has been added to accommodate a few non-standard FILES.BBS
        files I have encountered on several CD-ROMs.  The new tokens in
        FILEAREA.CTL will allow you to run many CD-ROMs of questionable
        compatibility virtually straight out of the box!  There are now
        five example include files illustrating the use of these tokens,
        and with only some paths to be changed you could use the examples
        directly with the CD's they are designed for (Night Owl 15 and 16,
        Monster Media 10, PC-Sig 14 and The Hacker Chronicles ][).

95/08/21
NBETA060:

        This beta includes the first of the new features for 1.2: it now
        supports UFO labels up to 16 characters in length.  This is a big
        improvement over [label BF] and [goto BF] - now you can put
        [label bigfat] or [goto bullfudge].  Labels are case insensitive.

        NanoBBS no longer updates lastreads when checking for personal
        email.

        The BBS now handles "free" files much better.  It no longer adds
        the byte counts for "free" files to the user's download totals,
        precluding later downloading of non-free files.  Before, you could
        download all the free files you wanted but if you went over your
        limit on them, tough.  The BBS now also hides the "/b" used to
        indicate a free file.

        The BBS no longer skips ratio checking on CD-ROM downloads.  This
        one drove me spare until I nailed it.

        The BBS can now handle even more kinky versions of FILES.BBS.  For
        example, on some really wacky CDs, FILES.BBS includes file dates
        and sizes, with the file size working backward until it actually
        touches the filename, like this:


                SMALFILE.ZIP  50065 94-01-01 This is a smaller file.
                FILENAME.ZIP1678082 95-01-01 This is a file.

        Previously, Nano would deem FILENAME.ZIP1678082 a "missing" file.
        Now, it detects this occurrence and splits it up, neatly displaying
        the file size (or not, if you have {correctly} specified the
        PCBSTYLE keyword in your filearea.ctl).

        A number of minor cosmetics have been cleaned up, mostly in the
        form of refinements to the file listing bug fixes of the 1.12a
        release.

        There are two more CD-ROMs included in the example control files:
        Night Owl 17 and Night Owl BBS Shareware (from 1994).  I have a
        source for a great many more and plan to include all of them if I
        can.

95/08/31
NBETA60B:

        This, along with NBETA60A.ZIP (not written up here) is a sort of
        "emergency beta" for John Barnard.  The high speed file searches
        are totally, totally rewritten.  The file area file has a new
        structure so the file areas MUST be recompiled using the new
        MFB.EXE.  Also run BBS /F after MFB has been run!  The NANOBBS.HDX
        and NANOBBS.HXA files are obsolete and can be deleted now.  The new
        MASTER.FIL generated by BBS /F is larger but it is a plain ASCII
        file and delivers comparable speed on new-file searches and
        filename searches, and VASTLY GREATER speed on description
        searches!  This rewrite eliminates the remaining extended
        description display bugs and all runtime errors associated with
        description searches!  And it's a whole lot smaller in code size to
        boot!

        A note to the programmers on the beta team - Pascal purists will
        tell you that the GOTO statement is a travesty, an abomination in
        the face of God and J&W.  BULLSHIT.  In rewriting the file
        searches, the use of just three GOTO statements eliminated nearly
        20k of redundant source, plus at least 10 indices and booleans in
        the remaining code, enabling me to use a single universal search
        routine where I had needed three.  The source is more readable and
        the resulting program is faster and far more solid and airtight.
        There are some instances in programming where a GOTO is the
        absolute best way possible to get things done.  Never let anyone
        tell you otherwise.

        Also if you experience weird wrapping problems with the extended
        descriptions in the file lists, add a ~, embedded keyword to the
        beginning of [sysmsg 603] and [sysmsg 604] in all your language
        files and then recompile them with NCOMP.  ~, forces a carriage
        return if the cursor is not on the leftmost column already.  This
        is documented in NanoBBS technical bulletin #2.

        Once I add multinode paging, I shall release NanoBBS 1.14.

95/09/09
NBETA61C:

        This is the last beta before the 1.14 release (barring a
        catastrophe).

        I have added Paging and Telegrams to the NanoCHAT features and
        added many of the TommCHAT bug fixes to NanoCHAT (in fact I ported
        the entire SmartActions code from the enhanced TommCHAT 1.13b
        product into NanoCHAT lock, stock, and barrel!).  If you have
        multinode enabled, I think your callers will really appreciate
        these new features - mine do!

        I have also strengthened the WAIT4IT function that waits for a
        locked file to come unlocked before attempting to open it.  Once in
        a while a user may experience a delay of up to 2 seconds in a
        multi-user function - this is WAIT4IT doing its job: the BBS would
        have exited with a runtime error otherwise.

        File Flagging is now much faster thanks to a last-200-files list
        buffer.  Most of the time, users will no longer have to wait for
        NanoBBS to search the whole index file when flagging a file or
        adding it to the batch from the batch menu.  The BBS will first
        search an in-memory list of up to 200 most recently listed files,
        and only if that fails to turn up anything will the BBS attempt a
        global search of MASTER.FIL.

        A new bug, where the Flagging option was absent from the More
        prompt in file lists and searches, is now fixed.

95/09/11
NANO114:

        Owing to a lack of feedback (and rotgut) from Don St. Germain, I
        dub Nano 1.14 ready for prime time!

        Last minute tweaks:

        I noticed that if a caller enters a message and then aborts it
        without saving, the BBS wouldn't resume the clock if you have
        POSTFREEZETIME active.  Now it does.

        I've noticed a *possible* place where NanoCHAT might drop a message
        every now and then - under certain circumstances it could write the
        IPC itself but not update the receiver's .STC (stack) file.  You
        may or may not notice an improvement in NanoCHAT's reliability,
        depending whether or not you were experiencing such a problem
        before.

        I have also added PAGE and TELEGRAM as internal NanoCHAT commands,
        so they are accessible from within NanoCHAT as well as from the
        canned who's on menu.  They're also available in UFO as
        [canned_pageuser] and [canned_telegram].  I may never add un-canned
        components of these two tokens as they are a bit complicated.  Then
        again, I might yet.  Time will tell.

95/10/14
NBETA062:

        I have spent the last few weeks taking a breather from serious
        programming after the release of 1.14, and I am now working on
        1.16.  Fitting with the new version numbering scheme, all 1.16
        betas will be version 1.15.

        In this beta, I have completely rewritten the global newscan code,
        which should eliminate many nagging problems in navigating through
        global newscans, email checks, and even general message reading.
        I've alpha tested this a lot today and found that all the old
        familiar quirks are blissfully absent... It also turns out that
        there was a logic bug in some of the code that was not rewritten,
        which had occasionally caused an elusive runtime 004.  This is now
        fixed.

        A new feature has been added: you can now type the message number
        of a message you want to read directly at any read prompt.  This
        way you can skip past large numbers of unwanted messages or quickly
        jump back or forward to a message whose number you know.  Most
        other BBS software already had this; Nano should've had it in its
        first release, it has it now.

        There's a new sysmsg 356 to service this feature.

        In addition, when you flag a file from a file listing, you get the
        "More" prompt again.  I will do some cosmetic work on this to
        minimize the number of lines scrolled out during a file flag; I
        might even implement some sort of a screen capture/redraw for a
        zero-disruption flag prompt!

95/10/28
NBETA063:

        A couple of bugs in the new newscan code are fixed: it no longer
        shows private messages you shouldn't be seeing, and it no longer
        gets stuck in a prompt loop without going to the next base.

        I have streamlined a number of things resulting in 28k less heap
        consumption.  This means NanoBBS will run in tighter memory
        quarters than in the last beta.

        I have also fixed a cosmetic bug in the Telegrams where, when you
        received a telegram, you'd see your own name and node as those of
        the person who'd sent you the telegram.

        Quite some time ago, I added a new PagePlay kernal to the BBS for
        its chat page music, but neglected to add in hooks to the modem so
        that the user could abort the paging.  Up until this beta, only the
        sysop could abort a page.  Now, the user can too, as was originally
        intended.

        Additionally, three new UFO keywords have been added, [writebang],
        [noabort] and [abortok], and the UFO script compiler itself has
        been updated slightly as well, with a very rare infinite loop bug
        discovered and fixed.

        And, I have at last located the line of code that sent a carriage
        return but failed to increment the line counter (in file lists
        only) resulting in file lists that often scrolled 30 or 40 lines
        (when you're set up for a 24 line page) before you'd get a More
        prompt.  This is now fixed.  At the same time, I have added extra
        intelligence to the file description wraparound code: it will not
        auto-wrap an extended description that has a high-bit character or
        certain regular ASCII characters as the LAST character of the first
        line of the extended description.  If it detects such a character,
        it will assume that the extended description has extended ASCII art
        or a box or some other large column-sensitive graphic, and will
        honour its line breaks.

95/11/01
NBETA064:

        There was an error in UFO.EXE where it would compile a GHOSTPOSTP
        as a GHOSTPOST and vice versa, resulting in public messages when
        you intended private.  This is now fixed.

        I have further refined the user editor's user flags editor.  It's
        much nicer now.

        I noticed that occasionally, when a user encountered a
        [harddownload] UFO keyword, it would fail to give the user the
        file, either because it was not in a FILES.BBS or because the
        user's ratio was unfavourable.  Since the most common use of
        [harddownload] is for files that ought to be free anyway (such as
        local FAQs, registration forms, must-have files like RIP icons,
        etc) I have added extra code that forces "free" mode when the
        keyword is invoked, so that files thus downloaded do not count
        towards the user's download totals and the ratio is not checked.

95/11/04
NBETA64E:

        This is a response to a serious bug reported by Don St. Germain, in
        which the Chat Prompt would generate a runtime 104.  I was never
        able to duplicate the problem but I strongly suspect an aberrant
        FILEMODE caused the error, so I went over every FILEMODE directive
        in the source by hand and made a few changes which should fix any
        further "not open for input" problems (i.e. runtime 104).

        I have also enhanced the Sysop "file directory override" and "raw
        directory" options at the file menu.  The raw directory now lists
        directories and the override lets you use . and .. as well as
        partial paths.

95/11/11
NBETA065:

        Some problems with flagging files and downloading files that are in
        the last-100-listed buffer have been fixed.  The last of the
        cosmetic fixes for file lists have been applied.

96/01/06
NBETA066:

        OK, NanoBBS development is underway once again after a busy
        Christmas season which left me with no time for programming...

        The runtime errors which commonly threw users out of NanoCHAT have
        been obliterated!  I have put in beta code which prints a warning
        to the sysop screen only whenever the BBS thinks a runtime error
        would have occurred if this fix were not in place.  After a short
        time, you will notice how bad the problem was.

        I have added two more levels of indexing to the master file index.
        MASTER.PRE is a pre-index which is exactly 729 records in length
        and points to offsets in MASTER.IDX.  MASTER.IDX contains
        filenames, file area numbers and offsets into MASTER.FIL.  Although
        I have not yet incorporated the code that searches these new
        indices, the preliminary code (still in testbed) has shown
        incredible results; any file in the system can be located (even
        with wildcards) in less than 1 second on my 486-33.  That's in a
        MASTER.FIL of 2.3 megs in size, indexing 39,000 files totalling
        over 2 gigs.  Not bad!  Next beta will have the new searching
        capability in file flagging and in the Download command and
        File-Search commands.  The new-file scan and description scan will
        necessarily continue to use the flat-file technology currently
        employed in all file searching, which takes a noticeable time to
        find a file.  Although, the flat-file system itself may be improved
        before 1.16.

        There is now code in place to free disused heap blocks (such as
        in-memory FILES.BBS lists) prior to memory-critical operations such
        as message entry and saving.  This reduces overall real-world
        memory requirements and makes out-of-memory runtimes much less
        likely.

        This is the first beta of 1996!  Note new copyright dates.

96/01/06
NBETA067:

        OK, the new searching code is in place in the file area.  The
        "D"ownload command, the flagging from within a file list, and the
        Batch Menu are affected.  All three of these functions are now much
        faster.  Next beta, the "F"ile Search (by filename/wildcard) will
        also have the same technology.

96/01/07
NBETA068:

        Oops!  The new file searching code doesn't search the current
        directory.  This isn't a problem if you're in an indexed file
        section (as all files sections are indexed) but if you're in an
        override directory, that directory may not be indexed, in which
        case a download would fail to find your file.  I have added code to
        use the old method when adding files to the batch from an override
        directory.

        As promised, the "F" command at the file menu now uses the new
        search code.  It's now an FFFF (Fucking Fast File Finder)!

        One thing, the new search code has a weakness: because it derives
        its speed from indexing the first two letters of each filename
        (effectively resulting in a tree with 729 branches at the first
        level) it must search more files if less than two letters of the
        base filename are supplied by the user.  For example, if a user
        wants to download EX*.*, the BBS positions its index pointer at the
        beginning of the files beginning with EX and finds them all very
        fast.  But, if the user requests E*.DAT, the program must search
        through all the files beginning with E.  This may not be so bad
        because all the E's are in one block in the index, but in a large
        BBS it may be noticeably slower.  The worst case is when a user
        supplies only an extension, e.g. *.PHK.  Then, NanoBBS must search
        the entire database for files with a .PHK extension, and is only
        marginally faster than the flat-file code.

        The flat-file search engine, BTW, is still in place because it is
        still the fastest way to do a description search without creating
        another huge index file of description words.  The same applies to
        searches by date.

        Override keys like the ones you can program for the canned main
        menu are now also available in the File Section.  They work the
        same way, except that in the file section you can only have up to
        30 of them, and the keyword in the config file is FOVRSTR instead
        of OVRSTR.

        Doors can now be addressed by their number instead of just the key.
        The prior limitation used to effectively restrict NanoBBS to just a
        few dozen doors; this was unsuitable for a dedicated gaming BBS.
        The canned door menu still uses single keys but this should still
        be more than enough for most BBSes; those that need a huge number
        of doors can now (and should!) build a UFO script to present an
        extended doors menu.  The single-key syntax still works with the
        same UFO keyword, so that existing scripts are not broken.

        I have also taken out some very ugly debugging messages,
        particularly in the file flagging and QWK building code.  This and
        a few rewrites of various inefficient functions has saved nearly
        10k of memory usage.

        It's been a long and productive weekend.  I smell a public release
        coming up!

96/01/16
NBETA069:

        Mostly cosmetic cleanups.  Only John Barnard got this one.

        I have added NanoWATCH, which is an IPC watcher.  Type BBS /A on an
        unused task on a busy multiline system and you'll soon see its
        usefulness.  It provides an at-a-glance status report on the
        current activity of up to 20 nodes.

96/01/20
NBETA070:

        I have added a "divider" feature to message and file area lists.
        When you do a file area list or a message area list (i.e. use the J
        and ? keys) you can now use dividers to break up the list, perhaps
        in categories of topic or of mail network affiliation.  The syntax
        is explained in the sample MSGAREA.CTL and FILEAREA.CTL files.  For
        faster speed you can use a preset sysmsg from the language file, or
        for greater flexibility you can specify an external filename for
        each divider.

        I have also added an "automatic area number" feature to MFB.EXE and
        MMB.EXE.  By using the @NEXT keyword instead of an area number
        (e.g. filearea @next instead of filearea 650) you can have MFB or
        MMB automatically assign the area the number that comes after the
        area number of the previous area.  You can also instruct MMB or MFB
        to automatically increment areas by amounts other than one.

        I have fixed a problem with the full screen editor, in which quoted
        text no longer appears.  This was a new bug introduced in the last
        code-tightening and memory-efficiency campaign.

        I have made many critical NanoCHAT messages non-abortable.  The
        abortability of messages had caused some people to lose /p's and
        the such.

        I have updated the More prompts to be more informative and improved
        the appearance (and verbosity) of the flagging-file lists (lists of
        files that are being flagged from within a file list).  Eventually
        I intend to have a really slick full-ANSI file-tagging system such
        as the one in PC-Board but that's probably not going to happen
        until version 2.0.  Which may come out sooner than anyone expects,
        if progress on NanoBBS continues at this pace.

96/01/27
NBETA071:

        This is the final beta before the release of 1.16.

        I have *FINALLY* nailed the bug where Zmodem transfer rates would
        sometimes really suck.  I had been unable to duplicate it because
        it only manifests for those who've locked their comports at 57600
        or faster, which I don't.  An uninitialized variable in Mark
        Dignam's protocol engine was the source - apparently Dignam did not
        forsee locked baud rates faster than 38400!  I have expanded that
        part of his code to take into account any baud rate up to 655360
        bps...

        I have also taken out the Zmodem beta text which was pretty ugly
        and has now served its purpose.  While I was at it, I improved the
        progress bar in the download screen - it uses a ▌ character to give
        twice as many gradations in the progress bar, so it advances twice
        as often now.  Overall it looks better that way.

96/01/31
NANO116:

        This is the release version of 1.16.

        In addition to all the new features and function improvements and
        bug fixes since the release of 1.14 in September, 1.16 also
        includes a utility to convert the userbase, message area
        definitions, and file area definitions from a RemoteAccess 2.0
        system.

        New features have also been added: You can now prohibit one word
        pseudonyms or one word real names.  And, if you're in sysop chat
        you can squelch the user by hitting Alt-Q.  This is useful when
        you're busy and you just want to say one thing and get out of chat
        and the user won't stop typing.

        The docs are also clarified in a few places.

        The structures are now included.

96/04/14
NBETA075:

        Fixed /KT in nanochat: erroneously changed node on user, now
        correctly changes channel.

        /S in NanoCHAT no longer counts nodes that are "waiting for a call"
        in the "number of users online".

        With the purchase of two 7-tray CD changers on THC, NanoBBS has
        been upgraded to support changers that require an external command
        to change the disc.  Through the use of a CD_ID filearea field, you
        can minimize unneccessary use of external CD change shells.  Your
        CD changer may come with a tray-swap program, I had to put mine on
        a dedicated server on the LAN and assign each tray's drive letter
        to a network directory name, which was then mapped on demand to a
        single common drive letter across the LAN.  Using this technique it
        is also possible to map multiple hard disk volumes to a single
        drive letter, providing a virtually unlimited file area
        addressability under DOS.

        I have fixed a long standing problem where internet e-mail
        addresses sometimes got truncated at 32 characters.  Email
        addresses can now be up to 80 characters.

96/06/16
NBETA077:

        There has been so much added that I didn't have any time to write
        up NBETA076!  Where do I start?  For starters, the gender dysphoria
        in NanoCHAT is now finally fixed.  NanoCHAT also now supports up to
        1000 actions and can index them far faster than before; this is in
        preparation for the upcoming user-definable actions which should be
        ready next beta.  Also, >name commands which cause directed public
        speech in NanoCHAT are now implemented and have significant
        intelligence improvements over the one in Glop.  Also, you can now
        use /handle to send a /p to a user without really knowing his node.

        Not all the new stuff is in NanoCHAT.  I have also fixed ALL of the
        time usage problems by totally reworking the time usage calculation
        code.  To test it, I made the /i8 file in NanoCHAT and also added
        an option to display the same thing at logoff.

        I have fixed quite a few things in NEd, especially dealing with the
        Ctrl-Y line delete.

        There is now code in place to support miniature uses of the
        internal message editors for things like file descriptions, chat
        entry/exit messages, sig files, "about me" files and much more!
        This is preliminary to the user base structure integration which
        places the entry/exit messages in a Squish message base along with
        other message-like user data.  The same file will also hold an
        "about me" message which will be part of the upcoming Registry.
        Note: we will have to call the Registry something other than that -
        we're already stomping on Galacticomm's toes enough as it is.  Any
        suggestions?

        Now here's the big one: I have made a MAJOR change to the user
        record structure!  In order to assist sysops running 1.12, 1.14 and
        1.16 and associated betas, I have included the CONVUSER program
        which does an elegant job of turning the old userlog into the new
        one.

        The first benefit you will notice from the new structure is that
        user logons (and lookups) are way, WAY faster.  Prior to this beta,
        user #3000 took about 10 seconds for the BBS to find before even
        asking the password; now this lookup time is imperceivable.  The
        new userlog structure is indexed and the indices are updated on the
        fly as required.  There is also a UHASH.EXE program to rebuild the
        indices from scratch is they ever become corrupted.

        Users can now have up to 6 lines in their /u1 and /u2 NanoCHAT
        entry/exit messages.  They are now entered in a mini version of the
        message editor, AND they can now be "edited" instead of totally
        re-doing them!

        User passwords are now SECURE.  NanoBBS now stores a CRC32 of the
        user's actual password instead of the password itself.  The CRC, if
        known, cannot be used to logon.  I will shortly add an even more
        secure Base64 encrypted password system to the system as well.  At
        that point, you will be able to have plaintext, CRC32 and Base64
        encrypted passwords in the same user file, used at random.  At this
        writing, the user change-password facility and the new-user
        password entry both store the CRC, and the CONVUSER program turns
        1.16's plaintext passwords into CRCs.

        I have also started putting in code to make NanoCHAT friendly with
        "linked" chat systems.  I am sure I will have to write an entire
        chapter on links before I release 2.00.  When a user logs into an
        account that has been flagged as a "link" account (there is a key
        in the user editor to do this) they will be thrust directly into
        the chat system, their own messages will not echo back to them, and
        /q will disconnect the call.  In addition, ANSI is disabled.  At
        this writing, a remote system with dialout ASCII link capability
        should be able to call a NanoCHAT, log in, and comfortably be
        linked until its link account runs out of time.  Needless to say, a
        special account should be created for each system you expect to
        link in.  I will very soon write outgoing link code as well, with
        an internal dialer and script processor to make links a matter of
        using a /k command from NanoCHAT.

        Among the many other benefits of the new structures, is the keeping
        of a separate "Internet Name" field, which is a 9-character
        username suitable for use as the basis of an internet address.  The
        User Editor has had several new fields added to it, and among these
        is the Internet Name.  If a user doesn't have an Internet Name, you
        can give her one in the User Editor by simply hitting Alt-I.  This
        will make NanoBBS quasi-intelligently synthesize an Internet name
        out of the user's logon handle.

        I have also fixed 3 or 4 annoying bugs in the fast file searching
        code.  Chief among these was that when *.ext (where .ext is any
        extension) was specified in a filename search, NanoBBS would quite
        happily display any file it found that matched the wildcard,
        without regard for whether the user is allowed to download the file
        or not.  This, of course, was inconsistent with Nano's basic design
        philosophy that: areas the user may not access are invisible to
        her.  This is now fixed, and thank Ghod it never did let the user
        flag these errant files...

        There will be many amazing and innovative new features added in the
        coming weeks as support for the new userlog fields is added one
        feature at a time.