Clarification on Libraries

[horrificmonster]

Hi All,
I've been reading up on libraries, and I think I get the general idea. There are still some fuzzy parts, and I was wondering if someone could clarify it for me.

It involves the dynamic library linking (Windows).

So far I've determined that there are three different files at play here, the .dll, the .lib and the .h.

The .dll is pretty self explanatory I suppose. It's compiled implementation code that will be dynamically linked at compile time. Now here is where I get tripped up. It also comes with something called an import library, the .lib file. Now at first I was confused because this is generally a static linked library file extension. But apparently it also has a bit to do with the dynamic linking as well. Then there's the .h file which is just the function/class signatures.

So I guess my question is, can I use a .dll with just the .h file?

Can I use the .dll with just the .lib file?

Can I use the .dll with both of them?

What are the consequences of using each different combination of files?

How are these libraries typically passed around to interested parties, do they usually come with all three?

Any help would be much appreciated, thank you!!!

[Thomas1965]

So I guess my question is, can I use a .dll with just the .h file?

Yes, you can - at least under Windows, not sure about Unix or Mac.
You need to load the dll by yourself with LoadLibrary and you can access the function with GetProcAddress.

Can I use the .dll with just the .lib file?

In theory you can but it's pointless since you don't know what's in the dll.

How are these libraries typically passed around to interested parties, do they usually come with all three?

In most cases I have seen you get all 3, but there might be exceptions.

[helios]

dynamically linked at compile time

This is contradictory. Dynamic linking is linking that happens when the program is executed. Static linking is linking that happens when the program is compiled.

But apparently it also has a bit to do with the dynamic linking as well.

Yes. There are two kinds of .libs. Static library .libs contain the code for the library within themselves, and do not necessarily load a DLL when the program is executed (they might still load DLLs if the code of the library requires this). Import library .libs don't contain the code itself, they just contain the code that loads the library at initialization and sets up internal function tables, and also contain shims so that the program can link to a static interface, without having to deal with function pointers.

Can I use the .dll with just the .lib file?

Yes and no. You can't make calls to the library's functions if you don't know what functions it contains, and if the linker detects that the .lib is not used at all, it might decide not to link it.
However, in the case of C++ symbols (not C symbols), the symbol name contains the full type information of the symbol, so a header for a C++ DLL can actually be generated from its .lib or even from the DLL itself. I've actually written programs that did something like this.

[horrificmonster]

So I guess my question is, can I use a .dll with just the .h file?


Yes, you can - at least under Windows, not sure about Unix or Mac.
You need to load the dll by yourself with LoadLibrary and you can access the function with GetProcAddress.

So what would the .lib file give you then? What's the point of using it if you only need a .h and .dll file?

[horrificmonster]

dynamically linked at compile time
This is contradictory. Dynamic linking is linking that happens when the program is executed. Static linking is linking that happens when the program is compiled.

Sorry I think I meant 'load time' dynamic linking. Run time dynamic linking from my understanding is using the OS API in order to link while the program is running. From what I can tell run-time dynamic linking doesn't really require any of the .h or .lib files in order to use.

But apparently it also has a bit to do with the dynamic linking as well.
Yes. There are two kinds of .libs. Static library .libs contain the code for the library within themselves, and do not necessarily load a DLL when the program is executed (they might still load DLLs if the code of the library requires this). Import library .libs don't contain the code itself, they just contain the code that loads the library at initialization and sets up internal function tables, and also contain shims so that the program can link to a static interface, without having to deal with function pointers.

So if you have the .h file you don't need the .lib?

Sorry if I'm asking obvious questions here I'm just trying to wrap my head around all the various pieces.

[helios]

From what I can tell run-time dynamic linking doesn't really require any of the .h or .lib files in order to use.

You still need something that tells you the function signatures and such. You don't need the headers, but you might end up rewriting them yourself from the documentation.

So if you have the .h file you don't need the .lib?

That's right. The .lib just obviates the boilerplate code (calls to LoadLibrary() and GetProcAddress()).

[Duthomhas]

You don't need a lot of things that make life easier, like compilers for example.

The .lib files compile into your .exe* so that the OS can automagically link functions in your .dll to function calls in your .exe without any further fuss or muss on your part.

* automagic!