A dynamic-link library (DLL) is a library of functions, data, and resources whose references are resolved at run time rather than at compile time. The string class is frequently used in programming, but at this point the promissed standard string class is not available. It would be nice if had such a standard class based on the simple char* type that you could use in projects compiled using different compilers. The solution is to create a DLL. It can be added to projects created in any windows compiler. Since this code is already compiled, it is independent of the compiler that is using it.
Applications that use code from static-linked libraries attach copies of that code at link time. Applications that use code from DLLs share that code with all other applications using the DLL, therefore reducing application size. For example, you might want to define complex windowing behavior, shared by a group of your applications.
If you have a class, like a generic string class, you feel will be useful in more than one problem. You can create a DLL by selecting the DLL icon in the new dialog.
You will notice that one cpp file with the same name as your project is created. This file has one function, DllEntryPoint, which is the standard windows function needed in a dll. Note the comments at the top of the file. DLLs have no memory allocated to them, so in case your class uses the Borland String class, you have to add a memory manager to your project. In this project, you will create your own generic string class that uses the primitive c++ memory manager and thus can be used in programs created with any c++ compiler.
You may now add your string cpp file (or any other class cpp file) to this project. The header has to be altered to make sure that the class is exposed to the windows linker (runtime linker). Classes that are exported from a dll must have the declaration class _export. Similarly when a class in a dll is used by an application, the header must declare the class as class _import. This can be accomplished without the need to change the header if you use the following boiler plate code. Notice that class has been replaced by HELLO_CLASS which is defined at various times as class, class _export or class _import.
//dll switches
#if defined(HELLO_TESTDLL)
#define HELLO_CLASS class
#elif defined (HELLO_BUILDDLL)
#define HELLO_CLASS class _export
#else
#define HELLO_CLASS class _import
#endif
HELLO_CLASS Hello
{
public:
Hello(const char* s);
void sayIt(char*)const;
private:
char* _sayWhat;
};
The cpp file corresponding to this program starts with the following include statement:
#ifndef HELLO_H #define HELLO_BUILDDLL #include "hello.h" #endif
The fact that HELLO_BUILDDLL is defined before the header is read results in the class declaration to be class _export which is what you want in this case. Notice that for different classes, you will use different names for the class substitute. For example if you were building a string class, you could replace HELLO_CLASS with STRING_CLASS and in all of the other identifiers with HELLO, replace HELLO with STRING.
After you compile your dll project, you will notice that you get two files one dll file and one lib file. The lib file is added to projects that use your dll, while the dll file must be distributed with your exe since it is linked at runtime. A quick glance at the dll file will confirm that you have exported your class. If all is done correctly, you my use QuickView to view your dll and you should see that your classes functions are listed in the export table. If they are not there, you have failed to define HELLO_BUILDDLL (or whatever you called your BUILDDLL identifier).
| |
|
When you want to use your dll in a project, first make a copy of the dll, lib and h files from your dll project. In this case, DLLTest.dll, DLLTest.lib and hello.h. Place them in the same directory as your new project and add the lib file to the project. Do not add either of the other files to your project. Include the h file in any file that uses a member of the Hello class. Your project will now compile as if the cpp file were in the project.
When you distribute a program that uses a dll, you must make sure the dll is installed either in the directory with the exe file or in the Windows (or Winnt) System (or System32) directory. You will want to use an install program such as Install Shield to distribute you program to make sure all dlls are in the correct folders. Remember the actual linking occurs at run time. This means which ever version of the dll is available for a given run of the program is the version that the program uses. Updating is simple since you need only send a new dll whenever you update and the program will use the new dll without recompiling. The down side of this is that if you place your dll in the Windows subdirectory, it may be destroyed by another program's installation. My feeling is that all dlls other than system dlls should be placed in the directory with the exe file that uses them.
You can get a complete copy of the project that created the hello dll and a project that uses it by clicking here .