Jump to content

  • Log In with Google      Sign In   
  • Create Account


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.

  • You cannot reply to this topic
13 replies to this topic

#1 Nazzrim   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?

2. On different sources I read about "static linking" & "dynamic linking" but I am not completely sure about it's meanings:

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. ;):
- Is my knowledge about DLL linking correct?
- 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.


Sponsor:

#2 Radikalizm   Crossbones+   -  Reputation: 2772

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.

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.

#3 kloffy   Members   -  Reputation: 865

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.


#4 Nazzrim   Members   -  Reputation: 136

Like
0Likes
Like

Posted 29 May 2012 - 05:46 AM

@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?

@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.


#5 Bacterius   Crossbones+   -  Reputation: 8158

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.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#6 Radikalizm   Crossbones+   -  Reputation: 2772

Like
2Likes
Like

Posted 29 May 2012 - 06:20 AM

@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.

#7 Nazzrim   Members   -  Reputation: 136

Like
0Likes
Like

Posted 29 May 2012 - 08:26 AM

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

#8 szecs   Members   -  Reputation: 2095

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.

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....

Edited by szecs, 29 May 2012 - 09:27 AM.


#9 Radikalizm   Crossbones+   -  Reputation: 2772

Like
0Likes
Like

Posted 29 May 2012 - 09:33 AM

@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 :)

#10 DvDmanDT   Members   -  Reputation: 768

Like
0Likes
Like

Posted 29 May 2012 - 11:49 AM

About the two linker flags in sdl.

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.

#11 Nazzrim   Members   -  Reputation: 136

Like
0Likes
Like

Posted 29 May 2012 - 04:51 PM


@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 Posted Image


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.

#12 DvDmanDT   Members   -  Reputation: 768

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

#13 Nazzrim   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.


#14 DvDmanDT   Members   -  Reputation: 768

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