Known front-ends have been modified to save configuration after plugin
initialization but before running the game. Now it is no longer
necessary for individual plugins to save their config.
Removing calls to ConfigSaveSection from within plugins makes the
mupen64plus-ui-console '--nosaveoptions' parameter work.
I was unable to test complete operation with this patch, due to:
https://github.com/mupen64plus/mupen64plus-rsp-cxd4/issues/43
...but I was able to get past the plugin initialization phase, which
verifies that the code change works as desired.
Not really a fix, just additional ifdefs to use the correct pointer
names for each case.
A proper fix would be to change the names in mupen64 api to fit the
upstream names or vice versa (considering the names I'd suggest the
former)
Not really a fix, but its done the same way in upstream for analog
uses.
Alternatively one could specify the size in the forward declaration of
the config object (in su.h)
This fixes reserved RDP and CPU op-codes in Zelda MM due to wrong RDRAM address limitation calculations from the RSP. _WIN32 builds were not affected by this issue (due to the preprocessor disabling the analysis) and thus remain unaffected by this commit.
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.
