question w/ botman's HLSDK patches for MinGW32.

[Whistler]

well it's a bit strange that the hl.dll compiled with MinGW32 (gcc 2.95.3) ONLY works if "wrapped" by another dll like bots or Metamod... and it worked very well. But if I load the hl.dll directly with HL engine it will crash.

Here's the information given by Dr. MinGW:

hlds.exe caused an Access Violation at location 035c9018 in module swds.dll Reading from location 38ea1564.

Registers:
eax=38ea1564 ebx=00000184 ecx=000001ea edx=38ea1564 esi=000001ea edi=07760000
eip=035c9018 esp=0012f024 ebp=0012f02c iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202

Call stack:
035C9018 swds.dll:035C9018 CreateInterface
035C9122 swds.dll:035C9122 CreateInterface
035C91CE swds.dll:035C91CE CreateInterface
0360E6BB swds.dll:0360E6BB CreateInterface
0360E3F0 swds.dll:0360E3F0 CreateInterface
035B4D7A swds.dll:035B4D7A
0360F2CC swds.dll:0360F2CC F
0360FDF0 swds.dll:0360FDF0 F
0360F98B swds.dll:0360F98B F
014055DE hlds.exe:014055DE CreateInterface
0CE80824

Any ideas? Thanks in advance.

[Pierre-Marie Baty]

C++ name decoration doesn't produce the same results in GCC and in Microsoft's CL. Why it works when another DLL sits in between is because since botman discovered how to build our custom exports list to hook single-player games correctly (through FUNC_FROM_NAME and NAME_FOR_FUNCTION redirects) we've building all our hook DLLs this way. Why it doesn't when no DLL sits in between is because the engine still relies on its own FUNC_FROM_NAME and NAME_FOR_FUNCTION facilities which expect Microsoft C++ style mangling.

This problem exists because of the way extra entity methods are exported in HL1 game DLLs. HL2 shouldn't have this problem. However, I wouldn't be surprised if you cannot use MinGW at all. The only solution may be to build your own exports list, like botman and myself were doing.

[Pierre-Marie Baty]

KoraX could tell you more about this, I sort of remember he's written a nice paper on C++ name decoration (which would fit nicely in our wiki btw )

[koraX]

yes indeed

linky

well my thoughts about this problem

- if you export all functions with extern "C", you are fine.
- Hovever there is one nasty problem, and that is GiveFnptrsToDll()

GiveFnptrsToDll() must be exported with stdcall, not cdecl. However after exporting this as __stdcall, its name will be mangled so you need to specify .def file or use Microsofts #pragma hacks. Look at someones bots makefile to check how it is exported in mingw32

So look at givefnptrstodll and how it is exported.

I recommend nice program called PE explorer which can inspect and do some hacks to .dll files. However it is hard to find on internet

[Pierre-Marie Baty]

hmm no KoraX, I'm afraid we're not talking about the same thing.

Some info here: http://metamod.org/singlep/

[koraX]

so Its justy that you need to load mangled functions ?
You cannot rely on mangled name, because it will change between compilers and even between different compiler version. This is done deliberately by C++ standard. So if you haven't changed name in .def file or by pragma hacks, you still may load function by its ordinal number in export table. Of course you must know the position. Or do some hacks like PMB did