... and auto-choose the right one

Tested on Windows 11 (x64) and Windows7-32

Don't install the fonts to the syncterm.ini, Deuce says they confuse sysops.

Renamed the setup.exe file due to warning from ISS about security concerns.

Tested on Windows 11.

This function appears to truncate the service pack info for Windows 7 (6.1):
"Windows NT Version 6.1 (Build 7601) Service Pack 1 x86" became:
"Windows NT Version 6.1 (Build 7601) S x86"

Don't close the handle to ntdll.dll (hey, that's stupid filename, Microsoft!)
since the module could be unloaded from the address space and then a call to
the captured procedure address could/would crash. This handle will be closed
when the process terminates anyway.

While we're here, correct the Windows 6.1 -> 7.0 numbering. That looks better:
"Windows NT Version 7.0 (Build 7601) Service Pack 1 x86"

Something should probably be done for Windows 6.2 -> 8.0 numbering too, but I
don't have a VM handy. Is anyone actually still running Windows 8.x?

Needed for building sbbsexec.dll

I guess #pramga warning only affects the following source line.

Apparently we're disabling this warning effectively via other means in all
other MSVC projects.

This is fun Microsoft. If Windows 11 is actually Windows 10.22000+, what will
Windows 12 be? No one can guess.

When the system time zone is not UTC, but the sysop wants to display some
dates and times in UTC, they can now use these @-codes to do that:
- TIME_UTC
- DATE_UTC
- UTC:fmt
- DATETIME_UTC
- MSG_DATE_UTC

Nobody will really care though.

This partially reverts commit 03b84df8.

I observed deadlocks on Linux attempting locks of user.tab on Samba share,
which also deadlocked my Windows nodes. Interestingly, the Windows nodes
never deadlocked on their own (after a week of testing) when using blocking
locks.

Double the frequency of lock retries - this has helped reduce the observed
user.tab lock failures on Vertrauen.

As Deon pointed out in DOVE-Net / Synchronet Discussion, having a local time
zone configured with a different UTC offset than your system time zone can
produce strange/unexpected results (e.g. displayed age of messages). Since
it's possible that not all sysops will complete the configuration wizard or
actually set their timezone to the correct value (and ignore the startup
warning message), we now make the default Local Time Zone to be
"automatic" - query the OS every time the local time zone is needed/used.

This has the downside of only storing (e.g. in message headers) the UTC
offset of the current time zone (not the time zone abbreviation/name as
encoded by SMB). I considered making an option to dynamically figure out
the actual time zone (not just the UTC offset) and while I think that's
doable, Deon just wanted his UTC offset (e.g. UTC+11:00) and not his
time zone name (e.g. AEDT) stored in message headers, so this setting
would be the behavior he expected/wanted.

I'm using the sentinel time zone value of -1 for this new behavior.

Existing configurations (behavior of existing systems) aren't changed.

... when current timezone is negative offset from UTC, but not a US time zone,
the default should be "No".

The non-standard strerror_r() is glibc specific, musl doesn't do
that.  It *appears* that __USE_GNU implies glibc.

Looking into potential causes of issue #843, I found several instances where
we call getuserdat() without checking the return value and restoring the
useron.number to the current user number upon error: getuserdat() zeroes out
the user struct/number upon error, a bad API choice made 23 years ago.

Replace those instances with calls to sbbs_t::getuseron() which logs any
open/lock/read failures of the user.tab and does not modify/zero-out the
sbbs_t::useron struct upon error.

... since all (almost all) callerd do a config check first.

Also, some callers of openuserdat() were expecting -1 on failure (always).

Functions that returned the return value of openuserdat() upon failure, now
return USER_OPEN_ERROR instead, to be consistent.

A copy/paste from websrvr.c

This needed a custom solution (not errprintf) since the filename is passed-in
is likely from dynamically allocated memory, so a pointer comparison isn't
enough - and we don't get the function name.

This is a solution for issue #842, but only for messages posted/sent from the
terminal server using built-in functions and not via JS or other means. A more
universal/generic solution would be nice (beyond just always storing message
headers and bodies in UTF-8), but nothing has come to mind.

Differently than all other types, the length must be set before
parsing because the BPP does not contain the length data, instead
the length is specified by the message definition.

The expectation is now that there will be a single copy of SSH BPP
contents and arrays and buffers will be pointers into that.

This avoids another allocation/free requirement.

All consumers are expected to only #include deucessh.h now.  Individual
headers should not be included.

Looks like this feature (commit d661427e) never really worked correctly
since it counted the files removed from each sub-dir and then stopped deleting
when the count reached the number of files in the base directory. This was
done to accommodate the 'keep' feature (part of previous commits).
So make 'keep' check conditional on it being non-zero and just don't ever use
a non-zero keep value with a recursive delete and we should be good! :-)

This fixes issue #841

part of fix for issue #619

Part of solution for issue #619 (for the web server)

Part of solution for issue #619 (for the mail server)

For alignment with the text() method and for instances where a script author
doesn't want to load('text.js') or use [bbs|system].text.ID to get a text.dat
string index from an ID.

(which might be UTF-8 encoded). This works-around the problem that Accession
reported in #synchronet with my reply to a UTF-8 encoded message using a CP437
terminal which resulted in a message body that was UTF-8 encoded but a message
subject that was CP437 encoded. This mix of encodings is not supported by FTN
standards.

This is just a work-around since if the user modifies the subject the result
could still have the CP437 unside-down question marks (indicating
non-translatable UNICODE chars) and those should be converted to UTF-8
chars when going out on FTN or being stored in the message base. So there's
still a bug here somewhere that I need to look into more.

- when converting from CP437 to UTF-8
- when reading from RESULT.ED drop file

This effectively limited message subjects in some instances to 69 chars
instead of 70. This bug was caught while debugging a replied-message subject
conversion from UTF-8 to CP437 issue reported by Accession.

Since we we're not using opennodeext(), we don't have the path/fname for
any failure error message here.

CID 515714

This would cause the "Logout" status and multinode chat activity
strings to be truncated to 3 or 7 chars.

CID 515713 and 515715