How to call a C++ dll function at runtime ?

Despite an enormous amount of information available on runtime dynamic linking of DLLs, I cannot get things to work using Win 7 / VS 2010. While there are many pitfalls, my current problem is how to find the 'decorated' names. Here is a snippet of a header file for my dll (lap.dll):

Code:

---

#ifdef LAP_EXPORTS
#define LAP_API __declspec(dllexport)
#else
#define LAP_API __declspec(dllimport)
#endif

#include "Parser.h"


// This class is exported from the LAP.dll
class LAP_API Clap {
public:
        Clap(void);
        ~Clap(void);

// Attributes
protected:
        char * m_pList;
        double ** m_fMatrix;
        CParser * m_pParser;

// Operations
public:
        void PutMatrix(double ** pMatrix);
        double ** GetMatrix();
        void DumpMatrix(double ** pMatrix);
        double **CreateMatrix(int nRows, int nCols);
        void FreeMatrix(double ** pMatrix);
        double ** Parse(char * expr);
        int GetOpMode();
        int SaveVariableMap(char * sfile);
        int LoadVariableMap(char * sfile);
        char * GetKeyList();
        char * GetVarList();
        char * GetFunList();
        void AddVariable(TNT::Matrix<double> Mc, char * svarnam);
        int EraseAllVariables();
        int RunScript(char * sfile);
        int ProcessScript(char* sscript);
       
};

---

and here is the lap.def file:

Code:

---

LIBRARY

EXPORT

        PutMatrix
        GetMatrix;
        DumpMatrix
        CreateMatrix
        FreeMatrix
        Parse
        GetOpMode
        SaveVariableMap
        LoadVariableMap
        GetKeyList
        GetVarList
        GetFunList
        AddVariable
        EraseAllVariables
        RunScript
        ProcessScript

---

Both lap.dll and the test app compile, but I cannot figure out how to define the correct function prototypes in the test file.

Here's a fragment of the test file. The handle comes back as valid, but I cannot get the proc address correctly:

Code:

---

#include "stdafx.h"

#include <windows.h>
#include <stdio.h>

typedef double ** PARSEPROC(LPSTR);

int _tmain(int argc, _TCHAR* argv[])
{
        cout << "Normal Beginning" << endl << endl;

    HINSTANCE hinstLib;
    PARSEPROC ProcAdd;
    BOOL fFreeResult, fRunTimeLinkSuccess = FALSE;
 
    // Get a handle to the DLL module.
 
    hinstLib = LoadLibrary(TEXT("lap.dll"));
 
    if (hinstLib != NULL)
    {
                printf("\nHandle is valid\n");

                ProcAdd = (PARSEPROC) GetProcAddress(hinstLib, "Parse");
        // If the function address is valid, call the function.
 
        if (NULL != ProcAdd)
        {
                        printf("\nProcAdd is not NULL\n\n");

            fRunTimeLinkSuccess = TRUE;
        }
        // Free the DLL module.
 
        fFreeResult = FreeLibrary(hinstLib);
    }

    // If unable to call the DLL function, use an alternative.
    if (! fRunTimeLinkSuccess)
        //printf("Message printed from executable\n");
                printf("Unable to call the DLL function\n");

        printf("\n\nNormal Termination\n\n");


        getchar();

        return 0;
}

---

All my efforts have failed to capture the procedure address. In fact, the way the test app is written here, it will not compile as it will not allow assignment (or casting) of the GetProcAddress, even though GetProcAddress(hinstLib, "Parse"); by itself will compile and run. I am uncertain whether this problem is due to name decoration, test app syntax, def file syntax, or some other problem.

There used to be a way to set the compiler to generate docorated names file when compiling a dll, but I can not find such a tool in VS 2010. The DumpBin.exe tool needed to have the path to mspdb100.dll set. When run against lap.dll, it DumpBin produces the following :

Code:

---

File Type: DLL

  Summary

        2000 .data
        3000 .idata
      18000 .rdata
        7000 .reloc
        1000 .rsrc
      BA000 .text
      59000 .textbss

---

which I have no clue as to what it means.

Any help greatly appreciated. But I've looked at a number of tutorials and most are either outdated or deal only with C declared function. It is worth noting that lap.dll has performed flawlessly when used as a staically bound dll.

Quote:

---

most are either outdated or deal only with C declared function

---

I deal with dlls since 1996. And I'm still not aware of a way how to wire up a pure C++ class from dll dynamically, what actually you're trying to do.

Well, the available options are:

• wrap the class into COM class
• expose a needed subset of class functions as interface

In other words, you have to re-design the dll to let it be linked at runtime. Or make a proxy dll with plain C exports which links the dll statically (the way most of plugins do). :)

Quote:

---

While there are many pitfalls, my current problem is how to find the 'decorated' names.

---

Well, your current problem looks pretty trivial comparing to what you gonna face to with the rest of "many pitfalls."

Quote:

---

Originally Posted by Mike Pliam

The handle comes back as valid, but I cannot get the proc address correctly:

---

Instead of going through trial and error with calling GetProcAddress, you should know that this function works in a very simple manner. In addition you can use the GUI tool Dependency Walker to get the list of exported names, and those exported names are the only valid ones that GetProcAddress will work with.

As to GetProcAddress, whatever name you state in the second parameter must match exactly with the name that is exported from the DLL. This includes casing, any special characters such as @, ?, etc. So if the exported function is "SomeClass@Parse@@int??" or some other weird name, then that is the name you must use for GetProcAddress to work. GetProcAddress doesn't know anything about name mangling, non-mangled names, def files, nothing. All it knows about is that final name that shows up in the export table of the DLL, and that is the name you must use to return a valid address.

Regards,

Paul McKenzie

Mike, in addition to what Paul just said. I believe you don't see a difference between global C++ function and C++ class member function. Suppose you obtained the function address, what you could do with that? Calling it directly gonna crash your app for 100%. To be called properly, the Clap object should be created first. Which means Clap constructor should be resolved and called properly. And so on and so forth...

Igor asked:

Quote:

---

what actually you're trying to do.

---

I want to give an application interface away for free, then charge for modular updates. I think the runtime dynamic linking dll is the way to go here. 1) Your client only needs to download and install a new dll and not the whole program interface 2) if the dll called by the client is not available (he didnt purchase it yet), the program can handle it and it will still run(unlike what happens if a static dll is missing). To accomplish this, the main app interface needs to be able to call the new dll function(s). Since there are only a few functions in the dll that serve as a gateways to the dll library, this shouldnt be much of a problem. I think that this is the method used by many programs to provide updates, add-ons, and plug-ins.

Paul, I downloaded and employed DependencyWalker, dragging lap.dll onto it's main window, and was quickly able to obtain a complete list of the decorated function names. THANKS! With that, I am able to obtain a Proc Address that is presumably valid. Now, how to use that address to execute the desired function in the test app?

Code:

---

#include "stdafx.h"

#include <windows.h>
#include <stdio.h>

typedef double ** PARSEPROC(LPSTR);

int _tmain(int argc, _TCHAR* argv[])
{
    HINSTANCE hinstLib;
        FARPROC ParseProcAddr;
    BOOL fFreeResult, fRunTimeLinkSuccess = FALSE;
 
    // Get a handle to the DLL module.
 
    hinstLib = LoadLibrary(TEXT("lap.dll"));
 
    if (hinstLib != NULL)
    {
                printf("\nHandle is valid\n");

                ParseProcAddr = GetProcAddress(hinstLib, "?Parse@Clap@@QAEPAPANPAD@Z");  // Tochiba
               
                if (ParseProcAddr == NULL) { printf("ParseProcAddr is NULL\n"); }

        // If the function address is valid, call the function.
 
        if (NULL != ParseProcAddr)
        {
                        printf("\nParseProcAddr is not NULL\n\n");

            fRunTimeLinkSuccess = TRUE;
 
                        double ** pMatrix;
                        //pMatrix = (double **)(ParseProcAddr)("x = 3");
      }
        // Free the DLL module.
 
        fFreeResult = FreeLibrary(hinstLib);
    }

    // If unable to call the DLL function, use an alternative.
    if (! fRunTimeLinkSuccess)
                printf("Unable to call the DLL function\n");

        return 0;
}

---

Output:
Handle is valid

ParseProcAddr is not NULL

So the problem now becomes, given a function prototype definition, double ** PARSEPROC(LPSTR), and given a presumably valid dll procedure address, FARPROC ParseProcAddr, how do I use these to execute the procedure and retrieve the double ** ? That which I have commented out above will not compile for reasons of both assignment and casting errors.

Why not use COM where the interface is compiler and platform independent?

Trying to expose C++ classes is a pain due to name decoration. And the real problem is the decoration could change between compiler versions or even compiler update.

For this to work reliably, you'll need to build the app and the new plugins with the same compiler. I would avoid that situation if I were you.

Quote:

---

Originally Posted by Mike Pliam

Paul, I downloaded and employed DependencyWalker, dragging lap.dll onto it's main window, and was quickly able to obtain a complete list of the decorated function names. THANKS!

---

However, I agree with Arjay. You do not want to get into the business of using mangled names, as that can change very easily (and is not compiler independent).

Either you use COM, or you use non-mangled names and create 'C' exported functions (similar to how most professional non-COM DLL's are done).

For the latter, you probably have to rethink your design in terms of trying to export a class. Instead you need to create a "Matrix API" that creates, destroys, and manipulates a Matrix, without having the client to even know there is a class internal to the DLL that is working behind the scenes.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by Mike Pliam

I want to give an application interface away for free, then charge for modular updates.

---

Then your approach of native exporting C++ class is wrong. What you need is "expose a needed subset of class functions as interface". Of course additionally you'll need some API for object creation/destruction, like Paul already said. The technique is really mature and proven to be safe and effective. With certain effort your dll becomes even cross language compatible and this way installable in third party apps, letting you reach clients beyond C++. As I mentioned, most of plugins go this way.

OK. I get the point. I have abandoned the idea of exporting class members and have began to experiment with writing simple C language DLL exports. I have attached a small demo that shows how to use runtime dynamic dll linking to export functions that return integers, doubles, and double pointers. But the pointers present a problem that Paul helped me to solve some time ago. Namely, once memory is allocated in the dll space, how does one deallocate that memory. With static linking and using class member exports, one could take advantage of the class destructor to free allocated memory and thus avoid memory leaks. But I cannot figure out how to do memory cleanup using only C. Note that the attached demo works but with considerable memory leak.

Quote:

---

Originally Posted by Mike Pliam

But the pointers present a problem that Paul helped me to solve some time ago. Namely, once memory is allocated in the dll space, how does one deallocate that memory

---

There should be another exported function that the client calls to clean up the memory and do any other housekeeping to remove the Matrix.

In addtion, the client shouldn't know the internals of how to clean up or properly destroy the Matrix. Today it could be delete[], tomorrow it could be GlobalFree(), next year it could be some other function internally -- the client shouldn't need to know this (or care).

Regards,

Paul McKenzie

Not so easy though, Paul. I think you and I have been down this road before.

Say the dll code contains the following declarations:

Code:

---

extern MY_API double * pVector;

// Get rid of name mangeling
extern "C"
{
...
        MY_API double * fvec(void);
...
        MY_API void cleanup(void);
...
}

---

and in the implementation file:

Code:

---

MY_API double * pVector;

double * CreateVector(int nSize)
{
        // Allocate memory including leading size containing byte
        pVector = new double [nSize + 1];

        memset(pVector, 0x00, nSize+1);

        return pVector;

}// CreateVector(int nSize)

void FreeVector(double * pVector)
{
    delete [] pVector;
        pVector = NULL;

}// FreeVector()

...

MY_API double * fvec(void)
{
        pVector = CreateVector(5);
        pVector[0] = 5.0;
        pVector[1] = 6.432;
        pVector[2] = 1.543;
        pVector[3] = 2.654;
        pVector[4] = 3.765;
        pVector[5] = 5.876;
        return pVector;
}

...

MY_API void cleanup(void)
{
        if(pVector != NULL) { FreeVector(pVector); pVector = NULL; }
        _RPT0(0, "cleanup ran ok\n");
}

---

Then if I execute the vector producing function and the cleanup using runtime dynamic linking in the test app,

Code:

---

typedef double *(*FVEC)();
typedef void (*CLEANUP)();

int _tmain(int argc, _TCHAR* argv[])
{
        int iOrg = _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG);       
        _CrtSetDbgFlag(iOrg | _CRTDBG_LEAK_CHECK_DF);

        cout << "Normal Beginning" << endl << endl;

            HINSTANCE hinstLib;
            BOOL fFreeResult, fRunTimeLinkSuccess = FALSE;

        FVEC _MYVEC = NULL;
        CLEANUP _MYCLEANUP = NULL;

            // Get a handle to the DLL module.
 
            hinstLib = LoadLibrary(TEXT("my.dll"));
 
            if (hinstLib != NULL)
            {
                _MYVEC = (FVEC)GetProcAddress(hinstLib, "fvec");
                _MYCLEANUP = (CLEANUP)GetProcAddress(hinstLib, "cleanup");

                        // If the function address is valid, call the function.
                if (NULL != _MYVEC)
                {
                        printf("\n_MYVEC is not NULL\n\n");

                                    fRunTimeLinkSuccess = TRUE;
 

                        printf("%0.0f\n", _MYVEC()[0]);
                        for(int i=1; i <= _MYVEC()[0]; i++)
                        {
                                printf("%0.3f  ", _MYVEC()[i]);
                        }
                        printf("\n");
                }

                if (NULL != _MYCLEANUP)
                {
                        printf("\n_MYCLEANUP is not NULL\n\n");

                                    fRunTimeLinkSuccess = TRUE;
 
                        _MYCLEANUP();
                }

                        // Free the DLL module.
                        fFreeResult = FreeLibrary(hinstLib);
    }

    // If unable to call the DLL function, use an alternative.
    if (! fRunTimeLinkSuccess)
        printf("Unable to call the DLL function\n");

        return 0;
}

---

the test application compiles and runs just fine, and I can see that the 'cleanup ran ok', yet there remains a memory leak corresponding to the memory allocated for the vector.

What am I doing wrong?

I use Notepad, to see decorated stuff.
No third party tools needed.

http://img708.imageshack.us/img708/1103/pooltex.jpg

Where does the "decorated stuff" start and end? It's a lot easier to use a tool that will tell you *exactly* what the decorated name is (instead of making guesses).

Viggy

Quote:

---

Originally Posted by Mike Pliam

What am I doing wrong?

---

If I counted correctly, you're calling _MYVEC() (and in turn fvec() and CreateVector() inside the DLL) a total of 12 times. Each of these calls except the first one not only allocates a new vector, it also overwrites the pointer to the previous one. When you finally call _MYCLEANUP(), this merely deallocates the last vector you allocated. Hence there are 11 vector memory blocks leaking.

Quote:

---

Originally Posted by Mike Pliam

Say the dll code contains the following declarations:

Code:

---

extern MY_API double * pVector;

// Get rid of name mangeling
extern "C"
{
...
        MY_API double * fvec(void);
...
        MY_API void cleanup(void);
...
}

---

...What am I doing wrong?

---

Your cleanup(), obviously, should take as a parameter a pointer returned by fvec().

Quote:

---

Originally Posted by Mike Pliam

Not so easy though, Paul. I think you and I have been down this road before.

---

The problem is not your DLL -- the problem is that your client/test program is misusing the DLL/API

Code:

---

        for(int i=1; i <= _MYVEC()[0]; i++)
        {
                printf("&#37;0.3f  ", _MYVEC()[i]);
        }

---

The _MYVEC() calls a function to allocate memory, and you're calling this in a loop. Each time, you're losing the handle that was created. So where is the call to free this memory that you've allocated for each of these allocations?

This is no different than doing this:

Code:

---

for (int i = 0; i < 12; ++i )
  HWND hWmd = CreateWindowEx( /* whatever */ );

---

How are you going to call "DestroyWindow" for each window when you've lost all the window handles (except the last) that CreateWindowEx returned?

Or this:

Code:

---

char *p;
for (int i = 0; i < 12; ++i )
  p = new char [10];

---

How are you going to free the memory for each allocation, when you've lost the return value of "new" in each iteration of the loop (except the last one)?

If an API or system call is documented to return a HANDLE, memory, Matrix, whatever, and it is the client's responsibility to free the handle by calling a function, then incorrect coding on the client's part doesn't mean the API or system call is faulty. There is just so much an API can do -- if the programmer using the API is coding in a faulty way, then nothing an API can do can save that programmer. The best that can be done is fully document and supply example programs that show proper usage of the functions.

As VladimirF pointed out, you should be using the pointer returned by fvec as a handle of some type, and it is the app's responsibility to use this handle when manipulating the matrix. If you want an example, look at the Windows API -- to do anything with a window, you must provide an HWND that was previously created with some sort of window creation function. Similarly, to do anything with your matrix, you supply the pointer that was returned from the Matrix creation function.

Regards,

Paul McKenzie

I think I get it now. My mistake was thinking that I could index the function pointer as one usually can do with a pointer, but that is not the case. Simply capturing the pointer returned by the function allows complete pointer indexing, and a single call to cleanup the pointer suffices. This little example works to return a vector from a dll using runtime dynamic linking without a memory leak.

Code:

---

///////////////////////////////////////////////////////////////////////////////
// mydll.h

#ifdef MY_EXPORTS
#define MY_API __declspec(dllexport)
#else
#define MY_API __declspec(dllimport)
#endif


extern MY_API double * pVector;

// Get rid of name mangeling
extern "C"
{

        MY_API double * fvec(void);

        MY_API void clean(double * dp);

}

////////////////////////////////////////////////////////////////////////////////////
// mydll.cpp

#include "stdafx.h"
#include "my.h"

MY_API double * pVector;

double * CreateVector(int nSize)
{
        // Allocate memory including leading size containing byte
        pVector = new double [nSize + 1];

        memset(pVector, 0x00, nSize+1);

        return pVector;

}// CreateVector(int nSize)

void FreeVector(double * pVector)
{
    delete [] pVector;
        pVector = NULL;

}// FreeVector(double * pVector)

MY_API double * fvec(void)
{
        pVector = CreateVector(8);
        pVector[0] = 8.0;
        pVector[1] = 6.4342;
        pVector[2] = 1.5453;
        pVector[3] = 2.6546;
        pVector[4] = 3.7657;
        pVector[5] = 4.23423;
        pVector[6] = 5.1232;
        pVector[7] = 6.87654;
        pVector[8] = 7.7755;
        return pVector;
}

MY_API void clean(double * dp)
{
        if(dp != NULL)
        {
                delete [] dp;
                dp = NULL;
        }
}

/////////////////////////////////////////////////////////////////////////////////////////
// test.cpp

#include "stdafx.h"

#include <windows.h>
#include <stdio.h>

// Function pointers that will be used for the DLL functions.
typedef double *(*FVEC)();
typedef void (*CLEAN)(double *);

int _tmain(int argc, _TCHAR* argv[])
{
        int iOrg = _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG);       
        _CrtSetDbgFlag(iOrg | _CRTDBG_LEAK_CHECK_DF);

        vector<double> vf;
    HINSTANCE hinstLib;
    BOOL fFreeResult, fRunTimeLinkSuccess = FALSE;

        FVEC _MYVEC = NULL;
        CLEAN _MYCLEAN = NULL;

    // Get a handle to the DLL module.
 
    hinstLib = LoadLibrary(TEXT("my.dll"));
 
                if (NULL != _MYVEC)
                {
                        printf("\n_MYVEC is not NULL\n\n");

            fRunTimeLinkSuccess = TRUE;
 
                        double * pVec = NULL;

                        // get vector
                        pVec =  _MYVEC();
                        int N = (int) pVec[0];
                        vf.resize(N);

                        for(int i=1; i <= N; i++)
                        {
                                vf[i-1] = pVec[i];
       
                        }
                        printf("\n");
                               
                        _MYCLEAN(pVec);

                        for(size_t i = 0; i < vf.size(); i++) { printf("&#37;0.4f\n", vf[i]); }

                }                }

        // Free the DLL module.
        fFreeResult = FreeLibrary(hinstLib);
    }

    // If unable to call the DLL function, use an alternative.
    if (! fRunTimeLinkSuccess)
                printf("Unable to call the DLL function\n");

        for(size_t i = 0; i < vf.size(); i++) { printf("%0.4f\n", vf[i]); }

        return 0;
}

---

Output:
Handle is valid

_MYVEC is not NULL

6.4342
1.5453
2.6546
3.7657
4.2342
5.1232
6.8765
7.7755

Thank you all for your kind help and patience with a slow learner. :)

Quote:

---

Originally Posted by Mike Pliam

My mistake was thinking that calling the double pointer function once was all I needed to do to get the whole array, but apparently that is not the case.

---

It actually can be implemented that way which would effectively mean making that vector a singleton. However, this is usually not considered good practice. And that's because if two or more parts of your program independently (i.e. without "knowing of each other") access the only one existing vector, they may have unwanted side effects on each other caused by manipulations of the commonly used vector.

Also, there's another little bug in your program:

Quote:

---

Code:

---

        memset(pVector, 0x00, nSize+1);

---

---

memset() always treats the target memory block as an array of bytes, regardless of the type you actually allocated (and that memset() has no idea of). Therefore the count parameter you pass to that function always is a count of bytes. As a consequence of this, the statement above only zeroes out 1/8 of your vector. (That bug slips through unnoticed because right afterwards you fill the vector with actual doubles in fvec().) The correct instruction would look like this:

Code:

---

        memset(pVector, 0x00, (nSize+1) * sizeof(double));

---