We no longer use/require the USE_DOSEMU definition anywhere else, so
this was just a miss when the DOSEMU patch was perm-enabled.

sbbs3/../xpdev/netwrap.h:45:27: warning: 'parseIPv6Address' has C-linkage specified, but returns incomplete type 'struct in6_addr' which could be incompatible with C [-Wreturn-type-c-linkage]
DLLEXPORT struct in6_addr parseIPv6Address(const char*);
                          ^

New Medium impact and a low impact issue still needs to be triaged.

Previously, when a user disconnected or ran out of time while running a
stdio-based external program on *nix, if the program was still running, we'd
send it a SIGHUP, wait up to 10 seconds for the process to terminate and if
it did not, terminate it (ungracefully) with SIGKILL. Since some programs
catch SIGTERM (and not SIGHUP) to indicate a termination request, we now will
first attempt a SIGHUP, wait up to 5 seconds for the process to terminate and
if it does not, then send a SIGTERM and wait up to another 5 seconds for it
to terminate and if it doesn't, then finally send it a SIGKILL (which cannot
be caught and always results in an ungraceful termination of the child
process).

This doesn't resolve any specific problem with any specific stdio-based
external program, but I was playing around with ESR's port of Adventure
(https://gitlab.com/esr/open-adventure) and a new auto-save/restore of game
state and noticed that we weren't using SIGTERM for this situation, though we
should have. Most modern programs, if they catch SIGHUP at all, use it to
indicate a refresh of configuration or data files, not a termination request
(or indication that a user has "hung up"). So SIGTERM is more reasonable to be
expected to be caught and initiate the graceful termination of the child
program that we're hoping for.

BINKP is suddenly frequently hanging on sendsocket() on Vertrauen on Windows
(sending files to my Z1 hub) so try this as a solution.

Need to nullify the xpms after destroying/freeing (as is done in other
servers already).

Sometimes files uploaded may have the wrong case in the filebase (a different
unresolved issue), but for instances where that has happened, make those files
viewable in sbbs. This really only impacts target OSes with case-sensitive
file systems (e.g. *nix).

As reported by Android8675 (SHODAN) on DOVE-Net.
This problem did not manifest itself in 32-bit builds.

If a new JS context could not be created for any reason, a JS runtime would
still be allocated (and leaked), potentially leading to out of memory
situations which had been seen (before this change) on vert.synchro.net.

The "Events" log messages will now be logged to a disk file in
data/events*.log by default (unless this option is disabled).

If the "First node" is > 1, then the base filename will be
"events<first-node>", otherwise, it's just "events". This is because you
would not want multiple instances of sbbs writing to the same events.log
file - that would be chaos. These log files are subject the log
rotation/retention policy defined in SCFG.

This should resolve the FAQ for Windows sysops about what log file to
which their event log messages are being written.

The functions aren't DLL-exported, so the difference in FILE* support
between an app and a library is not an issue... yet, but it could be
someday, so just for good measure.

Also, don't match against deleted (blank) usernames in name.dat
(e.g. when 'name' value consists of a single ETX character).

When there are no chat action sets or an action set has been deleted, bad
things would happen (e.g. segfault) when listing chat channels.

To be more consistent in syntax and include more details (e.g. the command
being invoked).

Address issue reported by Nightfox via DOVE-Net:
Today I was using the Archive class to extract exactly one file from a zip
file, and I'm a little confused on the exception throwing behavior regarding
the max_files parameter.  When calling extract(), I gave it a filename pattern
and expected exactly 1 file to be extracted, so I also gave a max_files
argument as 1.  It extracted the one file, but it threw an exception with the
error "Error: maximum number of files (1) extracted (after extracting 1 item
successfully)".

Should that be an error condition to throw an exception? I expected 1 file to
be extracted, and that file was extracted successfully.  If I specify max_files
as 2, then it doesn't throw an exception.   

1. It's a non-printable char
2. It's the Telnet IAC byte value
3. CNF files use this as an "uninitialized value" indicator

Fixes issue #421

As reported by cadeon on Vertrauen, Synchronet v3.19 hasn't worked on Windows XP due to error:
'The procedure entry point inet_ntop could not be located in the dynamic link library WS2_32.dll'

I think this is what nelgin/Keyop was asking for via IRC.

If we detect a client disconnection and terminate DOSXTRN.EXE, don't try to open DOSXTRN.RET and log an error when the file doesn't exist (as would be expected).

Broken in commit 082a9fce 3 years ago, the 'H' (highest ranked) message listing was showing the rank of the message (e.g. 1-20) instead of the message number itself.

Note: this centering logic does not know the expanded-size of the @-code, so use a fixed-length @-code (e.g. with padding) or use the 'C' @-code format modifier instead.

Fix issue #418

Also, the logic to check if the user could even view deleted messages (on line 912) was wrong, replace with new method: can_view_deleted_msgs().

As requested by deon (ALTERANT).

A single source of truth is now used for SBBS's mouse mode (MOUSE_MODE_ON). A JS script doesn't need to know what SBBS's preferred/default mouse-enabled mode flags are, just set to this property to "true". Setting to "false" is the same as setting to MOUSE_MODE_OFF (0).

Use the is_valid_subnum() function before using the smb.subnum as an index into (s)cfg.sub[]. Related to the previous committed fix of writemsg(): leaving the global smb.subnum as -1 (INVALID_SUB) after replying to a post via email or netmail, resulting in a crash here.

Fix issue introduced 9 years ago that could cause a crash after replying to a post via email or netmail and then displaying the header of a poll message or a normal message with votes:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f9f9569a317 in sbbs_t::show_msg (this=0x7f9f70c56880,
    smb=0x7f9f70c5e4e0, msg=0x7f9ebadf08b0, p_mode=4, post=0x7f9f18071a24)
    at getmsg.cpp:255
255                                             ,cfg.sub[smb->subnum]->misc&SUB_                                                                              NAME ? useron.name : useron.alias, NET_NONE, NULL);
[Current thread is 1 (Thread 0x7f9ebadf3700 (LWP 23279))]
(gdb) print smb->subnum
$1 = 4294967295
(gdb) bt
#0  0x00007f9f9569a317 in sbbs_t::show_msg (this=0x7f9f70c56880,
    smb=0x7f9f70c5e4e0, msg=0x7f9ebadf08b0, p_mode=4, post=0x7f9f18071a24)
    at getmsg.cpp:255
#1  0x00007f9f957b2aee in sbbs_t::scanposts (this=0x7f9f70c56880, subnum=9,
    mode=2, find=0x7f9ebadf1270 "") at readmsgs.cpp:670
#2  0x00007f9f957bb75a in sbbs_t::scanallsubs (this=0x7f9f70c56880, mode=2)
    at scansubs.cpp:219
#3  0x00007f9f9568c948 in sbbs_t::exec_msg (this=0x7f9f70c56880,
    csi=0x7f9f70c64768) at execmsg.cpp:315
#4  0x00007f9f95683129 in sbbs_t::exec_function (this=0x7f9f70c56880,
    csi=0x7f9f70c64768) at execfunc.cpp:422
#5  0x00007f9f95679450 in sbbs_t::exec (this=0x7f9f70c56880,
    csi=0x7f9f70c64768) at exec.cpp:1199
#6  0x00007f9f9577d742 in node_thread (arg=0x7f9f70c56880) at main.cpp:4364

writemsg() was changing the global smb.subnum and when writing an email or netmail, that subnum value is -1 (since it's not a sub-board) and then later show_msg() is using the smb.subnum as a index into scfg.sub[] when determining if the current user already voted on the message being displayed and then: bang, crash, fall down, go boom.

Simply saving and restoring the smb.subnum when executing an external editor is all that was needed here. And this is the first use of the C++ "auto" keyword in Synchronet!

As described in issue #412, when using extended mouse coordinate (SGR) mode, the mouse button release sequence would be received by the BBS after the hotspot-activated menu option was executed and then that button release sequence possibly passed through to the a child script or program that didn't know how to handle or ignore it.

To resolve this, the BBS now ignores ("eats") the mouse button *press* sequence and only acts upon the mouse button *release* sequence. This is more aligned with how button-clicks work in mouse-control/GUI applications anyway.

As requested. This closes issue #416

Address potential FAQ (issue #415)

In the mouse debug log output. Potentially helpful in debugging mouse related issues when using the SGR mouse reporting mode.