Go to DLL dynamic link library and Lib static Link Library for programmer Analysis

Bytes

(1) Lib is required during compilation and DLL is required during runtime.
If you need to complete source code compilation, it is enough to have Lib.
If dynamic connection is also enabled, DLL is enough.
In the development and debugging stages, it is best to have both.
(2) common dynamic library programs include lib files and DLL files. The LIB file must be connected to the application during the compilation period, and the DLL file will be called only during the runtime. If there is a DLL file, the corresponding lib file is generally some index information, the specific implementation is in the DLL file. If only the Lib file is available, the Lib file is statically compiled and the indexes and implementations are all included. The advantage of static compiling lib files is that dynamic libraries are no longer needed during installation. However, there are also some disadvantages, that is, the application is relatively large and the flexibility of the dynamic library is lost. During version upgrade, new applications must be released at the same time.
(3) In the case of a dynamic library, there are two files, one is imported into the database (. lib) file. One is a DLL file. The imported file contains the name and location of the function exported by the DLL. The dll contains the actual function and data, the application uses the Lib file to link to the required DLL file. The functions and data in the library are not copied to the executable file. Therefore, in the executable file of the application, stores not the called function code, but the memory address of the function to be called in the DLL, in this way, when one or more applications are running, the program code is linked to the called function code, thus saving memory resources. From the above description, we can see that the DLL and. Lib files must be released along with the application, otherwise the application will produce errors.

 

Experience of programmers in DLL dynamic link library and Lib static Link Library

Http://www.cnblogs.com/lancidie/archive/2011/03/12/1982253.html

Author: freeknight

Preface: Continue, vomit, hahaha ~~~~ In fact, it is still for the company programmers to literate, shouting, really want to go to bed. Let's get down to the truth.

1: Shenma is DLL and Lib, and Shenma is a static link and dynamic link.

Everyone understands that DLL is a dynamic link library, and Lib is a static Link Library. DLL is actually EXE, but there is no main.

Dynamic Links are relative to static links. A static link directly links a function or process to an executable file and becomes a part of an executable program. When multiple programs call the same function, there will be multiple copies of this function in the memory, wasting memory resources. The Dynamic Link provides the description of a function to the executable file (No memory copy is available). When the program is stuck in the memory, the system will create the connection between the DLL and the application at the underlying layer. When the DLL function needs to be called during execution, the system will actually execute the function code in the DLL Based on the location information of the link.

In Windows 32, each process has its own 32-bit linear address space. If a DLL is used by the process, the DLL is first transferred to the global stack of Win32 system, then, the DLL process address space is mapped through the memory ing file. If a DLL is called by multiple processes, each process receives an image of the DLL instead of multiple copies. However, in the Win16 system, each process needs to have its own DLL space. You can understand why there is no difference between static links.

2: Differences and links between DLL and Lib.

DLL is a file required by the program in the running stage.

Lib is the file to be linked during program compilation.

There is only one type of DLL, which must be the implementation of functions and procedures.

There are two types of Lib. If only Lib is generated, the Lib is statically compiled and contains function indexes and implementations. This Lib is relatively large. If a DLL is generated, a lib will also be generated. This Lib is different from the Lib just now. It only has function indexes and is not implemented. It is very small. However, these two lib libraries still follow the previous principle and need to be linked during compilation. If the first Lib is not linked, the function implementation cannot be found during the program running. If the second Lib is not linked, the function implementation cannot be found during the program running. However, there is an alternative to the second Lib, that is, in the program, use loadlibrary and getprocaddress to replace the second lib function. The first type of LIB will generate a large EXE file because all lib information is statically linked to the EXE file. The EXE file generated by the second lib will be relatively small, because the implementation of the function process is still in the DLL.

(I have a bunch of questions. I hope you can understand the differences between the two lib libraries. Otherwise, we can call the statically compiled lib as a static Link Library. However, the dynamically compiled Lib is called the import database. It may be better .)

The advantage of static link Lib is that it saves the trouble of attaching dynamic link libraries, but the disadvantage is that it is large in EXE and version control.

The advantage of dynamic link DLL is that the file is small, and the DLL can be changed when the version is changed. The disadvantage is that there are more files. If the dynamic link is used by multiple processes, it is more convenient and saves memory.

3: Why is a lib always generated during DLL compilation? Is this lib useful?

If we use a DLL instead of a static link, we also need a Lib, which is used to be linked to the program and tell the system what DLL file you need when running the program. The LIB stores the DLL name and the sequence table of the output function entry. It makes sense.

Of course, if our application does not link this Lib, we can use loadlibrary and getprocaddress to tell the system what DLL and its functions are needed during runtime.

4: DLL meaning.

1: DLL truly implements cross-language. Dll can be generated in various languages. For systems and applications, there is no difference in which language the DLL is generated.

2: dll has sufficient encapsulation, which is of great benefit for version updates. Because the DLL is used during running, the program does not need to be compiled even if the function implementation in the DLL changes (as long as the parameters and return values do not change. This greatly improves the efficiency of software development and maintenance.

3: DLL is used by multiple processes. Because of the memory ing mechanism, no more memory is needed.

5. Create a DLL. (Note: A log will not explain how to use the MFC Appwizard [DLL] method to create a DLL. If you are interested, go to Baidu. Creating a DLL here only means creating a non-mfc dll using Win32 dynamic-Link Library. Er, the three types of DLL will not be explained. You will know about Baidu .)

Each application must have a main or winmain function as the entry. Like DLL, there must be its own default entry function, which is dllmain. The function is as follows:

Bool apientry dllmain (hmodule, DWORD ul_reason_for_call, lpvoid lpreserved)
{
Switch (ul_reason_for_call)
{
Case dll_process_attach: // The process is called.
Case dll_thread_attach: // The thread is called.
Case dll_thread_detach: // The thread is stopped.
Case dll_process_detach: // The process is stopped.
Break;
}
Return true;
}

In general, we do not need to modify the default entry function, which will make the dynamic link library correctly initialized. However, when our DLL needs to allocate additional memory or resources, or when the DLL wants to initialize or clear the calling process or thread, you can add something you catch in the above Code case. (Lazy ...... I don't want to elaborate on--orz. Now it's, and there will be a bunch of things tomorrow)

The DLL does not have any difference between the export class and the export function. Just add the _ declspec (dllexport) modifier function or class.

However, people who have viewed the DLL code often see this piece of code.

# Ifdef fk_dll_exports

# Define fk_dll _ declspec (dllexport)

# Else

# Define fk_dll _ declspec (dllimport)

# Endif

It makes a lot of sense, but the problem is where should the fk_dll_exports macro be defined? In the DLL project or in the application that uses the DLL?

This blog has been confused for a long time ~ In fact, later I thought it was quite clear. Export is an export. Import is import. For DLL, these functions must be exported to other applications, so the fk_dll_exports macro should be defined. For applications that use DLL, it is imported and does not need to be defined.

It is easy to use.

Class fk_dll cmydllclass {};

The entire class is exported.

Fk_dll void mytestfun (int );

The function is exported.

But sometimes we can see such code

Extern "C" fk_dll void mytestfun2 (float B );

The principle of extern "C" indicates that the function must be compiled in the C form rather than in the C ++ form. The specific compilation principle is not too long. In short, functions defined by extern "C" can be called by DLL in C and other languages, but not defined by extern "C, C cannot access this function in DLL.

Another way to develop DLL in vs is to use the. Def file.

Create a new text document with the suffix fkdll. Def and add it to the project.

Add the following code to fkdll. Def:

Library fkdll

Exports

Mytestfun @ 1

Mytestfun2 @ 2

You can. The library statement indicates that the. Def file belongs to the fkdll. The name of the function to be exported under exports. The plus @ + number indicates the sequence number of the export function. This is enough. (Baidu in detail, so sleepy, Zzzzzz)

6. Use DLL

There are two methods to use DLL. Explicit and implicit links.

Implicit links are easy. Directly # progam comment (Lib, "fkdll. lib. Of course, you can also add libraries and paths in the project> Properties> link library (both relative paths and absolute paths are acceptable ).

Explicit link is more troublesome. Use loadlibrary in the program to load the DLL, and then getprocaddress to obtain the function implementation. Call freelibrary to release the Link Library dynamically before the program exits.

For example:

Void main ()

{

Typedef void (* fkdllfun1) (int );

Fkdllfun1 pfun1;

Hinstance hdll = loadlibrary ("fkdll. dll"); // If hdll is empty, the DLL cannot be read.

Pfun1 = (pfun1) getprocaddress (hdll, "mytestfun1"); // obtain the function pointer named mytestfun1 from the DLL image in the Application

Pfun1 (100 );

Freelibrary (hdll );

}

Of course, the export sequence of the export function is also specified in. Def, so we can modify the Section for getting the function pointer

Pfun1 = (pfun1) getprocaddress (hdll, makeintersource (1); // 1 is the export sequence number of the specified mytestfun1 function.

This can be faster, but do not confuse numbers, which may lead to strange errors.

7. Compare explicit and implicit links.

If possible, try to use explicit links.

Explicit links can dynamically load and unload DLL files during program execution. implicit links cannot.

Explicitly link loadlibrary. When getprocaddress is used, we can check whether the loading fails. We can handle the error. The explicit link may be a bad prompt or the result of a program crash.

For some ex-type enhancement functions, explicit links allow us to find an alternative. The same processing can also be used when d3d9. dll and OpenGL. dll are selected.

For example:

If (getprocaddress (hdll, "fkdllfunex") = NULL)

{

Pfun = getprocaddress (hdll, "fkdllfun"); // use pfun for processing

}

8: Export class and export Function

The export methods of classes and functions are described above. They are very similar.

Let's talk about using the Export class.

If we implicitly use an export class, we inherit it in the application, just like this class is in the application code, without any processing.

For example:

Class fk_dll cmydllclass {}; // code in the DLL file

-----------------------

Class cappclass: Public cmydllclass // code in the application, without any processing.

{

....

}

You can also use the DLL export class directly.

Void main

{

Cmydllclass * Pclass = new cmydllclass ();

}

However, if an application declares or categorizes the exported class objects in a DLL, this operation will invalidate the memory tracking system, reports memory allocation and release errors.

To solve this problem, we can provide two interface functions to create and destroy DLL export classes, so that the memory tracking system can be normal. For example

Class fk_dll cmydllclass {};

Two additional functions are added.

Fk_dll cmydllclass * createmydllclass () {return New cmydllclass ();}

Fk_dll void destorymydllclass (cmydllclass * p_pclass) {Delete p_pclass ;}

-----------------------------------------------

The above method can be used to track the memory correctly. However, because the DLL export class cmydllclass is still in the export status, you can skip the interface we provided and use it directly. So what should we do. Instead of exporting the class DLL, you can export all the functions in the class,

-----------------------------------------------

However, if you only provide the above two interface functions and all functions in the class, the functions can be implemented, but class inheritance cannot be implemented. If this class inheritance is important and must be open, you need to replace the original memory tracing program in the application with the new memory tracing program. Or use the following method. (See Module 9: complex issues)

-----------------------------------------------

Similarly, we can also find that exporting only functions in the DLL class without exporting the DLL class itself also has some advantages. Some functions that we do not want to know from the outside can not set export tags, this further protects the security of functions in the DLL.

9: complex issues.

If we use loadlibrary to explicitly load a DLL and try to call a class member function in an application, whether or not the function is declared in the header file, vs will give an "unresolved external symbol (unparsed external symbol)" error. Now we can change the inline function extension option in the project property to "only _ inline" or "any suitable. However, we may expect to disable the inline function extension when debugging the concatenation function. Another solution is to declare the function to be exported as a virtual function, for example

Class cmydllclass

{

Fk_dll virtual void mytestfun (int A) {dosomething ();}

// Use the above Code to replace fk_dll void mytestfun (int A) {dosomething ();}

}

There is an additional benefit to doing so. After the exported class member function is set to a virtual function, the class of the virtual function is declared in the application and can be inherited.

For example, if the above method is used, the application can inherit smoothly without requiring cmydllclass to be labeled as exported. (I do not know the principle. I hope that experts who are proficient in the underlying layer can help explain it .)

Class cappclass: Public cmydllclass // code in the application, without any processing.

{

....

}