What MSDN says about DLLs. Be sure to follow the links on that page they tell you all about DLLs and how to use them.

The acronym DLL comes from "Dynamic Link Library". As it implies, they're just libraries that contain code. Their difference from static libraries is that when you link to static libraries, the code of the library is "embedded" in your exe. For example, consider the following modules:

Your project: MyProgram
Static Library: StaticLib.lib

Linking them will produce a single monolithic MyProgram.exe that contains all the code. If you want to change the implementation of a function that is contained in StaticLib, you need to build the new StaticLib, then relink those two. Now, consider the following:

Your project: MyProgram
Dynamic Library: DynamicLib.lib

This time DynamicLib.lib doesn't contain any code, it's just a stub that contains information about where MyProgram.exe needs to look for functions. The actual code is contained in a DLL named 'DynamicLib.dll' which must be visible to the .exe. So, if you need to change the implementation of function contained in DynamicLib.dll, you don't need to touch MyProgram, since the code is not contained there. You just rebuild the DLL, substitute the old with the new version, and changes take place automatically.

Notice that you can even skip using DynamicLib.lib and use LoadLibrary() and GetProcAddress() to link to the functions. This is called run-time dynamic linking(the DLL is loaded and the symbols are resolved by the program itself during its execution) in contrast to load-time dynamic linking(the DLL is loaded and the symbols are resolved by the OS when it loads the program before executing it).

First of all, DLLs are not EXEs and though they may be binary files you can’t view them like text files (if that is what you mean). You can’t run them either, like exe files. They are in fact libraries, and like mikeman says, they are they're just binary entities that contain code (if that is any easier to understand).

Ok let me give you an example, imagine you have written a generic function called fatorial(int a); and you intend to use this function in 100s of places in 10 different programs. That’s is not that hard to imagine now, is it. Most of us programmers write code that is reused over and over. Now imagine your function takes 10000 bytes of code for every instance it is used (I know factorial() does not take that much, but just imagine it does :)) ). So it will be 10000x100x10 bytes of code for all 10 programs. Wouldn’t it be cool to just compile it away in a binary module and use the binary form all the time (instead of 10000..... bytes of code). That is what the DLL is. Since the code is already compiled into a binary, you do not need to compile it again.

Ok it is a very simplistic idea of what a DLL is, as mikeman and others have said, there are many more things like dynamic loading that you must understand.

I suggest that you do a basic program on DLLs first so that you get a grasp of the concept. DLLs are a very powerful concept which can be used very effectively to modularize your application.

Also, one thing that is slightly different between static libraries and dlls is that dll can *optionally* contain an entry function DllMain that is something similar to WinMain for .exes and that is called upon certain events, like when the DLL is attached or detatched from a process, or when the current process is creating or exiting a thread. If you need to perform certain initializations and cleanups, with static libs the user should have to explicitly call InitLibStuff() before using library functions and CleanLibStuff() before terminating the program. With Dlls, you can handle those in DllMain without the user being aware of it.