Background knowledge of DLL
Static link and dynamic link
The current link target code (.Obj) If a function is referenced, it is not defined, the link program may solve this reference from the outside of the function by two ways:
Static link
The linker searches for one or more library files (standard library .lib) until the object module containing the reference function is found in a library, and then the linker copies this object module to the result executable (.exe) . The link program maintained all the references to the function, allowing them to point to where the program is now available.
Dynamic link
The link is also searching for one or more library files (enter .lib), when the input record of the reference function is found in a library, copy the input record to the result executable, generate a function of the function Dynamic link. Here, the input record does not contain a function of the code or data, but specifies a dynamic link library that contains the function code and the order number or function name of the function.
When the program runs, the Windows is loaded, and looks for any dynamic link that appears in the file. For each dynamic link, Windows is loaded into the specified DLL and map it to the virtual address space of the calling process (if there is no map). Therefore, the actual link between the call and the target function is not completed (static) when the link application is linked, and is the opposite, is completed by Windows (dynamic) when running the program.
This dynamic link is called a dynamic link when loading. There is also a dynamic link mode.
Dynamic link method
The method of the function in the link dynamic link library is as follows:
Dynamic link when loading (LOAD_TIME DYNAMIC LINKING)
As mentioned above. When Windows searches for the DLL to be loaded, press the following order:
Application Directory → Current Directory → Windows System Directory → Windows Directory → Path Environment Variable Specifies the path.
Running Dynamic Link (Run_Time Dynamic Linking)
The programmer uses LoadLibrary to load the DLL into memory and map the DLL to the virtual address space of the calling process (if a mapping has been mapping, add a DLL reference count). First, the LoadLibrary search for the DLL, the search order is like a dynamic link when loading. Then, use getProcessAddress to get the address of the output function in the DLL and call it. Finally, use Freelibrary to reduce the DLL reference count, when the reference count is 0, remove the DLL module from the current process of virtual space.
Enter the library (.lib): Enter the library with .lib as the extension, the format is Coff (Common Object File Format). The extension of the COFF standard library (static link library) is also .lib. Files in the COFF format can be viewed with Dumpbin. The input library contains the output function in the DLL or dynamic link information of the output data. When you create a DLL program with an MFC, a input library (.LIB) and dynamic link library (.dll) are generated. Output file (.exp) output files with .exp as extensions, contains information of output functions and data, and link programs use it to create a DLL dynamic link library. Image file (.map) image files are extension, including the following information: module name, timestamp, group list (each group contains forms such as step :: Offset start address, length, group name, Class name), public symbol list (form, address, symbol name, virtual address flash address, definition symbol. Obj file), entry point is like section :: Offset, a FixUp list. Lib.exe tools It can be used to create input libraries and output files. Usually, you don't have to use lib.exe, if the engineering goal is to create a DLL program, the link will complete the creation of the input library. More detailed information can be found in the MFC manual and documentation. Linkage Specification This refers to a link to a function (Procedure) link protocol with different programming languages. The link specification supported by the MFC is "C" and "C ". The default is the "C " specification. If you want to declare a "C" link function or variable, it is generally used as a syntax: #if defined (__ cplusplus) Extern "C" {#ENDIF // Function Declarations ... // Variable Declaration (variables declarations) #if defined (__ cplusplus)} #ENDIF All C Standard header files are used, so they are in C Environment can be used in the environment. Decoration name "C" or "C " function is identified by the modified name internally (compiled and linked). The modisle name is a string generated when the compiler is generated when the compile function is defined or the prototype. Some cases are necessary to use the modifier of the function, such as the output "C " overload function, constructor, the structure, the destructor, and call "C" or "C " function in the assembly code. Wait.
The modified name, class name, call agreement, return type, parameter, etc.
Call agreement
Calling Convention Decides the following: The stack order of the function parameters, pops the arguments by the caller or by the caller, and the method of generating a function modifier. MFC supports the following calls:
_CDECL Press the parameter from right to left, and pops up the argument by the caller. For "C" functions or variables, the modifier is in front of the function name. For the "C " function, it is different. If the modulation of the function void test (void) is _TEST; for the "C " global function that does not belong to a class, the modifier name is? Test @@ zaxxz. This is an MFC default call convention. Since the caller is responsible for popping the argument, you can define a number of non-number parameters, such as the Printf function. _Stdcall Press the parameters from right to left, which pops up the argument by the caller. For "C" functions or variables, the modulation name is prefixed, then the function name, then the number of the symbol "@" and parameters, such as the function INT FUNC (Int A, Double B) is _func @ 12. The "C " function is different. All Win32 API functions follow this agreement. _FastCall head two DWORD types or parameters accounting for less bytes are placed in ECX and EDX registers, and the other remaining parameters are pressed into the stack from right to left. By popping the parameters by the caller, the "C" function or variable, the modulation name is prefixed in "@", then the function name, then the number of the symbol "@" and parameters, such as the function int func (int A, Double B) is called @ func @ 12. For the "C " function, it is different. Future compilers may use different registers to store parameters. Thiscall is only applied to the "C " member function. The THIS pointer is stored in the CX register, the parameter is placed from right to left. Thiscall is not a keyword, so it cannot be designated by the programmer. Naked Call When using 1-4 call conventions, if necessary, the compiler generates code to save the ESI, EDI, EBX, EBP registers, generate code recovery of these registers when entering functions. Naked Call does not produce such a code. Naked Call is not a type modifier, so you must use _Declspec, as follows: __DECLSPEC (Naked) int function body_parameters {// function body} Obsolete call agreed that the original call agreement can no longer be used. They are defined as a calling agreement_stdcall or _cdecl. E.g:
#define callback __stdcall
#define winapi __stdcall
#define WinAPIV __CDECL
#define apientry WinApi
#define apiprivate __stdcall
#define pascal __stdcall
Table 7-1 shows a function name under several calls ("C " function in the table refers to the "C " global function, not a member function), the function original is Void CallType Test (Void), CallType Can be _cdecl, _fastcall, _stdcall.
Table 7-1 Monors under different calls
