Sign in to follow this  

Difference B/W Library and DLL

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

If i can remember correctly, a .dll is a peice of compiled code that can be used many times by many different programs. A dll file is outside of the .exe, so it can be used by more than one. A .lib is the opposite, a compiled code inside the .exe. It isnt portable, and cant be used by anything but that .exe.

With .dlls your .exe is smaller but the .dll must be in the windows/system32 directory or in the same directory as the .exe (more common). With .lib your .exe is bigger but doesnt need any extra dependencies.

Thats what i remember, may be wrong.

Share this post


Link to post
Share on other sites
DLL's are Dynamically Linked libraries. However libs are not neccesarily static. A lib file can be used to link a dynamic dll (as is the case with most APIs these days). However a lib file can also contain all the executable code, this is less common but still possible.

If you create and use a static lib the code is linked and then "compiled" (for lack of a better word) into the final executable. This means there is nothing extra that you have to distribute.

When using a lib that merely links a DLL only the linking information is compiled into the EXE. And you'll need to distribute the DLL (If its something the user doesn't have already).

One final note here is that is possible to use a DLL without using a LIB to link to it. Check out MSDN for how to do that on windows if your intrested.

Share this post


Link to post
Share on other sites
Hi,

(In the following post, you may change .lib to .a, .obj to .o, .dll to .so. This should not change the philosophy behind this).

To superseed what other said (which is correct), the compiled code which is in DLL is loaded at run time while the code which is in a static library is (as the name implied) statically linked with the exe code - meaning that the code of the exe and the code of the library are located in the same file.

A little explaination of how a linker works is not too bad here.

When you compile a C++ file (replace C++ with whatever language here), it generates a compiled object file (either .obj or .o, depending on the compiler/platform/and so on). Imagine the common case where your C++ code refers to a symbol that is not defined in the C++ module you are compiling. For instance :


// in module_a.cpp
int MyClass1::DoSomeStuff(MyClass2 *myObject)
{
return myObject->ComputeAValue();
}

// in module_b.cpp
int MyClass2::ComputeAValue()
{
return 1;
}


The compiled module_a.cpp (-> module_a.obj) do not know what is the code of the ComputeAValue() method - he is aware of its existence because module_a.cpp includes module_b.h which tells the compiler that such function exists, but module_a.cpp do not even know that module_b.cpp exists. So the compiler must store in the object file that the code references the ComputeAValue() method.

Once all the cpp files are compiled, the linker tries to link all the object files in order to create the exe. If we simplify the process, the linker copies all the object files into a single big file. But then it must resolve the now unresolved references. For each unresolved symbol in an object file, the linker locates the symbol in another object file and links the reference to the symbol.

You should notice that if the code (or variable) behind a symbol is not found then you'll get this nasty "unresolved external" linker error.

A static library is just a big object file (in fact, it is a collection of 1 or more object files. you can use dumpbin (VC) or nm (unix/gnu) to see what the is the content of the library file. You can pre-link a lot of object files in order to create a library. This library may reference symbols that are not present in the library itself - just like another object file. As a consequence, linking your program with a static library is not different of linking your program with another object file.

When it comes to DLL, this is different. You have 2 way to use a DLL :

* "static linking" (word abuse) : you tell the linker that the program is going to use a particular DLL. The linker links your program with a DLL stub (which is a static library). The OS is now responsible for loading the DLL when the program is executed.

* dynamic linking : you are responsible for loading the DLL. On a Windows plateform, this is done using the LoadLibrary() API. You then get a pointer to any exported symbol in the DLL using GetProcAddress() (I know, using GetProcAddress() to get a pointer to a variable sounds weird but it actually works).

Using DLL have both pros and cons. First, some of the obvious pros :

* a DLL publishes an interface. If the interface do not change then you can safely change the DLL code.
* Using LoadLibrary()/GetProceAddress() allow you to easily write a plugin system.
* If a lot of program are using the same functions then using a DLL may decrease the size of the programs (as of today, given that your HD is 160GB, this is not really an issue).

Cons:

* DLL hell : this problem arise when another program installs another version of the DLL you are using. 2 years ago we tried to use the pegasus jpeg codec in our software. It is really fast. It worked well, and we began to have more contacts with pegasus. Then one of our client came with his laptop. We installed our soft on his machine an kaboom ! << no more jpeg save >> ! The problem was that he had acdsee v4 installed on his machine, and this version of acdsee is shipped with another pegasus product (and all pegasus products are using the same entry point : the pegasus function in pegasus.dll). So we finally decided to not using the pegasus library (an instead, we are using the intel jpeg library, which is nearly as good as pegasus one).
* strange memory behavior : using Windows and MFC, if you forget to add an AFX_MANAGE_STATE() statement at the beginning of each exported C function then you'll get some strange memory sharing problems - it seems that the global vars of your DLL is shared between all the instance of the DLL.
* interface change may be hidden : if you use a C interface then you only get the name of the exported symbols : no parameters and return types. Therefore, you can link with the wrong version of the DLL - never good, believe me :)

Hope this was of interrest,

Share this post


Link to post
Share on other sites
Quote:
Original post by Emmanuel Deloget
...
When it comes to DLL, this is different. You have 2 way to use a DLL :

* "static linking" (word abuse) : you tell the linker that the program is going to use a particular DLL. The linker links your program with a DLL stub (which is a static library). The OS is now responsible for loading the DLL when the program is executed.

* dynamic linking : you are responsible for loading the DLL. On a Windows plateform, this is done using the LoadLibrary() API. You then get a pointer to any exported symbol in the DLL using GetProcAddress() (I know, using GetProcAddress() to get a pointer to a variable sounds weird but it actually works).


Actually you can call it:
* compile-time-linking
* load-time-linking
* run-time-linking

Share this post


Link to post
Share on other sites

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

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this