Log the characters themselves of ASCII values (between 32 and 126) for com
debug log messages. Still a separate log message/line for every character
(so very chatty/verbose).

This fixes issue (feature request) #510

This should fix issue #509

Set Debug=true in the [com] section of sexpots.ini to enable this (and you'll
need to be logging debug-level message as well). For Nelgin.

Apparently com_setup() (which just calls tcsetattr()) will cause an attached modem (with a caller) to disconnect the caller. So you can't do this with a live modem. Leave the hack in for Nelgin's null modem cable setup, but you can't (apparently) support both 8N1 and 7E1 "callers" with a real modem (not surprisingly, for multiple reasons).

in sexpots.ini [COM] section(s).

Fixed bug where Parity was only initially set (in sexpots) if BaudRate was non-zero.

Another hack for Nelgin: this'll allow (in theory) the serial device to switch parity modes (e.g. 8N1 or 7E1) depending on what the user selects (key pressed).

I did not add byte/stop bit size configurations. We may need that.

Set Parity=true in [com] section of sexpots.ini
Set ParityOdd=true if using Odd parity.

For Nelgin's null modem setup, putty doesn't raise DTR?

<nelgin> sexpots   1492                               root    3u      CHR               4,64        0t0         90 /dev/ttyS0
<nelgin> Well, it's listening, but when I connect with putty I get nothing.
<nelgin> DigitalMan, probably always assume a client is connected since I have my pc wired to my linux box.

Nelgin: "anyway to get sexpots to report itself differently to syslog" [?]

Only used in manual answer mode,
RingCount defaults 1 (answer after the first ring) and RingInterval defaults to 6000 (maximum elapsed milliseconds between rings of the same "call").

This should address issue/feature-request #330 by Nelgin. Give that a try.

As reported by Nelgin

Fix warning while we're here.

The value of the macro is INT_MIN, not zero to protect agains weird
edge cases.

I considered INT_MAX, but figured you could get there in sane ways.

We need to re-parse the default sexpots.ini [TCP] section for every new session (when using the Prompt feature) or else there's no way to connect to the default host.

Also, telnet to be enabled or disabled (e.g. by setting Telnet=false) in any [TCP] or [TCP:x] section to support a mix of Telnet and non-Telnet hosts.

Also log a warning if a control character is received in response to the prompt, or log a notice if there's a timeout waiting for a response to the prompt. Change the non-control character response value to a debug-level log message.

Set CLS=true in the root section of sexpots.ini to enable. Sends a ^L ASCII 12 0x0c FF CS whatever you want to call it to the remote terminal before sending the carriage return and copyright banner. For Nelgin.

Set to number of seconds to timeout, if desired.
Log the received character in response to the prompt.

Wait up to 10 seconds for a single-char reply to the prompt and if a non-control character was received, use the [TCP:x] (x is the character sent by the user) from the sexpots.ini for the Host and Port values to connect to.

An experimental feature for Nelgin.

Fixed a couple sprintf() buffer overflow warnings/issues.

for Nelgin

This fixes the stat() issue on Windows XP/2K3 by allowing sbbs to benefit
from the run-time library updates that Microsoft releases periodically
(like https://www.microsoft.com/en-us/download/details.aspx?id=53840).

For more info on the stat() issue which caused all kinds of sbbs errors
(e.g. creating directories initially, but a lot more):
https://stackoverflow.com/questions/32452777/visual-c-2015-express-stat-not-working-on-windows-xp

Since we are using cryptlib which requires the MSVC runtime DLL anyway
(it is the default build behavior of MSVC), we weren't really gaining
anything from statically linking the CRTL (LIBCMT.LIB). And for some reason,
an up-to-date MSVC2019 still has (links-in) a LIBCMT.LIB file that includes
this stat bug. All the online help resources I found just to seem to suggest
updating the CRTL DLLs (on the target system), with no mention of any fixes
available for the static CRTLs on the build system. But with the no gain
from static linking anyway, I figured it was time to switch to DLL CRTLs.

The debug builds are still statically linking the CRTL for no particular
reason.

And fix Debug build error (/ZI) and warning (/Gm)

(e.g. with ^C).

Most of the copyright years in the source code were misleading (the date of
most recent publish was actually later) and all were unnecessary. I've been
removing copyright years piecemeal, for a long time, but I decided it was time
to just perform a bulk search and (mostly) replace. In some cases, I left
old copyright years on files that either are not used (and soon to be removed)
or obsolete and unlikely to ever be touched again (e.g. Win9x FOSSIL VXD). Some
of the runtime binaries still contain copyright years and those were updated to
2018.

application" error message (when run on XP) and reportedly will allow target
executables to run on non-SEE (pre-Pentium III) CPUs. Seriously, anyone really
running Windows XP on a Pentium II today? I guess it's possible <shrug> and we
really get little benefit from SSE in Synchronet.

I couldn't get Windows 2000 running in Hyper-V, so I guess Windows 2000 is
now officially unsupported by Synchronet (and long unsupported by Microsoft).

Thanks to Android8675 for the bug report and Rushfan for the solution tip.

loop immediately upon socket receive error (e.g. 54, ECONNRESET).

from everything that links with the sbbs library.

Also, use the absolute path to the 3rdp stuff to silence CMake warnings.