As Deon pointed out:

I saw that smbactive was removed recently (719b7523), but a quick search of
code, sees reminants in GNUmakefile and other files, which I'm wondering is a
cause of the problem...?

... rather than just failing silently with a special return value
(e.g. false).

When sending a user-to-user file transfer, SBBS (since v3.19) will check that
the file recipient will be able to download it (e.g. doesn't have restrictions
preventing it) and this was failing for most (non-sysop) recipient users since
they wouldn't normally meet the "access restrictions" of the user directory
(by design).

So use js_argc() to report an error if there's fewer than 1 argument, but
don't just fail silently when 2 arguments are provided.

Avoids crash when adding a msg to a non-sub-board msgbase.

It's possible to use savemsg() (from JS MsgBase.save_msg()) to add a message
to a message base that's not a sub-board (not configured in SCFG->Message
Areas and not the "mail" base), but in that case, savemsg() would dereference
an invalid sub in the scfg->sub array and crash. So use is_valid_subum()
to insure the subnum is a valid sub before using as an index.

If/when anyone wants this functionality again, write a short JS util.
For reference:
https://synchro.net/docs/utility_reference.html#SMBACTIV

This fixes issue #384.

This should resolve CID 453850

My first idea was to have a per-external-program setting to enable input
translation, but Deuce suggested it would be better done in input_thread() and
after some thought, I agree. Translations are not done in data/file transfer
mode, so use the CON_RAW_IN console flag to indicate this condition. So even
JS console.getbyte() will return a translated char unless the console is set
raw input mode (this could be surprising behavior for some!).

I considered saving/restoring the console mode when performing a file transfer
but will leave that to a time when obviously needed.

This fixes issue #497 in automatic way (no option needed).

e.g. when using Ctrl-K or when being prompted for key-press due to inactivity

A bare '\r' doesn't move the cursor to the first column in PETSCII terminals.
The '[' Ctrl-A code moves the cursor to the first column with multiple
cursor-left sequences, if necessary.

Ideally this sequence would be part of the text.dat string instead of
hard-coded here.

This fixes issue #561

jsexec is an extra weird case though, so don't touch that one for
now... I assume it'll just break as-is, but maybe it'll work...
Certainly gdi_ciolibinit() needs better error detection.

Not a huge deal, but there it is (or was).

Use a static char string list for the main menu options. These can't be const
becaue uifc.list() *can* modify them (!) - if they're too long.

Free the global opt[] (option list) when exiting.

These really are not of themselves important, but reduce the noise reported by
valgrind when looking for real issues.

(seeing a pattern here) :-)

After a negative-match of a Guru expression, we were searching for the next
'(' anywhere in the subsequent chars of the file rather than just the next
line that started with an open-parenthesis character.

This bug was the secondary cause of the buffer-overflow crash addresseed in
commit 86150e0a which was triggered by my recent updates to the guru.dat.

The trigger was this line in the recent change to guru.dat:
Unrealized potential. :-(

That open paren was parsed as the beginning of a new guru expression. A very
long guru expression that overflowed the stack variable 'str' here.

user_dir, sysop_dir, upload_dir, and offline_dir

These properties could magically appear later once
file_area.[lib|dir|lib_list] was enumerated for the first time.

Fix issue #551

When Secure EchoMail is enabled and a Bad Echo Area (*) is defined in the
area file (areas.bbs), but the packet source address is *not* listed as a
link to the Bad Echo Area (tag: *) in areas.bbs, any messages for unknown
areas in such a packet would cause the pkt to be considered a bad packet
with a security violation. Instead, the message should just be skipped.

Set the CIOLIB window title (so it's not the default "SyncConsole")

So a sysop now has 3 choices for SBBSecho's handling of incoming bad packets:
 - delete them
 - rename them *.bad
 - rename them *.reason.bad (the default)

If SBBSecho is configured to rename bad packets, but the rename fails, the
error is logged (as before) but the packet is not deleted (this is a change
from previous behavior).

Always log the *reason* a pkt was determined bad in the "Bad packet detected"
log message.

When bad packets are detected and renamed to ".bad" files, include the reason
in the new filename (e.g. "ff69453a.src-addr.bad" or "ff69453a.pkt-passwd.bad"
instead of just "ff69453a.bad") to make it easier for a sysop to determine
what to do with the bad packets without having to search through log files
to discover the reason *why* SBBSecho considered the packet to be bad.
This behavior can be disabled if desired by setting EchoCfg->Global->Verbose
Bad Packet Names to "No". Note: the reason used is the *last* reason
detected/logged for a packet to be considered bad; it's possible that there
are multiple reasons that a packet may be considered bad. All reasons will be
logged, but only the last reason is used in the new bad packet filename.

Also added the missing "Delete Packets" option (to EchoCfg->Global). Though
this setting was added in sbbsecho v3.0 (and settable via sbbsecho.ini), it
was never exposed via EchoCfg; I don't think that was intentional. Normally,
you'd always want to leave this set to Yes (the default) to delete processed
packets, but when debugging, it may be desirable to leave the packet files
in place. This what the old sbbbsecho v2 '-x' command-line option used to be
used for (disable the deleting of processed packets).

Moved the Global Settings, EchoMail Settings, and File Paths config menus to
the upper left of the screen in EchoCfg. The placement seemed inconsistent
and erratic, so this is a bit of a cosmetic improvement.

Using the same logic that SBBSecho uses to decide if a packet header is in
fact 2+ (the auxNet field must be non-zero), otherwise, type reported is 2e.

CID 452331
CID 452330

The CP437 character characters used for the arrow indicators aren't always
mapped to the expected characters in all fonts (e.g. on Windows), so add an
option to use ASCII alternatives (<>^v) when that's a problem.

Command-line options must begin with '-' (not ye olde CPM/DOS '/option')
Command-line options are now all case sensitive (e.g. '-a' not '-A').

Remove '-d' (long deprecated for '-id')
Remove '-t' (long deprecated, do nothing)

I noticed when setting a security level's lines per message value > 32767
in SCFG->System->Security Level Values, the value would be read back as 1 or
or some other crazy value. That was because we were writing this value
(and all the security level 16-bit values) using iniSetShortInt(). These are
*unsigned* 16-bit values, so that we should have been using iniSetUShortInt().
We'll just use iniSetUInteger() instead to fix that/those issues.

And since promotion/conversion from uint16_t or uint32_t to uint has no impact
when creating a decimal representation of a number, just use iniSetUInteger()
everywhere we're setting unsigned integer settings in the main config .ini
files. If/when these fields are made larger in the future, this code will just
work.

When reading .ini integers, use the more appropriate iniGet[U]Int16 functions
instead of iniGet[U]Short and use iniGetUInteger for reading enums or any
values that are immediately typecast to a uchar/uint8_t.

Replaced some other use of [u]short that I found when searching with stdint.h
types.