Really basic questions about libs and dlls
Okay, so I've never understood libs and dlls fully, even though I've been coding on and off for almost 7 years... pretty bad, eh?.
So, a .lib is just a file containing class and function definitions, and nothing else, right?
A .dll is to a .lib as a .exe is to a .cpp, its what is actually used at runtime, correct?
If I'm right about the above, how does the .exe know to look for a .dll, and what it will be named? Is that in the .lib file? How does it know where exactly to look into the .dll to find what it is looking for (entry point for a function)? Is that also in the .lib?
Lastly, I've never written a .dll, so... why would I ever want to write one? Is it just so that other programs or people can easily access my code without a million includes?
So, a .lib is just a file containing class and function definitions, and nothing else, right?
A .dll is to a .lib as a .exe is to a .cpp, its what is actually used at runtime, correct?
If I'm right about the above, how does the .exe know to look for a .dll, and what it will be named? Is that in the .lib file? How does it know where exactly to look into the .dll to find what it is looking for (entry point for a function)? Is that also in the .lib?
Lastly, I've never written a .dll, so... why would I ever want to write one? Is it just so that other programs or people can easily access my code without a million includes?
Last edited on
No, you got it all wrong.
A lib is a statically linked library. It contains compiled code that can be copied into the final executable.
A DLL is a dynamically linked library. Its code will not be copied into the executable. Instead, it will be loaded at run time. There are system calls that take a file name as parameter (e.g. "libbz2.dll") and can tell Windows to load a DLL into the code space of a running program. Windows will look for DLLs first in the working directory, and then in each of the directories specified in the PATH environment variable.
The point of DLLs and shared objects is that they save memory. The former, only in HDD, and the latter both in HDD and RAM. A DLL doesn't need to be copied into each executable that needs it, but because of that, it's considered a dependency (i.e. the program won't work without it). The same applies to shared objects, plus shared objects keep no more than one instance in memory at any given time, thus saving RAM.
Even using shared libraries, includes are necessary. The compiler needs to know at compile time what parameters a given function takes, and why some functions are undefined (because they defined inside the library, which the compiler doesn't have at compile time).
A lib is a statically linked library. It contains compiled code that can be copied into the final executable.
A DLL is a dynamically linked library. Its code will not be copied into the executable. Instead, it will be loaded at run time. There are system calls that take a file name as parameter (e.g. "libbz2.dll") and can tell Windows to load a DLL into the code space of a running program. Windows will look for DLLs first in the working directory, and then in each of the directories specified in the PATH environment variable.
The point of DLLs and shared objects is that they save memory. The former, only in HDD, and the latter both in HDD and RAM. A DLL doesn't need to be copied into each executable that needs it, but because of that, it's considered a dependency (i.e. the program won't work without it). The same applies to shared objects, plus shared objects keep no more than one instance in memory at any given time, thus saving RAM.
Even using shared libraries, includes are necessary. The compiler needs to know at compile time what parameters a given function takes, and why some functions are undefined (because they defined inside the library, which the compiler doesn't have at compile time).
One thing I forgot to mention earlier, but which I hope is obvious enough, is that the compiler (or, more accurately, the linker) does the copying when adding a lib to code.
That really clears up everything. I have been also wondering what were those *.dll's importance. :)
By the way, do they contain c++ code? Because I cannot view any of them with C++ compiler - and tutorials i find mostly explains how to create them with Java/VB/C#.
By the way, do they contain c++ code? Because I cannot view any of them with C++ compiler - and tutorials i find mostly explains how to create them with Java/VB/C#.
Java and all of the .NET languages (C#, VB.NET, etc.) generate bytecode, which is kind of like a higher-level Assembly. One of the properties of bytecode is that it can be easily decompiled, since lots of information of the original source remain in it. Another is that it has to be executed through a program, be it a virtual machine, an interpreter, or a just-in-time compiler. This also means that it's multiplatform (i.e. it can be executed in any system without recompiling).
DLLs, libs, and basically any other kind of compiled library, on the other hand, contain native code for a specific system. Like executables, they cannot be easily decompiled. When binary code is decompiled, the result is code lacking neat things like structure, variable names, function names, classes, etc.
Of course, there are people who can actually read disassembly. Those people are called "reverse engineers".
DLLs, libs, and basically any other kind of compiled library, on the other hand, contain native code for a specific system. Like executables, they cannot be easily decompiled. When binary code is decompiled, the result is code lacking neat things like structure, variable names, function names, classes, etc.
Of course, there are people who can actually read disassembly. Those people are called "reverse engineers".
Topic archived. No new replies allowed.