The other msgbase property values are stored in the smb.status or other private_t members which retain their value when the message base is closed, unlike the 'first_msg' property which required a read of the message base index to get the value (and that doesn't work when the message base is closed, so would return 0).

for deon (ALTERANT)

In the process of creating/testing the new Synchronet Virtual DOS Modem (SVDM) project, I made the following significant improvements:

- Don't default the log level to DEBUG for debug builds
- Add a "carrier change" event so carrier low to high transitions can be tracked too
- Replace several lprintf() calls with lputs() for performance reasons
- Specify 'volatile' storage for pending_interrupts
- Interrupts are re-asserted if there are any pending interrupts after reading IIR register
- Emulate FIFO enablement
- Support RTS flow control signal
- Remove conditional/configurable yields when polling LSR and MSR register, would just unnecessarily slow down terminal programs
- Report "DCD change" in MSR correctly
- Clean-up (e.g. close handles) in VDD_CLOSE handler
- VDD_LOAD_INI_FILE allows an optional ini filename (instead of directory) as its argument - for loading an ini filename other than sbbsexec.ini (e.g. svdm.ini).

Initialize log level in VDDInitialize(). For versions of Windows/NTVDM that use/call the "init proc" (this function), we just re-initialize global variables here.

If a 4th optional argument is provided, use that as the ini filename for virtual UART/FOSSIL driver settings instead of "sbbsexec.ini". Using this feature requires an updated sbbsexec.dll that supports an ini-filename argument (instead of a directory) to the VDD_LOAD_INI_FILE command.

If DOSXTRN fails to execute the passed command-line, _spawnvp() returns -1, log the errno value and description to DOSXTRN.ERR (in the same directory as DOSXTRN.ENV). This will help diagnose issues executing DOS command-lines (e.g. file not found).

Upon failure to open/create DOSXTRN.RET, don't prematurely terminate as that would skip a lot of important cleanup.

Long hostnames would prevent the protocol from being shown. Also, non-operators should be able to see the protocol used to upload files.

1. Was not setting f->dir to the correct directory number, so only ftp-uploads to the *first* directory (dirnum = 0) would extract DIZ files of uploaded files.

Removing the 'dirnum' parameter to addfile() since that implied that you did not have to initialize the 'dir' element of the passed file_t, but you do: to get the correct file path for file size/date detection and the DIZ extraction.

2. Was getting heap-corruption when freeing the imported/formatted DIZ text on Windows once the above problem was fixed: can't free() in one DLL memory that was allocated in another DLL. Created and now using free_diz() to free the memory allocated in read_diz().

format_diz() handles a NULL 'lines' argument correctly/gracefully, so no need for the NULL lines check in sbbs_t::uploadfile().

Added FTP server log messages for successful file upload or update by user.

Don't repeat call atoi() unnecessarily.

Allows quick traversing through timed events (e.g. for comparison of settings).

This really shouldn't be necessary to toggle (at least now) on Windows, since we treat all off-line executions as "native", but for *nix, it could make a big difference if trying to invoke a native program or shell script for a QWKnet call-out and it would either fail due to no DOS support or try to executing using Linux-DOSEMU (unless the command's program name was in the global "native program list" configured in SCFG->External Programs).

We shouldn't need a virtual UART/FOSSIL driver to execute "offline" program (e.g. timed events) in the first place, and our virtual UART/FOSSIL for Windows wouldn't work right in the scenario anyway even if it did load successfully.

This resolves the reported issues with timed events configured as not "native" returning error 255 (and not running successfully) on Windows with SBBS v3.19. I'm not even sure what changed exactly in xtrn.cpp, dosxtrn.c, and sbbexec.c between v3.18 and v3.19 that's causing this to now fail, but it (using DOSXTRN to run offline DOS programs) really shouldn't have been attempted in the first place. So that was just a design issue that happened to kind of sort of work up until v3.19.

Some programs (e.g. sbbs.exe v2.30) check for CTS (when configured/enabled for hardware flow control), so reflect the signal (Clear To Send) accurately.

Subpacket OVERFLOW means received subpacket byte offset is >= the max subpacket length.

This insures that the 'R'emove file option will work correctly if when displayed sorted.

... regardless of the timing of the last progress report.
For cases where the progress output isn't erased once done doing the thing.

This eliminates some link-list management and the debug-level log message "Scrolled x mouse hot-spots" for non-mouse-enabled user terminals.

This fixes an observed crash in sexyz for Windows. The crash was in RingBufWrite() where 'remain' was set to -1 (4.2B) apparently because pHead and/or pTail changed (to pTail=pHead) during the invocation of the RINGBUF_FILL_LEVEL() macro, because it wasn't thread-safe.

Amazing this problem never came up before.

Fixed typo in another comment

If a non-'T' exempt user had already used more time today than their security level allows, their timeleft would be computed as a negative value due to integer underflow. Since the return value of this function is assigned to a ulong (timeleft), this becomes a large positive number. Cap the floor of the computed time left at 0.

Also fix the potential for underflow that could occur if the system clock changes while a user is online and 'now' becomes greater than 'starttime'.

Previously, if a sysop had set SCFG->System->Toggles->European Date Format (DD/MM/YY) to "Yes", then many of the dates in drop files would have been written in this format. Unfortunately, since most BBS doors and door development kits were written by Americans, MM/DD/YY format is always assumed. So fixed that (using new TM_MONTH macro too).

Also, line 37 ("Event Time") of DOOR.SYS was always 00:00, now it'll be the next event time (in HH:MM format). Unfortunately, that time might be tomorrow or days away and there's no way to represent *that* fact in the DOOR.SYS file format. <shrug>

Previously, we just always made this a blank line.

Apparently this line was added at some point, not sure if it's actually used
in any doors, but here it is anyway.

This is a weird one: sbbsecho ran right as I was saving msgs.cnf via
SCFG and it seems like it loaded 0-byte msgs.cnf into memory and this
segfault was a result of trying to print sub[INVALID_SUB]->code.

The use of [f]nopen() with proper share perms should have prevented this
(truncated msgs.cnf read) from happening, so there's something else afoot here.

This restores the ability for JS MsgBase() to be used to create the
initial mail message base properly, if needed.

This means that the 'subnum' should now be equal to scfg.total_subs
when referencing an arbitrary SMB via path (not in the configuration).

Before commit 5da26eca, you could pass Msgbase() the path to an SMB
on the disk and open() it, no configuration needed. As of 2 years
ago, I broke that, and passing a path to an SMB would open the "mail" base
instead - most unexpected. This is a feature of smb_open_sub() which we
switched to using (from smb_open()), so go back to using smb_open() when
an unrecognized code is pass to the constructor.

This has the negative consequence that the "mail" base can't be created
via JS. Probably should fix that.

The DoorFrame door library will about with "Overflow Error" if it reads a door.sys file with lines 16 (calls), 42 (minute credits), or 52 (posted messages) with a value > 32767, the maximum positive value of a signed 16-bit integer. So cap these values in the door.sys file at that maximum. This does potentially break/limit doors that give minutes using the door.sys drop file, so use that "modify user data" option in SCFG with care.

Electrosys initially reported this problem with the Lemonade! door game which was barfing on a line 42 value of 449632.

This is what was causing the 'is_utf8' message header property to be created as a Number instead of a Boolean.

This prevents re-entry to the door configurations from returning to the previously highlighted menu option. Not sure why this was, but clearly re-zeroing static variables makes no sense in the first place.

If a sysop wants to prevent new users from using an email address of an existing user, they can set SCFG->System->New User Values->Question Toggles->Force Unique E-mail/NetMail to "Yes".

This partially addresses issue #127, at least for the terminal server.

Fixes issue #395

CID 351997 and 351998

ftello() returns 0 after fnopen(..., O_APPEND). Use filelength() instead.

For the following log files:
  hungup.log
  error.log
  crash.log
  hack.log
  spam.log
  guru.log

... they can be limited in size, in bytes, by the sysop, along with a maximum retention limit (number of *.#.log files). Configured in SCFG->System->Advanced.

By default, the limit and keep numbers are 0, so "unlimited" (same behavior as before). Once sufficiently tested, I'll change the default in a stock main.cnf file to use a sensible limit (e.g. 10 log files of 10MB each, something like that).

e.g. "Grunged message (type 2) from 4:80/1 at offset 58 in packet: (null)"

off_t is 64-bit, but long in 32-bit (on Win32), so needs a typecast here in
lprintf() call (otherwise, the upper 4 bytes of the offset are interpreted
as the string address for the corresponding '%s' argument, the filename).

JS doors with the "Use Shell or New Context" option enabled in SCFG and JS
modules installed a global hot key handlers would not automatically terminate
when the user disconnected (and js.auto_terminate was true, the default).
I'm not sure why the operation callback was only installed when scope==NULL
but always installing it fixes the issue with some global hot key modules
and JS doors becoming "zombies" when a user disconnects while running them.

Fixes issue #390

Fixes isue #388 - no change in behavior