V. Rama Krishna (view profile) January 18, 2000 |
Sometimes Explicit Linking to DLL's is advantageous over implicit linking. For example, if at runtime the DLL is not found the application can display an error message and still continue. Explicit linking is also useful if you want users to provide a plugin for your application, in which case you could explicitly load the dll and call some predefined set of functions in it.
Explicit linking to global(non-member) C/C++ is quite easy. For example, suppose you wan't to call to a function ExportedFn in a dll. You can simply export the function like this (or through the def file):-
extern "C" _declspec(dllexport) void ExportedFn(int Param1, char* param2);
Article: Expression Web 2 for PHP DevelopersSimplifying Your PHP Applications Some of the most important new features in Microsoft's recently released Expression Web 2 involve enhanced support for PHP. Don't think this is just a half hearted effort to appeal to the Open Source web development crowd. Expression Web 2 supports PHP developers with a carefully constructed, feature full treatment which you should seriously consider for your PHP applications. » |
Download: Silverlight 2 Beta 2 Runtime Microsoft Silverlight is a cross-browser, cross-platform, and cross-device plug-in for delivering the next generation of .NET based media experiences and rich interactive applications for the Web. Get Silverlight learning resources here and start building Silverlight 2 applications! » |
Catch All the Olympic Highlights in Silverlight Relive the excitement and check out the video highlights on NBCOlympics.com, the largest online media event ever accomplished on the Web. Powered by Microsoft Silverlight, viewers can catch all the Olympic highlights they missed in high-definition. Check it out now! » |
Download: Silverlight 2 SDK Beta 2 This Silverlight 2 Beta 2 Software Development Kit contains documentation, online samples, libraries and tools for developing Silverlight 2 applications. Check out related resources and see what other developers are also downloading. » |
Expression Blend 2.5 Preview Use Expression Blend 2.5 to create and modify managed Silverlight 2-based applications. Expression Blend for Silverlight 2 includes all of the features in Expression Blend 2 but has not reached the quality level of Expression Blend 2 for WPF or Silverlight 1 development. » |
The extern "C" linkage specification is required because otherwise C++ compiler generates a decorated name for the function and the function would not be exported with the name "ExportedFn" instead it would be exported something like "??ExportedFn@QAEX" . If this function resides in a DLL called DLL1.dll a client exe can call this function simply like this :-
HMODULE hMod = LoadLibrary("Dll1.dll"); typedef void (*PExportedFn)(int, char*); PExportedFn pfnEF = (PExportedFn)GetProcAdress("ExportedFn"); pfnEF(1, "SomeString");
But what if you want to export a bunch of member functions of a C++ class and link to them explicitly. There are two problems. The first problem is that C++ member function names are decorated names (Specifying extern "C" does not help). The second problem is that C++ language specifications do not allow pointer to member functions to be converted into other types (later on I will present a simple way to do that). These two problems do restrict exporting of C++ classes in DLL's. In this article I will show some ways by which we could overcome these restrictions and explicitly load classes from dlls.
I am going to present two methods in this article and I will cover another method (delegation) in an other article.
The three methods which I am going to cover in this article are :-
I will be taking the following example class for the purpose if this article.
class A { private: int m_nNum; public: A(); A(int n); virtual ~A(); void SetNum(int n); int GetNum(); };
I have provided two different implementations of the class in two different DLLs. A client exe allows the user to enter the name of the dll from which the class should be loaded and accordingly output the results. You can download the sample project from this link The sample contains one workspace known as ExpClass.dsw, which has three projects one each for the two dlls and one for the client exe. The code demonstrates both the methods.
This method is the basis of COM. When we declare member function(s) of a class as virtual, compiler creates a table of all the virtual functions in the order in which they appear in the declaration. When an object of that class is created the first four bytes of the object point to that table. If we change the declaration of the class A to be :-
class A { private: int m_nNum; public: A(); A(int n); virtual ~A(); virtual void SetNum(int n); virtual int GetNum(); };
Now a table is generated by the compiler which has the three virtual functions - the destructor, SetNum and GetNum. (You can actually observe that a virtual function table is created if you list the assembly with the source code. You can change the project options for that).
Now the object needs to be created in the dll. Since we are going to link only explicitly we need some global exported functions that create an object of the class through operator new. Since there are two constructors we can create two functions : CreateObjectofA() and CreateObjectofA1(int) and export them. Finally the exe can use the object as
typedef A* (*PFNCreateA1)(); PFNCreateA1 pfnCreateA1 = (PFNCreateA1)GetProcAddress(hMod, TEXT("CreateObjectofA1")); A* a = (pfnCreateA1)(); a->SetNum(1); _tprintf(TEXT("Value of m_nNum in a is %d/n"),a->GetNum()); delete a;
The important thing to note is that CreateObjectofA creates the the class using operator new this allows the client exe to safely call opeartor delete.
extern "C" __declspec(dllexport) A* CreateObjectofA1() { return new A(); }
This method is very useful if you want users to make plugins for your applications. The drawback of this method is that the memory for the class must always be allocated in the dll. If the client wants to create an object by allocating memory in a different way it can't do so.
The next method involves obtaining the functions directly through GetProcAddress and calling the functions. The trick is to convert the FARPROC returned by GetProcAddress into C++ pointer to member functions. Fortuantely through C++ facility of templates and union this could be don very easily. All that needs to be done is to define a function like this
template class ="" Src Dest,> Dest force_cast(Src src) { union { Dest d; Src s; } convertor; convertor.s = Src; return convertor.d; }
The above function lets us cast variables of any different types and is more powerful then reinterpret_cast. For example, if we define a pointer type
typedef void (A::*PSetNum)(int);
We can convert a pointer fp which is of type FARPROC to PSetNum simple by using.
FARPROC fp; . . PSetNum psn = force_cast<PSetNum>(fp);
The above operation is not possible through reinterpret_cast or C-Style cast.
Having found a way to convert FARPROC to a pointer to member, let's see ways to export C++ class member functions through friendly names. This can be done through .def files.
The first step is to find the decorated names of each of the functions that need to be exported, this can be done through either through map file or by generating assembly listing. Then the functions can be exported by friendly names through the following .def file syntax :-
EXPORTS ConstructorOfA1 = ??0A@@QAE@XZ PRIVATE ConstructorOfA2 = ??0A@@QAE@H@Z PRIVATE SetNumOfA = ?SetNum@A@@UAEXH@Z PRIVATE GetNumOfA = ?GetNum@A@@UAEHXZ PRIVATE DestructorOfA = ??1A@@UAE@XZ PRIVATE
Now the functions are exported through much more friendly names. Now here is the way by which these are called
typedef void (A::*PfnConstructorOfA1)(); typedef void (A::*PfnConstructorOfA2)(int); typedef void (A::*PfnDestructorOfA)(); typedef void (A::*PfnSetNumOfA)(int); typedef int (A::*PfnGetNumOfA)(); A* a1 = (A*)_alloca(sizeof(A)); PfnConstructorOfA1 pfnConsA = force_cast<PfnConstructorOfA1>(GetProcAddress(hMod, TEXT("ConstructorOfA1"))); (a1->*pfnConsA)(); PfnSetNumOfA pfnSetNumA = force_cast<PfnSetNumOfA>(GetProcAddress(hMod, TEXT("SetNumOfA"))); (a1->*pfnSetNumA)(1); PfnGetNumOfA pfnGetNumA = force_cast<PfnGetNumOfA>(GetProcAddress(hMod, TEXT("GetNumOfA"))); _tprintf(TEXT("Value of m_nNum in a is %d/n"),(a1->*pfnGetNumA)()); PfnDestructorOfA pfnDestA = force_cast<PfnDestructorOfA>(GetProcAddress(hMod, TEXT("DestructorOfA"))); (a1->*pfnDestA)();
An interesting things to note here is that constructors and destructors are both being called explicitly. This is perhaps only way by which class constructors could be invoked explicitly. The other point to observe is that the object has been allocated memory over the stack through function alloca (if want to allocate memory on heap you need to use malloc), this is because allocating memory through new or by just decalaring an object of type A the constructor of A is automatically called. We don't want't this because the constructor of A is implemented in the Dll and we have not implicitly linked to the dll. You need not explicitly call the constructor and destructor instead you could implement the constructor in you exe file as :-
A::A() { static PfnConstructorOfA1 pfnConsA1 = force_cast<PfnConstructorOfA1> (GetProcAddress(ClassLoader<A>::s_hMod, TEXT("ConstructorOfA1"))); (this->*pfnConsA1)(); } A::~A() { static PfnDestructorOfA pfnDestA = force_cast<PfnDestructorOfA> (GetProcAddress(ClassLoader<A>::s_hMod, TEXT("ConstructorOfA1"))); (this->*pfnDestA)(); }
The above two implementations just delegate to the actual function in the dll at the same time allow you two declare and use an object of A in normal fashion. I will cover a better form of delegation in the next article. An important point to mention here is that you need not implement the functions SetNum, GetNum etc. if you only call them through pointers. The sample attached explains all the methods.