• src/sbbs3/dat_rec.h ftpsrvr.h js_rtpool.c js_rtpool.h mailsrvr.h sbbs.h services.h ssl.h startup.h telnet.h userdat.h websrvr.h

    From rswindell@VERT to CVS commit on Friday, March 22, 2019 12:28:27
    src/sbbs3 dat_rec.h 1.4 1.5 ftpsrvr.h 1.57 1.58 js_rtpool.c 1.31 1.32 js_rtpool.h 1.5 1.6 mailsrvr.h 1.87 1.88 sbbs.h 1.505 1.506 services.h 1.44 1.45 ssl.h 1.14 1.15 startup.h 1.83 1.84 telnet.h 1.17 1.18 userdat.h 1.70 1.71 websrvr.h 1.55 1.56
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv32122/sbbs3

    Modified Files:
    dat_rec.h ftpsrvr.h js_rtpool.c js_rtpool.h mailsrvr.h sbbs.h
    services.h ssl.h startup.h telnet.h userdat.h websrvr.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).



    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net