Detailed description of static. shared rules mfc dll/MFC extension DLL

Introduction: when compiling the MFC Program Usually, you need to write a dll library for other programs to call. There are a lot of mixed knowledge about the mfc dll. Here, cool specially compiled some basic knowledge about the mfc dll Based on the problems encountered in the study. This section consists of two parts: Article This article is the first article. There are three types of mfc dll applications:
(1) Use the shared mfc dll rule DLL
(2) Rule DLL with static link MFC
(3) MFC extension DLL
The following describes the differences in the definitions of these DLL values:
1. Rule DLL
First, let's talk about the so-called "rule DLL": "rule DLL" is translated by "regular DLL. It actually represents the essence of two aspects:
(1) The DLL is based on MFC;
(2) This dll is a "rule", which is different from "MFC extension DLL". Although it can be used internally in the Rule DLL, however, the interface for rule dll should not be based on MFC. The MFC extension DLL and application interface can be MFC, and a derived class of MFC can be exported from the MFC extension DLL.
Generally, we use the rule DLL, because "rule DLL" can be provided to call interfaces in all languages that support the DLL technology. In rule DLL, there is a class inherited by cwinapp. The DLL entry function is automatically provided by MFC and encapsulated by MFC. Such DLL programs are derived from cwinapp, but there is no message loop:
The following describes the two categories of "rule DLL" in detail:
(1) Use the rule DLL that shares the mfc dll;
"Shared mfc dll rule DLL" is a library that does not contain MFC after compiling an MFC-Based DLL program, such as mfc42.dll, instead, it dynamically links to the MFC library when the DLL is running. This method is slightly larger than the compilation of "rule DLL with static link MFC. Therefore, when the "share mfc dll rule DLL" DLL is released, if the library of MFC is not installed on the other machine, the DLL cannot run, unless you also share the MFC library with him, the biggest difference between "share the mfc dll rule DLL" and "rule DLL with static link MFC" is that you use the MFC method.
It is precisely because of these characteristics of "sharing the mfc dll rule DLL" that, when the system loads this type of DLL, it involves loading multiple DLL files, if a resource with the same ID exists in the DLL and application, the system cannot correctly distinguish the programmer's intent. Therefore, to use the "share mfc dll rule DLL", we need to find the correct resource module through module switching and perform corresponding operations.
Switch the module of "share the mfc dll rule DLL:
Before explaining this problem, let's take a look at the internal running mechanism of the DLL:
The application process itself and each DLL module it calls have a globally unique hinstance handle, which represents the starting address of the DLL or EXE module in the process virtual space. The module handle of the process is generally 0x400000, and the default handle of the DLL module is 0x10000000. If the program loads multiple DLL files at the same time, each DLL module has a different hinstance. When the application loads the DLL, It is relocated.
The rule DLL that shares the mfc dll (or the MFC extension DLL) involves the hinstance handle issue. The hinstance handle is particularly important for loading resources. Both EXE and DLL have their own resources, and the IDs of these resources may be repeated. The application needs to find the correct resource by switching the resource module. If the application needs DLL resources, you should specify the resource module handle as the DLL module handle. If you need resources contained in the EXE file, the resource module handle should be specified as the module handle of exe.
To complete the module switching, the following statements must start with all the functions output from the DLL:
Afx_manage_state (afxgetstaticmodulestate ())
This sentence is used to correctly switch the status of the MFC module. Note:
Its function is to create an afx_module_state class instance on the stack (which means its scope is partial) and return its pointer pmodulestate.
The afx_module_state class uses its constructor and destructor to perform on-site and recovery of the storage module status.
This macro is used to set the pmodulestate to the current valid module status. When the macro's scope is left (the scope of the object on the stack indicated by pmodulestate is also left), the previous module state will be restored by the destructor of the afx_module_state class.
(2) Rule DLL with static link to MFC;
This is not to mention, it is to compile the mfc dll to its own internal DLL type, it is not hard to understand the comparison of "using the shared mfc dll rule DLL;
(3) Call conventions and name modification in Rule dll:
A call convention is a standard convention for a program to pass parameters to a function and receive returned values. It is a standard protocol established to realize function calls, this Protocol specifies the parameter transfer method in the function of the language, whether the parameter is variable, and who handles the stack. Different Languages define different call conventions.
In C ++, in order to allow Operator Overloading and function overloading, the C ++ compiler often rewrite the symbol names of each entry point according to certain rules, so that the same name (with different parameter types or different scopes) can have multiple usages without breaking the existing C-based linker. this technique is usually called name mangling or name decoration ). many C ++ compiler vendors have chosen their own name modification schemes.
Therefore, to enable modules written in other languages (such as Visual Basic applications, Pascal or Fortran applications) to call the DLL functions written in C/C ++, you must use the correct call conventions to export the function, and do not have the compiler modify the name of the function to be exported.
Call conventions are used to process the order of incoming and outgoing stacks when function parameters are transferred (by the caller or by the caller to bring the parameter to the stack ), the compiler is used to identify the name modification conventions of function names. microsoft Vc ++ 6.0 defines the following call conventions:
1 ,__ cdecl
_ Cdecl is the call Convention used by C/C ++ and MFC programs by default. You can also add the _ cdecl keyword when declaring a function. when _ cdecl is used, function parameters are pushed to the stack in the order from right to left, and the caller pops up the parameter stack to clear the stack. therefore, a function that implements variable parameters can only use this call convention. every function using the _ cdecl Convention must contain Code The size of the generated executable file is relatively large. _ cdecl can be written as _ cdecl.
2. _ stdcall
_ Stdcall is used to call Win32 API functions. when _ stdcal is used, function parameters are written to the stack in the order from right to left. The called function clears the stack of the transfer parameter before returning, and the number of function parameters is fixed. because the function body knows the number of passed parameters, the called function can directly clear the stack of the passed parameters with a RET n command before returning the result. _ stdcall can be written as _ stdcall.
3. _ fastcall
_ Fastcall conventions are used for scenarios with high performance requirements. _ fastcall: The two DWORD parameters starting from the left of the function are placed in the ECX and EDX registers respectively, the other parameters are still transmitted from the right to the left pressure stack. The called function clears the stack of the transfer parameter before returning. _ fastcall can be written as _ fastcall.
Note: The keywords _ cdecl, _ stdcall, and _ fastcall can be directly added before the function to be output, or in the setting environment... -> C/C ++-> code generation item selection. their corresponding command line parameters are/GD,/GZ, And/GR. the default status is/GD, that is, _ cdecl. when the keywords added before the output function are different from those selected in the compiling environment, the keywords directly added before the output function are valid.

(4) Other descriptions of Rule dll:
1. The DLL program entry point is dllmain.
Dllmain is responsible for initialization and termination. Whenever a new process or a new thread of the Process accesses the DLL, or when every process or thread accessing the DLL no longer uses the DLL or ends, it will call dllmain. However, using terminateprocess or terminatethread to end a process or thread does not call dllmain.
The dllmain function prototype meets the requirements of dllentrypoint and has the following structure:
OOl winapi dllmain (handle hinst,
Ulong ul_reason_for_call, lpvoid lpreserved)
{
Switch (ul_reason_for_call ){
Case dll_process_attach:
...
Case dll_thread_attach:
...
Case dll_thread_detach:
...
Case dll_process_detach:
...
}
Return true;
}
Where:
Parameter 1 is the module handle;
Parameter 2 refers to the class for calling dllmain. Four values are as follows: the new process needs to access the DLL; the new thread needs to access the DLL; a process no longer uses the DLL (detach from DLL ); A thread no longer uses DLL (detach from DLL ). Parameter 3 is retained.
If the programmer does not specify dllmain, the compiler uses its own dllmain. This function only returns true.
The rule DLL application uses the dllmain of MFC, which calls the initinstance function and exitinstance function of the DLL Application Object (derived from cwinapp.
The extension DLL must implement its own dllmain.
Of course, you must note that the mfc dll has hidden the dllmain. Its Initialization is actually an initinstance () function based on the cwinapp class.
The global variables defined by dll can be accessed by the calling process; The dll can access the global data of the calling process. Each process using the same dll has its own DLL global variable instance. If multiple threads concurrently access the same variable, you need to use the synchronization mechanism. For a DLL variable, If you want each thread that uses the DLL to have its own value, the local thread storage should be used (TLS, Thread Local strorage ).
DLL output function method:
(1) Specify the function or variable to be input in the export part of the module definition file.
(2) Use the modifier _ declspec (dllexport) provided by MFC );
To output the entire class, use _ declspec (_ dllexpot) for the class. to output the member function of the class, use _ declspec (_ dllexport) for the function ). For example:
Class afx_ext_class ctextdoc: Public cdocument
{}
Extern "C" afx_ext_api void winapi initmydll ();
(3) specify/Export command line parameters for the link program Link and output related functions.
The second method is recommended.
Ii. MFC extension DLL

The similarities between the MFC extension DLL and the MFC rule DLL are that the MFC class library can be used inside the two DLL types. The difference is that the interface between the MFC extension DLL and the application can be MFC. MFC extension DLL refers to the extension of MFC. Its main function is to generate reusable classes from existing MFC library classes. The MFC extension DLL uses the MFC Dynamic Link Library version. Therefore, only the MFC executable files (application programs or rule DLL) generated using the shared MFC version can use the MFC extension DLL. Such DLL is rarely used.

 

This article from teku bar http://www.tekuba.net/, the original address: http://www.tekuba.net/program/210/