Creating and Using DLLs with Visual C++ 6.0

Contents

1. Adding a new project
2. Adding files to the project
3. Exporting Functions
4. Building the DLL
5. Testing the DLL
6. Peeking Inside the DLL

Getting Started

Add New Project

Adding Files to the Project

Exporting Functions

Building the DLL

Testing the Dynamic Link Library in a Project

1. Create a Win32 Console Application and call it TestDLL. Make sure to add it to the current workspace.
2. Create a new .c source file named main.c and add it to the TestDLL project.
3. Place the code shown below into main.c and save it. Unlike a static library, the client has to do more work to use a DLL, but the flexibility of linking at runtime can be well worth it.

   
   // We actually need to include this because DLLs are Windows-specific
   #include <windows.h>  // HINSTANCE, LoadLibrary(), GetProcAddress(), FreeLibrary()
   #include <stdio.h>    // printf()
   
   void main(void)
   {
     const char *DLLName = "CS220Utils";      // Filename of the DLL that contains the function we need
     const char *FnName = "IntToBin";         // The function we want to call
     const unsigned char *(*MyIntToBin)(int); // A pointer to a function that takes an int and returns
                                              //   a pointer to a character (just like IntToBin!)
     HINSTANCE dll;  // a pointer
   
       // Load the DLL
     dll = LoadLibrary(DLLName);
   
       // If return is NULL, Windows couldn't find the DLL for us
     if (dll == NULL)
     {
       printf("Unable to load %s.\n", DLLName);
       return;
     }
   
       // Find the IntToBin function in the DLL. Since GetProcAddress returns
       // a pointer to an int, we need to cast it to the type of function
       // pointer we expect.
       //
       // This is also why we need to list the function in the EXPORTS section
       // of the module definition file. Failing to do so would certainly cause
       // GetProcAddress to return NULL.
     MyIntToBin = (const unsigned char *(*)(int)) GetProcAddress(dll, FnName);
   
       // If return is NULL, Windows can't find the function in the DLL
     if (MyIntToBin == NULL)
     {
       printf("Can't find function in DLL. Did you remember to export it?\n");
       FreeLibrary(dll); // Unload the DLL
       return;
     }
   
     //**********************************************************************
     // At this point, the DLL is loaded and the function has been located
     //**********************************************************************
   
       // Call the function and print out the bits
     printf("%s\n", MyIntToBin(127));
   
       // Unload the DLL
     FreeLibrary(dll);
   }
   
   

4. Now, Build the program.
5. The program should compile and link without warnings or errors.
6. You should notice the client does not #include bits.h anywhere, yet we are able to compile our program. The reason for this is because nowhere are we calling the IntToBin function directly. We are indirectly getting a pointer to it, which we obtained by asking for it by name via the GetProcAddress function. Of course, if we aren't careful, the call to GetProcAddress might fail (return NULL) if we spelled the function wrong or loaded the wrong DLL. There are many things that can still go wrong (as you'll see now when we try to run the simple client).

   If we run the TestDLL console application, this is what is displayed:

   

   Apparently, the call to LoadLibrary failed:

     // Load the DLL
   dll = LoadLibrary(DLLName);
   
     // If return is NULL, Windows couldn't find the DLL for us
   if (dll == NULL)
   {
     printf("Unable to load %s.\n", DLLName);
     return;
   }
   

   The problem is that Windows can't find CS220Utils.DLL. When Windows searches for a DLL, it looks in specific directories on the computer. The first directory that it looks in is the directory where the executable that called LoadLibrary is running. In this case, the executable is TestDLL.exe, so Windows looks in:

   E:\Digipen\Courses\CS220\Code\DLLTutorial\TestDLL\Debug

   because that's where Visual Studio put TestDLL.exe when it created it. The second place Windows looks is in all of the directories that are specified in the PATH environment variable. A directory that is surely listed in the PATH variable is:

   C:\WINNT\System32

   which contains hundreds (or even thousands) of DLLs. I'm not going to get into the religious debate over where you should put your DLL, but it is almost always a Bad Idea (stemming from laziness, pure and simple) to put them into \System32. So, for this example, we are going to copy the DLL into the same directory where TestDLL.exe lives:

   

   Now when we run TestDLL.exe, we see what we expected to see the first time:

   

Peeking Inside the DLL

The tool that I'm going to show is a free tool from Peter Vones called PE Viewer. Windows executables are in a format known as PE, which stands for Portable Executable (although I don't know how portable they are.) Search MSDN for "portable executable format" for more information.

If you run PEViewer and open CS220Utils.dll, you'll see the following displayed:

By the way, this kind of tool is invaluable when trying to determine on which DLLs your program is dependent. MS Visual Studio has a tool for listing dependent DLLs called Dependency Walker (depends.exe). You will probably find it on the Start menu (in MS Visual Studio Tools) in Windows. Or, if you don't have MS VS installed on a comptuer, Peter Vones also has a similar tool called Dependency Viewer which comes with the PE Viewer when you download it.

If you forget to export functions from your DLL (via a .def file or other means), you will not have an exports section in your DLL. GetProcAddress can't find a function unless it has been exported.