What is the relation/difference between a header file, dll and library?

[zealot]

What is the relation/difference between a header file, dll and library?

[lini]

A header file contains declaration of something (constants, classes, ...), usually ends with a .h or hpp extension.

A DLL (dynamically linked library) is a binary file (with .dll, .ocx, .a, ... extentions), containing functions, resources, ... and can be linked to your program at run-time. In order to use a DLL you need to include the corresponding header file, which declares things in the DLL, so that your program gets compiled. The DLL file is automatically loaded (by system) at run-time when your executable program invokes functions and asks for resources.

A library file (also called static library, with .lib extension usually) is a binary file which alsocontains functions and variables like DLL, but resolved at compile-time, meaning they need to be provided at link-time.

Dynamic and static libraries are often provided together with header file (but no source file, which contains the implementation) when the provider lets you use his/her functions/services but doesnt give you access to the implementation.

Is that what you ask?

[donbock]

Lini has summarized the generic meaning of "DLL". The same term is also used for the specific form of dynamic-link-library used by Windows and OS/2. Do you know whether you're referring to term generically or specifically in a Microsoft context?

[MrPickle]

@lini
Is there a difference between .h & .hpp?

[Banfa]

Not really. .h is a header file, .hpp is also a header file but typically only used in a C++ environment.

However when you get right down to it a header file can have any extension you want, it is only convention that uses h (for header).

[Balasing]

Thanks. Good & clear answer pal

[RedSon]

What are the memory requirements between static and dynamic libs? For example how is the heap and stack represented on each? When a process uses a DLL does it make a copy of the whole DLL? Do singleton classes implmented in DLLs remain a singleton between processes?

What is a "DLL boundry"? Why is communicating across DLL boundaries difficult or complicated to achieve?

I recently switched to a different project and I'm afraid I don't know what I'm doing now... :(

[JosAH]

@RedSon
In every self respecting Linux/Unix distribnution the 'text segments' of .so files (the equivalent of dll files) are only loaded once, so if two or more people use the same .so file the text segment (the part where the code is) is loaded only once). When the last user stops his/her process the segment is unloaded.

Static libraries don't have that advantage, i.e. they are completely loaded by every process that was linked against the static library because the code is part of the entire process, i.e. executable file.

I assume the same scenario works for Microsoft's .dll files.

kind regards,

Jos

[Banfa]

It is the same for Windows DLLs Jos.

One of the main differences between 16bit and 32bit windows is/was that under 16 bit windows memory used by a DLL was shared by all programs using the DLL. That is in 16bit Windows you could use a DLL to transfer data between programs easily.

In 32bit Windows the data used by DLLs is not shared between programs, each program instance of the DLL uses different data mapped into the programs virtual memory space. However the text segment (code) is only loaded once I believe.

Because the DLL and the application are different processes there are some class issues. For instance static data in a class used in a DLL and an application using the DLL results in the application and the DLL each having their own copy of the static data.

[RedSon]

@Banfa
Can you explain this in more detail?

[JosAH]

@RedSon
I don't understand it either; static class data is stored in the data segment and nowadays data segments are copied per process; it used to be different in the old days where data segments where shared between processes in MS Windows.

kind regards,

Jos

[Banfa]

Sorry I thought I had better come back and explain myself. While I was sure I had heard of problems involving DLLs and static class data I can find no backing for this statement.

You do have to make sure you export everything from the DLL correctly or you would get linker errors (unresolved symbols) but that isn't terribly surprising not the blanket of doom I initially implied.

Our company coding standards suggest caution when using inline functions with classes in a DLL or shared library. If you plan on being able to update the DLL/so without changing the application (which is in theory possible) the inline functions cause a problem because they would be compiled straight into the application requiring an application rebuild rather than a simple DLL rebuild and redistribute.

However since there is a fair amount of evidence that our company C++ coding standard was written before the C++ standard was ratified I find myself not willing to trust it on this without a more recent corroboration that this behaviour is still true (although logically it does make sense).

A-hem,
nothing to see here
move along please