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 rswindellThis was supposed to wait (block) until there was a new receivedbyte (the ringbuf semaphore was signaled), but we were passing the sem_tvalue 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 orerror. 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 thatcase, this call would block/wait forever. Simple one character fix.
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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-allThe 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>
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)