From rswindell@1:103/705 to CVS commit on Sat Jul 28 18:00:04 2018
src/uifc uifc.h 1.92 1.93
Update of /cvsroot/sbbs/src/uifc
In directory cvs:/tmp/cvs-serv15784
Modified Files:
uifc.h
Log Message:
Increase the maximum number of menu options from 10,000 to 100,000 to accommodate configurations of more than 10,000 things (e.g. sub-boards)
in a single menu (e.g. message group).
This brings this value over the 16-bit thresholds (0x7ffff and 0xffff)
where problems could happen if short's/int16's are used to capture the
return value of uifc.list(), but that's unlikely happening anywhere. Still
a good idea to make sure if you're using this library/headers.
From rswindell@1:103/705 to CVS commit on Fri Mar 22 14:29:29 2019
src/uifc uifc.h 1.93 1.94
Update of /cvsroot/sbbs/src/uifc
In directory cvs:/tmp/cvs-serv32122/uifc
Modified Files:
uifc.h
Log Message:
Use default calling convention (__cdecl) for DLL funcs in Borland builds.
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).