Skip to content
Snippets Groups Projects
  1. Jan 14, 2025
    • Rob Swindell's avatar
      First pass run of uncrustify (code beautification) · 45c8fa94
      Rob Swindell authored
      White-space changes only, exception being the rare insertion of NL before
      closing brace (couldn't find the option to disable that behavior).
      
      I excluded some header files (e.g. sbbs.h) since uncrustify seemed to be doing
      more harm than good there. I might just end up applying different set of rules
      to .h files.
      45c8fa94
  2. Feb 04, 2024
  3. Nov 22, 2023
  4. Apr 04, 2021
  5. Aug 16, 2020
  6. Sep 10, 2019
  7. 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
  8. Nov 19, 2016
  9. Mar 16, 2014
  10. Mar 15, 2014
  11. Mar 13, 2014
    • rswindell's avatar
      JS runtimes are no longer thread - cannot be shared among mutliple threads, · 4e7edfb2
      rswindell authored
      so the runtime "pool" concept might need to go away. For now, we'll just change
      the RT_TYPE to RT_UNIQUE (no sharing of runtimes, using more memory) and
      double the size of the RT pool from 128 to 256. Without sharing, the pool may
      not make sense unless there is a significant time penalty when first creating
      RTs (in which case reusing RTs will be faster).
      4e7edfb2
  12. Oct 18, 2012
  13. Mar 07, 2012
  14. Nov 02, 2011
  15. Oct 28, 2011
  16. Oct 19, 2011
  17. Oct 08, 2011
  18. Apr 03, 2010
  19. Apr 02, 2010
  20. Mar 13, 2010
  21. Mar 11, 2010
  22. Aug 04, 2009
  23. May 28, 2009
  24. Dec 10, 2008
    • deuce's avatar
      Fix BCC32 build using a DLLCALL hack. · 36d20ebd
      deuce authored
      <threadwrap.h> must be included AFTER <jsapi.h>
      <threadwrap.h> redefines DLLCALL via <wrapdll.h>
      The other alternative would be including <threadwrap.h> from js_rtpool.h
      which should not be required.
      36d20ebd
  25. Dec 08, 2008
  26. Dec 04, 2008
Loading