Creating "undecorated" DLL

[bobsobol]

I have followed this thread, and got a working DLL produced... however, I'm converting a library produced in another language, and need to link "undecorated" export names.

The option "Undecorate exported __stdcall functions" is ticked in the IDE compiler options, but still my function exports begin "@" and end "@n" where n is the number of bytes that need to come off the stack before returning.

I think my "extern" line is to blame...

Code: [Select]

extern void __declspec(dllexport) Debug(long lpszString); as an example... should I be using "__stdcall" instead of "__declspec", and what exactly should I use as syntax in that case?

I have to ask, because I can find a page in the help file for "__declspec" but can find none for "__stdcall". XD

[TimoVJL]

but still my function exports begin "@" and end "@n"

That is __fastcall function.

Check your compiler options.

If you want __stdcall

_declspec(dllexport) double __stdcall AddNumbers(double a, double b);

From help file:

Code: [Select]

FASTCALL calling convention

X86:

The caller will pass the first two arguments which fit into ECX and EDX, and push all other arguments
onto the stack before the call (right-to-left). Arguments are only passed in registers if they are of
integral or pointer type. The callee must remove any arguments from the stack; an assembly
procedure should use the ret n form. The name of a FASTCALL function is decorated as
@funcname@numbytes, where numbytes is the total size of all (promoted) arguments to the function.
This calling convention is rarely an improvement on X86; use the CDECL or STDCALL convention.
 

[bobsobol]

Aha! Thanks timovjl. My function is actually returning "void", so

Code: [Select]

extern void __declspec(dllexport) __stdcall Debug(long lpszString);did the trick.

Interestingly, explicitly declaring a "void" return where you declared "double" causes compilation to fail... but the actual function specifies the void return, so the end result is all good.