GitLab

Functionality replaced with Pascal::String

Ah, that's better. Actually would work correctly on big-endian platforms (should we ever support one) and with way less code.

So I was working on re-writing some of this door file generation code and noticed that the EXITINFO.BBS files generated by SBBS:

1. had a lot of garbage data filling unused string characters (no "harm", but potentially leaking information)
2. had the wrong total file length due to 64-bit logontime (time_t)
3. had the wrong total file length due to writing 19 GosubData elements (instead of 20)

The first and last issues appear to be some of those "forever" (20+ year old) bugs.

So I'm guessing no regularly used door games actually use these portions of the EXITINFO.BBS, so most likely: no harm, no foul. But still, best to fix this before I commit the rewrite.

This only works on little endian systems (which is all we support currently).

Fixes CID 174261: Wrong size argument

This binary drop file writing code is pretty terrible and inefficient, but I remember being really proud of it (supporting so many drop files). This really should be re-written to use structures and/or buffered file I/O.

CID 174261

Allow "FOSSIL Only" as a configuration option for external programs in SCFG. This is a much easier method of disabling the virtual UART support in the Virtual UART/FOSSIL device driver (if/when necessary) than editing the sbbsexec.ini file (which is still supported).

Needed the actually mapping of XTRN_UART -> EX_UART mode flag here.

A "hack attempt" sound file is now supported in the Terminal Server, Mail Server,  and Services.

"login" and "logoff" sound files are now supported in the Terminal Server, FTP Server, Web Server, Mail Server, and Services.
This enhancement fixes Issue #157

The following sound files may now be configured in the [Global] section of the ctrl/sbbs.ini file, if desired to set the default sound files for all servers/services in on place:
- AnswerSound
- LoginSound
- LogoutSound
- HangupSound
- HackAttemptSound

This won't impact Synchronet as it has a separate signal handling
thread, but we still need to behave properly for processes that
don't.  I'm also saying that ENOMEM does not indicate a disconnection,
though it may be better to pretend it was disconnected...

Hopefully not introducing any bugs in the process.

Hopefully not introducing any bugs in the process.

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

Always use the return value of term_supports(), which correctly supports pre-logon and auto-terminal-capability-detection, rather than useron.misc for all door drop file generation.

This should resolve the issue recently discussed in #synchronet with regards to a user getting non-ANSI output from door games even when using an ANSI-capable terminal.

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.

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.

This behavior was cut/pasted from xtrn_sec.js but doesn't play well with logon events (e.g. SBBSIMSG list) that should pause before a following CLS. As reported by altere on the I, the R, and the C.

This introduces pre/post execution modules for bbs.exec_xtrn. The logic previously in xtrn_sec.js for those functions is now in prextrn.js and postxtrn.js. These handle screen clear, evals, fonts, etc. Now everywhere that launches an external program will support these features

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.

Originally, the "pause on exit" was implemented in the C++ version of
sbbs_t::xtrn_sec() and not sbbs_t::exec_xtrn(). This meant that the pause
option was only implemented when the prgoram was invoked from the menu and
not when invoked directly (e.g. via Baja or JS exec_xtrn function).

When sbbs_t::xtrn_sec() was ported to JS, that functionality was also moved
to JS. But it really should have been implemented in exec_xtrn() to begin
with so that regardless of how the program is invoked, that SCFG setting takes
effect.

Thanks to Michael Long for pointing this out.

e.g. MM/DD/YY for drop files that assume that format, or either MM/DD/YY or
DD/MM/YY (depending on sysop preference) for backwards compatibility in
expanded @-codes, Guru chat keyword.

Fixed the birthdate check while logging on to work with new/all birthdate
formats.

strcpy -> SAFECOPY
sprintf -> safe_snprintf or SAFEPRINTF2
strcat -> SAFECAT

Enabling this feature causes the node's temp directory to be cleared before
running the external program and causes the drop file(s) to be created-in and
read back from (when appropriate) the node's temp directory.

Creating drop files in a node's temp directory eliminates the possiblity of
an external program (e.g. door game) accidentally reading the wrong drop
file (e.g. wrong-cased name or a stale file of a different type).

Note: Synchronet/XSDK doors *always* read their drop file (xtrn.dat) from the
node directory, so don't try to use this option with those doors. Only doors
where you can configure the drop file path or specify on the command-line
(e.g. %g for the temp dir or %f for the fullpath of the drop file) should
potentially use this new feature.

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.

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.

Delete the old hard-coded External Program Section (xtrn_sec) implementation. The system must use an external program module (e.g. xtrn_sec.js) now or this function will just display/log an error and exit.

- external programs section (default: "xtrn_sec")
- logon list (default: "logonlist")

This ties the Baja XTRN_SECTION and USERLIST_LOGONS functions and the
JS bbs.xtrn_sec() and bbs.list_logons() methods to the loadable modules (if
configured) automatically without the exec_bin hackery in *.src.

Also, allow the xtrn section argument to be passed to the JS/C++ method to
go directly to a specific xtrn program section.

The bbs.list_logons() can also accept an argument to pass to the module
(e.g. "-y" for yesterday's logons).

This is an artifact from SBBS v2 for DOS:
The file would contain the address of a shadow of the modem status register
(written by execdos.exe) for dropped-carrier detection in xsdk doors (or the
"dcdwatch" utility) while the BBS was "shrunk" out of memory to execute the
external program with maximal available memory.

On Linux, using DOSEMU, he would end up with both door.sys and DOOR.SYS in the
node directory and some doors would open the wrong file and fail to initialize.
Solution: delete all case-versions of drop filenames before creating them.
Don't you just love case-sensitive file systems? :-(

("Node X", user alias, etc.) - so removing a lot of the redundancies.
Also, logging the current timed event code and other prefixes in the
event thread log messages - something I've wanted for a while now.
There might be some redundant "Node X" strings, so if you see some funny
looking log message, please let me know.

Use drive mappings (e.g. D:, F:, G:, H:) rathe than absolute paths to node_dir,
ctrl_dir, data_dir, and exec_dir in drop files.
Also: fixed what appears to have been a copy/paste error in the node_dir
and ctrl_dir mapping to Win32-shortnames for non-native doors on Windows.

- if the sysop had text/menu/<filename>.bak (for example), the optoinal menu
  would attempt to load, resulting in an error ("<filename>.asc not found")
- if the sysop specified menu_file or menu_dir (e.g. via Baja), the existing
  checks for optional menu file existance would not work