The original decision to use custom-tailored versions of the C standard
library functions for the Windows build came from a number of
issues--most of which turn out to be not applicable to a Windows DLL
module extension (in which no executable entry point is required).
Since most non-Visual-Studio build suites for Windows will use the
standard, universally available MSVCRT.DLL for linkage, no compatibility
issues can arise from switching the code back to use standard C calls
for _WIN32 builds (provided the calls and usages conform to ANSI C89 and
do not involve forwards-compatibility with other newer extensions to the
C language added in MSVCR80.DLL, MSVCR90.DLL and so forth).
Visual Studio itself, however, chooses to disallow targeting use of
MSVCRT.DLL because Microsoft changes the C language implementation
details of that file while promising the availability of certain
extensions and non-ANSI features available with fixed-version CRTS.
Therefore, if building with Visual Studio, this commit will cause a
dependency on some numbered version of Microsoft's CRT instead of the
standard MSVCRT.DLL.
Note that this issue is negligible due to the fact that MSVC cannot be
recommended for compiling an optimized interpreter code base (not
limited to the example of this plugin).
To test with MSVC anyway, either a) have the CRT framework package
installed to system upgrades (knowing end users the plugin is shared
with may not have this), b) use an older version of Visual Studio to
build, c) statically link the CRT dependency with /MT, d) use the
portable DDK suite containing MSVC outside of Visual Studio to continue
using MSVCRT.DLL, e) temporarily revert this commit to increase DLL file
size by using static linkage of the custom CRT functions removed by this
commit.
Another problem was the fact that MinGW GCC always links in CRT startup
code, even to DLLs for which no entry point needs to exist, and this
startup code depends on -lmingwex which adds a bit of custom message
crap to the binaries. The obvious workaround for this (as obvious as
knowing to do it for DLLs) in the case of an EXE was obfuscated by the
fact that MinGW maintains an arbitrary design choice that calls __main
from inside main instead of in the startup code. This side effect is
fixed by using preprocessor checks to wrap around a dummy __main symbol
in the entry point translation unit's source file.
If MinGW is installed to:
E:\MinGW\
...and the current directory is:
C:\Users\me\rsp\
Then `cd E:\MinGW\bin` is a null operation when the -D argument isn't
passed.
