A garbage article written in the Daxia, the deletion in the disk, finally put a body here, it is also a testimony of a life ...
Generalism
With the expansion of the software size, a system can no longer be maintained by one or a few people from the head to the end, and modular design has become a consensus of the industry.
Maybe it's a module, you will think of Class, indeed, the class is a module, but it is just a module created. Each time you modified a small module, it will lead to re-all other modules. Compilation. Perhaps for your current, this recompile is just a short stay, however, when you are no longer a small job, but develop a large system with others, especially When the system is subsequently tested, you will find that the compilation of more than half an hour can give you enough reason.
The DLL is another module that is a running module. You can package classes into a small DLL, a piece of block test, and finally put them together. This is not only the selection of time, but also many modules with strong scalability can also be posted to others, of course, you can also get a DLL module with a feature from others to save development time and cost. You can see a pile of DLL in many large software, which is undoubtedly evidence of its strong vitality. Of course, the files that come with an application should be, the better, otherwise, the application will open hundreds of disk files, and no one can stand.
Just as the kind of fear psychology when I get in contact with WinMain, many people are in the face of DLLs. In fact, it is no difficulty in writing a DLL, and MFC has a good support for the DLL. Well, ok, I don't say much, let us start the journey.
DLL technology foundation
You should understand how the DLL works before you describe how to write a DLL.
The DLL is behaving in a disk, which cannot be launched by themselves. You can only wait for others to call it - or more specifically, load it to call the data and functions stored in it. If you want to use a DLL, you must map them to the address space of the application process. This is an obvious thing, the DLL is like a mercenary, if you want to let it sell for you, at least you should load it to you. Come in the army (process address space). Please note that once the DLL is transferred, only one page is retained in memory, no matter how much to them, it is just like EXE, it is a brand new space. The real space of the DLL is certain, which is also beneficial to memory savings. If you want to know more about DLL, see "Advanced Windows" in Jeffrey Richter (Chinese version) Machinery Industry Press)
DLL connection
DLLMAIN is the entrance to the DLL, you can make it more than Winmain. Dllmain is called when connected to the process and disconnects and other responses. If there is no it, we will not do anything. For details, refer to "Windows Core Programming".
DLL can be implicit or explicitly connected to the process. In the DLL contains an export function table, when the client is loaded into the DLL, you can get these functions through the symbolic name of the function, and then get the address within the DLL module through the function table, which will pass through these address call functions.
In the DLL, we declare that the function FUN is to be exported by the following ways:
EXTERN "C" __DECLSPEC (DLLEXPORT) INT FUN ();
Since some DLLs need to call other DLL functions, some DLLs also set import: extern "c" __declspec (dllimport) int fun2 ();
If we want to use the function you have exported to the DLL, you need this:
EXTERN "C" __DECLSPEC (DLLIMPORT) INT FUN ();
Of course, it is necessary to add a lib file generated with the DLL to the project, and "the client must call a function in the DLL export function". The DLL export symbol is recorded in the lib file, only which functions to call it can be called. When the link is compiled, these symbols in the lib are matched and bind to the exe file, and EXE saves the DLL file name in lib. When the program starts running, Exe goes to the following places to find the DLL and load, and then dynamically link the functions in the DLL at runtime:
1. The directory where the current running process exe
2, the current directory of the process
3, Windows System Directory (System / System32)
4, windows catalog
5, the directory listed in the PATH environment variable
Explicit connection does not require a lib file, call LoadLibrary ("DLL path name) directly. as follows:
Hinstance hinst;
Hinstance = loadLibary ("DLL path name";
If you want to use a function that is exported to DLL, you need to do this now:
Sortproc * pfun;
PFUN = (Sortproc *) GetProcaddress (Hinstance, "Fun");
INT RET = (* pfun) ();
The advantage of explicit connection is that DLL can be loaded at any time as needed, while implicit connections are loaded all DLLs at the beginning.
Use MFC to do DLL
Regular DLL and extended DLL
The MFC's AppWizard provides two support: extended DLLs and regular DLLs. Regular DLL can be loaded by any Win32 development environment, but it can only export the C style function, and cannot export the C class, member function or overload function, but we can use these things in the regular DLL.
The extended DLL can export the entire C class, but it requires a relatively high: First, the customer program must dynamically link to the MFC library, and the extension DLL to be used to the same version of the MFC DLL.
An example of a regular DLL
When you create a regular DLL, you can select a static or dynamic (using the MFC Shared DLL) to link to the MFC library. If a static link is selected, the DLL will include all the copy of the MFC library code it needs, so that a DLL will be relatively large, but can be used independently, no longer need to consider whether the operating environment will have MFC support. Small using shared MFC DLL, but must ensure that there is a corresponding MFC DLL on the client machine.
Below is a DLL example that generates uses the MFC shared DLL.
Click to complete, mainly generated a stddll.h and a stdddll.cpp.
Now, add the functions we want to export in stddll.cpp, assume that it is a square function:
Extern "C" __DECLSPEC (DLLEXPORT) INT DLLFUNCTION (INT VAL)
{
AFX_Manage_State (AfxgetStaticModuleState ()); // Note this must have
Return Val * Val;
}
Below we need to test this DLL, create a new MFC dialog project:
Note Here you must choose to share the DLL.
Now we add three controls for this dialog: a button, two edit boxes. Then set the control as follows: Control ID
data
function
IDC_Click
Onclick
IDC_IN
M_IINPUT
IDC_OUT
m_ioutput
First we have to import DLLFunction, add: TestDLDLG.H file:
EXTERN "C" __DECLSPEC (DLLIMPORT) INT DLLFUNCTION (INT VAL)
Write the onclick function as follows:
Void ctestdlldlg :: onclick ()
{
// Todo: Add Your Control Notification Handler Code Here
Updatedata (TRUE);
m_ioutput = dllfunction (m_iinput);
Updatedata (FALSE);
}
Ok, under the compilation, it is not successful, huh, we haven't told MFC to find a DLL, what should I do? First copy the stddll.dll and stddll.lib files under the DEBUG folder of the DLL project, stddll.dll is placed in the system folder (98 / Me under Windows / System folder, NT / 2000 / XP Put it under Winnt / System32 folder), stddll.lib is placed under the DEBUG folder of the current TestDLL project and then makes the following settings, find "Settings" under the Project menu:
Add that in "Object / Library Module", here is the path to the relative project folder, if you use other engineering settings, just need to add relative to the corresponding .dsp files relative to the project. The path can be.
The following run should be successful, the result is as follows:
Summarize, the task of DLL is to complete:
1. Generate a regular DLL project.
2. Add the required functions in the format in the CPP file.
The task of the EXE party is to complete:
1. Complete the call to the function in the DLL in the CPP file.
2. Declare the function to be exported by __Declspec (import) in the corresponding H file corresponding to the CPP.
3. Complete the settings to the LIB path, and the most important, copy the DLL to EXE to find it.
In fact, in the above example, you can completely disconnect the DLL file to the system directory, but copy it to the Debug folder of the TestDLL project, because the Exe file generated by the TestDLL project is definitely there, so that the DLL will definitely EXE can be found. If you are interested, you can also copy the DLL copy to another place.
An example of an extended DLL
Run AppWizard to generate the MFCAppWizard (DLL) in Projects, then select the MFC Extension DLL (MFC Extension DLL) in the following dialog. Figure:
Then, the following code is mainly produced and a DEF file:
// EXTDLL.CPP: Defines The Initialization Routines for the DLL.
//
#include "stdafx.h"
#include
#ifdef _Debug
#define new debug_new
#undef this_file
Static char this_file [] = __file__;
#ndifstatic AFX_EXTENSION_MODULE EXTDLLLLL = {null, null};
EXTERN "C" int Apientry
Dllmain (Hinstance Hinstance, DWORD DWREASON, LPVOID LPRESERVED)
{
// Remove this if you use lpreserved
Unreferenced_Parameter (LPRESERVED);
IF (dwreason == DLL_PROCESS_ATTACH)
{
Trace0 ("Extdll.dll Initializing! / N");
// Extension DLL One-Time Initialization
IF (! AfxiniteXtensionModule (ExtdllDll, Hinstance))
Return 0;
// Here I deleted the comment
New cdynlinklibrary (EXTDLLDLL);
}
Else IF (dwreason == dll_process_detach)
{
Trace0 ("Extdll.dll Terminating! / N");
// Terminate The Library Before Destructors Are Called
AfxterMextensionModule (EXTDLLDLL);
}
Return 1; // ok
}
Add new categories: extclass.h and extclass.cpp, add the following code in EXTCLASS.H:
#pragma overce
#ifdef _windll
#define dll __declspec (dllexport)
#ELSE
#define DLL
#ENDIF
Class DLL Cextdll
{
BOOL M_INUM;
PUBLIC:
Cextdll ();
~ Cextdll ();
Void DllMessageBox (LPSTR pszstring);
Void Func (INT I);
int ReturnVal ();
}
Add: in .CPP:
#include "stdafx.h"
#include "extclass.h"
Cextdll :: Cextdll ()
{
m_inum = 255;
}
CEXTDLL :: ~ Cextdll ()
{}
Void Cextdll :: DllMessageBox (LPSTR PSZString)
{
AfxMessageBox (pszstring);
}
Void Cextdll :: Func (INT i)
{
m_inum = i;
}
Int Cextdll :: ReturnVal ()
{
Return M_INUM;
}
Then compile, get .LIB and .dll file.
Then create a dialog-based project TESTEXTDLL and the setting is basically the same as TestDLL. Then do the following settings:
1. Add a edit box control to add the member variable Int type M_INUM with Class Wizard.
2, add events for the determination button: Write the following code in TESTEXTDLLDLG.CPP:
First, write one sentence:
#include "extclass.h"
This .h file should be copied from the original copy of the EXTDLL project.
Then add code to ONOK:
Void ctestextdlldlg :: onok ()
{
// Todo: Add extra validation here
Updatedata (TRUE);
// Note the following sentence to complete the call to the DLL
Cextdll ADLL;
Adll.dllMessageBox ("Hello:) !!");
ADLL.FUNC (88);
m_inum = adll.Returnval ();
Updatedata (FALSE);
}
3, then generate the EXTDLL project. LIB and .DLL files are processed as follows:
3A, copy to the DEBUG folder of the current TESTEXTDLL project
3B, in the Project-Set-Link tab, add Debug / Extdll.lib to "Object / Library Modules".
Finally compiled, the results are as follows:
It is not very difficult to look.
Here we have finished the basic ideas of MFC DLL, if you still have questions about the DLL, please refer to the "Visual C Technical Inside" (Tsinghua University Press) and other classical textbooks.
