- setInterval() returns a Number, not an Object.
- typos fixed
- markup added

The QWKnet user look-up feature was broken as of commit e4fc5d04 (a year ago).

Just noticed this regression as Andre asked in IRC about looking up network users for netmail. This feature worked for QWKnet users/addresses, at least, and now will work again.

This field should not normally have a value of '1' (no way to configure that, normally, since days are numbered starting at 1 and bit 1 is 2), but if it does, it's treated the same as 0 (any day of the month) - so fix that mismatch in getnexteventtime(). Just noticed this while comparing the logic with the new is_time_to_run() functions in main.cpp. That logic wasn't (should not have) changed, so this mismatch in the treatment of mdays == 1 existed before.

Reduced probably the biggest if() conditionals in sbbs to a single line by breaking the "time to run" logic into separate functions and sharing those functions between both QWKnet and timed-event scheduling. There was no actual problem with this code/logic, it was just very difficult to read and understand and step-through with a debugger and understand why or why not an event might run under different configurations and circumstances.

Also removed the PostLink network call-out logic. pnet.dab is no longer read and written-to and if you happened to have any PostLink hubs configured (how?!?), they'll no longer be "polled". This is the only functional change unless I did something wrong in the process.

One thing I noticed and contemplated, the current time is not queried between consecutive timed-event scheduling/execution. It's possible that an executed event can take a long time and impact the criteria for the next timed event. The events are checked for scheduling every few seconds, so I can't really think of a big down-side to the current design (apparently intended to reduce unnecessary querying of the current date/time), so I didn't do anything to change that. Just something I noticed.

With this option set to "No", sysops can still login, they just can't perform most sysop functions.

Updated System Password help text to clarify that the "Allow Sysop Access" option effectively disables the system password. Also mention the FTP Server use of the system password to enable sysop access.

As Andre pointed out while documenting this setting on the wiki, the option seemed confusing: if a sysop could not login with "system operator access", how could they login at all? Answer: they could not.

This setting used to be called "Allow Remote Sysop Logins", back when there was the concept of a "local login", so setting this option to "No" would mean that user accounts with sysop access could only be used for *local* login. But in Synchronet v3, there's really no such concept as a "local login", so it was changed to just "Allow Sysop Logins" (period) and not a lot of thought given to how/why a sysop would actually set to this "No" or what the implications would be (presumably, nobody ever sets this to "No").

So rather than just get rid if the option altogether, I changed it to mean: an account with sysop access (i.e. level 90+) can still login, but any action that normally requires the system password will not be allowed. This includes the sysop-actions available in the FTP server when authenticating with <user-pass>:<system-pass> as the password. The sysop-user can still authenticate (and login), but none of those sysop-actions will be available to them.

Partially revert Deuce's commit ea5b359b

This explains the EAccessViolation (stack corruption during sbbs startup) that sysops have reported when using the latest nightly builds.

This macro as written won't compile on mingw32 due to the attributes
on _mktemp().  This could be worked around, but it's easier to just
disable it since I don't need it, and nobody else is building with
mingw32.

On Win32 it can't be defined until after winsock*.h is #included.
On everything else, it needs to be a pointer.

For Win32, this is actually the pointer type an ioctl() third
argument needs to be.  For other OSs, this is basically what an
FIONBIO third argument needs to be... there's really no restruction
at all on what arguments after the second to ioctl() need to be.

It seems we can't add a const to a typedef in a static_cast<>()

uintptr_t should be the same as a DWORD on Win32,
and CRITICAL_SECTION can be stored in an inptr_t as well.

This should work fine, and allow more build environments to be happy.
This is generally caused by new C++ standards having thread support
in the standard library, so wrappers getting pushed deeper in.

At some pointer, this should be redone with standard threads, but
now is not the time.

This is so we can deal with send(), recv() and friends taking
a void* on BSD stacks, and a char* on Win32.

Not a big deal for C where a void* is universal, but C++ hates that
type of thing.

Thanks to Andre for pointing that out in his wiki updates.

Convenient way to get the path/name of the archive file as it was passed to the constructor.

warning C4244: '=': conversion from 'double' to 'uint64_t', possible loss of data

This is a millisecond timer that tries to avoid floating-point
operations.

it just seems it's even worst than Deuce thought. :-)

I'm not really happy about rounding floats in time-critical bits,
but there you go.

Now it should keep working after 24 days.

than the int supports, it's set to 0x80000000 to indicate overflow.

msclock() is *always* overflowing, and clock_t is only 32-bits on
some platforms (specifically FreeBSD).  To "avoid" problems, just
keep subtracting UIN32_MAX from the value until it's less than INT_MAX
then cast.

This function is, of course, terrible and shouldn't actually be used,
but it should at least sorta kinda workish.

At least one of MAP_ANON, MAP_GUARD, MAP_PRIVATE, MAP_SHARED, or MAP_STACK
must be specified.

Oddly enough the hbuf wasn't actually modified.

This will allow naming consistency in encode/*
This is the fix you're looking for Keyop. :)