This became apparent when the the LSB of the day got set (an odd
day). Oops.

This only impacted decoding of date/time, not encoding.

Increment SMBLIB version to 3.10

Fix issue #845: Changing system/OS time zone, changes dates/times of posted
messages

Sysops and users shouldn't notice any change unless they change the time zone
of their system/OS (not accounting changes for daylight/standard time) and
the result will be that message dates appear the same after such a change.

For backward compatibily, any stored time_t's in msghdr_t.when_written.time
(i.e. all existing SMB messages) will still be decoded and displayed properly.
We detect a time_t value by the upper 6 bits being non-zero. When the upper
6 bits of a when_written.time value are zero, then we know the 'year' is
stored in the 16-bits before the when_written field (never used bits of the
netattr field, now part of the when_t structure definition) and the Month,
Day, Hour, Minute, and Second of the wallclock at the poster's site are
encoded in the low 26 bits of the time field.

This also eliminates more uses of 32-bit time_t that'll likely start being
a problem 2038 and really fall over and die in 2106. At least messages'
posting dates won't have any issue now. The "when_imported" values could use
a similar treatment someday I suppose - and we could get rid of the
when_imported.zone value as its not really needed we could use those 16-bits
for the when_imported.year.

Didn't change anything with filebases (still using time_t's though the
when_written hdr field isn't used for much with regards to files).

Yes, we could have converted all imported "broken down" message dates to
UTC and continued to store them as a time_t using timegm() instead of mktime()
for conversion to time_t, and I considered that. But we would have needed to
create/use a flag in the message header to indicate such stored date/times
(since they'd have to go through different adjustment for original time zone
before display, basically reversing the logic of all the places we display the
message dates/times using localtime verus gmtime/UTC C RTL functions),
couldn't just initialize the time with a call to time() upon import of local
messages (unless the local timezone happened to be UTC). And in the end, we'd
still have a 32-bit time_t value. So this seemed the better path.

I would have liked to have stored the date fields in a more human readable
encoding (BCD or decimal, ala isoDate and isoTime_t), but I just didn't have
the spare bits in the fixed portion of message headers to be wasteful like
that.

Here's an example from smbutil v of a message header posted after this change:
  when_written     03292595 41E0 Fri Dec 20 18:22:21 2024 PST
  when_imported    6766265D 41E0 Fri Dec 20 18:22:21 2024 PST

Notice the difference in the hex encoding of the date/time between the 2
header fields: when_imported still uses time_t. The when_written.year value
isn't output here.

changed from 0 to 1:
 timeperday
 timepercall
 callsperday
 postsperday
 emailperday

There are restrictions to remove access to these features if that's what the
sysop desires.

This will allow unauthenticated mail clients to post a single message (per day)
to a sub-board, when there's a posting alias set up (sub:* in alias.cfg).

... 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.

Make the scheme ("http://" or "https://") configurable via rss.ini, default is
now "https://".

Make the message link format somewhat configurable via rss.ini (hopefully to
support some other/future web message reading interface should there be one).

Reportedly, the MsgBase.get_msg_header/body() calls of the "total_msgs" offset
were logging errors? I was not able to reproduce this (the !hdr check seemed
to be successfully ignoring such cases), but in any case, message offsets are
0-based, so this was definitely an off-by-one issue, even if it was a silent
failure for everyone else. <shrug>

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

DDMsgReader bug fix: In the scrolling message reader interface, it now exits on user input timeout (as it should). This should fix issue #844, reported by Keyop

Closes #844

See merge request main/sbbs!483

DDMsgReader bug fix: In the scrolling message reader interface, it now exits on user input timeout (as it should). This should fix issue #844, reported by Keyop

Presumably it's because I'm not using std=gnu11 or whatever

Use the same hack as for strerror_r()

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

... that is working (for me at least) to auto load/rerun sbbs

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.

This reverts commit 79fa3c0b.

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.