I'm using Microsoft Visual Studio 2010 Express: the C++ and VB versions.
- There is some VB code that forms the body of a program, and all the GUI.
- There is also some C++ code that does some fast processing (lots of loops).
I am trying to call the C++ code, compiled as a dll, using:
Private Declare Sub CalcGraph Lib "Model.dll" ()
And at the moment keep getting the error:
Unhandled exception has occurred in your application. Unable to find an entry point named 'CalcGraph' in DLL 'Model.dll'
Could someone explain how to correctly call the DLL, please?
Do you need any other information to better understand the problem?
I'm fairly new to programming, so please be patient with me!
That said, I'm prepared to do the leg-work, and have already spent quite a while reading around on this and other sites. Nothing seems to match quite well enough to help me understand what's going wrong.
Okay, with your help and a fair bit of Google, this finally works!
Here's a run-down, in case it helps anyone else in the future:
BUILDING_DLL
flag but Visual Studio requires you to create a definition in your main.c file.__stdcall
does something called 'name decoration' that is different from name mangling but will still change your function name. Thanks to @slugonamission for giving me a pointer about this. It finally clicked when using dumpbin.exe, as suggested by @HansPassant.__cdecl
manages to avoid name decoration, and compiling in C (or usingextern
and compiling in C++) avoids name mangling.The Implicit / Explicit dll linking is a very important distinction. Implicit linking requires a .lib file, the .dll and perhaps also a .h file. Explicit linking is what I was after - you can get away with the .dll by itsself. Thanks to @squelos for the link explaining this.
And last but not least:
In the dll:
And in the VB code:
And it finally worked!
I'm going to assume here the C++ DLL is written in pure C++ (not C++/CLI or anything like that). It seems that the VB
Lib
keyword will only be importing a .NET procedure, rather than a native procedure. Instead, you need to use P/Invoke.Something like this may work
But of course, fill in your parameters and return types too.
In some cases, depending on how the DLL was generated (ordinal or by name) you may have to use the DLL with GetProcAddress
This documentation here can give you a quick overview of how to use DLL's the oldschool way MSDN Linking overview
And finally, DumpBin can you help you out a lot, by allowing you to inspect a DLL (pretty useful if you dont have the sources or documentation )