• src/sbbs3/xtrn.cpp

    From Deucе@VERT to Git commit to main/sbbs/master on Wed Feb 17 10:55:55 2021
    https://gitlab.synchro.net/main/sbbs/-/commit/0e6853aeef28d32a26bc2c46
    Modified Files:
    src/sbbs3/xtrn.cpp
    Log Message:
    Correctly support 1,000 arguments to an external

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

    Fixes CID 33313

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Sun Apr 4 13:22:13 2021
    https://gitlab.synchro.net/main/sbbs/-/commit/7505f317f5581340ed1a9f60
    Modified Files:
    src/sbbs3/xtrn.cpp
    Log Message:
    Fix use of uninitialized local variable (err_pipe[]) on *nix

    And other weirdness around EX_NOLOG mode checks.
    Addresses Coverity-scan CID 330048.

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Wed Jan 26 20:10:24 2022
    https://gitlab.synchro.net/main/sbbs/-/commit/9445866c80a38b5ee6c170ea
    Modified Files:
    src/sbbs3/xtrn.cpp
    Log Message:
    Ignore VDD WriteFile() failures if the child process has terminated

    If the child process (e.g. door game) has terminated, don't log errors if/when WriteFile() to the mailslot fails. This would be expected as the mailslot is created/owen-by sbbsexec.dll which would also terminate along with the process, thus closing the mailslot.

    Hopefully resolves the errors reported by DesotoFireflite (VALHALLA).

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Sat Jan 29 12:32:30 2022
    https://gitlab.synchro.net/main/sbbs/-/commit/08ce315f97a09569f169ef89
    Modified Files:
    src/sbbs3/xtrn.cpp
    Log Message:
    Suppress "VDD Open failed" warning if child process terminated

    Another log message reported by DesotoFireflite (VALHALLA) that can happen when a user has typed something while the programming is running and the program terminates before the data can be sent to it.

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Thu Apr 28 18:55:48 2022
    https://gitlab.synchro.net/main/sbbs/-/commit/47e604723eb6eb602ed7e463
    Modified Files:
    src/sbbs3/xtrn.cpp
    Log Message:
    When running 16-bit DOS commands "offline" on Windows, don't use dosxtrn

    We shouldn't need a virtual UART/FOSSIL driver to execute "offline" program (e.g. timed events) in the first place, and our virtual UART/FOSSIL for Windows wouldn't work right in the scenario anyway even if it did load successfully.

    This resolves the reported issues with timed events configured as not "native" returning error 255 (and not running successfully) on Windows with SBBS v3.19. I'm not even sure what changed exactly in xtrn.cpp, dosxtrn.c, and sbbexec.c between v3.18 and v3.19 that's causing this to now fail, but it (using DOSXTRN to run offline DOS programs) really shouldn't have been attempted in the first place. So that was just a design issue that happened to kind of sort of work up until v3.19.

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Tue Jun 14 23:09:25 2022
    https://gitlab.synchro.net/main/sbbs/-/commit/e54263fde0be580dcbaf77c8
    Modified Files:
    src/sbbs3/xtrn.cpp
    Log Message:
    Log command-line that led to logged error opening DOSXTRN.RET

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Sat Jul 2 12:22:07 2022
    https://gitlab.synchro.net/main/sbbs/-/commit/280f16f4f373956c17d2a5eb
    Modified Files:
    src/sbbs3/xtrn.cpp
    Log Message:
    Add EXECDIR, DATADIR, and XTRNDIR to DOSemu command replacement tokens

    As requested. This closes issue #416

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Wed Jul 6 18:23:10 2022
    https://gitlab.synchro.net/main/sbbs/-/commit/ce475f794e112fa9c9f435c6
    Modified Files:
    src/sbbs3/xtrn.cpp
    Log Message:
    Don't log error opening DOSXTRN.RET when terminating an external

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

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Fri Oct 7 18:42:19 2022
    https://gitlab.synchro.net/main/sbbs/-/commit/e7109c87bc43f21636c5f981
    Modified Files:
    src/sbbs3/xtrn.cpp
    Log Message:
    When user hangs-up on external programs on *nix, try to terminate w/SIGTERM

    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.

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Deucе@VERT to Git commit to main/sbbs/master on Thu Dec 29 09:35:16 2022
    https://gitlab.synchro.net/main/sbbs/-/commit/f78a70986d1e3b21b09ca32e
    Modified Files:
    src/sbbs3/xtrn.cpp
    Log Message:
    Fix name of data event

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Wed Jan 25 10:29:48 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/23513871ebc07d81e7cb83d8
    Modified Files:
    src/sbbs3/xtrn.cpp
    Log Message:
    0-init the 'gamedir' variable

    Resolves CID 434888, not sure why this one didn't show up before.

    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net