OSDev.org

Ok , I have created a static library project and a dynamic library project in c/c++.

From my understanding a static library is just an archived file that contains the .o files that you can link against by using the header files and includeing the .a file to your library path while linking. It essentially is equivalent to just typing passing all the .o files to the gcc/g++ compiler/linker all in one shot. And it basically just copies the functions into your final exe file.

From my understanding a dynamic library is loaded at runtime/load time and methods are not copied into your exe.
Reducing the size of your exe and making the exe use only what it need's in the dll.
But also makes the exe dependent on have the dll available.

My question is when you create a dynamic link library it creates 4 types of files I believe dll , lib , def , and exp
dll is where the functions/everything is and is needed.
lib ,def ,exp I don't fully understand why you need it?
I have read that lib is important for defining what functions can be used in a dll. But I have seen applications with no .lib files run fine with just dll's.


Thanks for any help here.

Also is their away to call dll functions without the .lib file.
I know you can load a dll then call it but I am talking about including a header file/ using the functions in a dll before compileing not using loadlibrary to do it.

You seem to be asking very windows specific questions. Why not try their website ==> http://msdn.microsoft.com

You are mostly right in your assumptions.

I have read that lib is important for defining what functions can be used in a dll. But I have seen applications with no .lib files run fine with just dll's.

LoadLibrary and GetProcAddress allow a dynamic library's functions to be accessed without any library defining them.

Ok , so if you are not using a .lib file with your .dll then correct me if I am wrong.
You must use a loadlibrary statement in code and you cann't just compile your program against a dll with out the lib file as well.

It depends on the tool you are using. There are assemblers, for example, that just need to be told what DLLs you are using. As long as the symbols match, you don't need anything extra to make it work. The only catch is that the symbol name in the DLL may not be pretty (or what you expect it to be).

So if you used objdump to look up a particular function in a dll.
Then all you would have to do is put an extern dll_function_name ;
line in your program and compile against the dll and you can use it.

That would be pretty straight forward.

If that is the case then what is the point of the .lib file ?

Shipping the header files and the dll should be enough to call those function in the dll as well as not having to us objdump to lookup the names.

Does not all compilers allow you to compile against a dll ? Because then maybe that specific compiler would need the .lib , exp , def ,...etc

Curious what the format of the .lib , exp , and def are. I am assuming it is the same format as an exe. Like coff , a.out ,...etc the only difference would be a few section headers maybe but just a guess.

Could you ever ship a .lib file instead of a .dll file for use?

I've never made a DLL, so I'm not sure exactly, but I'm pretty sure (some of) the extra files just tell the compiler the symbol names (possibly giving them "pretty" aliases), along with the size (and/or total byte size) of parameters to functions, etc.

Like I said before, it depends on the tool as to what extra things it needs to work. It is all compiler specific. Ultimately the OS only cares about its own stuff, which on Windows means EXE and DLL. The other stuff is just extra things needed by specific tools to work (even if it mean the extra stuff makes life more difficult for the user).

I highly recommend googling for the use of file extensions of which you are not familiar.

Ok , just curious if anybody nows given just a dll with it's header files.
Is their away to compile the extern function's you are using from the dll into your exe.
Basically static link (copy the functions from the dll into your .exe) as oppose to dynamic (loading it at runtime and having it depend on the dll being their).

Could you do it if you had the .lib file? (basically would the lib file help you)

Sam111 wrote:Ok , just curious if anybody nows given just a dll with it's header files.
Is their away to compile the extern function's you are using from the dll into your exe.
Basically static link (copy the functions from the dll into your .exe) as oppose to dynamic (loading it at runtime and having it depend on the dll being their).

Could you do it if you had the .lib file? (basically would the lib file help you)

Yes it's possible to convert a dll to a static lib. There are tools to do it.

like what tools are we talking about?

In linux the .dll is a .so and when I generate a .so their is no other files generated.
So the lib , exp ,...etc are probably just microsoft specific and unnessary in most cases ?


I have looked into def files and they seem to be the equivalent of linux's gcc linkerscripts but with less control over stuff.
Correct me if I am wrong.

.exp files are just equivalent to one piece of a def file the EXPORT section.
So .exp and .def would server the same purpose as if you one where using the .def EXPORT section.
Correct me if I am wrong.

Using ".dll .exp .def .lib" for a Google search, found this link (#2 hit) explaining many of your questions.

The #1 hit isn't as encompassing, but comes with lots of useful followup-links.

(I'm not trying to sound smart or weasel-ly. I don't know much about how Windows does things either, and I'll probably read those pages myself at a later point, but I don't feel like writing up a summary.)

I guess this answers the need for .lib under windows

A linker needs more information, such as the DLL filename, what symbols are available in the DLL etc. This information is normally available in an import library file, which also has a .lib extension. When a linker builds a .dll file, it also generates an import library .lib file. This .lib file is distributed to the developers that will make use of the DLL at the develop-time, to be exact, when their programs link. The .dll file must be available when the developers' target executables run at run-time. (Actually you know the .h header files should also be available to the developers that use the DLL.) The import library .lib file is used exactly like a static library file at linking from the developer's perspective.

I guess you need to have the .lib if you are developing a program that will use function in a dll?
I was under the impression that you could use objdump to lookup the names in the dll then just use a extern keyword statement in your code to call that dll function. But from this it seems you need the .lib file. <- Probably because of some name mangling issues or something .

Although I still believe you should beable to call a dll directly without the need for .lib.
Like in linux all you have are .so which are the equivalent of dll's.

Maybe the .lib copies the function you are using into your dll (allows you to use them like static link does by copying the function directly into your code)??? Curious to know this.

The def is not really needed any more better to use the dllexport statement in code.
exp would be useful only in the rare case that you have a library depending on a library and visa-versa (circular logic) which is in general not a good idea. So basically exp won't usually be used.

Again thanks for all your help
Maybe somebody that knows a little bit more on the subject could clear these up.

You can view the Windows lib file created alongside a dll as the PLT bit in an elf. The compiler generates that by itself in unix systems and is expected to insert it, including the load-library logic, into the target executable when linking to a shared library. Windows linkers aren't that smart, they just use the PLT logic and library loading logic embedded inside the lib file.

That also means that the lib file is at least 95% redundant. It contains no logic or intelligence that the compiler wouldn't be able to figure out from the dll/so file itself.

The dllimport/dllexport is to make the choice between the "plt-loaded" function and the directly loaded function. Unix systems make a fairly random decision to use .plt.func or func, windows systems allow you to say you want the __imp_func or func style reference. The first is the indirect "plt-style" jump, the second is direct.

A def file removes the need for marking something dllexport; all functions mentioned in there are dllexport anyway. That cleans up your code but doesn't work well for non-C-style functions. You still need the dllimport on the other side (or the exp file) to indicate which functions it should use. Technically speaking, the def/exp logic is more sane as it puts the logic at the level of the library, where the dllimport/dllexport puts it on the file level.

.

I want you to explain this then:

I put gdi32.lib through objdump, and all it did was rename FunctionInDLL to __imp__FunctionInDll by means of an indirect jump, doing exactly what candy said: solve C calls with calls directly into DLL space because the compiler is too stupid to generate those bits on its own.

So unless symbols not in gdi32.dll are present in GDI32.lib, the libfile is technically wasted space as it can be 100% generated from the .dll alone.

However it is again wrong. The LIB is needed because a DLL is NOT a LIB. For example the DLL does not contain information about the calling convention and the number and type of parameters for each function.

And the relevant header files do not contain the calling convention info? And even if you don't have them, you know custom DLLs contain mangled names by default?


I might also add that GoASM comes with a linker that does not need .lib files, as it indeed uses DLLs directly.