allow a TXT record to be set for yourname.synchro.net DNS look-ups.

The procedure entry point inet_ntop could not be located in dynamic link
library ws2_32.dll

run with the '-p' or '-!' options. This resolve the issue of (on Win32)
having to enter *twice* to close the program in this mode.

This resolves the issue where if an external program closes the
client_socket_dup, the passthru_thread can't write to the passthru_socket,
so it terminates itself - by definition, deactivating the passthru_socket, but
it didn't clear passthru_socket_active, so the input_thread would keep trying
to write to it rather than sending the input from the user to the BBS.

Also, terminate the passthru_thread (without any special log message) when
sbbs->online is non-zero.

Also overhauled a lot of the passthru-related log messages. Passthru ain't just
for SSH anymore.

If you don't specify any args, it seems that load() leaves the old argc/argv
in place.

Go back to old design, but append the node number to the queue name.

(Initial port)
Does not currently have an install/uninstall thing... I'm still figuring
out how that should work.

messages is a null (0x00) byte. Some broken FidoNet software may include
a full 20 usable characters in their DateTime header field, like so:
"04 Feb 119  20:26:32" - representing February 4th, 2019.  Y2K. <sigh>

The DateTime won't be parsed fully correct, but at least the packet won't be
rejected outright because it is "Grunged". - for Alterego (ALTERANT)

%!jsdoor%. %serr.js -d %f -s %h

May help determine if the socket is disconnected or just not writable.

A child of the parent scopes js object can't do on_exit() stuff properly
due to the missing private context.  Create a new JS object in the child
instead.

We also need to copy in the js.load_path_list array contents since we don't
want the child changing the parent by accident.

Always call recv() when select() says the passthru_socket is readable, even
if the outbuf is full. This resolves an issue where the disconnection of the
passthru_socket would not be detected if the outbuf was full (e.g. the
output_thread stopped running).
Also, check if RingBufWrite() returns a short-write count and log the values
(actual versus expected write byte count).

if the ringbuf is shared among multiple threads (e.g. the sbbs->outbuf is
shared between output_thread() and passthru_thread()) - it was possible
for a race condition to occur between the caller would call RingBufFree
to determine the available space in the ringbuf and the call to RingBufWrite
which would happily overflow the allocated buffer if more data was
written to the ringbuf (by another thread) in the unprotected time between the
RingBufFree and RingBufWrite calls.

Now, RingBufWrite() can perform short-writes and will return a length less
than what was requested to write when there is not enough available space
to write the requested length.

Hopefully this resolves the corruption/crash issue Deuce is seeing in
sbbs's passthru_thread().

- returns the fixed printed-width of the specified UTF-8 encoded string

log message to:
- only log the message if the "full command line" is different than the
  command-line argument to the external() function. I'm pretty sure that was
  the reason for the addition of this log message, for debugging Linux-DOSEMU
  issues where the fullcmdline != cmdline.
- change from INFO to DEBUG log level
- change the message from "executing external: " to "Executing cmd-line: "

when de-activating the passthru_socket.

exit_code, and don't throw the exception in the caller.

Remove support for js_scope == scope.  It sorta defeats the whole purpose
of js.exec().

Remove DEBUG.LOG file support for Win32-debug builds, never really looked-at.

This allows executing a new script in a specified scope, much like load().
There are important differences however...
1) js.exec() *must* specify a scope.
2) js.exec()d scripts can call exit() and their handlers are ran then,
   rather than when the parent script exists as in js.load().
3) The js object is installed in the scope with the real JS object as the
   prototype.  This generally shouldn't be an issue, but if you're doing
   strange things, stranger things may happen.
4) As part of #3, the exec_path/exec_dir/exec_file/startup_dir/scope
   properties of the JS object represent the new script, not the calling
   one.
5) js.exec() only searches in the passed startup dir (if specified) and the
   current js.exec_dir path.  It does not search the load paths or the mods
   directory at all.

This API is also subject to change.

utf8_encode(): to convert a CP437 string or a single Unicode codepoint (number)
  to UTF-8 encoded string
utf8_decode(): to convert a UTF-8 encoded string to a CP437 string

Move the require() enumeration to just below load() so it's documented closer
to its dad in jsdocs.html

1. when de-activating the passthru socket, give the passthru_thread some
   cycles to copy any remaining socket data into the outbuf before we let
   the node_thread continue on and spew its own data into the outbuf.
   This fixes the problem of final messages of a file transfer protocol
   being intermixed with BBS data (prompts, menus, and such) and causing
   file download finalization issues.
2. Don't read from the passthru socket until there is enough room in the
   outbuf for the maximum possible telnet-expanded read size. This fixes
   streaming download protocol (ZMODEM and YMODEM-G) errors.

Also, for good measure, check the passthru_socket for writability before
send()ing on it and log a warning if it's ever not writable.

use them easily.

client_socket_dup before activating the passthru_socket. This resolves the
issue of external programs receiving stale data from the previous passthru
session - data that was not sucessfully read by the last external program
invoked.

file named in the ZFILE frame, they will usually compute the local CRC
value and request the sender to compute and send its CRC of the file it
wants to send. If the CRCs match, the receiver will send a ZSKIP frame
next ("skip this file, I already have it"). However, when I implemented
the ZCRC frame support in zmodem_send_file(), I added the ZCRC frame
check *after* the check to see if its a ZSKIP frame, when in fact, they
will normally come in the other order (ZCRC, then ZSKIP). This would result
in multiple ZCRC request/response, then ZSKIP requests that were ignored
by the sender (who just send a ZFILE frame again). Simple fix: check for
ZCRC frame before ZSKIP frame.

upper-case character.

Provide upper-case wrapper for compatibility.