When multiple servers are recycling at the same time, (e.g. due to saved
change in SCFG) they'd each call sbbs_read_ini() with a shared global_startup
struct, which in turn calls sbbs_free_ini(), which would free all the
allocated network interface lists (including the global_startup one) using
iniFreeStringList (just a wrapper for strListFree), but iniFreeStringList()
does NOT modify (NULLify) the freed-pointer, so your second or third server
that called sbbs_read_ini(), with the shared MainForm->global structure, would
*again* free the same global interface list. This bug actually has always
existed because get_ini_globals() freed the global interface list in the same
way, except it *immediately* re-allocated a new one by calling
iniGetStringList(), so the time window (opportunity) for this race condition
to occur was much smaller. Truly, SBBSCTRL should use a mutex or other
mechanism to protect the shared global_startup struct, but this is a first
step to a full fix: sbbs_free_ini() should (and now does) nullify the freed
network interface pointers by using strListFree() directly. I haven't been
able to reproduce the crash upon recycle in SBBSCTRL after making this change.

warning: format not a string literal and no format arguments

Weird this warning is happening for me with GCC 12.2 (debug or release build)

smtp_netmail_addr() - not currently used anywhere else, but may be someday.
load/mailutil.js's fidoaddr_to_emailaddr() has this same logic (for FTN addrs
at least and is now used by nntpservice.js).

Also, always pass a buffer to smb_faddrtoa() from the mail server since it's
multi-threaded and its unsafe to pass NULL (using a static local buffer).

smb_faddrtoa() uses a static local buffer if passed NULL and we shouldn't be
doing that from multi-threaded callers.

Use the terminal server sem file check interval instead of node_sem_check
(it was only used in the event thread) and node_stat_check was only used in
the control panel, so just support a registry over-ride, but default to 5 sec.

These settings were artifacts from SBBS v2 (WFC mode), and not really relevant
or in the proper configuration place.

CID 451182

This is an easily overlooked setting, let's make it easier

Modem result codes. Oh, the memories...

... rather than just return false.

This will make debugging this type of issue much easier in the future.
sendmail.js was allowing empty recipient_list array arguments and the MsgBase
.status was 0 and .error just an emtpy string - unhelpful.

(like we do for Message Groups and File Libraries already)

Move the Mail Server->SendMail* settings to their own sub-menu.

Added popups while reading sbbs.ini

Fixed reversal of logic for FTP Server->Sysop File System Access option

And display an error message upon failure.

Still needs online help text.

This allows the [Global] section to be applied to each server section correctly

Before this change, changing BindRetry in the global settings would result in
the original global BindRetry value being added to each server/section of
the sbbs.ini file.

Remove values, not keys, when setting a key with a global default.

Use UInt16 functions for getting/setting TCP ports (this fixes an issue with
the FTP PasvHigh port being set to -1 (instead of 65535).

Use iniGetUInteger instead of iniGetShortInt for most other key values.

First sbbs.ini save support in SCFG, still experimental.

Allows SCFG to more easily display the most relevant .ini file using the
UIFC timedisplay() callback.

I'm surprised more people haven't wondered aloud: why are all the Synchronet
server settings in this huge sbbs.ini file? Well... this kind of answers that
question: it's a hell of a lot of settings! And this isn't even everything
(several advanced/rarely-used/borderline-deprecated settings aren't included)!

As part of this change, I've replaced the old date/time display with the
current config file path/name that's being edited (more or less). This will
help when a sysop has multiple sbbs.*.ini files and makes it clear if you have
multiple sbbs installs (like me), which one you're editing at any given time.

I have not implemented any of the server setting edits (other than a couple
simple toggles) or help text yet and this does not detect changes or save them
to the sbbs.ini file, but I wanted to get this committed at this stage anyway.
If you're running sbbsctrl.exe (or maybe even gtkmonitor), then maybe this is
completely redundant and unnecessary, but I figured it was good to have these
settings in one edit find/edit platform-agnostic location anyway. Hoepfully
this will (when its done) make SBBS for *nix just that much easier for a newbie
sysop/sysadmin.

Since commit fd90eec6 (2 months ago), the Synchronet Web Server on
my Windows systems has occasionally gone into a state where every HTTP session
thread was causing 100% CPU utilization and each new HTTP session thread
would just exacerbate the problem eventually leading to complete system
instability/unresponsiveness until the sbbs instance was terminated. This was
more readily reproducible on a Win7-32 VM, but would occasionally, though
much less frequently, happen in a native instance on Win10-64 as well.

Using the VisualStudio debugger, I was able to narrow it down to this:

Each new HTTP thread (eventually, hundreds of such threads) would get stuck
in this loop in http_output_thread():

    while(session->socket!=INVALID_SOCKET) {

		/* Wait for something to output in the RingBuffer */
		if((avail=RingBufFull(obuf))==0) {	/* empty */
			if(WaitForEvent(obuf->data_event, 1000) != WAIT_OBJECT_0)
				continue;
			/* Check for spurious sem post... */
			if((avail=RingBufFull(obuf))==0)
				continue; // <--- data_event signaled, but never cleared
		}

There appears to be a race condition where this logic could be executed
immediately after the output ringbuf was created, but before writebuf() was
ever called (which would have actually placed data in the output buffer),
causing a potential high-utilization infinite loop: the data_event is signaled
but there is no data and the event is never reset and nothing can ever add
data to the ringbuf due to starvation of CPU cycles.

Uses of ringbuf's data_event elsewhere in Synchronet don't seem to be subject
to this issue since they always call RingBufRead after, which will clear the
data_event when the ringbuf is actually empty (no similar loops to this one).

The root cause just appears to be a simple copy/paste issue in the code added
to RingBufInit(): the preexisting 'empty_event' was initialized with a
correct initiate state of 'signaled' (because by default a ringbuf is empty)
but the newly added events (data_event and highwater_event) should *not* be
initially-signaled because... the ringbuf is empty. So I added some parameter
comments to these calls to CreateEvent() to hopefully make that more clear
and prevent similar mistakes in the future.

Relieved to have this one resolved finally.

Fixes CID 451020

This was needed back in the v2 days to be sure the escape sequence was sent
*after* an output buffer before might've been cleared by a user's abort/Ctrl-C
action. SYNC/ASYNC called riosync() which called rioctl(TXSYNC) and we have no
equivalent in Synchronet for TCP/IP (modern sbbs). A user's Ctrl-C will clear
all pending I/O, but won't prevent subsequent output from being sent (until
the abort condition is cleared) as used to be the case with serial I/O.

... possible loss of data (yeah, yeah, we know)