How to use a dll

Question

I recently was very confused in trying to use gdi+, since the sdk files where just three files, one of which being a .dll file. I assumed I need to load the dll and since I had never been taught or exposed to such things, needless to say I was bewildered. (it now seems that the installation also put gdi+ sdk files in the folder which VS looks for standard files (the things that are included via <>, and still leaves me clueless as to what the dll is doing there).

I researched and got an explanation that seemed to suggest the following:

A .dll file is a file who's code is loaded into memory when it is executed, saving time by referencing the memory via pointers rather than copying the code as a standard lib load does. This also allows versatility for changing the dll without changing the executable file.

To use it, you must use loadlibrary, and then getprocaddress to basically get a pointer (or something, wasn't clear to me) to specific elements, such as a class or function, in the dll.

You see, I was under the impression that a library is basically code you are to reuse for things, the same concept, but a more efficient form of simply makes .cpp files of useful methods and classes and then including them.

From what I can tell, this assumption is incorrect and I would like someone who knows the inside and out of this .lib and .dll library thing to explain it if they please.

Please remember that my current understanding of the purpose of a dll or lib is to reuse code. Make a file with classes and methods and then just import it in to use it. I am extremely inexperienced with libraries in this sense.

Answer 1

A .dll and a .lib are as you said options to reuse code. A .dll is called dynamic library, because the library is loaded at runtime, while a .lib is a static library, loaded and put into your program at compile time. I'm aware of three options to use these libraries:

• You use the .dll directly, which means using LoadLibrary() to load the .dll into memory and then use GetProcAddress to get a function pointer (basically a memory address in a variable, but you can use it just like a function). The problem here: you need to know the mangled names of the functions (mangled = compiler generated unique names for function overloads and similar) and you need to know the function-arguments and return values.
• You use a static library (.lib). This means you include the header file of the library into your project, which tells your compiler the function names (without mangling), their parameters and return values, just as you would do it with functions defined in different .cpp files. But then the code of the library is copied into your program, which increases its size and if the library is updated, you have to recompile your program.
• Some SDKs include prebuilt (or easily built) static library files (.lib) which actually just contain stub code which then loads the .dll containing the actual code at the start of your program. This will give you the best of both possibilities, since you dont have to mess with name-mangling/function pointers at all while still loading the library at runtime. This also means you only have to recompile your program once the API (=header) of your library changes.
• The steps involved in the first example in this list can be handled by the host operating system: if your compiler is smart it can detect what external functions you're calling and declare them in an "Import Table" directly within your output executable file. When the OS loads your program it can link-up the import table for you - this does slow down program load time (potentially wasting time if certain functions are never called) - or causing the program to not load if a dependency file is not found on the hard disk (whereas if you use LoadLibrary you can fail gracefully), but it does significantly reduce the programmer's burden.
• There is also COM (or CORBA), which can be seen as an extension of the 1st example in this list; COM allows entire objects to be exposed and exported instead of just free functions. This is a powerful approach which enables things like re-usable user-interface widgets and database access code. The downside is that component container DLLs must conform with a defined Application Binary Interface and require lots of legwork and other files like IDL (Interface Definition Language).
  • Side-note: runtimes like Java and the CLR provide a COM-like way for components to declare the classes and components they contain and allow other programs to reference and use those objects at runtime without any compile-time linking. Microsoft Windows 8.0 (and later) generalize this approach to more executable binary types using the "Windows Runtime" where a simple metadata file (.winmd) essentially serves as a kind-of "export list". It can be considered a kind of "COM on Steroids" or "COM for the 21st Century" if you're feeling mean.

Answer 2

To use a DLL, you:

1. #include the header file when you compile.
2. include the .lib file (the 'implib') in the link process, so that the linker knows that the symbols are coming at runtime from the dll.
3. Arrange for the .dll file to be present in a directory included in the PATH environment variable.

Note that in some versions of Windows, this process is complicated by SxS considerations, and you will need a manifest. You can look up SxS and the related issues for yourself.