DLL Conventions: Issues and Solutions, Part I - A simple problem
(Page 2 of 4 )
Before we move on I'll explain a generic problem that you might have experienced first hand in your career as a developer, but dismissed because someone did that for you, or you took an entirely different approach to solve that problem.
Say you just downloaded the PDFLib PDF library and purchased the license to it. Prior to your purchase, you tried the sample applications and they all just compiled happily. Now when the development started, you realized that you'll be developing the applications that use the library in Borland C++ Builder 6.0 rather than Visual C++ 6.0, in which all the samples were written and compiled. If you've been through such a situation you can surely appreciate the description of the problem above.
Let's now analyze and find the cause and solution to the problem. If you're reading this just to gain some knowledge, then you'll surely find the basic terminology discussion beneficial.
Some Terms to Know A Dynamic Link Library (DLL) is a file that contains C Style functions or whole C++ classes that you can use for developing your applications to lessen your development effort and to save time when testing problems in a normal SDLC.
Any function that is visible outside the DLL and is intended for use by external client applications is said to be an export from the DLL. Consequently any client using this function from the DLL is said to have an import from the DLL. Sometimes we call all exported C Style functions and Classes to be exported symbols as a collection.
An import library is a file with a .lib extension and provides the compiler with enough information to resolve function call references if you choose to link implicitly at compile time. You may choose to load the DLL at runtime (using LoadLibrary API) and resolve and call functions then, by locating them in the DLL (using GetProcAddress API).
The import library is the key element if you're linking implicitly, and in most cases this poses a greater problem, as we'll see shortly. Also required is the header file and the DLL you're trying to use.
So now let's recap all we've discussed until now and then we shall move to analysis of the problem. While using third party DLLs in an environment which poses certain problems in the usage, we start with three elements (please note that we're stretching only to implicit linking, and that too with DLLs exporting C style functions, and explicit linking is not in the scope of our discussion right now. But we shall discuss it in the next article of this series):
- The DLL built with any tool and exporting C Style functions only.
- A header file that provides prototypes to all the functions exported by the DLL.
- The import library that is emitted by the compiler when the DLL is built.
With these three ingredients we can have all the functions and classes at our disposal and use them freely in our code. We shall have real life problems so that we can see it all happen; so we'll be using a DLL built with Microsoft Visual C++ 6.0 in Borland C++ Builder 6.0. This case will be similar to the problem mentioned above (the PDFLib case).
Next: Where is the actual problem? >>
More C++ Articles
More By Digvijay Chauhan
