[EXPERIMENT/MSS] Attempt func 0x00467810 and 0x004799A0

[TheRedDaemon]

Run into multiple things that might need updates on Ghidra side. Here my comments from one file:

// TODO:
// - DAT_00df3844 did not exist and I created it to test it
// - the mss types need to use the mss32 header, not the Ghidra exported one (how to handle this?)
// - "_close" is treaded like an OFFSET function and reduces the score of reccmp
// - "UnkSoundFlagsAndLoopCount" plays not nice with any number-like operation, the more likely thing therefore are
// either a union, which allows to access the different parts separately, but this would likely compile to WORD
// operations, or a bitfield, maybe like this:
// int loopCount : 16;
// int reserved : 13;
// int unknownFlag1 : 1;
// int unknownFlag2 : 1;
// int uninterruptable : 1; // ?
// In a test in the current file it compiled to "& 0x80000000" properly when using the specific field, but no idea if
// this works for multifield checks or assigns

EDIT:
Currently have an assertion error if the "_close" is called. Something does not fit at the moment...

[gynt]

• the mss types need to use the mss32 header, not the Ghidra exported one (how to handle this?)

I tweak this in the Ghidra export such that all files that use Mss32 use Mss32.h. Basically I collapse everything underneath a certain namespace/folder in Ghidra to the Mss32.h header. Just like it is done for Directplay.

Regarding _close

"_close" is treaded like an OFFSET function and reduces the score of reccmp

Can you show the dump / diff?
Have you tried? https://github.com/isledecomp/reccmp/blob/master/docs/annotations.md#annotating-a-comment-of-the-functions-symbol
Or: https://github.com/isledecomp/reccmp/blob/master/docs/annotations.md#library

Currently have an assertion error if the "_close" is called. Something does not fit at the moment...

We need to make sure we use MSVCRT not UCRT (I had issues with mixing the two). Or perhaps it is the other way around and we have to use UCRT.
Also, we may need this compiler flag: UnofficialCrusaderPatch/UnofficialCrusaderPatch3#58

Would it be better if we implement _close via a function resolver macro call? Then we use the game's own one for the time being, avoiding any IO issues. Shall I use OpenSHC::IO::WindowsHelpers as a namespace for _close, _open, etc.?

[TheRedDaemon]

We might end up needing these CRT functions as resolvers, yes. Likely with a shared "implemented" flag. With a bit of luck we maybe can just use the ptr to the windows version for "implemented".
The important thing seems to be this:
Link

If Crusader has the CRT statically linked, we are out of luck, and need to hook the functions anyway. It might actually be, because this might have been the reason I switched our build to static CRT a while ago, but I have not checked the dll imports in a while.

Regarding the Mss32 header
Bink would be another case where I created "Fake" Structures. I mean, I did again in our bink-header, but they are different. 🙃