- Aug 22, 2020
-
-
Rob Swindell authored
-
- Aug 16, 2020
-
-
Rob Swindell authored
-
- Jun 27, 2020
-
-
deuce authored
setting.
-
- Jun 26, 2020
-
-
deuce authored
-
rswindell authored
Change the Get/Set FlowControl function to control both tx and rx flow control and accept/return a bit-field so multiple flow control methods can be enabled concurrently.
-
deuce authored
-
rswindell authored
Change the return value and arguments to Get/SetTxFlowControl functions to support multiple types of flow control, not just RTS/CTS, but also DTR/DSR and XON/OFF (and obviously, none). TODO: consider how the dcb.fRtsControl member might need to be adjusted by the comSetTxFlowControl function (for Win32).
-
deuce authored
-
rswindell authored
-
deuce authored
-
rswindell authored
Need *nix implementations now.
-
rswindell authored
Need a *nix implementation now.
-
- Mar 22, 2019
-
-
rswindell authored
Fix age-old bug with Borland/C++Builder built executables (Windows): to achieve compatibility with the default __cdecl symbol naming rules of Visual C++, we were using __stdcall convention for DLL functions when building code with Borland/C++Builder tools and using the default (__cdecl) convention when building with Microsoft (Visual C++) tools. Although this allowed symbols to be located when linking, the calling convention mismatch caused a stack cleanup issue that very rarely manifested itself in a bug (e.g. exception of some kind in sbbsctrl.exe, usually). Mismatching the calling conventions was unintentional (I thought the default for MSVC DLL functions was __stdcall) - but since the calls to MSVC-Built DLL functions worked 99% of the time, I didn't realize there was an underlying issue. So I now work-around the DLL symbol naming mismatch using a command-line option (-a) passed to implib in src/sbbs3/ctrl/makelibs.bat I had previously worked-around exceptions when calling MSVC DLL functions in sbbsctrl.exe by calling the problematic DLL functions from a timer tick handler rather than a user control (e.g. button) event handler. Those work-arounds can now be removed. The erroneous "DLLCALL" definition design pattern was replicated (copy/pasted) to many other projects' header files in cvs.synchro.net. In the future, we may want to just remove all instances of *CALL since they now serve no purpose and appear as useless "Kruft" (but do allow us to more-easily globally change DLL function calling conventions if/when necessary in the future).
-
- Feb 18, 2019
-
-
rswindell authored
error: 'O_NONBLOCK' undeclared ... on Alpine Linux.
-
- Jul 24, 2018
-
-
rswindell authored
Most of the copyright years in the source code were misleading (the date of most recent publish was actually later) and all were unnecessary. I've been removing copyright years piecemeal, for a long time, but I decided it was time to just perform a bulk search and (mostly) replace. In some cases, I left old copyright years on files that either are not used (and soon to be removed) or obsolete and unlikely to ever be touched again (e.g. Win9x FOSSIL VXD). Some of the runtime binaries still contain copyright years and those were updated to 2018.
-
- Jan 13, 2017
-
-
rswindell authored
-
- Apr 18, 2015
-
-
deuce authored
be set and read using the POSIX macros and related (currently Linux-only).
-
- Feb 14, 2014
- Oct 24, 2012
-
-
deuce authored
-
- Oct 21, 2011
-
-
rswindell authored
-
- Jul 06, 2009
-
-
rswindell authored
to E-7-1.
-
- Jan 20, 2008
-
-
deuce authored
Did I never test this at all?!?!
-
- May 23, 2007
- May 22, 2007
- May 16, 2007
-
-
rswindell authored
-
- May 11, 2007
-
-
deuce authored
-
- Apr 21, 2007
-
-
rswindell authored
Moved comReadBuf() into comio.c (common functions)
-
- Apr 20, 2007
- Mar 23, 2007