Previously, more than 999 arguments would overrun a buffer and break
things.

Fixes CID 33313

Hopefully not introducing any bugs in the process.

Hopefully not introducing any bugs in the process.

Michael Long authored Dec 17, 2020 and Rob Swindell committed Dec 17, 2020

The hardcoded external.bat file has been moved to a templated
/exec/external.bat which can be modified by the sysop. ENV
vars are in there to be able to customize as needed. emusetup.bat
is no longer needed, but still supported. The actual dosemu command line
is now stored in /exec/dosemulaunch.ini and can be customized for
fossil or i/o command lines. the keystroke is now only sent for i/o, and
only sent as \n instead of \r which would trigger undesired behavior in
certain programs. The above 2 files can also be placed in door dirs
to override. ansi.com has been removed as it was not needed. default
external.bat includes cmd lines for share, x00, etc. (user will still
need to provide these in xtrn/dosutils).

cmdstr() is often called for non-executable command-lines (e.g. for @include: file name/path arguments), so don't default to native unless a mode value was specified. Hopefully addresses issue reported by bobrob without breaking anything else (again).

This reverts commit 94517fdf.

Always check the command-line for a '*' or '?' prefix and compare the executed filename against the native program list. For DOSEMU magic drive/path name command-line specifier substitution, but only when invoking DOS programs. Reported by bobrob via IRC.

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.

... 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.

JavaScript modules are intuitively "native" and have not historically required
the "native" option to be set to "yes" in SCFG.

Support temp_dir (%g) and text_dir %(z) expansion to magic DOSemu drives/paths.
Use DOSemu-compatible temp_dir and text_dir paths in drop files.
Automatically recognize native node_dir paths in %f (e.g. editor temp files) and replace with DOSemu equivalent.

... when running DOS programs on Linux with a DOSEMU-enabled build.

Allows %f (drop file) and %s (startup-directory) to be specified on the external program's command-line and expand to the paths that DOSEMU will understand. No more hard-coding "D:\" or "E:\" and the drop filename on the command-line required.

Also (for all builds), include the door's startup directory for %s specifier on the clean-up command-line. This just seems like an oversight.

I'm fed-up with MSVC assertions in ctype functions (e.g. isdigit, isprint, isspace, etc.) when called with out-of-range (e.g. negative) values.

This problem only affects MSVC debug builds, but if you run them (like I do), these things are like little time bombs that can drive you crazy (knocking your board out of service).

The new macros names are bit more descriptive as well.

One can't have too many semicolons.

Rather than introduce yet-another-external-program/config flag to enable
the "new JS run-time/context" per invocation of any particular JS command,
I'm using the XTRN/EX_SH ("Use Shell") option as it had no function for
JavaScript command-lines and the concept is similar.

So if you want to invoke a JS external program/timed-event in its own
"sandbox", enable the "Use Shell / New Context" option for that
program/command in SCFG. There may be performance penalties when running
JS mods in this way, but you get the benefit of isolating one JS module
from all others, if/when necessary.

Add support for %^ command-line specifer which expands to the system architecture (e.g. "i686" for Win32 builds, "x64" for Linux-x86_64 builds).
Currently, there underlying XPDEV macro definition does not differentiate
between arm32 and arm64, but it should. Next...

An experimental external() mode flag that runs JS modules in their own separate runtime and context - currently does not work (appears to corrupt the shared JS context). Not actually used currently.
The reason I wanted to run a JS module (actually JS doorgame) in its own context was to get useful error messages (filenames and line numbers) when the module throws an exception. Currently, the error is just reported as occuring in xtrn_sec.js, which isn't helpful or correct.

Move term_env from static (BSS) variable to sbbs_t member. Static member function variables are shared among threads, so this was just a race-condition waiting to happen. <grimmace>

programs: PCBDRIVE (the drive letter of the current node directory) and PCBDIR
(the path to the current node directory, without the drive letter).

These emulate the same variables crated by PCBoard.

The reason these are being added is that Sunrise Door Software's 16-bit doors
contain special support for these environment vars when used in their .CFG files
(e.g. %PCBDIR%DOOR.SYS) and this allows easy multi-node configuration with a
single .CFG file. The SBBSNODE environment varialbe would have worked perfectly
fine for this purpose, but apparently Sunrise Doors (or the DoorFrame
development kit they utilized) has hard-coded these PCBoard (and Wildcat!)
environment variable names, so SBBSNODE wont' work for this purpose.

For Synchronet-Win32, you will need the DOSXTRN.EXE revision 25 or later
or you may experience NTVDM crashes when running external DOS programs.

YEAR, MONTH, MONTHNAME, WEEKDAY, DAY

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: "

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

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.

Now, it assumes the CR is bare (not followed by LF or NUL), so that should
probably be fixed. But for now, just copied pretty much as is from telnet_io.c
so I can eliminate another version of this function.

will now expand to "raw" rather than "telnet/rlogin/ssh". This disables IAC
handling in sexpots, for example, which isn't needed or desired when using
the passthru socket.

Also, put some conditional checks for passthru_thread_running in external()
and if it's not (e.g. for testing purposes), then lock the input_thread_mutex
instead of changing passthru_socket_active. This is currently just a way to
easily test the differences between direct and passthru socket I/O
(dependant on whether or not the passthru_thread is running which is controlled
in main.cpp.

use socket I/O (e.g. sexyz, door32.sys doors, sync-xsdk doors) - not just when
the client is connected via SSH. This solves a number of problems:
- programs that change socket options
- programs that don't support non-CP437 charsets (e.g. PETSCII, UTF-8)
- programs that don't support Telnet-IAC escaping

This greatly simplifies (reduces the need for) input_thread locking.

The passthru_thread now handles chunks of up to 4000 bytes per transfer
between socket and ringbuf, instead of a char at a time, greatly improving the
performance.

it and decide whether to write directly to the output ring buffer (EX_BIN) or
use rputs() for charset translations.

translation "for free". Windows only for now.

can't because it's a DOS program and the current node doesn't support it.

Fix the missing carriage-returns in the shell (bash) prompts by always building with the stderr logging
support (in *nix builds) - but run-time disable as desired via EX_NOLOG option. I've been wanting to get
rid of that "XTERN_*" macro for a long time anyway (it's "XTRN" damn-it!). :-)