What is the relationship between lib and dll?
From http://blog.sina.com.cn/s/blog_4b9b714a0100gzip.html
(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 included in it. 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, store 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 run, the program code is linked to the called function code, thus saving the memory resource. 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.
1. Three types of files must be noted during development and use of dll.
1. dll header file
It refers to the. h file indicating the output class or symbol prototype or data structure in dll. When other applications call the dll, the file must be included in the application's source file.
2. Import dll files
It is the file generated after the dll is compiled and linked. The main function is to introduce the file into the application when other applications call the dll. Otherwise, dll cannot be introduced.
3. dll file (. dll)
It is the real executable file when the application calls the dll runtime. After the dll application is compiled and linked, the. dll file exists. Only the. exe file and. dll file are available when the application program is running successfully. The. lib file and the dll header file are not required.
A dynamic link library (DLL) is an executable file used as a shared function library. Dynamic links provide a way for a process to call a function that does not belong to its executable code. The executable code of a function is located in a DLL, which contains one or more functions that have been compiled, linked, and stored separately from the processes that use them. DLL also helps to share data and resources. Multiple applications can simultaneously access the content of a single DLL copy in the memory.
The difference between dynamic and static links is that dynamic links allow executable modules (. dll file or. exe file) only contains the information required to locate the executable code of the DLL function at runtime. In a static link, the linker obtains all referenced functions from the static Link Library and puts the library together with the code into the executable file.
Using Dynamic Links instead of static links has several advantages. DLL saves memory, reduces swap operations, saves disk space, makes it easier to upgrade, provides after-sales support, and extends the MFC Library Class mechanism to support multi-language programs, and make it easy to create international versions.
The biggest difference between lib and dll files is in calling.
Dll can be static
Lib and DLL
From this chapter, my content will be specific to the Windows platform. In fact, this article can also be seen as a summary of my development experience in windows, because I decided to switch to Unix later.
The previous chapter describes compilation and link. It is very simple and should be put together in this chapter. Many single-speaking C ++ books are too academic. There is almost no reference to how to combine hundreds of source files in a real working environment. I guided the reader to step by step to see what is going on with lib and DLL.
The simplest C ++ program requires only one source file, which contains the following statements:
Int main () {return 0 ;}
Naturally, this program does not do anything.
When the program needs to do something, we will add more and more statements to the source file. For example, we will start to add code to the main function:
# Include <stdio. h>
Int main ()
{
Printf ("Hello world! \ N ");
Return 0;
}
Due to the limitation of human intelligence, when a function contains too many statements, it is not easy to understand. At this time, subfunctions are required:
# Include <stdio. h>
Void showhello ()
{
Printf ("Hello world! \ N ");
}
Int main ()
{
Showhello ();
Return 0;
}
In the same way, a source file contains too many functions, which is also hard to understand. People start to split multiple source files.
// Main. cpp
Void ShowHello (); // [1]
Int main ()
{
ShowHello ();
Return 0;
}
// Hello. cpp
# Include <stdio. h>
Void ShowHello ()
{
Printf ("Hello World! \ N ");
}
Add these two files to a VC project. They will be compiled separately and finally linked together. In the output window of the VC compiler, you can see the following information:
------------------ Configuration: hello-Win32 Debug --------------------
Compiling...
Main. cpp
Hello. cpp
Linking...
Hello.exe-0 error (s), 0 warning (s)
This shows their compilation link process.
Next, even if you do not know, you should guess that when there are too many source files in a project, it is hard to understand, so people think of a method: compile a part of the source file into a library file, that is, a lib file. When you want to use the function, you only need to link the lib file, instead of ignoring the original source file.
Create a static library project in VC, add the hello. cpp file, compile it, and generate the Lib file. Assume the file name is hello. Lib.
There are two ways to use this Lib for other projects:
1. Add hello. lib to the project option-> link-> Object/Library module.
2. Add a line of command to the source code.
# Pragma comment (Lib, "Hello. lib ")
Note that this is not part of the C ++ language, but a pre-processing instruction of the compiler, used to notify the compiler that a link to hello. Lib is required.
You can use either of the following methods based on your interests.
This lib file format can be briefly introduced. It is actually a collection of any OBJ files. The OBJ file is compiled and generated by the CPP file. In this example, the Lib file only contains one OBJ file. If multiple CPP files exist, multiple OBJ files are compiled and generated, the generated lib file also contains multiple OBJ,Note: This is just a set and does not involve link. Therefore, when compiling such a static library project, you will not encounter a link error.. Even if there is a mistake, the error will only be exposed in the EXE or DLL project using this Lib.
There is only so much content about static Lib. It's really easy.Now we will introduce another type of Lib, which is not a collection of OBJ files, that is, it does not contain actual implementations, it only provides the information required to dynamically link to the DLL. This lib can be generated by the compiler when compiling a DLL project. When DLL is involved, the problem becomes complicated. I don't expect to clarify the principle of DLL in this article. This is not the goal of this article. I will introduce the operation layer.
To put it simply, there are two differences between a DLL project and an EXE project:
1The EXE entry function is main or winmain, And the DLL entry function is dllmain.
2. The entry function of EXE indicates the start of a processing process. After the function exits, the process is completed. The entry function of DLL is just a pass for the system, when the DLL is loaded, it passes by once. When the DLL is uninstalled, it passes by [2]. You can perform process processing in the DLL entry function, but this is usually not the purpose of the DLL, DLL is used to export functions for other DLL or EXE. You can understand the relationship between DLL and exe as the relationship between main. cpp and hello. cpp. The implementation methods are different.
First, let's look at how to write a DLL and how to export the function. First, you should try to use VC to create a new dynamic link library project. If you do not select an empty project when creating the project, in this way, you can get an example to start working on the basis of this example.
Let's take a look at the header file in the example you created with a statement similar to this:
# Ifdef dll_exports
# Define dll_api _ declspec (dllexport)
# Else
# Define dll_api _ declspec (dllimport)
# Endif
This is all about function export and use of export functions. Your DLL project has defined a macro dll_exports in the Project Settings, so your function declaration only needs to add the dll_api to export it, And the DLL user does not define this macro, so when it contains this header file, it regards your function as imported. By imitating this example, you can write a series of functions marked as exported.
Another way to export a function is to use the def file and Def file, which only limits the function name. Here, we will introduce the second [4] Method of Using DLL: Display loading. Using the loadlibrary and getprocaddress functions of Windows API, we can implement [5]. here, the getprocaddress parameter requires a function name in the string format. If the def file is not used in the DLL project, you may need to use a very strange function name (such :? Fndll @ yahxz) can be called correctly. This is because the function name is reencoded by the function overload mechanism in C ++. If the def file is used, you can explicitly specify the function name before encoding.
With this knowledge, you can start to write some simple DLL applications, but I am sure that you will encounter a crash, and the previous non-DLL version is no problem. If you use DLL through explicit loading, it may be caused by inconsistent call conventions, resulting in a crash. The so-called call convention is to add _ stdcall _ cdecl and so on before the function declaration, note that some macros, such as WINAPI, will be defined as one of these qualifiers. It doesn't matter if you don't understand them, but remember to be consistent, that is, the Declaration is consistent with the definition, this is not a problem when using implicit loading, but it is possible that inconsistency may occur because the header file is not used for loading.
The call convention is not what I really want to talk about, although it is a possibility. I want to talk about the issue of memory allocation and release. See the following code:
Void foo (string & str)
{
Str = "hello ";
}
Int main ()
{
String str;
Foo (str );
Printf ("% s \ n", str. c_str ());
Return 0;
}
When the function foo and main are in the same project, or foo is in a static library, there is no problem, but if foo is a DLL export function, do not write it like this, it may lead to collapse [6]. The cause of the crash is that "one module is allocated and another module is released". DLL and EXE belong to two modules. In this example, the assignment operation in foo leads to memory allocation, however, after the return statement in main, the string object structure will cause memory release.
I don't want to mention all such situations. I just ask you to consider the issue of memory allocation and release when designing the DLL interface. Please follow the principle of who allocates and who releases the memory.
If you do not know how to design it, copy the Microsoft API, which is our common DLL interface, for example:
CreateDC
ReleaseDC
In pairs, one function is allocated with memory, and the other function is used to release the memory.
Back to the example where we may crash, how can we avoid it by modifying it?
This can be done as an exercise for readers. This exercise may take a long time. If you do a good job, you will be ready to work. I have seen at least two programmers with more than five years of experience make such a mistake.
Note [1]: for the purpose of illustration, I will use the direct declaration method here. In actual engineering, the header file should be used.
Note [2]: There are also threads to create and destroy will also pass the DLL entry, but this is of little significance to the novice.
Note [3]: the format of the DEF file is very simple. For the example of the DEF file, you can see it by creating an atl com project.
Note [4]: the first method is similar to using a static library, including header files and linked library files. Then, like using a common function, it is called implicit loading.
Note [5]: For details about the call method, refer to MSDN.
Note [6]: the possible reason is that if both projects are set to dynamically connect to the Runtime Library, the allocation and release are all performed in the DLL of the Runtime Library, in this case, no crash will occur.
: Http://blog.csdn.net/Albert_1030/archive/2008/10/15/3078120.aspx
Both dll and. lib are a set of programs to facilitate code reuse. Binary files.
. Dll is also called a dynamic link library. The link to the program is run-time linked, in the PE (portable executable) format, that is, the complete program .. Exe,. dll,. fon,. mod,. drv,. ocx and so on are all dynamic link libraries. For example, .exe is a set of functions called by the system .. The dll does not have a reference with the same name and has an export table as the import table.
. Lib is also called a static link Library. It links to the program during compilation and "embeds" it into the program. There will be redundancy (program file code redundancy and runtime memory storage redundancy). When two lib links, the address will be re-set up the same. Before using. lib, reference the header file. h corresponding to lib in the program source code. These header files tell the compiler. lib what is there.
A. lib is usually generated when. dll is generated. This. lib will be compiled into the program file, and the. dll to be loaded by the operating system will be told when the program is running. This. lib includes the file name of the corresponding. dll and the sequence table (ordinal table contains the entry point of the function exposed by. dll). When the program is running, function jump is implemented through the sequence table.
If you do not want to use or cannot find this. lib, you can use LoadLibrary () Win32 API and GetLibrary () Win32 API. (I do not know how to handle it for the time being :))
To implement program debugging, vc ide generates. PDB (Program database, binary), which contains the file information and row information called by the source file. In this way, you can debug the program line by line. (Not very clear :))
Open. lib and check its ascii code. You can see the function names @ My_Function1123. These names are compiled using mangling mechanisms? I do not know how to translate) mangling of the name is performed.
During program compilation, if the following error "unresolved symbol _ some_funtion @ 1234" occurs, it is usually because the referenced external function cannot be found. lib file, or. c ,. cpp source file.
If the. lib file written in c ++ is used, you need to reference it as follows:
Extern "C" {# include "headfile. h "} dll --- com component dll |||__ conventional dll ___ win32 dll ||___ mfc dll ||___ extended dll (all dll do not participate in compilation) lib | _____ the uncompiled symbol file is similar to the obj file. The difference with the obj file is that it declares the transfer function.
Reference a good article
Compare the dynamic libraries of Windows and Linux systems
Http://www.linux-cn.com/html/test/20070411/2287.html
Abstract: The concept of dynamic library exists in Windows and Linux systems. Dynamic library can effectively reduce the program size and save space, improve efficiency, increase program scalability, and facilitate modular management. However, because the dynamic libraries of different operating systems have different formats, dynamic library programs need to be transplanted when calling different operating systems. This article analyzes and compares the two types of dynamic operating system library technology, and provides the methods and experience for porting the dynamic library compiled by Visual C ++ to Linux.
1. Introduction
Dynamic Library (DLL) is a frequently used technology in programming. It aims to reduce the program size, save space, improve efficiency, and have high flexibility. It is easier to upgrade the software version by using the dynamic library technology. Unlike Static Link Library, functions in the dynamic Library are not part of the execution program, but loaded as needed, its Execution Code can be shared among multiple programs at the same time.
This method can be used in both Windows and Linux operating systems for software design, but their calling methods and programming methods are different. This article first analyzes the dynamic library calling methods and programming methods commonly used in these two operating systems, and then analyzes and compares the differences between the two methods, finally, based on the practical experience of the porting program, this paper introduces how to port the Windows dynamic library compiled by VC ++ to Linux.
2. Dynamic library technology
2.1 Windows dynamic library technology
Dynamic Link Library is used to implement Windows ApplicationsResource Sharing, memory saving, and improved efficiencyIs an important technical means. Common dynamic libraries include external functions and resources, and some dynamic libraries only include resources, such as Windows Font Resource files, which are called resource dynamic link libraries.Generally, the dynamic library uses. dll,. DRV,. Fon, and so on as the suffix. The Windows static library usually ends with. Lib.Windows implements some major system functions in the form of a dynamic library module.
The Windows dynamic library is loaded into the virtual space of the process at runtime, and the memory allocated from the virtual address space of the calling process becomes part of the calling process. Dll can only be accessed by the thread of the process. The DLL handle can be used by the calling process, and the call Process Handle can be used by the DLL. The DLL module contains various export functions to provide external services. Dll can have its own data segment, but does not have its own stack. It uses the same stack mode as the application that calls it; a DLL has only one instance in the memory; DLL implements code encapsulation;DLL compilation has nothing to do with specific programming languages and compilers. You can use DLL to implement mixed language programming.. Any object (including variables) created by the code in the DLL function is owned by the thread or process that calls it.
Based on different call methods, dynamic library calls can be divided into static call methods and dynamic call methods.
(1)Static call, also known as implicit callThe compilation system loads the DLL and the encoding of the DLL uninstallation when the application ends (the Windows system is responsible for counting the number of DLL calls). The Calling method is simple, can meet common requirements. The call method is usually to add the. LIB file generated when a dynamic Connection Library is generated to the project of the application. To use a function in the DLL, you only need to declare it in the source file. The LIB file contains the symbolic name and selectable Identification Number of each DLL export function and the DLL file name, excluding the actual code. The information contained in the Lib file enters the generated application. The called DLL file is loaded into the memory when the application is loaded.
(2) Dynamic callThe explicit call method is used by the programmer to load and uninstall the DLL using API functions to call the DLL,Complex but more effective memory usage is an important way to compile large-scale applications.. In Windows, functions related to dynamic library calls include:
① LoadLibrary (or AfxLoadLibrary of MFC) to load dynamic libraries.
② GetProcAddress: Get the function to be introduced and convert the symbol name or ID number to the internal DLL address.
③ FreeLibrary (or AfxFreeLibrary of MFC) to release the dynamic link library.
Creating a dynamic library in windows is also very convenient and simple. In Visual C ++, you can create a DLL program directly written in C language without using MFC, or create a DLL program based on the MFC class library. Each DLL must have an entry point. In VC ++, DllMain is a default entry function. DllMain is responsible for Initialization and Termination. The dynamic library output function also has two conventions, which are based on the call Convention and name modification convention.The functions defined by the DLL program are divided into internal functions and export functions. The functions exported by the dynamic library are called by other program modules.. Generally
Methods To export functions:
① Use the EXPORT part of the module definition file to specify the function or variable to be input.
② Use the modifier _ declspec (dllexport) provided by MFC ).
③ Use the/EXPORT command line to output related functions in the command line mode.
In a windows dynamic library, you sometimes need to write a module definition file (. DEF), which is a text file consisting of module statements used to describe the DLL attributes.
2.2 Linux shared object technology
In Linux, many Shared Object technologies are used. Although they correspond to dynamic libraries in Windows, they are not called dynamic libraries. The corresponding shared object file uses. so as the suffix. For convenience, this concept is not specifically distinguished in this article. There are many shared objects ending with so in the/lib of the Linux System and the/usr/X11R6/lib directory of the standard graphic interface. Similarly, in Linux, there is also a static function library call method, and the corresponding suffix ends with.. Linux uses the shared object technology to facilitate sharing between programs, save space occupied by programs, and increase program scalability and flexibility. Linux also allows developers to replace system modules with the modules in their libraries through LD-PRELOAD variables.
Like Windows systems, it is easier to create and use dynamic libraries in Linux. Just add the-shared option when compiling the source program of the function library, in this way, the generated execution program is a dynamic link library. Generally, such a program is suffixed with so. In the process of Linux dynamic library program design, the process is usually to write user interface files, usually. h file, compile the actual function file. c or. cpp is the suffix, and then write the makefile file. This can be avoided for smaller dynamic library programs, but this design makes the program more reasonable.
After the dynamic Connection Library is compiled and generated, it can be called in the program. In Linux, you can use multiple calling methods, the same as the Windows System directory (.. \ system32, etc.). You can copy the dynamic library file to the/lib directory or create a symbolic connection in the/lib directory for all users to use. The following describes functions frequently used in Linux to call dynamic libraries. However, when using a dynamic library, the source program must contain the dlfcn. h header file, which defines the prototype of the function used to call the dynamic link library.
(1) _ open the Dynamic Link Library: dlopen, function prototype void * dlopen (const char * filename, int flag );
Dlopen is used to open the dynamic link library with the specified name (filename) and return the operation handle.
(2) function execution address: dlsym. The prototype of the function is void * dlsym (void * handle, char * symbol );
Dlsym returns the Execution Code address of the function corresponding to the symbol Based on the handle and symbol of the dynamic link library.
(3) Close the Dynamic Link Library: dlclose. The function prototype is int dlclose (void * handle );
Dlclose is used to close the dynamic link library of the specified handle. It will be uninstalled only when the usage count of this dynamic link library is 0.
(4) dynamic library error function: dlerror. The prototype of the function is const char * dlerror (void). When the dynamic link library operation function fails to be executed, dlerror can return error information, if the return value is NULL, the operation function is successfully executed.
After obtaining the function execution address, you can call the functions in the dynamic library according to the function interface declaration provided by the dynamic library in the Use Program of the dynamic library. When compiling the makefile file of the program that calls the dynamic library, you must add the compilation options-rdynamic and-ldl.
In addition to writing and calling dynamic libraries in this way, the Linux operating system also provides a more convenient dynamic library calling method, which also facilitates the calling of other programs, this method is similar to the implicit link in Windows. The dynamic library name is "lib *. so .*". In this naming method, the first * indicates the name of the dynamically linked library, and the second * indicates the version number of the dynamic library. In this call method, you need to maintain the configuration file/etc/ld of the dynamic link library. so. conf to make the dynamic link library used by the system. Usually, the directory name of the dynamic link library is appended to the dynamic link library configuration file. If the file has an X window System release version, the file has/usr/X11R6/lib, which points
The Directory of the dynamic link library of the window system. To make the dynamic link library shared by the system, you also need to run the management command./sbin/ldconfig of the dynamic link library. When compiling the referenced dynamic library, you can use the-l or-L option in gcc or directly reference the required dynamic link library for compilation. In Linux, you can use the ldd command to check the program dependency shared library.
3. Comparison and Analysis of Dynamic libraries of the two systems
Windows and Linux use the dynamic link library technology for the same purpose, but because of the different operating systems, they are still different in many aspects. The following describes the following aspects.
(1) dynamic library programming. In Windows, the execution file format is PE, and the dynamic library requires a dllmain function as the initial population, the _ declspec (dllexport) keyword is usually required when exporting the function declaration. In Linux, the GCC compiled execution file is in the ELF format by default. It does not require initialization entry, nor does it need to make special comments on functions. This is easier to compile.
(2) dynamic library Compilation: in windows, there is a convenient debugging and compilation environment. You do not need to compile makefile files on your own. But in Linux, You need to compile makefile files by yourself, therefore, you must master certain makefile writing skills. In addition, the Linux compilation rules are usually relatively strict.
(3) For dynamic library calling, both Windows and Linux can use explicit or implicit calling for the dynamic library, but the specific calling methods are also different.
(4) view the dynamic library output function. In Windows, there are many tools and software that can be used to view the functions output in the DLL, for example, the command line dumpbin and the depends program in the VC ++ tool. In Linux, nm is usually used to view the output function. You can also use LDD to view the shared object files implicitly linked by the program.
(5) dependency on the operating system. The two dynamic libraries depend on their respective operating systems and cannot be used across platforms. Therefore, dynamic libraries that implement the same functions must provide different dynamic library versions for two different operating systems.
4. Dynamic library migration method
If you want to compile a dynamic link library that can be used in both systems, the initial development is usually completed in the debugging environment provided by Windows VC ++, after all, the graphical editing and debugging interfaces provided by VC ++ are much more convenient than vi and GCC. After the test is completed, the dynamic library program is transplanted. Generally, the default GCC compilation rules are more strict than the default compilation rules of VC ++. Even if there are no warning errors under VC ++, many warning errors may occur in GCC debugging, you can use the-W option in GCC to disable the warning error.
The following describes the rules and experiences to be followed for program porting.
(1) Try not to change the sequence of original dynamic library header files. Usually in the C/C ++ language, the sequence of header files is quite related. In addition, although the C/C ++ language is case sensitive, Linux must be the same as the header file when the header file is included, because the ext2 file system is case sensitive to the file name; otherwise, the file cannot be compiled correctly, in Windows, the header file can be correctly compiled in case.
(2) Unique header files of different systems. In Windows, the windows. h header file is usually included. If the underlying communication function is called, The winsock. h header file is included. Therefore, when porting to a Linux system, You Need To comment out the header files unique to these Windows systems and some constant definitions for some windows systems, and add header files supported by all underlying Linux communications.
(3) data type. VC ++ has many unique data types, such as _ int16 ,__ int32, TRUE, SOCKET, etc. They are not supported by the gcc compiler. The general practice is to copy the statements defined for the data in windows. h and basetypes. h to a header file, and then include the header file in Linux. For example, you can change the SOCKET type to int.
(4) keywords. In VC ++, there are many keywords not used in standard C, such as BOOL, BYTE, DWORD, __asm, and so on. They are usually used as far as possible to facilitate transplantation, if it is unavoidable, you can use # ifdef and # endif to write two versions for LINUX and WINDOWS.
(5) modify the function prototype. Generally, if you use a standard dynamic library written in C/C ++, you do not need to rewrite the function. However, because of the differences between the two systems, you need to change the call method of the number of letters. For example, in the dynamic network communication library compiled by Linux, use the close () function instead of the closesocket () function in the windows operating system to disable the intercept. In addition, there is no file handle in Linux. To open the file, you can use open and fopen functions. For the usage of these two functions, see [2].
(6) Write makefile. In windows, the VC ++ compiler is usually responsible for debugging. However, gcc requires you to compile the makefile file by yourself. You can also refer to the makefile file generated by VC ++. For dynamic library migration, you must add the-shared option when compiling the dynamic library. For programs that use mathematical functions, such as idempotence,-lm must be added when a dynamic library is called.
(7) other notes
① Program design structure analysis is an essential step for porting the dynamic library program compiled by another user. Generally, the dynamic library program does not contain operations such as interfaces, so it is relatively easy.
② In Linux, permissions on files or directories are divided into owners, groups, and others. Therefore, when accessing a file, pay attention to whether to perform read or write operations on the file. If you perform write operations on the file, pay attention to the permission to modify the file or directory. Otherwise, the file cannot be written.
③ When using a pointer, define a pointer to allocate only four bytes of memory to it. If you want to assign a value to the variable pointed to by the pointer, you must use the malloc function to allocate memory for it or define it as a variable without defining it as a pointer. This is more rigorous than windows compiling in linux. Similarly, a structure cannot contain values in a function. If you want to transmit values in a structure in a function, you must define the structure in the function as a structure pointer.
④ Path identifier, which is "/" in Linux and "\" in Windows. Note that dynamic library search paths are different in windows and Linux.
⑤ Programming and debugging skills. There are different debugging skills for different debugging environments, which are not described here.
5. Conclusion
This article systematically analyzes the implementation and usage of dynamic libraries in windows and Linux, this article comprehensively analyzes and compares the differences between the two call methods in terms of programming, compilation, calling, and operating system dependencies. Based on the actual program porting experience, the methods for porting a Windows dynamic library compiled by VC ++ to Linux and the issues needing attention are given. At the same time, the sample program snippets are provided, because of the system design and other aspects, it may be far more complicated to be transplanted than above. This article summarizes and summarizes these aspects to provide interesting experiences and skills for program transplantation of different operating systems.