Don't do the DOSEMU drive-letter dance for xtrn startup directory if the xtrn's command line is implicitly native (e.g. Baja or JS).

Also, recognize Baja command-lines as native in cmdstr() - for %n, %!, etc. DOSemu expansion hack.

If a node's configuration can't be loaded (e.g. nodeX/node.cnf is missing), fall-back and load the "first node" (e.g. Node1) configuration. On recent *nix installs (since the migration to Git), the node2+/node.cnf files were not copied/created, so let's solve that soon-to-be-FAQ now.

This resolves the issue of node2+/node.cnf file missing.

Update README.txt - website defunct

See merge request !44

Update sysop.doc - cvs is gone, and these files haven't changed in a long time...

See merge request !42

Fixes issue introduced in last commit to this file (the each-node-has-its-own-config-in-memory enhancement) that would prevent users from logging in because their time was reduced for an upcoming event that had already run. The change assumes the event thread is running (its the thing that reads the event last-run info from time.dab). Thanks to mlong for the report.

Update sysop.doc - cvs is gone, and these files haven't changed in a long time so its really not needed in the instructions

... between all nodes of  a instance sbbs instance. That's now no longer true.

Previously, all nodes shared the same copy of the configuration in memory. This prevented any node from seeing an updated configuration until all nodes were offline or waiting for connection and could be recycled. Now, no recycling of the server is needed for a node to load a new config. A node in-use *still* cannot reload configuration until the user disconnects, but all you have to do is logon to another unused node and you (or that user) will get an updated configuration. Bots or server recycling problems will no longer prevent the sysop or user from getting a current configuration when connecting to any node.

This is one of those instances of giving the sysop what he wants rather than what he asked for. I should've done this a long time ago, but the idea just occurred to me. You're welcome. :-)

Let UIFC do the truncation as necessary to fit windows/forms, when applicable.
Thanks for jc and nelgin for pointing this out via IRC.

The name length is limited to 25 chars, so we don't need a 50-char wide menu here.

Thanks for pointing that out mlong.

(emulating the syslog date/timestamp format). Makes debugging file transfer issues easier.

And a couple of minor cosmetic adjustments.

misspellings in jsdocs

See merge request !40

Basically, try to scare away people who won't file bug reports.

More logging details (e.g. subpacket byte progress).
Identify XON and XOFF by name (e.g. when purging receive buffer).
Some variable naming and comment improvements.

Also, zmodem_send_raw() was saving the "last sent" char, even if it wasn't successfully sent.

Eliminated the "errors" mode of zmodem_recv_header_raw() since was no longer used.
Eliminated zmodem_recv_header_and_check() since it's no longer used.

Some debug-log fix-ups (e.g. with progress/offset).

only when the errored data subpacket was a ZCRCW (waiting for ZACK).
To resolve a non-streaming failure to recover after CRC error issue.

... like the last commit that did this, but do in the other 2 places where
stderr output is logged as log messages.
Also, include the extended program name in the stderr log messages, making it
easier to find the output you're looking for.

... based on the configuration setting.
Also, prompt for upper or lowercase after setting the editor information file type, so no "door drop file" needs to be selected to change the case of the editor information file. - reported by mlong

Makes easier trace/debugging of issues (e.g. matching up with sending side logs).
No functional change.

__FUNCTION__ cannot be used a string literal in GCC.

Previously, a ZRINIT frame would be sent even after a failed file download, and this could be misinterpreted by the sender as a successful file receipt 
 acknowledgement. 'lrz' just completely aborts the receive "batch" under the same conditions, so we'll just do the same to prevent the sender (e.g. BBS) from mistakenly counting this as a successful transfer (download).

A lot of log message updates: additions, removals, and use of the __FUNCTION__ macro.

Call this one "2"
Flashbacks to manually editing zone files here.
I may end up going with YYYYMMDD numbers like I sometimes did in
zone files, but maybe I'll just do the single number thing... not
really sure yet.

These frames were already not allowed in the binkp/1.0 protocol,
and it is mentioned in the spec (issued in 2005) as "Some old
implementations do send empty frames as the last frame.".

It's certainly not allowed now, and any mailer which does it is
broken.

For zero-length data packets, it will be seen as a frame containing
zero data bytes which will also be logged as being after the file
if it comes after the file has already been completely transferred.

A zero-length command packet will abort with M_ERR, logging an error
regarding command number NaN or something like that.

This may fix #185 since attempting a recv() of zero bytes and
succeeding is the only way I can see for a zero second timeout to
have been logged in receving frame data.  The software assumed that
receiving zero bytes was a timeout, but if that's what you asked for,
it's actually success.

Only observed on Windows, the option value variable (val) was uninitialized so querying byte-sized options using WinSock getsockopt() would leave the MSB of the value as undefined (garbage), resulting in sockinfo.js output like this:
KEEPALIVE = -858993663
instead of this:
KEEPALIVE = 1

Ctrl-A codes that cause cursor movement or attribute changes or anything except toggling the console output will now be ignored when console output is off.

Only in Socket I/O mode. This will allow us to tweak the SNDBUF size (to account for slow ZMODEM downloads - sends from sexyz) and frob other socket knobs.

Also added a line feed to Windows OutputDebugString() messages since MSVC's debug log viewer now assumes that you will.

we assume it's 1.1 anyway.

This has been fixed upstream for some time.