You have a lot of things mixed up there

1. You have it somewhat right, but not entirely. A DLL is what we call a Dynamically Linked Library, which indeed contains program functionality. DLLs however are not the only type of linked library used, which gets me to your second question.

2. As you may or may not know, the general build process of a program is divided into 2 steps: the first step is the compilation step, the second is the linking step. The compilation step goes over each of you files which require compilation (like .cpp files for example), and compiles them down to object files. When a compiler finds an external dependency (say a function which is defined in an external .cpp file) it will not try to resolve this dependency itself, but it leaves this job up to the linker. The linker takes all the object files generated by your compiler and it links them together into your executable file. However, if you need some functionality someone else has written you'll need to link against a library. It is correct that there are both static and dynamic libraries. A static library will be linked in its entirety to the program you're building (the library actually becomes part of your program), and can be really ideal when working with smaller libraries. The downside of course being that if you're working with large libraries your program will get bloated quite fast. Dynamic libraries on the other hand are not linked at link-time - although they can somewhat be linked to using import libraries, but I'm going to leave that out of the discussion for now - but they can be loaded in at runtime. This results in no executable bloat for your program and gives your program a more modular layout, but it can also result in what most programmers like to call "dependency hell" where multiple versions of a single dynamic library are available for linking, which can end up in the wrong library being loaded in at runtime. As you mentioned the LoadLibrary and FreeLibrary calls can be used on Windows platforms to do dynamic linking at run-time, but to avoid any issues it might be easier to use import libraries for dynamic linking.
Cross-platform dynamic linking in general is not possible. I do not have that much experience with dynamic linking in linux or any other unix-variants, but instead of DLL files they use Shared Object (.so) files.

The #include directive has almost nothing to do with linking, and doing an include of a file into a source file does not mean you're linking to the library that file is associated with.


3. Having never actually used SDL I can't answer this one.

4. One version of the libraries contains data which could be used for debugging, the other doesn't, it's as simple as that

5. If I remember correctly the .a files can be static libraries/import libraries (see 2)

6. I've never done any real research on this, but I do not think it matters quite that much. I would advise you to look into import libraries though so you don't have to manually load in your dynamic libraries. To be honest with you, the only time I've ever actually used LoadLibrary to do dynamic linking was for a plugin framework where plugin functionality was defined in DLL files.

6. If I link dynamic: Is it better to include all needed DLL-functions/classes/etc. at once at the beginning, or should I load the DLL every time a function is needed?
I am not sure because I don't know how fast DLL's are. Maybe they are a bottleneck, I don't know;). Or it would consume too much memory to save all function-addresses the whole Runtime?[/quote]
Linking dynamically allows you to fallback on a different option if the DLL doesn't exist, or is an older version and is missing some function, etc... if you statically link, you cannot fallback - your application will just die showing the familiar message "This application has failed to start because foo.dll was not found. Reinstalling the application may fix this problem". This may or may not be a concern for your particular application, but it's nice to keep that in mind.

The advantage of using a DLL is that you can change program functionality without having to recompile the entire codebase - you only recompile the DLL with the new code added, and swap it in (kind of like a plugin), as long as your main program knows how to use the DLL (with particular functions, etc...). There are other advantages (such as being able to reuse code in other applications without recompiling - for instance Win32 DLL's allow you to use the Windows API without having to recompile the whole API everytime you want to create a winform), and some disadvantages, but that's the gist of it.

@Radikalizm
Wow, thank you very much. That helps alot :-).
So is it right, that DLL's are designed for dynamic linking, and every use of them is a dynamic link?
I'm not sure if I got it:
I will definitly read about import libraries, but what is the benefit against using #include <...>? Is is, that it would include the whole library instead of only the necessary things?

The #include directive is used in the compilation step, not in the linker step, so try to keep these concepts separated. Including header files has absolutely nothing to do with linking to libraries.

Doing an include on a header file (.h file) tells the compiler to actually insert the contents of that file into the file you're trying to compile (the .cpp file). These header files mostly contain class or function definitions of classes and functions implemented in other compilable files. After the contents of your header file are copied over to your cpp file for compilation the compiler will see these functions defined without an implementation and it will assume that their implementations reside somewhere else in your program, or in an external library. This creates a dependency for the linker to resolve in the second build step. If the implementations of those functions you defined cannot be found in the rest of your program or in any of the libraries you provided for linking against the linker will throw one of those infamous linker errors.

If you want to experiment with your compiler and linker you could easily set up a small project with a couple of cpp files and some random functions. You could first of all try creating header files for all your cpp files where you define your function definitions and let it compile. After that you could try to remove the header files and write function definitions in the actual cpp files which require said functions. You'll notice that this will work exactly the same as doing an include. I don't recommend getting rid of header files of course, but it's a good way to get to know the build process and the tools involved in it somewhat.

Um, I think you are still not quite right. I'm not sure though.
I don't think you can get away with #including and linking libraries, or you are in to some programming hell.

There is (are) the include file(s). You need to include this (these) to be able to use the stuff in the library, which you also need to link. The things in the library that you linked and compiled to the .exe are making the dynamic linking of the .dll files at runtime.

Am I right about this? I'm not sure.

I'm not sure how linking works either, I always thought that only the actually referenced functions (and of course the hidden, internal states, global variables) are compiled into the executable. Then the exe does the dynamic linking (the parts of the exe that were complied from the libraries which require the include files as the interfaces).

But maybe every defined (or declared? I always confuse these terms) function in the include file gets compiled? MAybe, because some libraries (DevIL for example) says you have to alter some directives to control which parts to compile.

rzzzzz. Did I get it right?

So briefly: the included and linked library does the "access on classes/flags used inside a DLL". I guess there are ways to hook into a DLL without this. Well, good luck with it....

@Radikalizm
I think I got it now ;-). If I link dynamic there is no need of a Link-flag, because everything gets resolved at runtime. But if I don't want to link dynamic I have to tell the Linker where to look.

If I seperate the #include from the rest in my mind, there is no need of an include statement if I use dynamic link, because then I would be forced to include everything out of the header file.
But how can I get access on classes/flags used inside a DLL.
And not special for SDL: Why can there be more than one linker-flag for one DLL? Can a DLL contain different separated libraries?
Hopefully the last two are not SDL specific and more like "problems of general DLL usage" ;-).

You're still confusing your concepts; as I said, the include statement has absolutely nothing to with linking, so there's no association to be made between static/dynamic linking and including header files.
I think you should maybe pick up a book on programming in C++ to get your concepts straight, a forum isn't exactly the right place to learn all these elementary things