Difference between DLL and LIB

Within visual studio, depending on project settings, I can generate a XXX.lib
and a corresponding XXX.dll.

What is the difference between a .lib and .dll? The major differences I understand
are :

DLL : as the name states is a dynamic link library, that can allows functions/
classes/ implmented within XXX.dll to be called at run time. Hence the calling
.exe or .dll links with XXX.dll at run time.

LIB : is static linking. I.e when the calling exe or dll calls the XXX.lib
the exporting functions/classes etc are pulled in at compile time, opposed
to run time.

Please can anybody enlighthen me!
Thanks!

"nav" <navpreet_bains@hotmail.com> wrote:
>
>Within visual studio, depending on project settings, I can generate a XXX.lib
>and a corresponding XXX.dll.
>
>What is the difference between a .lib and .dll? The major differences I
understand
>are :
>
>DLL : as the name states is a dynamic link library, that can allows functions/
>classes/ implmented within XXX.dll to be called at run time. Hence the calling
>.exe or .dll links with XXX.dll at run time.
>
>LIB : is static linking. I.e when the calling exe or dll calls the XXX.lib
>the exporting functions/classes etc are pulled in at compile time, opposed
>to run time.
>
>Please can anybody enlighthen me!
>Thanks!

I have run across this in my position. I work on a team that builds DLLs
and LIBs which are used by a fairly large team of developers. Your understanding
of DLLs and LIBs is correct and I have only one addition. If, for the project,
you specify that you wish to produce a LIB then you will end up with a LIB
file. But, if you specify DLL you will end up with a DLL AND a LIB. In
both instances the LIB file is statically linked in to the executable at
build (compile) time. However, in the second instance (the DLL alternative)
the LIB file simply contains a "stub" of which functions are to be included
at runtime. Since the LIB file only references the functions and does not
include the code the size of the LIB is very small.

This explanation may not be 100% accurate. I am not an experienced C or
C++ programmer but I felt I should respond since I asked a very similar question
in my workplace and had a seasoned developer give me an answer.
Hope it helps. Let me know if it doesn't, or I missed your question completely.

To the responses you've had so far, I can add a simple example
of where you could use a DLL instead of a LIB:

We have an application, say, 'OURAPP.EXE', which can communicate to a number
of different serial devices.

Based on our customers' field devices, we issue a different
dynamic library, always named 'COMMS.DLL'.

'OURAPP.EXE' always loads a file called 'COMMS.DLL' and
always expects to find one function exposed:

TalkSerial( const char *Command, int *Response, int Size ).

It does not know or care about the differences at the "back-end"
of each variant of 'COMMS.DLL'.

This allows us to maintain a single 'flavour' of 'OURAPP.EXE' for
all of our customers, regardless of their field devices.

Regards,
M. Galea
Senior Systems Engineer - Automation
Schneider Electric (Australia)

>If, for the project,
>you specify that you wish to produce a LIB then you will end up with a LIB
>file. But, if you specify DLL you will end up with a DLL AND a LIB.
In
>both instances the LIB file is statically linked in to the executable at
>build (compile) time
That is only one way to do it, it is known as Linking implicitly.
You can also explicitly load a DLL's using calles to LoadLibrary() alowing
you to sellect wich DLL to load at run time e.g. probmpt a user for a languadge
and then load the correct DLL. Note that using LoadLibrary you will not
be able to just call functions from the DLL but will need to use GetProcAddress
to get a pointer to them and then call them. Also since DLL's are a win32
issue you should note that MFC applications loading extension DLLs should
use AfxLoadLibrary instead of LoadLibrary.
Hope this helps
Joey

"Joey Edelstein" <joey@denx.com> wrote:
>
>>If, for the project,
>>you specify that you wish to produce a LIB then you will end up with a
LIB
>>file. But, if you specify DLL you will end up with a DLL AND a LIB.

>In
>>both instances the LIB file is statically linked in to the executable at
>>build (compile) time
>That is only one way to do it, it is known as Linking implicitly.
>You can also explicitly load a DLL's using calles to LoadLibrary() alowing
>you to sellect wich DLL to load at run time e.g. probmpt a user for a languadge
>and then load the correct DLL. Note that using LoadLibrary you will not
>be able to just call functions from the DLL but will need to use GetProcAddress
>to get a pointer to them and then call them. Also since DLL's are a win32
>issue you should note that MFC applications loading extension DLLs should
>use AfxLoadLibrary instead of LoadLibrary.
> Hope this helps
> Joey
>
>

Kumar :

Let me explain the differences between the LIB generated as a result of a
DLL and Static Library.

Static Library - Generates only LIB
DLL - Generates a LIB and a DLL

LIB generated from a Static Library has to be linked at build time and it
is as good as having the object code in the DLL or EXE where you have linked
the Static Library

LIB generated from a DLL can be linked at build time and this LIB contains
only the Proxy for the methods used and the actual DLL will have the Obj
code which is used at run time.

LIB generated from a DLL won't be useful for you if you load the DLL dynamically
using LoadLibrary.

Static Libraries are used for 2 reasons:
1. Avoid versioning problems
2. Distributing your module as a single entity ( DLL or EXE )

Disadvantage is that ur module size is big.

You can ask me if you have any problems regarding the LIB or DLL, I have
worked for some time to solve the issues regarding these.

One good reason why a LIB is generated when you need a DLL. Let us assume
that you load the DLL using LoadLibrary. Now you have only one function to
use i.e the GetProcAddress. But you need to get to the address of a Global
object in the DLL which is not a Procedure. How do u do it?

Open the LIB file generated in bin mode, copy the resolved string and pass
this string as a parameter to GetProcAddress and typecast the address to
the Object*

Hope this helps.

Thanks
Kumar

"Joey Edelstein" <joey@denx.com> wrote:
>
>>If, for the project,
>>you specify that you wish to produce a LIB then you will end up with a
LIB
>>file. But, if you specify DLL you will end up with a DLL AND a LIB.

>In
>>both instances the LIB file is statically linked in to the executable at
>>build (compile) time
>That is only one way to do it, it is known as Linking implicitly.
>You can also explicitly load a DLL's using calles to LoadLibrary() alowing
>you to sellect wich DLL to load at run time e.g. probmpt a user for a languadge
>and then load the correct DLL. Note that using LoadLibrary you will not
>be able to just call functions from the DLL but will need to use GetProcAddress
>to get a pointer to them and then call them. Also since DLL's are a win32
>issue you should note that MFC applications loading extension DLLs should
>use AfxLoadLibrary instead of LoadLibrary.
> Hope this helps
> Joey
>
>

The cool thing about Dynamic Linking is that even though a .LIB is created
when you compile your .DLL, you don't need to use it (you could technically
delete it). Let's say that you have a .DLL named MyDLL.dll, and it contains
a single function called ShowMessage that takes a LPCTSTR, and returns nothing
(void). In you executable, you'd link to it like so:

typedef void (CALLBACK *lpfShowMessage)(LPCTSTR message);//lpfShowMessage
is a function pointer type.
lpfShowMessage ShowMessage;//ShowMessage will point to the dll function.
HINSTANCE hDll;//Handle to the dll

hDll=LoadLibrary("MyDll.dll");
if (!hDll)
{
MessageBox(NULL, "Some Error Message", "App Name", MB_ICONINFORMATION);
PostQuitMessage(0);
}
ShowMessage=(lpfShowMessage)GetProcAddress(hDll, "ShowMessage");
if (!ShowMessage)
{
FreeLibrary(hDll);
MessageBox(NULL, "Some Error Message", "App Name", MB_ICONINFORMATION);
PostQuitMessage(0);
}

//You may now call ShowMessage as if it were a function in your executable...
ShowMessage("Hello World!");

//When your program completes, call FreeLibrary to release the DLL.
FreeLibrary(hDll);

The difference in simple words is that DLL contains the
actual function while LIB file contains stub code to
link to these function dynamically.

You can attach DLL to your process using LIB
file which will load the DLL when your
process is loaded into the memory or
you can directly load the DLL, when required,
from your code by using calls like loadlibrary() and
GetProcAddress()without using stub code
provided by LIB file.