Just curious, I was told that with dll files, you can make modifications to the dll without recompiling the whole application that uses it. On the other hand .lib files need to be compiled so the code can linked to the application as one.
So I know that the .lib files are turned into machine code. but what about the dll's ?? Are they turned into machine code upon the execution of the application ??
This could probably lead to easy hacking if not used right.
The dlls are still machine code. They're just dynamically linked in at run time (hence then name) so (if you don't change the function signatures) you don't have to recompile your main program to use a dll after it's been changed. A static library is physically part of your executable, that's why changes there require a recompile (or really, a relink).
DLLs do contain compiled machine code. The difference is that the linking between the application EXE and the DLL is done at runtime, instead of at (traditional) link time between OBJ and LIB files.
A DLL normally contains machine code. The point isn't that you can modify the DLL because it's source code, but that you can modify the source code for the DLL, re-compile and re-link, and as long as the interface remains the same, you can replace the old DLL with a new one, and the rest of the application can use the new instead of the old.
In reality, this frequently leads to problems, such as an application including code that depends on a bug in the old DLL. When/if you create a version that fixes the bug, it breaks the application. Google for "DLL Hell" for many more examples.
Simply put:DLLs can be swapped out post-compilation because they are physically separate from your exe. Lib and obj files, on the other hand, are compiled into your exe, so that updating them requires recompiling your app.
Dlls are effectively exes that don't define main().
When a DLL is linked to the main program, only the interface, i.e. classes, functions etc. it exports are linked by their signature. The actual machine code inside the DLL is loaded only on runtime, not on compile-time; that's why you can build your app with just the DLL's lib, and put the actual DLL where you'd rather have it (for example some shared DLLs folder or whatever).
You can then swap out this DLL with any other DLL with the same interface. That is how plugin-systems usually work, as each plugin is simply a DLL that conforms to a documented pre-defined interface, and the program just loads all DLLs of that interface it finds in some "plugins" directory.
The (possibly) confusing part here is that there are effectively two kind of .lib files:
a) libs for static linking. These put all their compiled code directly into the main app, and are a fixed part of the resulting .exe file.
b) libs for dynamic linking. These contain an interface for a DLL containing the actual code, which must be available to the app only at runtime (and if it isn't, it won't start, and simply tell you which DLL it couldn't find).
Btw: you don't have to specify which one of the libs you link to is what type, it does it automatically.
Also: Some applications are built as DLLs meant to being run inside some external environment. Webservices, for example, are implemented as DLLs with a specific interface, which are being run by an Apache/IISAPI/whatever server. This works similarly to the aforementioned plugin-system, but here each DLL effectively is the application.