Public Group

# Proper DLL use

This topic is 2243 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hey everyone.
I am learning SDL for some month now, which dramatically increased my C++ skills.

But I have some questions about the use/general function of DLL files:

1. My interpretation of DLL file is a collection of functions and classes (not necessarily C/C++) provided for other programs. Is this right?

If I use #include <SDL/SDL.h> the header file for SDL.dll is directly included into my project when compiled. I hope till this point I am not wrong...
This way the DLL is linked static because the specific header for this DLL version was included, isn't is?
So you can't exchange the DLL version because of eventually lacks of compatibility?

And if I want to link a DLL dynamic I include <windows.h>. I have a bunch of typedefs for the used functions like:
 typedef int (*SDL_Init_i) (Uint32); 

And then I have to get the address of the called function at runtime with some code like this:
 SDL_Init_i iSDL_init; HINSTANCE hSDL = LoadLibrary("SDL.dll"); if (hSDL) { iSDL_init = (SDL_Init_i) GetProcAddress(hSDL, "SDL_init"); if ( !iSDL_init) { return 1; } } else { return 1; } 

After that I hopefully can use the function probably this way for example:
 if (iSDL_Init (SDL_INIT_VIDEO | SDL_INIT_TIMER) == -1) { log->log("SDL init error..."); return false; } 

At the end of my programm I have to free my program with FreeLibrary(hSDL);.

This way I have the possibility of changing the SDL.dll for example with a newer version, haven't I?

So now the actual questions for 2. ;):
- If it is: Isn't there a cross platform solution for dynamic linking or: how would this be done in a Linux environment?
- I have chosen the example above because it shows an other problem: If I link a DLL dynamic, how can I use special flags or classes out of this DLL (like SDL_INIT_VIDEO or SDL_Rect as class)?

3. If I am compiling I always use the following flags: -lSDL -lSDLmain. I know they are used for the Linker and they tell what to use but why are there two for one DLL? If I also use SDL_image.DLL I have to add -lSDL_image. So exactly: What is the -lSDLmain flag for?

3.a. Is there a difference in linking static/dynamic and the use of flags? Because I "hardcode" the DLL filepath when linking dynamic, so there is no need of extra compiler flags?

4. Why are there Runtime Libraries & Development Libraries? Just a missing documentation or what is the difference?

5. Inside the lib folder of SDL there are .a files. What are they used for? I read some tutorials about DLL's and the .a files are a product of creating DLL's (surprise...). Are they part of dynamic/static links or are they needed always?

EDIT:
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?

I hopefully didn't scare you with my bad English skills and/or my newbie problems;).

I am thankful for every help.

Nazrim Edited by Nazzrim

##### Share on other sites
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.

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.

##### Share on other sites
If you want to load libraries at run-time, here's some additional information: Good patterns for a C/C++ plugin-based system?.

Note: You don't need to do that if you just want to link SDL. Edited by kloffy

##### Share on other sites
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?

@kloffy
Thank you I will read it as soon as possible:).
I think I didn't/don't(;-)) understand the meaning of a DLL, because SDL is released with LGPL and it only allows other licences if dynamic linked, so I wanted to learn more about it, poorly the only thing I knew at this point was: "everything comes out of this DLL Oo". So I thought this could be the right way.. But it seems to me that every DLL use is dynamic Oo. Great misunderstanding. Edited by Nazzrim

##### Share on other sites
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. Edited by Bacterius

##### Share on other sites

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.

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.

##### Share on other sites
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" ;-).

##### Share on other sites
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.

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.... Edited by szecs

##### Share on other sites

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

##### Share on other sites

There's one DLL and one static library (ie, the content gets merged into your exe). SDLmain is a static library containing a wrapper main() function doing some additional initializations or whatever before calling your main(). I'm not entirely sure what it does, but I think it's a way to get rid of the console in Windows while being source compatible with all other platforms.

I think there's a single .c file (sdlmain.c) you can add to your project instead of that -lsdlmain flag.

1. 1
2. 2
Rutin
25
3. 3
4. 4
JoeJ
18
5. 5
gaxio
11

• 14
• 22
• 11
• 11
• 9
• ### Forum Statistics

• Total Topics
631765
• Total Posts
3002213
×