Programming on DLL in VC
Many dynamic connection libraries can often be seen when we actually use software. Dynamic connection libraries have their own advantages such as memory, support multi-language, and other functions, and when the function in the DLL changes, as long as it is not the function of the parameter change, it is not necessary to recompile. This is useful when programming. As for other wishes, you can see in computer magazine, books, I am talking about nonsense here. How do I have to do my own Win32 DLLS in VC5.0, you have to do your own Dynamic connection library, first, know what kind of classification of DLLs in VC5.0. VC supports three kinds of DLLs, which are: 1.non-mfc dlls2.regular DLLS3.EXTENSION DLLS NOTE: Improper translation wording, so the term is incorporated by reference correct word Non-MFC DLL: Refers to the class library structure without MFC, Directly written directly with C language, the function of its output is generally used as a standard C interface and can be called by an application written by non-MFC or MFC. LL, Regular DLL: Like the Extension DLLs described below, it is written in the MFC class library. Obviously, there is a class inherited CWINAPP in the source file. It can also be subsequently connected to the MFC and dynamically connected to the MFC. But static connection to MFC dynamic connection libraries are only supported by VC's professional and enterprise version. Extension DLL: Used to achieve the reuse of classes inherited from the MFC, that is, with this type of dynamic connection library, can be used to output a class inherited from the MFC. The Extension DLL is created using the MFC's dynamic connection versions, and it is only called by the application written by the MFC class library. Everyone sees this is a little dizzy if it is a little flower, please don't be discouraged, then watch it twice, then continue to see it, it is gains. Title: About the DLL of the VC [1] This section describes the writing methods of the NON-MFC DLLS. The following is a generic wording: BOOL APIENTRY DllMain (HANDLE hModule, DWORD 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;} Every DLL must have an entry point, just like the application we write with C, there must be a Winmain function. In this example, DllMain is a default entry function, you don't need to write your own DLL entry function, and declare the parameter switch / entry declared with the command line of Linker. With this default entry function, you can get the correct initialization when the dynamic connection library is called. Of course, you don't fill in the code that crashes the system when you initialize. In the parameter, hmoudle is a handle that is passed when the dynamic library is called (actually, it is a selector pointing to the _dgroup segment) ul_reason_for_call is a sign of the cause of the dynamic library. When a process or thread is loaded or unloaded, the operating system calls the entry function and describes the reason why the dynamic connection library is called. All possible values: DLL_PROCESS_ATTACH: The process is called DLL_THREAD_ATTACH: The thread is called DLL_PROCESS_DETACH: The process is stopped DLL_THREAD_DETACH: The thread is stopped LPRESERVED is a parameter reserved by the system. The entrance function has been written, and it is not difficult, you can join the function or variable or C class you want to output in the file or, or, or,? It seems that there are more parts.
Look here! Now you will join a new output function: void _declspec (DLLEXPORT) JUSTSOSO () {MessageBox (Null, "It's so easy!", "Haha ...", MB_OK);} To output A class is also possible, as follows: class _declspec (dllexport) Easy {// add your class definition ...}; you must notice that the output function or class is used to use _Declspec (dllexport), this is a VC provided by the VC Keywords, use it to output a data, a function or a class in a dynamic connection library. Use this keyword to save a lot of things, you don't have to explain this class in the .def file, that function. OK! Try to knock on the examples, Just So Easy! Let's talk about this sender: Dragon (Dragon), the letter area: VC Title: About DLL programming in VC [2] The Non-MFC DLL has a method of calling a DLL now. The call to the DLL is divided into two, one is an explicit call, one is implicit call. The so-called explicit call means that the AFXLOADLIBRARY explicitly supplied with LoadLibrary or MFC in the application, the file name of the dynamic connection library is the parameter of the two functions, and then use GetProcAddress () Get the function you want to introduce. Since then, you can call this introduction function like using a function of using a customized function as this application. Before the application exits, the AFXLOADLIBRARY to release the dynamic connection library with Freelibrary or MFC. Implicit calls need to add the .lib file generated when generating a dynamic connection library to the application. When you want to use the function in the DLL, you only need to explain the following, as follows: Description of the output function void Justsooso () Implicit calls don't need to call loadLibrary () and freelibrary (). This seems that the method of implicit instructions is relatively simple, but the DLL changes, the application must be compiled from the new. Also, all the calling DLLs are loaded into memory while the application is loaded, but the DLL that the application calls is more slower, the process of loading is very slow. Implicit calls, the application doesn't know the DLL or implicit calls you want to load. At this time, allow the user to specify the dynamic connection library to be loaded, more flexible sender: Dragon (Dragon), the letter area: VC title : About the programming of the DLL in the VC [3] Regular DLL can be called by the application written by all languages that support DLL technology. In this dynamic connection library, it must have a class that inherited from cwinapp, and the DLLMAIN function is provided by the MFC without its explicit writing.
Here is an example: // MyRegularDll.h: main header file for the MYREGULARDLL DLL # include "resource.h" // main symbolsclass CMyRegularDllApp: public CWinApp {public: CMyRegularDllApp (); // Overrides // ClassWizard generated virtual function overrides // {{AFX_VIRTUAL (CMyRegularDllApp) //}} AFX_VIRTUAL // {{AFX_MSG (CMyRegularDllApp) // NOTE - the ClassWizard will add and // remove member functions here.// DO NOT EDIT what you see in these blocks // Of generated code! //}} AFX_MSGDECLARE_MESSAGE_MAP ()}; // myregulardll.cpp: defines the initialization routines for the dll.//include "stdafx.h" #include "MyRegularDll.h" // Note! /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// / If this DLL is dynamically linked against the MFC // DLLs, any functions exported from this DLL which // call into MFC must have the AFX_MANAGE_STATE macro // added at the very beginning of the function.//// For example: / /// extern "C" BOOL PASCAL EXPORT ExportedFunction () // {// AFX_Manage_State (AfxgetStaticModuleState ()); /// Normal Function Body Here //} //// IT IS VERY IMPORTANT THAT THIS MAC ro appear in each // function, prior to any calls into MFC. This means that // it must appear as the first statement within the // function, even before any object variable declarations // as their constructors may generate calls into the MFC // DLL.BEGIN_MESSAGE_MAP (CMyRegularDllApp, CWinApp) // {{AFX_MSG_MAP (CMyRegularDllApp) // NOTE - the ClassWizard will add // and remove mapping macros here.// DO NOT EDIT what you see in these blocksEND_MESSAGE_MAP () // CMyRegularDllApp constructionCMyRegularDllApp :: CMyRegularDllApp () {// TODO: add construction code here, // Place all significant initialization in InitInstance} more than two documents containing the major AppWizard generated code, and you can be distinguished from the Non-MFC Dlls seen . But pay attention to the reminder of the APPWIZARD above.
Sender: Dragon (Dragon), News District: VC Title: About DLL Programming in VC [4] Send Station: Drinking Water Source Station (THU Mar 25 00:46:22 1999), the station letter is about this time Last dynamic connection library: EXTENSION DLLS. Recommended again, the Extension DLL is only called by the application written by the MFC class library. In this dynamic connection library, you can inherit you from MFC you want, more appropriate The class you use and provide it to your app. You can also provide you with an object pointer for MFC or MFC inherited class. Extension DLLS and Regular DLLS are different, it does not have an object that is inherited from cwinapp, so you have to add initialization code and end code for your own DLLMAIN function. As follows: #include "stdafx.h" #include "#include projnamedll = {NULL, NULL};
EXTERN "C" int Apientry
Dllmain (Hinstance Hinstance, DWORD DWREASON, LPVOID LPRESERVED)
{
IF (dwreason == DLL_PROCESS_ATTACH)
{
TRACE0 ("Projname.dll Initializing! / N");
// Extension DLL One-Time Initialization
AFXINITEXTENSIONMODULE (ProjnaMedll,
Hinstance);
// INSERT this DLL INTO The Resource Chain
New CDynlinkLibrary (DLL3DLL);
}
Else IF (dwreason == dll_process_detach)
{
TRACE0 ("Projname.dll Terminating! / N");
}
Return 1; // ok
}
Capture this dynamic library module in the AFXINITEXTENSIONMOUdle function in the code
use.
The purpose of a CDynlinkLibrary object when initialized is: it
Can be an Extension DLL want the application to output a CRUNTIMECLASS object or resource.
If this dynamic connection library is explicitly called, you must also be in DLL_PROCESS_DETACH
Call AFXTERMEXTENSONMODULE on the execution code of the selection, this is guaranteed
Separation of process and dynamic connection library is correct to clean up dynamic library modules in memory. in the case of
Implicit called, this step is not necessary.
