I'm attempting to forward some symbols from some C++ DLLs through a MASM DLL to a MASM EXE.
Linking the program gives LNK2001 Unresolved External errors.
Putting the PROC and INCLUDELIB commands into the exe work fine, but the forwarding DLL doesn't work.

I put the usual library include line into the DLL, starting with just one DLL for now:
INCLUDELIB BFGFX.LIB

And the following lines in my DLL's .DEF file:

LIBRARY BF
VERSION 1.1

EXPORTS
GFX_INIT = BFGFX.GFX_INIT
GFX_CLOSE= BFGFX.GFX_CLOSE

MSDN says not to do any symbol decorations (_GFX_INIT@20, etc) and none of the Windows DLLs that use forwarding do either.

Is there a specific LINK command I need to use, or do I need to put more things in my DLL source code? ML seems to put the correct .LIB filename into the .obj file, but I still get unresolved externals. C++ symbol decoration isn't a problem, they're declared as extern "C" with the stdcall convention.

Help!
Posted on 2002-11-25 05:33:30 by AlphaGremlin
they're declared as extern "C" with the stdcall convention.


extern "C" - that means they're of the C calling convention!

How can they be both C and stdcall calling conventions at the same time?

I think this may be the cause of the problem, if the C DLL is using C calls, then the MASM include file needs to have them declared as C calls too, otherwise decoration will be different, and the linker will blow up.

Mirno
Posted on 2002-11-25 08:11:03 by Mirno
Hi Mirno,


How can they be both C and stdcall calling conventions at the same time?


extern "C" just means they aren't decorated in a c++ way e.g.:

void __stdcall blah(void *, char *, char *, unsigned long);

gives ?blah@@YGXPAXPAD1K@Z

void __cdecl blah(void *, char *, char *, unsigned long);

gives ?blah@@YAXPAXPAD1K@Z

extern "C" void __stdcall blah(void *, char *, char *, unsigned long);
gives just _blah@16

and

extern "C" void __cdecl blah(void *, char *, char *, unsigned long);
gives _blah

i hope this helps

-stormix
Posted on 2002-11-25 09:56:18 by stormix
I can't do any _BLAH@20 stuff. I've tried putting in the symbol decorations and it gives symbol not found errors when I run the program, even though it compiles properly. Using the __cdecl method will use the C calling convention, won't it, meaning I have to re-write all my procedure prototypes, which I shouldn't have to do.

Actually they are declared as:
extern "C" DWORD APIENTRY GFX_INIT(HWND,DWORD,DWORD,DWORD,DWORD);
and I set the calling convention in the project settings to __stdcall.

Like I said, I shouldn't need to put in name decoration. For example the Kernel32 call HeapAlloc forwards to NTDLL RtlAllocateHeap, accorting to dependency viewer, with no decoration at all. The linker is supposed to handle the underscores and @numbers, but it doesn't in this case.
Posted on 2002-11-26 01:21:12 by AlphaGremlin