Writing DLLs with C/C++
The message shown above is remarkably clear: there’s no Checkfunction in the DLL! At least this time, the culprit is notVisual Basic, but a particular feature of Visual C++.

When you write DLLs with C or C++ you have to qualify thefunction with a macro to specify the calling convention and makesure the function will be regularly exported. Macros such asAPIENTRY, WINAPI, or a keyword such as __stdcall do just this.They are all synonims. Using the standard convention (also knownas the PASCAL convention) causes the parameters of a function tobe inserted onto the stack in the same order they appear in thefunction’s declaration from right to left. As a result, thefunction will pick them up in the reading order. (The stackfollows a LIFO discipline.) Adhering to the standard conventionalso means the all the arguments are assumed to be by valueunless a pointer is explicitly mentioned and the stack is cleanedup after the call.

Let’s try to recompile the Visual C++ DLL without the WINAPIqualify, and following a non-standard C-based convention. Whatchanges is just the error!

What happens is that now Visual Basic finds out a functioncalled Check but it doesn?t like the function’s callingconvention ?which is not the Pascal’s.

Looking at the C++ function declaration, notice the keyword extern”C”. This is necessary only if you’re using the C++language, that is the file is compiled as C++ and not C. It justinforms both compiler and linker that the function is not apublic member of any class but must be considered as a simplerstandalone, global symbol. In other words, that function namemust not be changed to fit into a class name scheme. (When youexports C++ classes, their methods are exported through differentnames. The new name is a combination of the method’s name, theclass name and the prototype to make the final symbol unique.Such a process is known as name-mangling and may differfrom compiler to compiler!)

Overall, the extern “C” keyword is notresponsible for the errors we’re having. The same thing can besaid regarding WINAPI. Perhaps, the point to investigate furtheris the keyword that actually causes the function to be exported.

Exporting Functions from C/C++ DLLs
From Visual C++ 5.0 on, Microsoft recommends the use of _declspec(dllexport)to export a DLL function. There’s an alternative technique: don?tadd anything at the level of the function’s declaration but groupall the exported names in a definition file (DEF) to be linked tothe project. The use of a DEF file is suggested to be somewhatobsolete. The DEF file for a simple DLL exporting just a Checkfunction is like this:

LIBRARY vbcppEXPORTSCheck @1

You just declare the library and lists the exported functionswith an optional number that can be used as well as the functionname to load the function dynamically.

In theory these two techniques should be completely equivalent.In practice, this is true only if you’re calling the DLL fromwithin C/C++ programs. If you want to call the DLL also from VB,then only the DEF technique works fine! Let’s see the details.

It’s Visual C++’s fault?
By design the Visual C++ applies a sort of name-mangling tofunction names when it detects the standard PASCAL callingconvention (WINAPI, APIENTRY or __stdcall). Due to this, a simpleCheck function becomes an odd [email protected], as shown below.

The screenshot reproduces a portion of the output that dumpbin.exegenerates. It is a utility you find in the BIN directory ofVisual C++. It returns information about the content of a Win32binary module. The command line I used to get this is:

dumpbin /EXPORTS vbcpp.dll >vbcpp.lst

The switch EXPORTS makes it enumerate all the exported symbols.As you can see, there’s no mention of a Check function whichjustifies the error we got above. The mangling, and thesubsequent error 453, is due to the PASCAL calling convention. Onthe other hand, if we change the calling convention we obtainanother error! One possible solution is? using anothercompiler to create our C/C++ library. The same scenario doesn?toccur if you compile with the Borland C++ compiler, for example!Another solution might be calling the function with its actualname: [email protected]. However, this isn?t a valid name to VisualBasic. With reason!

Actually, I’ve never experienced this?
I write DLLs almost every day and a large number of them endsup being called from within Visual Basic. So, imagine my surprisewhen I heard of this. Taking for granted that any DLL functionmust be declared WINAPI and that you have to prefix it withextern “C” if you’re writing a C++ file, what remainsto decide is how to actually export a function to make itcallable from VB. You have just to use a DEF file. The name thatthe linker writes in the DLL file is what is written in the DEFfile if any. The linker works in two steps. Firstly, it manglesthe name of the function as soon as it realizes about the PASCALconvention. Secondly, it writes down in the binary file the namedefined by the DEF file. If no DEF file is specified then thefunction names default to the mangled ones. Since I’ve never used_declspec to export functions, but always resorted to DEFs,actually I’ve experienced this. Thus, remember to exportfunctions through a DEF file to make them callable from VBclients. This behavior applies to both Visual C++ 5.0 and 6.0.Everything works fine, instead, with previous versions and othervendor’s compilers.