Many dynamic connection libraries can often be seen when we actually use software. Dynamic connection library has its own advantages
Such as saving memory, supporting multi-language, etc., and when the function in the DLL changes, as long as it is not a change in parameters
The function that is called does not need to be recompiled. This is useful when programming. As for other things, you are in your computer
Magazine, you can see it in books, I will talk about it here.
What I have to say this time, how 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 DLLs, they are:
1.NON-MFC DLLS
2.Regular DLLS
3.Extension Dlls Note: Improper translation, so the term is quoted
Non-MFC DLL: It is referring to the class library structure that does not need MFC, directly written with C language, the function of its output
The standard C interface is used, 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. Obvious characteristic is
There is a class inherited CWINAPP in the source file. It can also be finely connected to the MFC and dynamically connected to the MFC.
of. 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 the class from the MFC, that is, use this kind
A dynamic connection library that can be used to output a class that is inherited from the MFC. Extension DLL uses MFC
Dynamic connection versions are created, and it is only called by the application written by the MFC class library.
Everyone sees this here, if the eyes are a little flowers, please don't be discouraged, look at it twice, then continue to look down,
Growth.
Title: Programming About DLL in VC [1]
This section describes the method of writing Non-MFC DLLs. Below is a universal
Write:
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;
}
Each DLL must have an entry point, which is 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 yourself
DLL entry function, and declared with the parameter switch / entry declared with the command line of Linker. This is missing
The entrance function of the province will make the dynamic connection library to be proper initialization, of course, you
Don't fill in the code that makes the system crashes when you initialize.
In the parameter, hmoudle is a dynamic library that is transferred when the dynamic library is called.
(In fact, it is a selector pointing to the _dgroup segment)
UL_REASON_FOR_CALL is a logo for explaining the cause of the dynamic library. When a process or thread
When loading or unloading the dynamic connection library, the operating system calls the entry function and explains the dynamic connection library.
Causes of called. All possible values are:
DLL_PROCESS_ATTACH: Process is called
DLL_THREAD_ATTACH: Thread called
DLL_PROCESS_DETACH: The process is stopped
DLL_THREAD_DETACH: Thread is stopped
LPRESERVED is a parameter that is reserved by the system. The entrance function has been written, and it is not difficult, you can join what you want to lose in the file.
Function or variable or C class or, or, or,? It seems that there are more parts. LOOK here now
To join a new output function:
Void _Declspec (DLLEXPORT) JUSTSOSO ()
{
MessageBox (Null, "It's So Easy!", "Haha ...", MB_OK;
}
To output a class, you can follow:
Class _Declspec (DLLEXPORT) EASY
{
// Add your class definition ...
}
Everyone must notice that I use _Declspec (dllexport) in output functions or classes.
This is a keyword provided by VC, with it to output a data in a dynamic connection library.
A function or a class. Use this keyword to save you a lot of things, you don't have to be in .def file
Instructions I want to output this class, that function.
OK! Try to knock on the example on the example, Just So Easy!
Let's talk about this first.
Sender: Dragon, Letter area: VC
Title: Programming About DLL in VC [2]
The following is a method of calling the DLL now. DLL
The call is divided into two, one is an explicit call, one is implicit call.
The so-called explicit call refers to the use of LoadLibrary or MFC in the application.
AfxLoadLibrary explicitly adjusts your own dynamic connection library, dynamic connection library
The file name is the parameters of the upper two functions, and use getProcAddress () to get the desired introduction.
The function. Since then, you can use the functions of using the custom from this application.
Call this introduction function. Before the application exits, use FREELIBRARY or
The AFC provided by the MFC release dynamic connection library.
Implicit calls need to be added to the .lib file generated when generating a dynamic connection library
In the engineering engineering, you want to use the functions in the DLL, you only need to explain the following, as follows: Description
Output function void JustsoSo ();
Implicit calls don't need to call loadLibrary () and freeelibrary ().
From this point of view, the method of implicit instructions is relatively simple, but the DLL changes, the application
It must be compiled from the new. Also, all the calling DLLs are loaded to the internal
In stock, but the DLL of the application call is more slower, the process of loading is very slow. Implicit call
Then the application doesn't know that the DLL or implicit call to be loaded is unsuccessful. At this time, the user is allowed
Specifies the dynamic connection library to be loaded, more flexible
Sender: Dragon, Letter area: VC
Title: Programming About DLL in VC [3]
Regular DLL can be written by all languages that support DLL technology
Call. In this dynamic connection library, it must have an inherited from cwinapp.
Class, the DLLMAIN function is provided by the MFC without its own explicit writing. Here is one
example:
// myRegulardll.h: main header file for the myregularll DLL
#include "resource.h" // main symbols
Class 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_MSG
Declare_message_map ()
}
//Myregulardll.cpp:defines the initialization routines for the dll.
//
#include "stdafx.h"
#include "MyRegulardll.h"
// Note!
//
// if this dll is DynamicalLinked 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 fence.
//
// for example:
//
// Extern "C" BOOL PASCAL EXPORT ExportedFunction ()
// {
// afx_manage_state (AFXGETSTATICModuleState ());
//////mmal function body here
//}
//
// IT is Very Important That this Macro Appear in Each
// function, prior to any, calls INTO MFC. this means That
// it Must Appear as The First Statement within The First Statement Withnin THE
// function, Even Before any 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 blocks
END_MESSAGE_MAP ()
// CMYREGULARDLAPP CONSTRUCTION
CMYREGULARDLLAPPPPPPPPPPPPPPPPPPPPPPP ()
{
// Todo: Add Construction Code Here,
// Place All Significant Initialization in InIntinstance
}
The above is two files generated by AppWizard, you can
See the difference between Non-MFC DLLs. But pay attention to the reminder of the APPWIZARD above.
Sender: Dragon, Letter area: VC
Title: Programming About DLL in VC [4]
Sending station: Drinking water Siyuan Station (THU Mar 25 00:46:22 1999), station letters
This time you have to talk about the last dynamic connection library: extension dlls. Re-explanation,
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 suitable for your own class, and
Provide it to your app. You can also provide MFC for your app freely.
MFC inherited object pointer.
Extension DLLS and Regular DLLs are different, it does not have a CWINAPP
Inherited class objects, so you must add initialization to your own DLLMAIN function
Code and end code. As follows:
#include "stdafx.h"
#include
Static AFX_EXTENSION_MODULE 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.
