https://gitlab.synchro.net/main/sbbs/-/commit/0d4953ecadccced9caab24b4
Modified Files:
src/sbbs3/sbbsexec.c
Log Message:
Fix sem_wait() call in vdd_read()

Introduced in Revision 1.16 (CVS)
Wed May 10 08:52:11 2006 UTC (15 years, 6 months ago) by rswindell

This was supposed to wait (block) until there was a new received
byte (the ringbuf semaphore was signaled), but we were passing the sem_t
value rather than the pointer to the sem_t. Since sem_t (on Windows)
is a HANDLE (which is a void*), there was no compiler warning or
error. Type-safety in C sucks.
So, this just never worked (I'm assuming the call would just fail).

I discovered this bug while working on NTVDMx64 support and in that
case, this call would block/wait forever. Simple one character fix.

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

https://gitlab.synchro.net/main/sbbs/-/commit/48874e1e329fbdf00a35d8fb
Modified Files:
src/sbbs3/sbbsexec.c
Log Message:
The sem_wait() call was just a bad idea after-all

The sem_wait() call from vdd_read() that was fixed in the previous commit to this file was a bad idea to begin with:
There is (often) not a 1:1 ratio of bytes in the receive ring buffer and the semaphore count, so we'd often halt here waiting for the semaphore to be signaled even though there were still characters in the receive buffer. This caused (new) stalls/hangs in keyboard input in DOS door games. We didn't see this previously because the sem_wait() call just didn't work (wrong semaphore pointer value).

Now, call sem_trywait_block() in vdd_read(), but only if the RingBufRead() returned 0 (no bytes read) and even then, only block/wait for a maximum of 30 seconds (same as X00 FOSSIL driver). This blocking behavior is specified for FOSSIL function 02h (Get received character with wait) and would not have worked previous to the previous "fix", so now we have that corrected behavior too. The FTSC spec says the wait is indefinite, but I think a 30 second timeout (ala X00) is more reasonable.

Log the git brach/hash instead of the old CVS revision.

GetMailSlotInfo() apparently always fails on Windows 7 with error 87 (even using Microsoft's own sample code), so lower the log message severity of that failure from ERR to DEBUG. Apparently this is pretty harmless anyway as nothing really needs the write-mailslot status. <shrug>

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

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 driver

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

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

https://gitlab.synchro.net/main/sbbs/-/commit/d395a548874bac3a46370a3d
Modified Files:
src/sbbs3/sbbsexec.c
Log Message:
Better RTS support

Reducing log output (lowering log level of line 437 from LOG_INFO to LOG_DEBUG) highlighted an issue with Telix stopping RX. That was fixed by checking RTS in input_thread(). Qmodem needs RTS checked when writing the MCR.

This improved RTS support has been tested with Telix, Qmodem, Telemate, and Banacom at full data rates.

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

https://gitlab.synchro.net/main/sbbs/-/commit/8dbbe0a38f295e6e773f745b
Modified Files:
src/sbbs3/sbbsexec.c
Log Message:
No need to call reset_yield() if we're not calilng maybe_yield()

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

https://gitlab.synchro.net/main/sbbs/-/commit/3ba5aa8d7a6633e248d57063
Modified Files:
src/sbbs3/sbbsexec.c
Log Message:
Store the UART register/settings in a struct for easy re-init

Re-init the UART struct in the init routine to avoid confusion when making .ini file changes with older NTVDMs (including NTVDMx64) which don't re-load the VDDs for every invocation.

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

https://gitlab.synchro.net/main/sbbs/-/commit/19396b9c77e3da8e849eaf7a
Modified Files:
src/sbbs3/sbbsexec.c
Log Message:
Fix compile-breaking typos in last commit

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

https://gitlab.synchro.net/main/sbbs/-/commit/30553f8a946b789856bb49c2
Modified Files:
src/sbbs3/sbbsexec.c
Log Message:
Better log messages and yielding upon ReadFile(mailslot) error.

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

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

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