Initial conceptualization
Application and executable are different things. Application is a set of things (eventually it can be only the executable when it is something very simple), of functions, tasks, activities that benefit the user, is a more abstract concept. When a main executable (EXE on Windows) needs a DLL it no longer represents the application alone. If without the DLL the application does not work, if the executable has dependencies, the application certainly does not get confused with the executable.
Comparison
DLL |
LIB |
Multiple executable files |
A monolithic file |
DLL/Dependency Hell |
Incompatibilities between libraries |
General applications get bigger |
Executable gets bigger |
Allows loading unforeseen codes |
Everything necessary needs to be in the executable |
Does not allow certain optimizations |
Global optimizations are possible |
Slower load to map all symbols |
Faster charge, all links are ready |
Can be used freely with LGPL |
You need a commercial or more liberal license |
Allows reuse of distributed binaries |
Duplicate common binary during build |
Better interaction with third-party tools |
Only interacts if the tool generates custom executable |
Allows malicious code injection easily |
Hinders malicious code injection |
Allows a canonical binary |
Risk of confusion between versions |
Some items depend on how the library is created/used.
Static library
A static library cannot be used by an application directly, it cannot be executed. It is used to generate an executable (EXE, DLL) for an application. It is needed for the executable assembly process, which we often call compilation time (although technically this is done after the compilation itself).
The library consists of several files called objects that are generated by the compiler. In fact it is possible to insert these objects in the application even without the existence of LIB which is a way to group and facilitate the work of constructing the application. These files are compilation units. There are utilities to manage these files in LIB.
When you use a function of one of these compilation units the whole object is included in the executable (which can be called monolithic if it does not depend on anything external).
Objects that do not have functions referenced by their application do not enter even if they have been nominated for selection during the linkediting. The process of linkediting is intelligent in this regard. Linking (Binding) function with the application is done in time linkediting unlike the dynamic library where this is done at runtime.
Note that the correct term is "time of linkediting" not "compile time". Libraries are mounted or linked to an application after the code has already been compiled.
In well-built libraries objects should contain only functions that must be used together, such as the methods of a class, for example.
Dynamic library
A DLL/OS is an independent executable in an independent file. It is even possible to run it as a normal executable under certain circumstances. It also has these objects (they are binary).
The definition of which objects are there is the responsibility of who built the DLL (or SO, I speak more in DLL to simplify), as well as in a normal executable. The DLL may contain a lot of things your application doesn’t need and the executable does not call. And if a(s) DLL(s) does not contain(in) everything your application needs, you will have problems while running.
Unless you’re using the. NET, where Dlls work in a special way since they are not native code, it is not possible to manage the content after the file is generated.
A DLL tends to be larger because of these possible unnecessary codes that are pre-linked and because it needs additional information to make the dynamic call. This is not always a great disadvantage but it is good to take this into account.
It is possible to use a load-on-demand technique that allows a DLL that is not effectively used by the application in a specific execution not to be loaded into memory.
But a specific DLL cannot only load the functions that will be used by the application, because it does not even know what will be used. It’s all or nothing (actually at the lowest level this is not quite so, but it is a control of the virtual memory and not of objects).
Given the problem of DLL Hell (in English) and dependency (in English) increasingly frequent, the advantages of the DLL are getting smaller and smaller since to solve these problems it is customary to avoid the reuse of binary and the distribution of the necessary Dlls is chosen along with the main executable.
In the end we have the DLL only because everyone does so. I keep saying that developers, especially the younger ones, don’t think at all, follow formulas.
In addition, as already stated, some optimizations are not possible under these conditions unless the code runs on a virtual machine (.NET, Java) that normally prepares the environment and makes the latest optimizations at runtime (which has a cost).
No. NET binding is done at runtime - done by Jitter - what makes possible make some optimizations even better than the linkeditor static would. It is a process similar to Java. The .NET Native will allow binaries, obviously native, monolithic.
Guide of choice by DLL
- Your application uses some external API that is only available by DLL or is there any real convenience in opting for DLL.
- You have the option of linkage static or dynamic but the license you need only allows dynamics (Qt for example using LGPL).
- The application needs flexibility and has a system of plugin in which it uses executable codes which can be called in the process by linking the new code to the main executable.
- Link statically two libraries is causing some conflict or difficulty and dynamically resolves.
- You are producing something that should be used with an application that expects a DLL. It may be because that code needs to be guaranteed to be unique between applications or third parties need it (use with another language) or it is still a plugin.
- Its application is part of a larger solution or a wide range of products that are usually installed on the same machine and have many parts in common. Think a little more about whether to use DLL or not. I tend to not use. Today binary reuse is a weak argument in most cases.
Often the benefit does not compensate for the loss, we are in the 21st century, we do not have the same problems of the last century. That is, opt for the DLL/OS when you have no other option or are having a problem that is difficult to solve otherwise.
Completion
The use of DLL tends to make the application bigger and slower. Although that’s not a big problem in most cases. The use of DLL can give the false impression that the application gets smaller based on the size of the main executable. But the application is more than it.
If you can choose, the first option should be the use of static library and only if there is a specific reason to use the dynamic library should it be chosen.
A single executable facilitates maintenance, debugging, implantation and diagnosis not to mention the reliability of the application that has fewer dependencies after built as already mentioned in this and another answer.
But if it is necessary to have a dynamic library, leave to use only where it is needed. That is, you can make a mix. One way doesn’t stop the other. Create a main executable with maximum built-in code and use auxiliary files as strictly necessary, with this you reduce the risk surface.
Anyway, the subject is wide, you can ask dozens of questions and not exhaust everything you have to say.
Wikipedia article (in English).
ve if this helps you http://www.differencebetween.net/technology/difference-between-lib-and-dll/
– Pablo Tondolo de Vargas