So you added a function to your dll, but your application can’t call the function. This can happen for several reasons:
You didn’t build the your source code
This is sort of the “did you plug in the device?” kind of question, but worth checking. This can include are you building the right directory? I have been know to work in a folder on someone else’s computer by mistake, but only after working remotely with someone else and looking at files on their computer.
You didn’t put the new version of the DLL in the OS
Review Platform Builder: Pulling it all together with Makeimg, but you already checked that didn’t you?
You didn’t export the function from the dll
This is much more common a problem and more difficult to understand. So first let’s see if you did export the function. To do that, you will use dumpbin.exe.
Using Dumpbin /EXPORTS
Dumpbin.exe is a valuable tool for looking into your exe or dll. One of the things that you can do is look to see which functions have been exported so that another exe or dll can call the function. The /EXPORT flag allows you to see the exported functions. If your function isn’t listed, then your application will not be able to call it.
> dumpbin /EXPORTS MyDLL.dll
Microsoft (R) COFF/PE Dumper Version 7.10.4017
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file MyDll.dll
File Type: DLL
 Section contains the following exports for MyDll.dll
    00000000 characteristics
    48527C77 time date stamp Fri Jun 13 09:56:07 2008
        0.00 version
           1 ordinal base
          7 number of functions
          7 number of names
    ordinal hint RVA      name
          1    0 00003074 MyFunction1
          2    1 00003110 MyFunction2
          3    2 00003160 MyFunction3
          4    3 000031B0 MyFunction4
          5    4 00003378 MyFunction5
          6    5 00003444 MyFunction6
          7    6 000034FC MyFunction7
        1000 .data
        1000 .pdata
        1000 .reloc
        4000 .text
So now you know if your function is exported from the DLL, if it is not there are several ways to export the function:
1.       Use a .def file to export it:
LIBRARY       MyDll
2.       Use export in the function definition
__declspec(dllexport) BOOL MyFunction(void)
C/C++ Incompatibility
The first time that you run into this one it can be an eye opener. C++ decorates function names, which is inconsistent with C. If you work exclusively with C files, this won’t be a problem,  or if you work exclusively with CPP files and only call standard APIs this won’t be a problem. But the first time that you cross the boundary and try to call a C function from a CPP file, you might run into this one.
Let’s look at the following files:
#include <windows.h>

int MyAPI( void )
                return( TRUE );
#include <windows.h>

extern int MyAPI(void);

int Foo( void )
                return( MyAPI() );
These look simple enough, but you will have a linker error when you build it:
BUILD: [01:0000000051:ERRORE] File2.obj : error LNK2019: unresolved external symbol "int __cdecl MyAPI(void)" (?MyAPI@@YAHXZ) referenced in function "int __cdecl Foo(void)" (?Foo@@YAHXZ)
But we can fix this by changing File2.cpp:
#include <windows.h>
extern "C" {
                int MyAPI(void);
int Foo( void )
                return( MyAPI() );
By putting the extern “C” {} wrapper around the declaration of MyAPI() we tell the compiler not to add the C++ function decoration on the function call.
Notice in this example, I didn’t show how I compiled the code. I did this on purpose because the problem exists whether this is built:
·         Into OBJs and linked to create an exe or dll
·         File1.c into a static library and linked with File2.obj to create an exe or dll
·         File1.c into a dll and the lib lined with File2.obj to create an exe or dll that implicitly dynamically links with the dll that contains File1.c
But were this become more challenging, and applies to this article, is when File1.c is built into a dll and a modified File2.cpp is built into an exe or dll that explicitly dynamically links with the dll that contains File1.c
File2.c explicitly dynamically linking with File2.c:
#include <windows.h>
int Foo( void )
                HMODULE hLib = LoadLibrary( TEXT("File1.dll") );
                int (*MyAPI)( void ) = GetProcAddress( hLib, TEXT("MyAPI") );
                FreeLibrary( hLib );
                if( MyAPI != NULL )
                                return( MyAPI() );
                return FALSE;
 This uses LoadLibrary() and GetProcAddress(). In this case, there will be no linker error, but there will be a runtime error when GetProcAddress( hLib, TEXT(“MyAPI”)) is called.
Copyright © 2008 – Bruce Eitman
All Rights Reserved