mfc extention dll 與 normal dll 的區別

extention dll

1.指從MFC中繼承過來的DLL，一般要求使用共享MFC DLL進行連接，也要求調用者也使用MFC且使用共享MFC，如此可保證DLL與調用者有相同的MFC庫。

2.在使用資源的時候，打個比方說，加載一個對話框，會調用 AfxGetResourceInstance () 進行獲取HINSTANCE，這個函數會自動獲取DLL的 hInstance，所以，這牠不會造成調用者與DLL的資源混淆。

normal dll

1.這個可以當成普通的DLL，調用者可以不是基於MFC編寫，這個DLL可以使用共享或靜態連接。

2.在使用資源的時候，AfxGetResourceInstance () 會得到調用者的 hInstance，所以這個時候，會產生資源加載混淆，經常會出現對話框彈不出來的情況，一般會在需要使用DLL資源的導出函數中加入：AFX_MANAGE_STATE(AfxGetStaticModuleState( )); 這樣，就可以把hInstance轉換成DLL的hInstance，可以正確加載資源了。

完整的區別：

地址：http://www.cnblogs.com/taoxu0903/archive/2009/05/10/1453718.html

1. Dll types
Three:
Win32 dll
MFC regular dll
MFC extension dll
2. MFC extension dll
Basic[MSDN]:
An MFC extension DLL is a DLL that typically implements reusable classes derived from the existing Microsoft Foundation Class Library classes.

An MFC extension DLL has the following features and requirements:

    *      The client executable must be an MFC application compiled with _AFXDLL defined.
    *      An extension DLL can also be used by a regular DLL that is dynamically linked to MFC.
    *      Extension DLLs should be compiled with _AFXEXT defined. This forces _AFXDLL to be also defined and ensures that the proper declarations is pulled in from the MFC header files. It also ensures that AFX_EXT_CLASS is defined as __declspec(dllexport) while building the DLL, which is necessary if you are using this macro to declare the classes in your extension DLL.
    *      Extension DLLs should not instantiate a class derived from CWinApp, but should rely on the client application (or DLL) to provide this object. [my note: since every CWinApp needs to manage its module state, as extension dll just use the caller's, so it just accepts the current module state.]
    *      Extension DLLs should, however, provide a DllMain function and do any necessary initialization there.

An MFC extension DLL uses a shared version of MFC in the same way an application uses the shared DLL version of MFC, with a few additional considerations:

    *      It does not have a CWinApp-derived object. It must work with the CWinApp-derived object of the client application. This means that the client application owns the main message pump, the idle loop, and so on.
    *      It calls AfxInitExtensionModule in its DllMain function. The return value of this function should be checked. If a zero value is returned from AfxInitExtensionModule, return 0 from your DllMain function.
    *      It creates a CDynLinkLibrary object during initialization if the extension DLL wants to export CRuntimeClass objects or resources to the application.

Memory Management

MFCx0.dll and all extension DLLs loaded into a client application's address space use the same memory allocator, resource loading, and other MFC global states as if they were in the same application. This is significant because the non-MFC DLL libraries and the regular DLLs do the exact opposite and have each DLL allocating out of its own memory pool.

Sharing Resources and Classes

Exporting resources is done through a resource list. Each application contains a singly linked list of CDynLinkLibrary objects. When looking for a resource, most of the standard MFC implementations that load resources look first at the current resource module (AfxGetResourceHandle) and if the resource is not found walk the list of CDynLinkLibrary objects attempting to load the requested resource.

Walking the list has the disadvantages that it is slightly slower and requires managing resource ID ranges. It has the advantage that a client application that links to several extension DLLs can use any DLL-provided resource without having to specify the DLL instance handle. AfxFindResourceHandle is an API used for walking the resource list to look for a given match. It takes the name and type of a resource and returns the resource handle where it was first found (or NULL).

If you do not want to walk the list and only load resources from a specific place, use the functions AfxGetResourceHandle and AfxSetResourceHandle to save the old handle and set the new handle. Be sure to restore the old resource handle before you return to the client application. For an example of using this approach to explicitly load a menu, see Testdll2 .cpp in the MFC sample DLLHUSK.

3. MFC regular dll (Talk only Regular DLLs Dynamically Linked to MFC)

Basic [MSDN]:

A regular DLL dynamically linked to MFC is a DLL that uses MFC internally, and the exported functions in the DLL can be called by either MFC or non-MFC executables. As the name describes, this kind of DLL is built using the dynamic-link library version of MFC (also known as the shared version of MFC). Functions are usually exported from a regular DLL using the standard C interface.
You must add the AFX_MANAGE_STATE macro at the beginning of all the exported functions in regular DLLs that dynamically link to MFC to set the current module state to the one for the DLL. This is done by adding the following line of code to the beginning of functions exported from the DLL:

AFX_MANAGE_STATE(AfxGetStaticModuleState( ))

A regular DLL, dynamically linked to MFC has the following features:

    *      This is a new type of DLL introduced by Visual C++ 4.0.
    *      The client executable can be written in any language that supports the use of DLLs (C, C++, Pascal, Visual Basic, and so on); it does not have to be an MFC application.
    *      Unlike the statically linked regular DLL, this type of DLL is dynamically linked to the MFC DLL (also known as the shared MFC DLL).
    *      The MFC import library linked to this type of DLL is the same one used for extension DLLs or applications using the MFC DLL: MFCxx(D).lib.

A regular DLL, dynamically linked to MFC has the following requirements:

    *      These DLLs are compiled with _AFXDLL defined, just like an executable that is dynamically linked to the MFC DLL. But _USRDLL is also defined, just like a regular DLL that is statically linked to MFC.
    *      This type of DLL must instantiate a CWinApp-derived class.

    *      This type of DLL uses the DllMain provided by MFC. Place all DLL-specific initialization code in the InitInstance member function and termination code in ExitInstance as in a normal MFC application.

All memory allocations within a regular DLL should stay within the DLL; the DLL should not pass to or receive from the calling executable any of the following:
    *      pointers to MFC objects
    *      pointers to memory allocated by MFC

If you need to do any of the above, or if you need to pass MFC-derived objects between the calling executable and the DLL, then you must build an extension DLL.

Key points:
1) it has its own module state. So regards to resource loading (string, dialog, etc), in order to load its resource correctly, module state switch before loading resource is a must.
2) for every exported function from this dll, the switching module state sentence must be the first code line of every function.
3) The AFX_MANAGE_STATE macro should not be used in regular DLLs that statically link to MFC or in extension DLLs.

4. Loading resource example (from codeguru)

The article link is:http://www.codeguru.com/cpp/w-p/dll/article.php/c109

[Key extraction]The next issue involving DLLs and dialog boxes, involves a DLL invoking a dialog which is located in a different DLL. There are four calling possibilities: 1. Regular calling and Regular DLL, 2. An Extension calling and Regular DLL, 3. A Regular calling an Extension DLL, 4. Extension calling a Extension DLL.
case 1: since it's hard to directly use the exported dialog class as module state can't be switched to the parent regular dll's of the wanted dialog, the dialog resource can't be located, the only way to be able to call the dialog is by exporting a function which inside it can show the dialog.
case 2: same as #1.
case 3: as the regular dll has its module state and the extension dll has no way to join in its resource chain and no way to do module state switch as it can only accept the caller's module state, so no way to realize the dialog call here.
case 4: easy. any way can be fine.

5. Other

1) No need to worry about the project setting's preprocessors and CRT setting. New a MFC extension or regular dll in VS, you will get standard setting there.

2) MFC Module state. Only regular dll needs to manage module state, while for MFC extension dll, it will only accept a module state as it may be called by regular dll or MFC application directly (exe), but it really has no way to do sth with module state.