• src/sbbs3/sbbsexec.c

    From Deuc¿@VERT 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

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Mon Mar 11 19:44:25 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.

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