Where's the compiler warnings guys?

As suggested/requested by Fernando Toledo in issue #826, you can:
1. run 'jsexec make_areas_ini.js' to export your areas.bbs file to areas.ini
   (your old areas.bbs is left in place, in tact, unmodified)
2. change your Area File in echocfg->Paths and Filenames->Area File to
   somepath/somefile.ini (e.g. "../data/areas.ini") and SBBSecho will use
   the .ini file format instead of the old AREAS.BBS format (NIH)

You can always go back to your areas.bbs file by just reverting the Area File
setting back to some other non-ini filename (e.g. "../data/areas.bbs").

Incremented version number to v3.23

Of course documentation and echocfg changes will need to follow, but this is
enough to start testing (looking at your Fernando! :-).

I tried to minimize the diff as much as possible and resisted updating
(modernizing, fixing) the very old AREAS.BBS parsing and areafix code.
The new .ini code is largely modeled after the old areas.bbs code, but oh,
xpdev/ini_file makes things so much nicer and easier.

There are no known fixes for any pre-existing area file/fix issues (including
issue #826), but it's always possible I've introduced a new issue.

Use BACKBONE.NA from Vertrauen as echolist for all Fido zones
(anyone have a better authoritative http link to a fixed file
name or archive name?).

Are there official echolists for these zones?

Can't used designated initializers in fmutex_init() because this file is still
built with C++Builder6.

and might return before setting it to anything else.

For some reason, MSVC was initializing the time_t (second element of the
struct) to -1, not the int fd (the first element), which was initialized to
0. Weird.

The auto-remove param was only needed for fmutex(), which immediately closes
(and thus don't want auto-removal), so create an internal function that's
used by both fmutex() and fmutex_open().

This is needed for *nix where normal (i.e. not Samba-mount) file behavior
requires that we manually unlink() the file, but not until just before closing
it. So we have to keep track of the file name and the 'auto_remove' desire of
the caller. This is not necessary when the file is on a Linux-smbfs, but we
need to work as expected on normal/local *nix file systems too.

This solves atomic lock file removal for *nix, but does not gaurantee lock file
cleanup upon ungraceful process termination (e.g. crash). At least in this
particular case, Windows beats UNIX.

This reverts commit e55183c0.

fmutex_open()'s auto-remove feature doesn't work on normal/local Linux file
systems: unlink() of a file immediately removes its directory entry allowing
subsequent opens of the same file name, defeating the lock.

I had tested fmutex_open() on a Samba mount (from Linux) and it worked as I
wanted (like the Windows version does). Still searching for a good solution:
if a process terminates, gracefully or not, I'd like the file to be removed
at that time and until then, other processes or threads can't create or open
the same lock file (using O_EXCL and file locking to insure this).

Change requested in issue #747 and from Dan_C in #synchronet

Oh, so much copy/paste eliminated!

This appears to be the best we can do when Windows+M (minimize all)
is pressed.  We don't seem to be notified that we should minimize,
only that a different application is being activated.

This also makes Alt-TAB behave a bit more like expected.

Telnet BINARY_TX mode from the client disables CTRL-C input checking in all
versions of SBBS (before now). This change shouldn't be necessary now, but
it worked-around the BINARY_TX issue when I was having it (couldn't abort
mqtt spy).

This condition caused aborting BBS operations via Ctrl-C to fail when
connecting from a traditional Telnet client using binary transmission
mode (e.g. telnet -8) or SyncTERM v1.2rc6.

The check of rio_abortable was probably enough to disable this function
during file transfers (e.g. we've had no issues with SSH file transfers
that might include byte 0x03 received from the client), but I added the
check for SS_FILEXFER system status check too, perhaps unnecessary.

Update Cryptlib to 3.4.8

See merge request !473

Allow only US-ASCII, and send the BADCHARSET response code indicating
that.  Fixes issue with aerc.

On *nix, you need the command shell to do wildcard expansion of filenames

Add the errno value to help root-cause.

We really should be using safe_strerror() everywhere.

If an original references header field was supplied with the message, include
*that* in the header (since it should contain all the IDs of the replied-to
message thread) rather than just the message's reply_id (a single message
ID) when sending via NNTP. This maintains more NNTP post integrity when
sending back out via NNTP.

Not sure why we were storing received "references" in the hdr.references
returned by parse_news_header(), we don't seem to be using it anywere. Maybe
copied from 822header.js or mailproc_util.js? Seems like cruft, so remove it.

Also, don't ever send an "In-Reply-To" heder field via NNTP (it's not valid
/used for NNTP articles, per RFC 5536).

... so this was just redundant noise. Altough "References" is a valid header
field *both* for email and nntp articles, "In-Reply-To" is for email only.
per RFC 5536

We only want one Message-ID (we'll use the last, since that appears to be the
message being replied to based on SLRN behavior). This fixes reply linkage
when posing from newsreaders that put multiple message-IDs in the
references header field. This is required for SBBSecho to do its magic
creation of the FTN REPLY kludge during export.

This is the fix that Accession was looking for, I think.

This reverts commit d4692e0a.

Not the fix we're looking for.

This reverts commit a7f1a24a.

Not the fix we're looking for.

Use the fastest message base access methods documented.
Cache read/write configs and avoid parsing on read if unchanged.
Make common saves dependent on there being changes.

This is likely as good as it gets (assuming it works)