Vc dll Programming

When we use software, we often see many dynamic connection libraries. The dynamic Connection Library has its own advantages, such as memory saving and multi-language support. In addition, when the function in the DLL changes, the called function does not need to be re-compiled as long as it is not a parameter change. This is very useful in programming. As for other highlights, you can see it in computer magazines and books. I am talking nonsense here.
This time, I want to talk about how to make my own Win32 DLLs in vc5.0. You should first know which types of DLL are available in vc5.0 to do your own dynamic Connection Library. VC supports three types of DLL, which are:

1. Non-MFC DLLs
2. Regular DLLs
3. Extension DLLs note

Non-mfc dll: Refers to a DLL written directly in C language without the use of the MFC class library structure. The output function generally uses the Standard C interface, it can be called by applications not compiled by MFC or MFC. Ll, regular DLL: similar to the following extension DLLs, it is written using the MFC class library. Obviously, there is a class that inherits cwinapp in the source file. It can be subdivided into static connection to MFC and dynamic connection to MFC. However, the dynamic connection library for static connection to MFC is only supported by VC professional and Enterprise Edition.
Extension DLL: Used to reuse the classes inherited from MFC. That is to say, a dynamic Connection Library of this type can be used to output a class inherited from MFC. Extension DLL is created using the dynamic connection version of MFC, and is called only by applications written in the MFC class library.
You may see that if your eyes are a little bit of flowers or your head is a little dizzy, please do not feel discouraged. Read it again twice and continue to look at it again.

Question: DLL programming in VC [1]

This section describes how to compile non-MFC DLLs. Below is a general syntax:

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 the same as an application written in C. It must have a winmain function.
In this example, dllmain is a default entry function. You do not need to write your own DLL entry function and use the linker command line parameter toggle/entry declaration. Using this default entry function can properly initialize the dynamic connection library when it is called. Of course, you should not enter the code that causes the system to crash during initialization.
In the parameter, hmoudle is a handle that points to itself when the dynamic library is called (in fact, it is a selector pointing to the _ dgroup segment) ul_reason_for_call indicates the reason why the dynamic library is called. When a process or thread loads or unmounts a dynamic Connection Library, the operating system calls the entry function and describes the reason why the dynamic Connection Library is called. All its possible values are:
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 entry function has been written, and it is not difficult to add the function or variable you want to output or the C ++ class or, or, or ,? It seems that there are more differences. Look here! Now we need to add a new output function:

Void _ declspec (dllexport) justsoso ()
{
MessageBox (null, "it's so easy! "," Hahaha... ", mb_ OK );
}

You can also output a class as follows:

Class _ declspec (dllexport) Easy
{
// Add your class definition...
};

You must note that I use _ declspec (dllexport) in the output function or class. This is a keyword provided by VC, it can be used to output a data, a function, or a class in the dynamic Connection Library. Using this keyword saves you a lot of trouble. You don't need to explain in the. Def file that I want to output this class and that function.
OK! As shown in the above example, you can try to think about just so easy!
Let's talk about this first.

Sender: Dragon (Dragon), email area: VC
Question: DLL programming in VC [2]

We have discussed the compilation method of non-mfc dll. Now we will talk about the method of calling DLL. There are two types of DLL calls: explicit call and implicit call.
Explicit calling refers to explicitly calling your own dynamic Connection Library in the application using the afxloadlibrary provided by loadlibrary or MFC, the file name of the dynamic Connection Library is the parameter of the above two functions, and then getprocaddress () is used to obtain the function to be introduced. Since then, you can call the introduced function like a function defined by the application. Before exiting the application, use the afxloadlibrary provided by freelibrary or MFC to release the dynamic Connection Library.

For implicit calls, you need to generate the dynamic Connection Library. the LIB file is added to the project of the application. To use functions in the DLL, you only need to describe the following: Describe the output function void justsoso () in the previous article (); implicit call does not need to call loadlibrary () and freelibrary ().

From this point of view, it seems that the call method is relatively simple, but after the DLL is changed, the application must be re-compiled. In addition, all the called DLL files are loaded into the memory when the application is loaded. However, when the application calls a large number of DLL files, the loading process is very slow. Implicit call means that the application does not know the DLL to be loaded or the implicit call fails. In this case, users are allowed to specify the dynamic connection library to be loaded, which is more flexible.

Sender: Dragon (Dragon), email area: VC
Question: DLL programming in VC [3]

Regular dll can be called by all applications written in languages that support DLL technology. In this dynamic connection library, it must have a class inherited from cwinapp. The dllmain function is provided by MFC and does not need to be explicitly written by itself. The following is an example:

// Myregulardll. h: Main header file for the myregulardll
# 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 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 macro appear in each
// Function, prior to any callinto MFC. This means that
// It must appear as the first statement within
// Function, even before any object variable declarations
// As their constructors may generate callinto 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 ()
//////////////////////////////////////// ////////////////////
// Cmyregulardllapp Construction
Cmyregulardllapp: cmyregulardllapp ()
{
// Todo: Add construction code here,
// Place all significant initialization in initinstance
}
The above are two files generated by Appwizard that contain the main code. You can see the difference between them and non-MFC DLLs. Note the above Appwizard reminder.

Sender: Dragon (Dragon), email area: VC
Question: DLL programming in VC [4]
Mailing station: Yin shuisiyuan station (Thu Mar 25 00:46:22 1999), internal mail

This is the last dynamic Connection Library: Extension DLLs. again, extension DLL is called only by applications written in the MFC class library. in this dynamic connection library, you can inherit the classes that you want and are more suitable for your own use from MFC and provide them to your applications. You can also provide the object pointer of the MFC or MFC inheritance class to your application at will.
Extension DLLs is different from regular DLLs. It does not have a class Object inherited from cwinapp. Therefore, you must add initialization code and end code for your own dllmain function:

# Include "stdafx. H"
# Include

Static afx_extension_module projnamedll = {null, null };

Extern "C" int apientry
Dllmain (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
}

In the above Code, the afxinitextensionmoudle function is used to capture this dynamic library module.
The purpose of a new cdynlinklibrary object during initialization is: it can be an extension DLL that wants the application to output a cruntimeclass object or resource.
If the dynamic Connection Library is explicitly called, afxtermextensonmodule must also be called in the Execution Code of the dll_process_detach selection item, this ensures that when the calling process is separated from the dynamic Connection Library, the dynamic library module in the memory is correctly cleared. This step is not required if it is called implicitly.