Basics of compiling dll in VC (zz)

When we use software, we often see many dynamic connection libraries. Dynamic Connection Library has its own advantages
Such as memory saving and multi-language support. If the function in the DLL changes
The called function does not need to be re-compiled. This is very useful in programming. For other highlights
It can be seen in 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.
To dynamically connect to the database, you must first know which types of DLL are available in VC5.0. VC supports three types of DLL, which are:

1. Non-MFC Dlls
2. Regular Dlls
3. Extension Dlls Note

Non-mfc dll: refers to the DLL directly written in C language without the MFC class library structure. Its output function 1
Is a standard C interface, and can be called by applications not written in MFC or MFC. LL,
Regular DLL: similar to the following Extension Dlls, it is written in the MFC class library. Obviously
In the source file, there is a class that inherits CWinApp. 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.
Type Dynamic Connection Library, which can be used to output a class inherited from MFC. Extension DLL uses
The dynamic connection version is created and called only by applications written in the MFC class library.
You can 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 down,
There will be gains.

Question: DLL programming in VC [1]

This section describes how to compile Non-MFC DLLs. Below is a general
Statement:

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, just like an application written in C,
There must be a WINMAIN function.
In this example, DllMain is a default entry function, and you do not need to write your own
And use the linker command line parameter toggle/ENTRY declaration. Use this missing
The provincial entry function can correctly initialize the dynamic connection library when it is called. Of course, you
Do 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
When loading or detaching a dynamic Connection Library, the operating system calls the entry function and describes the dynamic Connection Library.
The reason for the call. 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 store it. You can add what you want to lose in the file.
Output function or variable or c ++ class or ,? It seems that there are more differences. Look here! Now
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. Using this keyword saves you a lot of trouble. You don't need to use it in the. Def file.
It indicates 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. For DLL
There are two types of invocation: explicit invocation and implicit invocation.
Explicit calling is provided by loadlibrary or MFC in an application.
Afxloadlibrary explicitly calls the dynamic connection library you have made recently, and dynamically connects to the library
The file name is the parameter of the previous two functions. Use getprocaddress () to obtain
. Since then, you can use the same functions as the user-defined functions of this application.
Call this to introduce the function. Use freelibrary or
The afxloadlibrary provided by MFC releases the dynamic Connection Library.

For implicit calls, you need to add the. Lib file generated when a dynamic Connection Library is generated to
When you want to use a function in a DLL in a program project, you only need to describe the following:
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 changes, the application
Must be re-compiled. In addition, all the called DLL files are loaded to the internal directory while the application is loaded.
But the application calls a large number of DLL, the loading process is very slow. Implicit call
If the application does not know that the DLL to be loaded or the implicit call fails
Specifies 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 compiled by all languages that support DLL technology
Called. In this dynamic connection library, it must be inherited from CWinApp
Class. The DllMain function is provided by MFC and does not need to be explicitly written. Below is
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.
See the difference with 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 the Connection Library, You can inherit the classes you want from MFC that are more suitable for your own use, and
Provide it to your application. You can also provide MFC or
Object Pointer of the MFC inheritance class.
Extension DLLs is different from regular DLLs.
The inherited Class Object. Therefore, you must add initialization for your own dllmain function.
The code and end Code are 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
}
In the above Code, the AfxInitExtensionMoudle function captures this dynamic library module
Use.
The purpose of a NEW CDynLinkLibrary object during initialization is:
It can be Extension DLL that wants the application to output the CRuntimeClass object or resource.
If the dynamic Connection Library is explicitly called
Call the afxtermextensonmodule In the Execution Code of the selected item.
Separating a process from a dynamic Connection Library is a correct way to clean up the dynamic library module in the memory. If yes
This step is not required if it is called implicitly.