... rather than calling textmode() after.

This solves the problem of black bars above and below the UIFC window in
echocfg and SCFG on ChromeOS, at least.

All keys are now in the root/global section and they are now:

video_mode (default: 42)
uifc_mode (default: 0)
ciolib_mode (default: 0)
scaling (default: 0)
lines (default: 25)
insert (default: false)
esc_delay (default: 25)

These global variables weren't actually used for any purpose.

If a sysop wants to override the default user interface/console I/O library
behavior of SCFG without using command-line arguments, they can create a
ctrl/scfg.ini file with the following optional [section] keys:

[uifc]
mode (advanced uses, e.g. disabling mouse support)
height (in lines)
insert (keyboard insert mode, not overwrite)
esc_delay (ESC-key delay)

[ciolib]
mode (advanced uses)
scaling (fractional values, e.g. 1.5, supported)
height (in pixels)
width (in pixels)

Command-line arguments take precedence over scfg.ini settings (if set).

The scfg.ini file is read *before* parsing command-line args, so if a ctrl
directory is specified on the command-line (e.g. rather than via environment
variable), the scfg.ini file won't be read from that specified location but
rather the default (/sbbs/ctrl) or the SBBSCTRL env var value.

Another attempt to make Nelgin happy and close out issue #749, though no, this
doesn't auto-save the current parameters (you'll have to create/edit the
scfg.ini file by hand).

I'm not clear why Walnut Creek would list files (e.g. readme.txt) in these
lists of "directories", but don't create file areas for them. Less clean-up
required after import.

    Comparing an array to null is not useful: "client->protocol == NULL",
    since the test will always evaluate as true.

or will always evaluate as *false* (the array won't ever be NULL). <shrug>

getfname() just returns the last path element, so can't use that here.

The dirnum and subnum are used for the next/previous (left and right) arrow
nav through sub-boards and directories. For message groups or file libs that
are configured to auto-sort the sub-boards or directory list, when importing
an unsorted list, the dirnum and subnum values would then be wrong after the
qsort() at the end of the import thus making the left/right nav thing broken
(jump to other groups/libs and such).

This fixes that.

Could I have fixed this by passing an index value to the next/prev_dirnum()
and _subnum() functions and returning the next/previous index value instead of
relying on the subnum/dirnum elemment to be correct? Maybe. <shrug>
Do I like second guessing myself? Not really.

The fallback to external extractors/archivers didn't really work unless a
libarchive function (called from extract_files_from_archive) actually failed
and the return value was < 0. A return value of 0 would mean the external
file extractor would never be used.

This was discovered when trying to import DIZ from old ZIP files (from 1992)
that used "Implode" compression method for the FILE_ID.DIZ, which is a
compression method *not* supported by libarchive. This is a reason why sysops
might want to leave Info-zip's 'unzip' as a configured Extractable File Type
handler (in SCFG) for 'zip' files.

Don't call the external archiver 3 times for the 3 DIZ filenames supported.
Just call the external archiver once, and pass all 3 filesnames. This also
means that the call to system() can return non-zero (e.g. Info-zip 'unzip'
will return 2 if any of the files aren't present in the archive, even if
one is) - so ignore this return value from system(). This speeds up bulk
import (e.g. using addfiles.js).

Unfortunately, I couldn't really find a nice cross-platform way to suppress
the unzip "caution: filename not matched" message sent to stderr. That's
a bummer and a little annoying.

Ignore 0-length DIZ files.

Fix observed crash when shutting down services server where the client_t
protocol was pointing to a freed service's protocol description string.

This was the last pointer in client_t and should resolve the last race
conditions (memory ownership issues) with its data members.

This also resolves a small memory leak in getnodeclient() where the last
client "gotten" would have its heap-duplicated protocol string leaked.

lastchar() returns a char pointer, not a char.

This fixes issue #751

Strip prepended and trailing slashes.
Convert backslashes to forward slashes.

When setting lib's parent path:
- Auto-fix the sub-directory name case
- Display error when setting lib parent to path that doesn't exist

The iteration variable (p) is created on the stack.

Walnut Creek and Simtel CD-ROMs usually have this file format which lists the
sub-directories along with descriptions of each (one per line).

Not to be confused with the DIRS.TXT format that has long been exported from
and imported into SCFG.

This is an attempt to make Nelgin happy (issue #749) without writing/reading
an additional settings file.

WIPterm hasn't been supported in ages and HTMLterm was just an ephemeral
experiment.

Leave the WIP ARS keyword parsing support, for backwards script compatibilty.

And use DWORD insteaad of 'unsigned long' where specified by Win32 API.

error: cannot bind non-const lvalue reference of type ‘long unsigned int&’ to an rvalue of type ‘long unsigned int’

Just getting rid of more use of ulong (replaced with size_t).

... as requested by "ben" in #synchronet at irc.synchro.net

Currently, this assumes all stdio doors aren't "UTF-8 native", which might be
an incorrect assumption.

The "default" mnemonic string attributes are still set in ctrl/attr.cfg,
but now, each mnemonic string (e.g. from text.dat or passed to JS
console.mnemonics()) can include a "MNE:" @-code to over-ride the default
mnemonic string attributes (low, high, and command). If the "high"
attribute isn't specified, it defaults to the same color as the "low"
attribute with the "high intensity" flag flipped. The "cmd" attribute
defaults to whatever was included in the attr.cfg, if not specified.
Technically, the separator between the attributes can be any non-valid
attribute character (e.g. symbol).

Renamed (really old function) attrstr() to strtoattr() since its usage now
more closely resembles other std C strto* functions (has an 'endptr' arg).

Fix a long standing bug where by sysops could page for chat or send node
messages or telegrams to any node, even if there wasn't a user even connected.

Regular users were not affected by this bug.

And use sizeof, not the magic number (again).

Deuce expanded the local 'error_code' buf to not trip the SAFECOPY macro
destionation buffer length check. Only this buffer needed to be 4 chars
exactly to truncate the 'message' string at 3 chars (e.g. just "404" for an
error message string that starts with "404 "). Switch from SAFECOPY to strlcpy
to eliminate this bug.

As reported by Ragnarok as part of issue #748

The web error files should work again.

Update to commit 85a2de04 (2 years ago).

FSC-74 specifies:
"The conference name shall be no more than 60 characters in length."

SCFG was limiting sub and dir area-tags to 40 chars and SBBSecho was limiting
area tags to 50 chars in length.

FSC-74 isn't a standard, but lacking this detail in FTS-4 and considering it
comes from the same authoritative source (the Conference Mail System User
Manual), I think it's the best source of truth we have.

Also, since we're no longer using .cnf files, we don't need different max
area-tag lengths between SBBSecho and SCFG structs - they all now use the same
macro: FIDO_AREATAG_LEN

We're just using it to "fix" the case, if the file indeed exists.

If client socket is connected, wait up to the specified timeout period (in ms)
for the output buffer to be emptied.

This is much preferred over blindly calling mswait() after sending some data
(e.g. a file) and possibly waiting much longer than necessary.

Since the Terminal Server is a single thread, let's not block for long
periods of time trying to send bytes to a client (e.g. send the badip.msg
file contents to a client with a blocked IP address), effectively DoSing the
terminal server.

This should address the problem reported via IRC:
<theviper4> │Apr  9 15:38:11 viper-bbs synchronet: term Terminal Server timeout(outcom) 0000 0000
<theviper4> │Apr  9 15:38:35 viper-bbs synchronet: term Terminal Server !ERROR 110 sending on socket 39
<theviper4> │Apr  9 15:38:35 viper-bbs synchronet: term Terminal Server !ERROR 32 sending on socket 39
<theviper4> │Apr  9 15:38:35 viper-bbs synchronet: term Terminal Server !ERROR 32 sending on socket 39
<theviper4> │Apr  9 15:38:36 viper-bbs synchronet: term 0039 Telnet !CLIENT BLOCKED in ip.can: 117.95.153.33

Also, make the outcom timeout error message more helpful (e.g. include the
sock descriptor of the client) and don't use the old rioctl() function
here any more.

yes, this is a Y2K38 (or Y2106) issue, but we should have that worked out
when upgrading to the next libmozjs.

Need something like NUMBER_TO_JSVAL() and equivalent LAZY_NUMBER macro that
can deal with >32-bit ints correctly (or just always convert to double?).

... while the mods/*.bin command shell filenames could be any-case!

Only impacted non-Windows systems (UNIX file systems are case-sensitive).

Discovered while making this tutorial video: https://youtu.be/HlwQ0uX4S04

This is the time_t (seconds since Unix epoch, Jan-1-1970 UTC) date/time of the
current (most recent) Git commit used to build the running binary.

If a JS developer wants to check if a build is recent-enough to include some
change, this is the property they should use to check (with >= comparison).

This solves the problem of exit() values (e.g. non-zero return codes) not
getting propagated to callers when nest-called (e.g. via bbs.exec()).

I think it was kk4qbn that pointed this out via IRC: an exit(1) call from
prextrn.js did not stop the external program from running (as it should, for
any non-zero exit code). This only happened when the prextrn.js called another
JS script (e.g. via bbs.exec() or as was the case here, indirectly via "EXEC"
@-code in the YesNoBar text.dat string (which executed yesnobar.js). This
nested JS script invocation via sbbs_t::js_execfile() would clobber the stored
js.scope property value (where the "exit_code" property is written).

Script invoked in their own context (e.g. via js.exec()) wouldn't have this
issue in the first place.

A QWKnet tagline usually contains CP437 character 254 and if/when appended to
a message during export, would "convert" the message to CP437 thus making the
"ASCII" charset advertisement incorrect.

If a FIDO CHARSET value was already specified (e.g. in HEADERS.DAT), that
value will (still) not be overridden. So the *original* import via QWK (before
it gets exported to a QWKnet) is where this change will take effect.

Fix for issue #741