• src/sbbs3/xtrn.cpp

    From Rob Swindell@VERT to Git commit to main/sbbs/master on Saturday, January 29, 2022 12:32:30
    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 Thursday, April 28, 2022 18:55:48
    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 Tuesday, June 14, 2022 23:09:25
    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 Saturday, July 02, 2022 12:22:07
    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 Wednesday, July 06, 2022 18:23:10
    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 Friday, October 07, 2022 18:42:19
    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 Thursday, December 29, 2022 09:35:16
    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 Wednesday, January 25, 2023 10:29:48
    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