Dynamic library loading issue

Question

I'm trying to make a very simple example of run-time dynamic library loading on Windows, but GetProcAddress() is returning errors and I don't understand why.

dll_test.cpp:

#include "stdafx.h"
#include "dll_test.h"

static const char* const helloWorldStr = "Hello world!";
static const int age = 25;

DLL_TEST_API const char* helloWorld()
{
    return helloWorldStr;
}

DLL_TEST_API const int getAge()
{
    return age;
}

dll_test.h:

#ifdef DLL_TEST_EXPORTS
#define DLL_TEST_API __declspec(dllexport)
#else
#define DLL_TEST_API __declspec(dllimport)
#endif

DLL_TEST_API const char* helloWorld();
DLL_TEST_API const int getAge();

And now the dynamic linking code, dll_dynamic.cpp:

#include <stdio.h>
#include <stdlib.h>
#include <Windows.h>

typedef const char* (__cdecl *helloWorldFunc)();
typedef const int (__cdecl *getAgeFunc)();

int main()
{
    HMODULE lib = LoadLibrary(L"C:\\VS\\dll_compile\\Release\\dll_test.dll");

    if (lib == NULL)
    {
        fprintf(stderr, "Failed to open lib (%lu)\n", GetLastError());
        return EXIT_FAILURE;
    }

    helloWorldFunc myHelloWorld = (helloWorldFunc) GetProcAddress(lib, "helloWorld");

    if (myHelloWorld == NULL)
    {
        fprintf(stderr, "Failed to open helloWorld() (%lu)\n", GetLastError());
        return EXIT_FAILURE;
    }

    getAgeFunc myGetAge = (getAgeFunc) GetProcAddress(lib, "getAge");

    if (myGetAge == NULL)
    {
        fprintf(stderr, "Failed to open getAge() (%lu)\n", GetLastError());
        return EXIT_FAILURE;
    }

    printf("\"%s\"\n", myHelloWorld());
    printf("age = %d\n", myGetAge());

    if (!FreeLibrary(lib))
    {
        fprintf(stderr, "Failed to free lib (%lu)\n", GetLastError());
        return EXIT_FAILURE;
    }

    return EXIT_SUCCESS;
}

This code prints the following:

Failed to open helloWorld() (127)

This error is defined as:

ERROR_PROC_NOT_FOUND

127 (0x7F)

The specified procedure could not be found.

I've used objconv to check that the functions are indeed exported, and I think they are, if I've interpreted the following correctly:

; Disassembly of file: dll_test.dll
; Sun Nov 15 20:06:06 2015
; Mode: 32 bits
; Syntax: MASM/ML
; Instruction set: 80386

.386
option dotname
.model flat
assume fs:nothing

public ?helloWorld@@YAPBDXZ
public ?getAge@@YA?BHXZ
public Entry_point

extern EncodePointer: near                              ; KERNEL32.dll
extern GetSystemTimeAsFileTime: near                    ; KERNEL32.dll
extern GetCurrentProcessId: near                        ; KERNEL32.dll
extern GetCurrentThreadId: near                         ; KERNEL32.dll
extern GetTickCount: near                               ; KERNEL32.dll
extern QueryPerformanceCounter: near                    ; KERNEL32.dll
extern IsDebuggerPresent: near                          ; KERNEL32.dll
extern SetUnhandledExceptionFilter: near                ; KERNEL32.dll
extern UnhandledExceptionFilter: near                   ; KERNEL32.dll
extern GetCurrentProcess: near                          ; KERNEL32.dll
extern TerminateProcess: near                           ; KERNEL32.dll
extern InterlockedCompareExchange: near                 ; KERNEL32.dll
extern Sleep: near                                      ; KERNEL32.dll
extern InterlockedExchange: near                        ; KERNEL32.dll
extern DecodePointer: near                              ; KERNEL32.dll
extern _except_handler4_common: near                    ; MSVCR100.dll
extern _onexit: near                                    ; MSVCR100.dll
extern _lock: near                                      ; MSVCR100.dll
extern __dllonexit: near                                ; MSVCR100.dll
extern _unlock: near                                    ; MSVCR100.dll
extern __clean_type_info_names_internal: near           ; MSVCR100.dll
extern _crt_debugger_hook: near                         ; MSVCR100.dll
extern __CppXcptFilter: near                            ; MSVCR100.dll
extern _amsg_exit: near                                 ; MSVCR100.dll
extern _initterm_e: near                                ; MSVCR100.dll
extern _initterm: near                                  ; MSVCR100.dll
extern _encoded_null: near                              ; MSVCR100.dll
extern free: near                                       ; MSVCR100.dll
extern _malloc_crt: near                                ; MSVCR100.dll

Next time, use Dependency Walker. http://www.dependencywalker.com/ It is a much easier tool to use. — PaulMcKenzie, Nov 15 '15 at 22:08
Note carefully: `public ?helloWorld@@YAPBDXZ`. Not `public helloWorld`. — Raymond Chen, Nov 16 '15 at 03:52

score 3 · Accepted Answer · edited May 23 '17 at 10:27

3

You'll need to make sure that the exported function names are seen as C, otherwise the names get mangled. You could do this:

extern "C" {

    DLL_TEST_API const char* helloWorld()
    {
        return helloWorldStr;
    }

    DLL_TEST_API const int getAge()
    {
        return age;
    }

}

If you don't know if your C header files are going to be used in C++, you can make sure your symbols are exported in the C linkage by wrapping your your header files using

#ifdef __cplusplus
extern "C" {
#endif

and

#ifdef __cplusplus
}
#endif

edited May 23 '17 at 10:27

Community

1
1

answered Nov 15 '15 at 20:50

Kenney

9,003
15
21

Thanks, that worked. Why, though? I didn't declare the functions in any class/namespace to begin with, so why did Windows mangle them? – Doddy Nov 15 '15 at 21:34
It's in a `cpp` file so it's treated as C++. [Here](http://stackoverflow.com/questions/3789340/combining-c-and-c-how-does-ifdef-cplusplus-work) you'll see a common syntax used in header files. – Kenney Nov 15 '15 at 21:39

Dynamic library loading issue

1 Answers1