I think I''m starting to get the hang of libs and dlls, but I also get the impression that a lot of my "knowledge" may be a bit too based on hearsay and conjecture. Anyone care to compare and contrast the two for me? I get the impression that libs are only to be used at compile time, whereas dlls are, as the name implies, dynamically linked. If that''s all there is between them, why would we ever need both? Basically, I''d appreciate any information on the differences between the two I could get. I have a few answers, but I''m just not confident they''re right. Thanks in advance! -Arek the Absolute

From what I understand(which means I could be wrong) libs let the compiler know how to access a dll. Think of it like showing where functions are and how they are used. libs are only used at compile time. They basically show the compiler how to make the comipled exe interact with the dll. Because dlls are just binary files, the compiler doesn''t really know anything about them, or how they work. The lib lets the compiler know that stuff

That can''t be... I just made a quick test for libs that went like this:

in a static library project, I had a function like this:
void Hey(){
cout << "Hey!" << endl;
}

and I compiled it into a lib, which I then used in another project.
I then called the Hey() function, and it worked fine. There''s no dll involved, so... I dunno. I''m just as confused as I was before, I guess. Thanks, though.

-Arek the Absolute

libs are compiled with the program at comilation. with a dll you can call funtions within the dll at runtime, this means you can alter the contents of a dll (update it) without affecting the program providing the functions that are called are still there, also dlls can be shared between multiple programs.

I think a lib is used by a programmer, and once the EXE is compiled, it''s no longer needed by the end user who runs the program. But if an EXE uses a DLL, then the end user will need the DLL in order to run the EXE. However the good thing about DLLs is that they can be loaded from different sources at run time, making things like "plug-ins" possible, or another example would be a graphics engine with one DLL for OpenGL and another DLL for DirectX. The user can then decide at run time which DLL to load.

What Cold_Steel says is also right. you can set VC++ to generate a lib for a dll project. when you then want to use this dll, you link the lib. the lib then cares about loading the dll and getting the procAdresses, so you don''t have to worry about that.
this solution combines the convienience a lib with the easy updatabilty of a dll. so you don''t have to recompile or even change the exe, when you alter the functions in the dlls. of course, your function prototypes have to remain the same.

to sum it up:
libs are statically linked into the exe at compile time
dlls are dynamically linked at runtime

hope if made no mistake


Yesterday we still stood at the verge of the abyss,
today we''re a step onward!

Well, basically, you can have a lib that contains different information. You can compile the lib functions into you main program, or you can use them in a dll. For instance, you might use a lib like a header so that people can''t view your code. You can also use a lib to tell your program before it''s compiled how to access a dll. Once the program is compile, it will "know" how to access the dll so the lib is no longer need. The same way when you use the lib alone to compile into your program, the functions are built into the executable, so you no longer need the lib. However, if you had a dll, and a lib you wanted someone else to be able to use in his/her program, you would need to give him/her the lib, because without it, the program would not know anything at all about how to access the dll.

ex.

Let''s say I''ve dll that contains a function called ''output''. I compile the dll into a binary file. So now, that ''output'' function is no longer called ''output'', it is now basically just an address in memory for the program to jump to when the function is called.

Now, let''s say we have an exe program we are writing that calls ''output''.

output()

There is no way for our program to know where the heck in the dll that functions is, it''s just a binary, who knows what''s a function, what''s data...etc.

The lib knows. The lib will provide a mapping for you program to access the dll. Conceptually it might look like

output() -> 24FF:3EFA

It basically tells your program where the function is found in the dll, without it, all you''ve got is meaninless 1s and 0s

Once your program is compiled, it will be compiled with the information necessary to access the dll. ie the address of the function in the dll gets hard coded into the exe with the help of the lib. After that, the lib is no longer necessary.

As for using just a lib, that amounts to using a header, or additional cpp file. The functions that exist within the lib will be compiled and hard coded into the exe as well as the information on dlls.

Everyone is basically correct, but, remember, the main purpose of dlls is to reduce the size of the executable. If all programs were statically linked with the Win32 libraries, they''d be huge in memory and on disk.

but with hard drive sizes now I think it might be better just to use libs and have a self contained exe and do not have to worry about any installation procedure

and what about debugging? how does that work? I suppose to trace through the code of a DLL you need a source code or not? I remember MFC had a special debug DLL ?

If I find a 3d engine I would prefer to be able to have the option to trace through that as well as my source but I guess there are few 3d engines like that since most people would not want to share that.

And then there is .NET DLLs which are suppose to be bette rin some ways.. i forget

oh yeah.. you do not need to register them!

quote: Original post by angrytofu
but with hard drive sizes now I think it might be better just to use libs and have a self contained exe and do not have to worry about any installation procedure

true, but think of directX! you would need recompile your exe everytime a new version comes out that has features (faster, etc.) your program should benefit from. with dlls, you just have to install the new version and the program uses the new routines automatically as it uses the directX dlls.
And if you eleminate dlls to the last and only use self contained exes, you wouldn''t even need an OS...


Yesterday we still stood at the verge of the abyss,
today we''re a step onward!