59
I know that .dll and .lib are libraries, the first is dynamic and the second is static. But what does it really mean? How does each one work?
If I have to generate a library from a code, what I should keep in mind to decide whether I make a .dll or a .lib?
35
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.
| 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.
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.
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.
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.
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.
O uso de DLL tende deixar a aplicação maior e mais lenta, the application should not get smaller? Because the executable does not incorporate the library into its binary. Or by "application" you meant "library"? And it has a typo: "dysgnostic".
No, this is a classic error. In the details the answer shows that the opposite occurs. DLL is part of the application. The most that can happen is to give her the illusion of being less in her distribution if you can be sure that the appropriate DLL is already on the user’s computer. Can you guarantee it? No. Then you have to send it along. If so, you can use it instead of installing yours which is the same, but runs the risk of DLL Hell. Do you think this makes the application smaller? Do you have any gain? Disk space was problem in last century. In memory that is the most important c/ctz gets bigger
I understood, then: código+dll > código+lib. The difference is when you use the lib the exe gets bigger when you use the dll the distribution gets bigger. Correct? Is that by "application" I was understanding how exe. Now I think it’s clear to me.
What can happen in memory is the load happens late and for some time does not consume the memory but when the DLL loads it will probably load things that the application does not need. It is true that if depending on of how the application is made, if you do not use a certain function, the DLL will not be loaded. I understood its comparison but to conceite right exe+dll > monolithic exe. To lib is part of the exe, it can not be dissociated. The exe gets bigger, so what if he needs it and stuff? No point in winning a toast and paying the whole more dearly than buying the toast.
I worked a while ago on a system that records dll as a COM object on the application server and the application terminals connected via RPC on this server, I think that today programmers are more concerned with tiering to follow some Pattern design than actually enjoying the use of DLL as a library to be used once in all applications that have been published on the server.
I confess that I am one of those, because in the same server, I have the same system running for different clients and for each instance of the system, I have the same DLLs that could have AIDS registrations in windows and be shared between systems
14
Both have the same purpose: they are libraries that allow you to reuse a certain code. One is static (*.lib, *.a) and the other dynamic (*.dll or *.so). You already know that.
But the differences are:
Python can only use a C library if it is dynamic? The languages I use that allow the use of these libraries can mount executables that include C libraries.
Vários programas diferentes podem reutilizar a mesma biblioteca dinâmica. you mean that a single dynamic library can be accessed by multiple programs at the same time, correct? While lib is loaded into the memory embedded in the main executable, therefore it cannot be accessed by other programs. Because "reusable", the two libraries are: Ambas tem a mesma finalidade: são bibliotecas que permitem reutilizar um determinado código
@Math Several applications can access the same DLL at the same time. This is an advantage. But it is increasingly difficult for this to actually happen, and it only happens on very stable Dlls that are part of the operating system. Reuse is not one of the best advantages of DLL nowadays. Reuse in this case is from final torque. Think about it, this would help when computers were barely more than a few MB and Hdds barely made it to Gbs. The gain today is derisory in most cases and practice has shown that it is common not to have this gain. DLL created a problem and to fix it created another.
9
Briefly, a DLL is a library that contains functions, which can be called at runtime by the application, thus giving a dynamism in its use.
Already the LIB is a static library whose methods can only be invoked at compile time.
Soon the use of LIB would result in a larger file, which could be divided with the use of DLLs, thus making the DLLs reusable, but against the background of the use of DLLs there is a problem with its versioning.
The dynamism of the use of DLL is linked to the fact that the same DLL provide a sharing between different running programs.
Runtime or Runtime (English term), is the period in which a computer program remains running. The term Runtime can also refer to a virtual machine that manages a program written in a computer language while running.
The runtime term is a counterpoint to the compile time term, which is a reference to the period when the code is compiled to generate an executable program.
Advantages DLL
The following list describes some of the advantages that are provided when a program uses a DLL:
In short
When using LIB at the end of the compilation everything will be part of an executable, using the DLL there is a fragmentation of the executable modules, which can be used after the compilation of the executable.
Source: http://www.differencebetween.net/technology/difference-between-lib-and-dll/
Why does the function called at runtime give dynamism? What does it mean uma função ser chamada em tempo de execução and um método ser invocado em tempo de compilação? Ultimately, won’t the executable use both types of libraries the same way? The only difference is the larger size of the executable when using lib? Why is dll more reusable than lib?
@Math every function is called at runtime and "never" method is invoked at compile time (it even has something rarely used and makes no difference to that question), it’s probably just the wrong use of nomenclature. What he may have tried to say is when the function is linked. I edited my answer to reflect this.
@Math, in this case runtime is the compiler runtime and not the program.
I edited my reply based on more content I studied on the subject.
Browser other questions tagged c c++ dll library lib
You are not signed in. Login or sign up in order to post.
ve if this helps you http://www.differencebetween.net/technology/difference-between-lib-and-dll/
– Pablo Tondolo de Vargas