Now, if the BOOL argument value is FALSE, then the .ini file is opened read-only (and thus only read permissions are needed, resolving issue #455).

If the BOOL argument value is TRUE, create-if-not-exist is implied. There are no use cases where we would want to open an .ini file for writing only if it already existed.

Otherwise, socket stuff (e.g. socklen_t) isn't defined and sockwrap.h
included by ini_file.h causes build error.

Fall-back to uname() if this fails.
https://www.freedesktop.org/software/systemd/man/os-release.html

There shouldn't be multiple keys with the same name in a section, but if there
were, a call to iniRemoveKey() would would only remove the *first* key with
that name. So loop until all the keys with the matching name are removed and
return true only if they were all successfully removed from the specified
section.

This resolved an observed issue with sbbsctrl-windows displaying an error
dialog "Failure writing initialization file: path/to/sbbs.ini" when there
were multiple *Sound keys in a section and the first such key value matched
that same key in the [Global] section: in this case, we try to remove the
duplicate key/value from the non-global section, but that removal was
considered a failure (iniKeyExists returned TRUE) because we only removed
the *first* key with that name (assuming there would be only one). So we
would abort the save entirely and display the error dialog.

Fixes build in IDE again. Was getting unresolved log-related function
errors (from nopen.obj) during link.

Loading empty main.ini file results in no (0) command shells be configured, but this scenario needs to be supported if we are to be able to run upgrade_to_v320.js via jsexec when there is no ctrl/main.ini file.

Only the terminal server cares about command shells, so just move the checking and critical-error reporting there.

was always returning 0 (oops), so user.tab searches for specific string values
(usually user's real name) did not work.

max_files, max_age, seq_dev

To match the existing JS file_area...dir_list properties.

These were mismatched between cnfdefs.js and scfg*.c already, so lets
fix but make more consistent with the JS object model.

So extended internal codes (e.g. for msg and file areas) now have a max length
of 32 chars (16 prefix, 16 suffix) and most other internal codes are now
limited to 16 chars (instead of 8).

This is pretty much a direct port using the *almost* exact same
form definition file, except:
1. Uses sbbs.dll for common functions
2. Read config file (main.ini), so now needs SBBSCTRL env var set
3. Some minor improvements, like hour-glass cursor while searching
   and re-reading/loading/displaying the user data when any changes
   are saved.
4. Supports the v3.20 user base (obviously)
5. Flags nodes in-use by modified users with the UDAT node flag

Some old bugs (e.g. the user credits were read/written from the old/wrong
byte-offset) are no longer relevant.

This should be used elsewhere too.

putuserdatetime() needed to take a time32_t argument to be compatible with
Borland C++ Builder. Eventually, when we stop using that tool, we can move
to just 64-bit time_t's everywhere.

parseuserdat() now accepts and optional array of field pointers to populate
for each user field (for use with the new UserEditor.exe).

As reported by Max (WESTLINE)

This would crash/segfault when the .ini files didn't exist

We may want Ctrl-A sequences in the telegram subject, but not in the message
subject

... unless a comma is actually required.

This Coverity reported issue was previously resolved (incorrectly) with
commit d02fc1a2 which also introduced a bug that ate all the unexpected
cursor position report characters (causing issue #304).

The correct fix was to compare the response length against the buffer size
minus one, to leave room for the NUL terminator.

While fixing this and issue #304, I noticed that this function was using the
response length ('rsp') as both the state machine state and string length,
which didn't work right if a nearly-matching report/response was received:
the x/y values would have been stripped from the response before stuffing
in the keyboard input buffer. So a bit of a refactor here using a proper
state machine variable.

Unexpected characters received (maybe typed by the user) were supposed to
be stuffed in the keyboard input buffer using ungetstr(), but the input string
was cleared rather than NUL-terminated before logging the expected character
and calling ungetstr(), so nothing (a blank string) was logged and nothing was
stuffed in the keyboard input-buffer in this case. Just an off-by-one bug.

This should fix issue #304. Thanks to Keyop and Nelgin for their persistence
in reporting and testing (in #synchronet at irc.synchro.net).

I didn't look closely enough at which write() call I was instrumenting.
This is now more useful, though I think we already found the root-cause
based on different log output ("Unexpected ansi_getxy response").

This just resulted in a lot of unhelpful noise in the log output

When reading and writing characters to chat files, log each with a debug-level
log message. If a read or a write fails, log with an error-level log message.

This will hopefully help root-cause and resolve issue #304.