1. 10 Mar, 2022 2 commits
  2. 11 Feb, 2022 2 commits
  3. 10 Feb, 2022 1 commit
  4. 31 Oct, 2021 1 commit
  5. 05 Jun, 2021 2 commits
  6. 05 Apr, 2021 1 commit
  7. 15 Feb, 2021 2 commits
  8. 16 Aug, 2020 1 commit
  9. 17 Apr, 2020 1 commit
  10. 15 Apr, 2020 1 commit
  11. 14 Apr, 2020 1 commit
    • deuce's avatar
      Fix fencepost error detected by Coverity... · 3f98d20c
      deuce authored
      Because the test to continue is *after* the loop, we can't continue
      when c is the last index into lzh->son, or the code will make use of
      lzh->son[sizeof(lzh->son)/sizeof(lzh->son[0])] which is outside the bounds
      of the array.
  12. 03 Aug, 2019 1 commit
  13. 18 Jul, 2019 1 commit
  14. 10 Jul, 2019 3 commits
  15. 08 Jul, 2019 5 commits
  16. 06 Jul, 2019 6 commits
  17. 29 Jun, 2019 2 commits
  18. 28 Jun, 2019 2 commits
  19. 22 Mar, 2019 1 commit
    • 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).
  20. 24 Jul, 2018 1 commit
    • 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
  21. 09 Mar, 2018 1 commit
  22. 23 Feb, 2018 2 commits