- Feb 10, 2022
-
-
Deucе authored
-
- Apr 04, 2021
-
-
Rob Swindell authored
This won't impact Synchronet as it has a separate signal handling thread, but we still need to behave properly for processes that don't. I'm also saying that ENOMEM does not indicate a disconnection, though it may be better to pretend it was disconnected...
-
- Aug 16, 2020
-
-
Rob Swindell authored
-
- Jul 10, 2019
-
-
deuce authored
-
- Jun 30, 2019
-
-
rswindell authored
-
- Jun 29, 2019
- 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).
-
- 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.
-
- Feb 10, 2014
-
-
deuce authored
-
- Oct 23, 2012
-
-
deuce authored
-
- Jun 04, 2008
-
-
deuce authored
by properly const-ifying the appropriate functions and variables. Not yet tested on Win32
-
- Aug 13, 2007
-
-
deuce authored
-
- Aug 12, 2007
- Jul 11, 2007
-
-
rswindell authored
-
- Jul 10, 2007
- May 09, 2006
- Jun 07, 2005
-
-
rswindell authored
-
- Jun 06, 2005
-
-
deuce authored
-
- Sep 23, 2004
- Aug 30, 2004
-
-
rswindell authored
-
- Feb 27, 2004
-
-
rswindell authored
-
- Feb 26, 2004
-
-
rswindell authored
-
- Oct 15, 2003
-
-
rswindell authored
-
- Apr 01, 2003
- Mar 26, 2003
-
-
rswindell authored
-
- Apr 26, 2002
-
-
rswindell authored
-
- Nov 11, 2000
-
-
rswindell authored
Separated code from crc32.h into crc32.c (to allow combination of mailsrvr and sbbs into single module).
-
- Oct 10, 2000
-
-
rswindell authored
-