What is a dll?

问题:

This may be a very noobie question, but in today's world of web app development many programmers don't need to deal with dll's much, and thus don't bother to learn about their purpose.

So what is a dll?

1. What is it used for?
2. How does it work?
3. How do you create one?
4. In what situations is creating one appropriate?

I've been told that dll's are used to store libraries of functions, but beyond that I don't know much. Hopefully someone here can enlighten me so I can finally stop wondering what all those .dll files in my Windows directory are doing.

回答1:

A DLL is a dynamic link library. It is a collection of code and/or data, which may be used by several applications (or other libraries/modules).

So for instance common methods to process files, work with GUI components etc. are made available in libraries so several applications may use the same functionality. This not only reduces the need to build the same stuff multiple times, but it also ensures that e.g. common dialogs are the same between applications.

Libraries can be loaded at runtime and thus shared between different concurrent applications. This is called dynamic linking.

In some cases the library can be included within the application itself. This is known as static linking. Static linking makes deployment easier at the cost of flexibility as different application will each load the same copy of the DLL.

However, static linking is not always an option. E.g. you can't statically link a .NET application. The user must have the .NET libraries in order to run a .NET application and libraries (or assemblies as they are called in .NET) are loaded at runtime.

DLLs are created by the same tools used to create applications. The specific details depend very much on the tools used.

回答2:

DLL = Dynamic Link Library

The name is actually quite descriptive of what they accomplish.

Library

Lets you isolate code for a specific problem domain into a single location. Then share this among multiple applications. The library can be swapped out for another at any time to fix bugs or add functionality.

Link

You can "Link" the library to an application so that the logic in the library is not compiled directly into the application.

Dynamic

The library can be loaded on-demand. Instead of loading a mammoth single EXE into memory, the OS can load only the portions needed. Plus if a DLL is shared between applications, the OS can optimize how the library is loaded and share it between apps.

回答3:

DLL (dynamic link library) files can be described as small "sub-programs" which are meant to help a bigger program run well. They provide a means of linking various hardware and software resources (at various points in its run-time sessions) to the main executable program upon which they are based, on an "as-the-need-arises" basis. This eliminates the need to load everything to do with the main executable program onto the computer's RAM (random access memory) when the program is first ran.

The software resources carried by DLLs include code for the various program functions that aren't really needed to keep the program running: that is, functions that only need to be called upon at certain times during a given computing session and might actually not even need to be called at all. Loading those functions (and there can be a considerable number of them for a given program) onto the computer's RAM when the program is first ran and then keeping them there throughout the session would be a waste of RAM space - which is considered to be at a premium.

A major advancement:

The development of DLLs was a major advancement in computing, because before they were available, everything to do with a program (including functions that were rarely if ever used) had to be loaded onto the RAM when the program was first loaded. That led to extremely inefficient computing, with slower speeds exhibited by various programs. It was also extremely hard to multitask by running even a couple of simple programs, because of the attendant strain on the RAM.

Considerations:

DLLs are usually version-specific. Those that work well for, say, Version 1 of a program (or a programming language, as may be the case) might not work well with Version 2. The general rule is that the DLLs in the older version tend to be unable to work well with the newer version, but those of the newer version can generally work quite well with the older version of the program or programming language.

回答4:

Dynamically Linked Library.

To give you an example, If you have someone else's DLL loaded into you application you can use bits of programming from it.

You can load a DLL that generates random numbers that always start with "5" or something.

In you program you can call CrazyDLL.GenerateRandomNumbersSorta() and it will return the number.

For a real world example, I have DLL that combines 4 textboxes (you'd use these to type IP addresses) and it automatically only accepts numbers less than 256, and handles pressing the backspace key to jump to a previous textbox.

I've created a DLL with that code, and now all I have to do is drag and drop more of those IP address textbox collections without having to duplicate all that code over and over again.

The same DLL also has function for converting IP addresses to hexadecimal strings, and other useful code.

回答5:

From MSDN Library:

A dynamic-link library (DLL) is a module that contain functions and data that can be used by another module (application or DLL).

回答6:

DLL = Dynamic Load Link Library. As you have been told, it is basically a collection of functions, C++ classes, and/or global variables. You can load the DLL statically (i.e. the OS loads it automatically when your program starts) or dynamically (your program explicitly loads it), at which point the functions and stuff inside the DLL are available to your program.

Creating one is similar to creating an EXE, except there doesn't need to be a main() function. There are linker directives to tell the linker to create a DLL rather than an EXE.

The main reason you'd want to do this is to encapsulate some code in one place and use it from multiple exe's, rather than linking the code into each one.

A somewhat historical reason is that your exe can be smaller since some of the code is physically located in a different file. This means that the amount of space taken up in memory by your exe can be smaller. On modern systems, this is less of an issue than it used to be, though it still might be an issue on Windows Mobile.