This prevents MSVC from reordering the exports in a way that doesn't match our spec file. Also improve the algorithm to apply ordinals, by starting with the first specified ordinal, possibly reserving ordinals for anything declared without an ordinal before.
- Add some of the missing CMake adjustments to continue the configure and compile process with ARM64 MSVC
- Created quick stubs for the functions in SDK needed to finish the configuration process
- Put in an ARM64 option for spec2def
CORE-17518 CORE-17615
'int128' arguments are NOT almost always GUID, as was claimed, and the
usage of the wine_dbgstr_guid() function to display them would require
the presence of yet another wine-specific header.
Instead, define a "MyInt128" typedef, local to the stub file being
generated, as the structure of two __int64's (lower and upper), and
print this "MyInt128" as the couple of these two __int64's.
Besides, display the __int64 numbers prefixed with "0x" (together with
the PRIx64 formatter).
Finally, when generating the debug-print function calls, it is useless to
explicitly cast the 'aX' variables with their types, because their types
are already known from the prototype of the stub-function!!
Therefore we can use the same `fprintf(file, "a%d", i);` for all the
ARG_LONG, ARG_PTR, ARG_STR, ARG_WSTR, ARG_DBL, ARG_INT64 and ARG_FLOAT.
Only in the case of ARG_INT128 we output "a%d.lower, a%d.upper" .
The reason is that dlltool orders the exports differently than MSVC builds (MSVC orders the exports by symbol name, rather than by export name), so we rely on sorting in the spec file, which was only respected, when ordinals were put into the def file.
On MSVC builds it is left to the linker to determine the correct order, which helps to get the differences between architectures right (different symbol decoration, difference between order for functions like NtLoadKey vs NtLoadKey2, which results from the stdcall decoration on x86, which is missing on other architectures.
TODO: To correctly handle non-x86 architectures with GCC builds, spec2def would need to reorder the export list based on symbol names, which would work for C functions, by taking the calling convention into account, but would require an extra c++-stdcall calling convention to be added to know the corresponding symbol starts with "?".
