Name Decoration of dll function, #pragma comment(linker...) - c++

I've got 2 Question concerning exported function names.
I walked through the MSDN Example:
Creating and Using a Dynamic Link Library (C++)
Why can I access the dll function with their undecorated name? There is no .defFile. As MSDN states :
"dllexport of a C++ function will expose the function with C++ name mangling" I am wondering about why this works.
If I remove the __declspec(dllexport) resp. the macro and use instead a
#pragma comment(linker, "/EXPORT:"__FUNCTION__"="__FUNCDNAME__)
within the function body e.g.:
double __stdcall ExternalAdd(double arg1, double arg2)
{
#pragma comment(linker, "/EXPORT:"__FUNCTION__"="__FUNCDNAME__)
return arg1 + arg2;
}
I get a linker error. Why?
dumpbin /Exports on the dll shows:
ExternalAdd = #ILT+720(?ExternalAdd##YGNNN#Z)
dumpbin /Headers on the lib shows:
Symbol name : ExternalAdd
...
Name : ExternalAdd
Many thanks for your help.

Related

Visual studio C++ 20 module import .h&.cpp lib

lib1 has two files
math.h
inline void hello();
and math.cpp
#include <iostream>
#include "math.h"
void hello() {
std::cout << "hello from math";
}
lib2 is a c++ 2a module lib:
export module Bar;
import "math.h";
import std.core;
export namespace bar {
void BarFunc() {
hello();
}
}
visual studio 16.8.0
compiler will say:(Bar.ixx.obj) : error LNK2001: unresolved external symbol "void __cdecl hello(void)" (?hello##YAXXZ)
math.h
inline void hello();
to
void hello();
works.
Given the current information, I am afraid that I cannot determine the cause of the problem. So, I suggest that you could use DUMPBIN to help you find the cause.
The /EXPORTS and /SYMBOLS options of the DUMPBIN command-line tool are
useful here. They can help you discover which symbols are defined in
your .dll and object or library files. You can use the symbols list to
verify that the exported decorated names match the decorated names the
linker searches for.
In some cases, the linker can only report the decorated name for a
symbol. You can use the UNDNAME command-line tool to get the
undecorated form of a decorated name.

Using a c++ builder application with an external dll

I'm trying to use an external dll in my c++ builder application. The dll (let.s call it X.dll) was created with Qt Creator (using MingW 32 bit compiler, tried gcc as well )
and consists of a single functon to keep things simple (besides X.dll, an import library X.a is also created).
The dll header (Dll_lib.h) is basically just
__declspec(dllexport) Dll_method(float *p, int n);
If I create a simple Qt application, add the dll header to it and link it to the dll import library X.a, everythink works as expected.
However, when I try to use the dll in my c++ builder application, I get an "unresolved external _Dll_method referenced from ..." error.
The part of my c++ builder app that references the dll looks like
#include "lib\Dll_lib.h"
#pragma comment(lib, "X.lib")
__declspec(dllimport) Dll_method(float *p, int n);
.....
X.lib was created directly from the dll using the implib tool that comes bundled with c++ builder. I also tried to create X.lib from X.a using coff2omf tool but nothing worked and I always get the same error message.
C++ environments have a habit of name mangling to support overloads, different arguments with the same name, like:
int use(int x, char y); // mangles to something like use__Int__Chr.
int use(double x); // mangles to something like use__Dbl.
This allows the correct one to be linked depending on the arguments.
You may need to wrap it inside extern "C" to get it to not mangle the name, something like:
extern "C" {
__declspec(dllimport) Dll_method(float *p, int n);
}
That's assuming you're creating it without name mangling and using it from something that assumes it is mangled. If it's mangled on both sides, you'll probably have to create and use it with extern "C" since there's no guarantee different compilers will mangle with the same rules.
As an aside, you should be able to examine the object files or DLLs created by your toolchain, to ascertain what the function is called where it's defined and also what it's expected to be by the caller. Under Linux, I'd use something like nm, I'm not sure what the equivalent is for Windows.

Standard method for creating dll in c++ and calling in delphi

I am looking for the correct method to create a DLL in C++ and call it in Delphi. I use CodeBlocks for the DLL and Delphi RAD Studio 10.2.
My C++ header and source code for building the DLL as described in How to create dll in C++ for using in C# is as follows:
Main.h:
#ifndef MATH_HPP
#define MATH_HPP
extern "C"
{
__declspec(dllexport) int __stdcall math_add(int a, int b);
}
#endif
Main.Cpp :
#include "main.h"
int __declspec(dllexport) __stdcall math_add(int a, int b)
{
return a + b;
}
This code in CodeBlocks builds math_dll.dll without any error.
Calling the DLL in Delphi:
function math_add(X, Y: Integer): Integer; stdcall; external 'math_dll.dll' name 'math_add';
But when I run Delphi and call this function, I have the following error:
"the procedure entry point math_add could not be located in the dynamic link library math_dll.dll"
Which part of my code is wrong?
The default name mangling for the __stdcall calling convention is _<name>#<bytes_in_arguments>. So your DLL function is most likely being exported as '_math_add#8' instead of as 'math_add' like you are expecting. Use a tool like PEDUMP to verify that.
You can use a .DEF file when compiling the DLL to change the exported name, or you can update your Delphi function declaration to use the correct exported name for the name attribute.

Exporting function names from C++ Dll to Delphi

I have a working DLL written in C++ with Visual Studio 2015. It contains many functions of the form:
BECALIBRARY_API int Functions::GetVersion(char* ptrVersionString)
{
char * Version;
Version = "Test 123456";
strcpy_s(ptrVersionString, strlen(Version) + 1, Version);
return strlen(Version);
}
The Delphi function to retrieve this is:
unit uBecaLibrary;
interface
function getVersion(Str1: pAnsichar): integer; stdCall;
implementation
function getVersion; external 'BecaLibrary.dll' index 1;
//function getVersion; external 'BecaLibrary.dll' name 'getVersion';
end.
This works fine except that I have to maintain the Delphi code using the index numbers of the DLL.
What do I need to do to both the C++ side and the Delphi Seattle Windows 10 side to use function names rather than indexes.
You can use dumpbin utility to view exported names as
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\dumpbin.exe" /EXPORTS BecaLibrary.dll
Names will probably be mangled but it should not be a problem.
If you can change DLL, you can add following inside function body to export unmangled name
#pragma comment(linker, "/EXPORT:" __FUNCTION__ "=" __FUNCDNAME__)
You can just use the function name on the last like this
var
function getVersion(Str1: pAnsichar): integer; stdCall; external 'BecaLibrary.dll' name 'GetVersion';
implementation
For the DLL
To export an undecorated name, you can link by using a Module Definition (.def) file that defines the undecorated name in an EXPORTS section. For more information, see EXPORTS. Another way to export an undecorated name is to use a #pragma comment(linker, "/export:alias=decorated_name") directive in the source code.
When you declare dllexport or dllimport, you must use extended attribute syntax and the __declspec keyword.
Source: https://msdn.microsoft.com/en-us/library/3y1sfaz2.aspx

Can't find DLL entry point

I have been trying to call a DLL function in my VBA project but I keep getting this error message:
Run-time error '453': Can't find DLL entry point "CheckStatus" in "Power.dll"
Here is the definition for the DLL in the C++ file:
#define CLASS_DECLSPEC extern "C" __declspec(dllexport)
CLASS_DECLSPEC int __stdcall CheckStatus();
And here is how I'm trying to declare it and call it in VBA:
Public Declare Function CheckStatus Lib "Power.DLL" () As Long
Dim test As Long
test = CheckStatus
And then when I run it received the aforementioned error message.
Does anyone know how to fix this? Thanks.
This has to do with name mangling (even with extern "C").
Look at what export is really in the DLL, a guess would be either _CheckStatus or _CheckStatus#0.
To force the name to be as-is, make a .def file in your project with the content:
EXPORTS
CheckStatus=CheckStatus
using this MSDN article, I would try this method of declaring the function:
Public Declare Function CheckStatus Lib "Power.DLL" Alias "_CheckStatus#0" () As Long