May I ask you if you still have some reason to use stdcall?
When I started with dyn libs long ago I used this calling convetion on Windows, then I went from Delphi to Lazarus, ported apps for Linux and OSX and there I had to use cdecl.
And now, when I test on Windows with cdecl I don't see any problem, at least with FPC/Laz.
I tried to put everything I know about writing and using dynamic libraries in the article series and there's some discussion and hints there about why one would select stdcall vs. cdecl.
https://macpgmr.github.io/MacXPlatform/PascalDynLibs.htmlCertainly, if you're writing a library to be used by an app on Windows that expects stdcall, then you wouldn't have any choice there.
One drawback with stdcall and a 32-bit lib is that apps compiled with MSVC will expect the lib function names to be decorated, although even that can be worked around by linking with GCC instead of the MS linker (use -Wl,--enable-stdcall-fixup switches).
With .NET, you can specify either StdCall or Cdecl calling convention, but MS also provides CallingConvention.Winapi, which means use StdCall on Windows and Cdecl on non-Windows. So that certainly seems like a hint about what MS thinks one should use.
Since it's so easy conditionally compile a lib function's calling convention with Pascal, that's what I always do with production code (Stdcall on Windows, Cdecl everywhere else). However, the NDFD library from Part 3 of the article series uses cdecl by default for all platforms and works fine across a range of languages on Windows (.NET, Python, C).
Note that the GIS GDAL library whose Pascal interface is included with Part 3's source files uses {$IFDEF MSWINDOWS}stdcall{$ELSE}cdecl{$ENDIF} for some functions, but cdecl for others because that's the way the library does it, probably because of a combining of code over time from different authors/projects.
I've also worked with at least one library written with MSVC that uses cdecl for all of its functions.