• Create Account

Banner advertising on our site currently available from just \$5!

Proper DLL use

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

13 replies to this topic

#1Nazzrim  Members   -  Reputation: 136

Like
0Likes
Like

Posted 29 May 2012 - 04:46 AM

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;
if (hSDL)
{

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, 29 May 2012 - 04:51 AM.

Like
2Likes
Like

Posted 29 May 2012 - 05:18 AM

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.

I gets all your texture budgets!

#3kloffy  Members   -  Reputation: 951

Like
0Likes
Like

Posted 29 May 2012 - 05:42 AM

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, 29 May 2012 - 05:44 AM.

#4Nazzrim  Members   -  Reputation: 136

Like
0Likes
Like

Posted 29 May 2012 - 05:46 AM

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, 29 May 2012 - 05:52 AM.

#5Bacterius  Crossbones+   -  Reputation: 11356

Like
0Likes
Like

Posted 29 May 2012 - 05:48 AM

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?

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, 29 May 2012 - 05:52 AM.

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”

Like
2Likes
Like

Posted 29 May 2012 - 06:20 AM

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.

I gets all your texture budgets!

#7Nazzrim  Members   -  Reputation: 136

Like
0Likes
Like

Posted 29 May 2012 - 08:26 AM

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" ;-).

#8szecs  Members   -  Reputation: 2379

Like
0Likes
Like

Posted 29 May 2012 - 09:19 AM

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, 29 May 2012 - 09:27 AM.

Like
0Likes
Like

Posted 29 May 2012 - 09:33 AM

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

I gets all your texture budgets!

#10DvDmanDT  GDNet+   -  Reputation: 1300

Like
0Likes
Like

Posted 29 May 2012 - 11:49 AM

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.

#11Nazzrim  Members   -  Reputation: 136

Like
0Likes
Like

Posted 29 May 2012 - 04:51 PM

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

Maybe I didn't point out my thoughts clearly: If I use the include statement, the whole content of the header file is included into my executable and because there is no implementation of the functions the Linker will look at the locations I tell it.
I think I nearly understood the concept of include statement / dynamic/static link (will do some practice on that) but maybe I am not able to find the right words...

My actual problem is that I don't know how to handle this information in C++, or: How does a static/dynamic link look in C++?
Until know I thougt thats its static if I use Link-Flags and if not its dynamic.

And yes you are right, I thougt my problem is a lot smaller, but I think I should consider some lecture.
But thank you very much:-).

@DvDmanDT: Thank you. Hopefully got it.

#12DvDmanDT  GDNet+   -  Reputation: 1300

Like
0Likes
Like

Posted 29 May 2012 - 05:54 PM

When you compile something in C/C++, you compile one source file (ie .c, .cpp or .cxx) at a time. Now, obviously each source file cannot contain all functions/classes/whatever, so you use a .h/.hpp/.hxx file to say "this function/class/whatever is available, but it's content is defined elsewhere". It does not specify where, just that it exists. The compiler therefore inserts stuff like "Insert call to FUNC here" in the .obj file which contains the program code from it's respective .c/.cpp/.cxx file.

Then you invoke the linker to combine all .obj and .lib/.a files into an .exe (or a .dll/.so, or even another .lib/.a). There are two types of libraries (.lib/.a), import libraries and static libraries. The static libraries contains the actual definitions of it's functions/classes/whatever, while import libraries just says "the contents of my stuff reside in whatever.dll or whatever.so". Both static and import libraries are .lib or .a files, included with the same linker flags (ie -lSDL) and the only way to know if it's a static library or an import library is to look in the documentation of that library (or use tools to examine them or whatever).

#13Nazzrim  Members   -  Reputation: 136

Like
0Likes
Like

Posted 30 May 2012 - 01:22 AM

DvDmanDT:
Okay, does that mean that the way a library is linked is determined only by the library and not by the way I actual code it? If it does I got it :>.
I didn't know that a library "sets itself" to static/dynamic. Maybe I should get information about DLL's in general.

With this, kept in mind the following sentence I found on SDL site makes sense to me, because now I know that this resulting the dll being a dynamic one.
And if I want to know if a library is dynamic or static I have to examine the library itself.
Helped me a lot. Thank you

Can I use SDL in a commercial application?

Yes! If you link dynamically (via .dll's, .so's or using other dynamic linking devices) then you do not need to to anything. If you link statically (include the SDL source inside your project when you compile) you have to provide some way for your customer to relink your application a custom version of SDL.

Edited by Nazzrim, 30 May 2012 - 01:22 AM.

#14DvDmanDT  GDNet+   -  Reputation: 1300

Like
1Likes
Like

Posted 30 May 2012 - 01:38 AM

If I understand your question, then yes. It's determined by the library, not how you use it in your code or what flag you pass when you link against the library.

When you create a library, you select whether you want to create a static library or a dynamic library (I think that's the terminology used in VS). If you choose to create a dynamic library, then both a .dll and a .lib file will be created, if you choose to create a static library you'll only get a .lib.

A static library is often quite large (hundreds to thousands of kbs) while an import library (the .lib file which just includes references to its .dll) is isually in the 5-20 kb range.

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

PARTNERS