How to Stop Name-Mangling of My Dll's Exported Function

How do I stop name-mangling of my DLL's exported function?

Small correction - for success resolving name by clinet

extern "C"

must be as on export side as on import.

extern "C" will reduce name of proc to: "_GetName".

More over you can force any name with help of section EXPORTS in .def file

Can't prevent name mangling

Changing calling convention to cdecl worked for me. The extern "C" solution won't of much help to me as in my case the problem was with name mangling while compiling .C files where as if I understand it correctly the extern "C" solution is for suppressing name mangling when compiling cpp files.

C++ DLL Export: Decorated/Mangled names

You can get what you want by turning off debug info generation. Project + Properties, Linker, Debugging, Generate Debug Info = No.

Naturally, you only want to do this for the Release build. Where the option is already set that way.

Is there a way to suppress c++ name mangling?

"bradtgmurray" is right, but for Visual C++ compilers, you need to explicitly export your function anyway. But using a .DEF file as proposed by "Serge - appTranslator" is the wrong way to do it.

What is the universal way to export symbols on Visual C++ ?

Using the declspec(dllexport/dllimport) instruction, which works for both C and C++ code, decorated or not (whereas, the .DEF is limited to C unless you want to decorate your code by hand).

So, the right way to export undecorated functions in Visual C++ is combining the export "C" idiom, as answered by "bradtgmurray", and the dllimport/dllexport keyword.

An example ?

As an example, I created on Visual C++ an empty DLL project, and wrote two functions, one dubbed CPP because it was decorated, and the other C because it wasn't. The code is:

// Exported header
#ifdef MY_DLL_EXPORTS
#define MY_DLL_API __declspec(dllexport)
#else
#define MY_DLL_API __declspec(dllimport)
#endif

// Decorated function export : ?myCppFunction@@YAHF@Z
MY_DLL_API int myCppFunction(short v) ;

// Undecorated function export : myCFunction
extern "C"
{
MY_DLL_API int myCFunction(short v) ;
} ;

I guess you already know, but for completeness' sake, the MY_DLL_API macro is to be defined in the DLL makefile (i.e. the VCPROJ), but not by DLL users.

The C++ code is easy to write, but for completeness' sake, I'll write it below:

// Decorated function code
MY_DLL_API int myCppFunction(short v)
{
   return 42 * v ;
}

extern "C"
{

// Undecorated function code
MY_DLL_API int myCFunction(short v)
{
   return 42 * v ;
}

} ;

How to avoid Visual C++ from mangling the names of my DLL functions

After reading and reading I found out that (maybe) there's no way to avoid name mangling with StdCall calling convention.

I wanted to call my functions from VB6, so here's a workaround that actually works:
Declaring the functions with alias:

Declare Function prettyname Lib "mydll.dll" Alias "_prettyname@16" () As Integer

Of course, it is better to use extern "C", so the names don't get horribly mangled.

C++ dll and name mangling issue

Why the function name of dllmain.h getting mangled in spite being
marked as extern "C"?

Because __declspec(dllimport).

Why can I not create instance of test class A from extern methods?
What would be good way of doing it?

I think that's fine, but you didn't provide any class A code. Just do this:

class __declspec(dllexport) A
{
    /* ... */
};

Why EXE compile failed?

This is because you have not imported the LIB file of the DLL into the project.

There are two ways to import it:

Add #program comment(lib, "<YOUR_LIB_FILE>.lib") to the code file.
Add <YOUR_LIB_FILE>.lib to Properties -> Linker -> Input -> Additional Dependencies.

Microsoft documentation: https://learn.microsoft.com/en-us/cpp/build/importing-and-exporting

why the @number symbol at the end of an exported dll function

The "@n" is used by the stdcall calling convention. You don't need to mention it in your declaration, you just need to change your declaration to stdcall so that the compiler knows they need to be decorated with "@n" suffixes. Like this:

__declspec ( dllexport ) XLStatus __stdcall _xlActivateChannel(XLportHandle,  XLuint64, unsigned int, unsigned int)

Correct calling convention for exporting windows DLL functions for Excel VBA without mangled names

Per Microsoft's documentation:

https://learn.microsoft.com/en-us/office/client-developer/excel/developing-dlls

When compilers compile source code, in general, they change the names of the functions from their appearance in the source code. They usually do this by adding to the beginning and/or end of the name, in a process known as name decoration. You need to make sure that the function is exported with a name that is recognizable to the application loading the DLL. This can mean telling the linker to associate the decorated name with a simpler export name. The export name can be the name as it originally appeared in the source code, or something else.
The way the name is decorated depends on the language and how the compiler is instructed to make the function available, that is, the calling convention. The standard inter-process calling convention for Windows used by DLLs is known as the WinAPI convention. It is defined in Windows header files as WINAPI, which is in turn defined using the Win32 declarator __stdcall.
A DLL-export function for use with Excel (whether it is a worksheet function, macro-sheet equivalent function, or user-defined command) should always use the WINAPI / __stdcall calling convention. It is necessary to include the WINAPI specifier explicitly in the function's definition as the default in Win32 compilers is to use the __cdecl calling convention, also defined as WINAPIV, if none is specified.
You can tell the linker that a function is to be exported, and the name it is to be known by externally in one of several ways:
Place the function in a DEF file after the EXPORTS keyword, and set your DLL project setting to reference this file when linking.
Use the __declspec(dllexport) declarator in the function's definition.
Use a #pragma preprocessor directive to send a message to the linker.
Although your project can use all three methods and your compiler and linker support them, you should not try to export one function in more than one of these ways. For example, suppose that a DLL contains two source code modules, one C and one C++, which contain two functions to be exported, my_C_export and my_Cpp_export respectively. For simplicity, suppose that each function takes a single double-precision numerical argument and returns the same data type. The alternatives for exporting each function by using each of these methods are outlined in the following sections.
...

The article then goes on to provides examples of each method.

In your case, since you are already doing the 2nd method and not getting the result you want, you will have to employ the 1st or 3rd method as well.

DLL export symbol mangling via DEF file seems to get modified

I finally got it working.

As Hans Passant noted, the linker somehow does handle @-signs within export definitions in a way that I found hard to grasp...

My observations:

Mangled C++ function (??0FooBar@@QAE@ABV0@@Z) forwarded to an unmangled (extern "C") function (__E__0__)
=> C++ function mangling gets cropped at the first @-sign (??0FooBar)
Mangled C++ function (??0FooBar@@QAE@ABV0@@Z) forwarded to a mangled (extern "C" __declspec(dllexport)) function (___E__0__@4)
=> C++ function mangling stays intact

This would be my initial test-case, now being close enough to my initial goal.

From the DEF file of the wrapper:

EXPORTS
??0FooBar@@QAE@ABV0@@Z=___E__0__@4 @1

From the wrapper DLL's exports (generated using dumpbin):

ordinal hint RVA      name

   1    0 00001000 ??0FooBar@@QAE@ABV0@@Z = ___E__0__@4
   2    1 00001000 ___E__0__@4 = ___E__0__@4

What really astonished me is that the export from ordinal 1 remains invisible when using OllyDbg to read the exports table. Still, when loading the DLL (LoadLibrary) and resolving the address of that function using GetProcAddress(hDLL, "??0FooBar@@QAE@ABV0@@Z"), things work just fine.

So I now have a DLL that wraps the original one, using a functionally identical exports table. It now shows an additional export of my proxy implementation, but that is no problem for my purposes. That way it is possible to create a proxy DLL that intercepts and, if needed, enhances the original implementation even when C++ mangling is involved. I somehow feel that I overcomplicated things a little but hey, it works.

For functions that I entirely pass through, I simply create a forwarding export in my DEF file, looking like this:

??BarFoo@WhoCares@@@Z = OriginalDllName.??BarFoo@WhoCares@@@Z