Contents

Introduction
LoadTime Linking
RunTime Linking

Printable version

LoadTime Linking

In loadtime linking the OS automatically loads the DLL for you when the program is starting up. However this requires that the client code be linked to the .lib file (library file) provided with the DLL during compilation. The .lib file defines all the items that the DLL exports. These may include normal C-style functions, or even classes. All the client code needs to do is link to the .lib file and include the header provided by the DLL and the OS will automatically load everything for you. As you can see, this method seems very easy to use, since everything is transparent. However it introduces dependencies so that the client code will have to be recompiled each time the DLL code changes and generates a new .lib file. This may or may not be a concern for your project. The DLL can define functions it wants to export using two methods. The standard way is to use .def files. The .def file of a DLL is simply a listing of the names of functions it wants to export.


//============================================================
//Dlls .def file

LIBRARY       myfirstdll.dll
DESCRIPTION  'My first DLL'
EXPORTS
              MyFunction


//============================================================
//Dlls header file which would also be included in client code

bool MyFunction(int parms);


//============================================================
//Dlls implementation of the function

bool MyFunction(int parms)
{
   //do stuff
   ............
}

It goes without saying that there can only be one MyFunction in the global namespace of your DLL. The second way is Microsoft specific, but is more powerful as you can not only export function, but also Classes and variables. Lets take a look at some code which generated by creating a DLL using the VisualC++ AppWizard. The comments generated are quite enough to explain how this works


//============================================================
//Dlls header file which would also be included in client code


/*
The following ifdef block is the standard way of creating macros which make exporting 
from a DLL simpler. All files within this DLL are compiled with the MYFIRSTDLL_EXPORTS
symbol defined on the command line. this symbol should not be defined on any project
that uses this DLL. This way any other project whose source files include this file see 
MYFIRSTDLL_API functions as being imported from a DLL, where as this DLL sees symbols
defined with this macro as being exported.
*/

#ifdef MYFIRSTDLL_EXPORTS
#define MYFIRSTDLL_API __declspec(dllexport)
#else
#define MYFIRSTDLL_API __declspec(dllimport)
#endif

// This class is exported from the test2.dll
class MYFIRSTDLL_API CMyFirstDll {
public:
   CMyFirstDll(void);
   // TODO: add your methods here.
};

extern MYFIRSTDLL_API int nMyFirstDll;

MYFIRSTDLL_API int fnMyFunction(void);

When you compile the DLL the MYFIRSTDLL_EXPORTS symbol is defined, and the __declspec(dllexport) keyword is prefixed to classes/variables or functions you want to be exported. And when the client code is being compiled the symbol is undefined and __declspec(dllimport) is prefixed to the items being imported from the DLL so that the client code knows where to look for them.

In both the methods outlined above, all the client code needs to do is to link to the myfirstdll.lib file during compilation and include the given header file which defines the functions and/or classes, variables being exported and it can use the items normally as if they had been declared locally. Now lets take a look at the other method of using DLLs, which I personally believe is more openended.

Next : RunTime Linking