Skip to content
Snippets Groups Projects
  1. Aug 16, 2020
  2. Jul 10, 2019
  3. Jun 30, 2019
  4. Jun 29, 2019
  5. Mar 22, 2019
    • rswindell's avatar
      Use default calling convention (__cdecl) for DLL funcs in Borland builds. · bf82a889
      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).
      bf82a889
  6. Jul 24, 2018
    • rswindell's avatar
      The great Copyright year update and (mostly) removal of 2018: · f869ad3d
      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.
      f869ad3d
  7. Feb 10, 2014
  8. Oct 23, 2012
  9. Jun 04, 2008
  10. Aug 13, 2007
  11. Aug 12, 2007
  12. Jul 11, 2007
  13. Jul 10, 2007
  14. May 09, 2006
  15. Jun 07, 2005
  16. Jun 06, 2005
  17. Sep 23, 2004
  18. Aug 30, 2004
  19. Feb 27, 2004
  20. Feb 26, 2004
  21. Oct 15, 2003
  22. Apr 01, 2003
  23. Mar 26, 2003
  24. Apr 26, 2002
  25. Nov 11, 2000
  26. Oct 10, 2000
Loading