1. Forum
  2. FidoNet
  3. SYNC PROGRAMMING

  • src/sbbs3/sbbsexec.c

    From Rob Swindell@1:103/705 to Git commit to main/sbbs/master on Tue Feb 1 01:26:56 2022
    https://gitlab.synchro.net/main/sbbs/-/commit/5f2881f28b5ed36f112e31cc
    Modified Files:
    src/sbbs3/sbbsexec.c
    Log Message:
    Fix (loss of) carrier detect reporting in Virtual UART driverSo Hobo and I have noticed that Global War was leaving game lock (*.LOK) files behind when he disconnected while in the game (e.g. due to the game not responding or something). This was happening because GWAR was not recognizing the loss of connection ("carrier detect" or DCD) and SBBS would ungracefully terminate the process after 5 seconds of being disconnected, thus the game lock files would remain and requiring manual clean-up.I discovered that if I changed the WAR.CFG file to use FOSSIL instead of UART, Global War would then correctly recognize the loss of carrier and exit gracefully (and not leave any .LOK files behind). So... I suspected an issue with the Virtual UART driver. It turns out, that a program that relies on the modem status register change interrupt (and doesn't "poll" the UART MSR register) might never know that the "carrier" was lost. This is fixed by waiting on the hungup_event in the interrupt_thread and deasserting DCD in the "virtual" MSR register and asserting the MSR change interrupt to notify the program that it has in fact changed. Good thing for WaitForMultipleObjects(). Uh huh.
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to Git commit to main/sbbs/master on Thu Dec 29 09:55:46 2022
    https://gitlab.synchro.net/main/sbbs/-/commit/9488bda6b6a96006b41db017
    Modified Files:
    src/sbbs3/sbbsexec.c
    Log Message:
    Fix typo
    --- SBBSecho 3.20-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Windows 11)@1:103/705 to Git commit to main/sbbs/master on Mon Mar 11 19:44:24 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/fc41cb22e51817ab0f2cd6e0
    Modified Files:
    src/sbbs3/sbbsexec.c
    Log Message:
    Statically initialize uart to COM1 details, don't rely on VDDInitialize call

    Older versions of Windows don't (always?) call VDDInitialize(), so we need
    to statically initialize the uart struct.

    This should address the problem reported by Fzf (FQBBS) via DOVE-Net:

    ... When using the included SBBSEXEC.DLL, the UART emulation
    defaults to base address 0x000 and interrupt 0x0. The lockups do not occur when this is left as-is but none of the UART emulation does anything. Setting a ComPort in a [UART] section of SVDM.INI or SBBSEXEC.INI does change the I/O address and IRQ to an expected value. But this isn't necessary. The mere existence of one of those two INI files, even if empty, sets the UART to the expected default of 0x3F8/IRQ4. The debug entry is always as follows when left without any INI file:

    [180] SBBS: Virtualizing UART (0x0, IRQ 0)

    This bug appears to be caused by commit 3ba5aa8d7a663 (1 year ago), where
    uart was no longer statically-initialzed and relied on VDDInitialize() to be called to copy default_uart to the uart struct.
    --- SBBSecho 3.20-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)