Thread: How would you link a program to a DLL?

What is this process called? Linking a program to a DLL for more source code? Where would I learn this? Can anyone explain a bit? Thanks.

Nice name.

A DLL is a Windows-specific dynamically-loaded library. Basically, you compile your program with some statically-linked library (say, libSDL.a or SDL.lib), and then when you run your program, it looks for say SDL.dll and loads that into memory. This means several things:

• If the library is already loaded into memory, it does not have to be loaded again. This is great for really common libraries.
• If the DLL version is not what your program is expecting, you might have trouble.
• And of course, anyone who runs your program must have the DLL.

Anyway, with that out of the way . . . when you create a DLL, you basically combine a bunch of .o (or .obj) files. When you compile a .c or .cpp file, that is what you get. A DLL is just ordinary C or C++ code written in such a way that the code does not have a main(); rather, it has functions and classes that can be used in another program.

[edit] At least, that's what I think . . . I've never really used DLLs, being a Linux person. For more information, you might try google: http://www.google.ca/search?hl=en&q=...e+Search&meta= [/edit]

Linking a DLL usually requires 3 things:
1) The DLL file itself.
2) A .lib file to link with, specific to the DLL. Generated when creating the DLL file.
3) A header with the prototypes of the functions exported by the DLL.

What you do is include the header file, the add the .lib file under "additional libraries" or such under your linker so it searches the lib file.
Then you can call all those functions in the dll as if they were in your own program. This process is called static linking.

There is another way called dynamic linking.
In this one, you don't need a .lib file, nor a header really, but you still need to know what functions are exported and how to call them correctly, so a header is a good thing nevertheless.
Anyway, you first load the dll using LoadLibrary.
You then find the function you want to call using GetProcAddress, whose return you should cast to a function pointer. Then you can call that function pointer to call the function of choice. Then you close the library using FreeLibrary.

Static linking requires the DLL to be present with your application, otherwise Windows will complain "X.dll couldn't be found. Try reinstalling the application." Your program will never even begin to run.

Dynamic linking has the advantage that you can check if the dll exists and print errors or whatever, but your program can run without the dll.

Code:

// Let's find the function "foo", whose prototype is "void foo(int n)".
typedef void (FooFncPtr)(int);
HMODULE hDll = LoadLibrary("my dll.dll");
FooFncPtr* pFoo = (FooFncPtr*)GetProcAddress(hDll, "foo");
pFoo();
pFoo = NULL;
FreeLibrary(hDll);

This is dynamic.
All of these functions are located somewhere in the nest of Windows.h. And you would like to have a header to the dll that shows the exported functions from the dll and the prototypes of them.

Originally Posted by bithub

There is no such thing as statically linking to a DLL. DLL stands for Dynamic Link Library, therefore all DLL linking is dynamic. You are getting static linking mixed up with implicit linking.

Yeah, it's called implicit linking. My bad.
Thanks for the correction.

No such thing as static linking as bithub mentioned. It's called implicit linking. It was my bad >_<

Oh I see bithub just called it explicit. However, according to MSDN, it's called implicit linking.
But even so, the name doesn't really mean that much. It's the first method I mentioned, using a .lib file.