[MSVC] Plugins fail to load with "badf"

[wootguy]

When compiling plugins using MSVC, they fail to load with "badf" status. This happens when using the binaries from the latest release or compiling from source in MSVC.

Adding this code to metamod fixes the problem:
wootguy@753cfb1
That code comes from hzqst's custom version of metamod-p. I don't know if this is the most correct fix. Are plugin authors supposed to be adding a special pragma if they'll be compling in MSVC?

There was a compile warning for that pragma implying that it would be ignored:
h_export.obj : warning LNK4197: export 'GiveFnptrsToDll' specified multiple times; using first specification
Maybe it just doesn't work in the latest Visual Studio.

[kungfulon]

Be sure to mark your GiveFnptrsToDll with extern "C" to avoid C++ name mangling, otherwise the compiler will mangle its name to _GiveFnptrsToDll@8.

[wootguy]

I do, and so do the example plugins, which also fail. I just saw this:
https://github.com/Bots-United/metamod-p/blob/43a86cb651285e77b4b5cf3457d8ae2fec3f1c32/doc/txt/windows_notes.txt
WINAPI is needed to prevent crashing, but that mangles the name even if you use extern "C". Technically it's not mangling since the @8 is indicating how many bytes of arguments are needed for the __stdcall call (WINAPI). So, it should always be GiveFnptrsToDll@8 until the size of a pointer is changed. I guess the pragma needs updating.

[kungfulon]

After looking through the HLSDK again, I saw that it has a module definition file: https://github.com/ValveSoftware/halflife/blob/master/dlls/hl.def

And inside the project file of hldll, it configures module definition file: https://github.com/ValveSoftware/halflife/blob/master/projects/vs2010/hldll.vcxproj#L66

Maybe you can try this approach, as this is also what the original metamod does. I don't have VS2022 around so please try and see if it would resolve your problem.

[kungfulon]

Are plugin authors supposed to be adding a special pragma if they'll be compling in MSVC?

Sorry I didn't notice this question. Yes, you will need to either do the module definition file approach, or the pragma approach, or specify /EXPORT linker flags in order to force the export to be the normal name for your plugin. Metamod and the engine expects the name to be in unmangled form.

Now that I remember it, even with extern "C", the __stdcall calling convention will decorate the name with byte count. Only __cdecl will not decorate the name, as in Linux. That's why we need to rename the export in the first place. IDK why valve just decided to randomly use __stdcall for just one function like that.

[wootguy]

Ok, adding pragmas to every plugin does also fix the problem:

#pragma comment(linker, "/EXPORT:GiveFnptrsToDll=_GiveFnptrsToDll@8")
#pragma comment(linker, "/SECTION:.data,RW")

I thought there was something wrong with these pragmas in metamod, but those exist exist for the engine calling GiveFnptrsToDll in metamod, not for metamod to call GiveFnptrsToDll in each plugin. The pragmas are redundant in metamod due to the .def file, but otherwise they work fine.

That said, I like hzqst's solution better, where metamod loads the @8 function name as a fallback. I'd rather metamod handle as much boilerplate code as possible.