Regular DLLs Statically Linked to MFC
| Overview | How Do I | FAQ | Details | Sample
Feature Only in Professional and Enterprise Editions Static linking to MFC is supported only in Visual C++ Professional and Enterprise Editions. For more information, see .
A regular DLL, statically 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.
A regular DLL, statically linked to MFC has the following features:
The client executable can be written in any language that supports the use of DLLs (C, C++, Pascal, Visual Basic, etc.); it does not have to be an MFC application.
The DLL can link to the same MFC static link libraries used by applications. There is no longer a separate version of the static link libraries for DLLs.
Before version 4.0 of MFC, USRDLLs provided the same type of functionality as regular DLLs statically linked to MFC. As of Visual C++ version 4.0, the term "USRDLL" is obsolete.
A regular DLL, statically linked to MFC has the following requirements:
This type of DLL must instantiate a class derived from CWinApp.
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.
Even though the term "USRDLL" is obsolete, you must still define "_USRDLL" on the compiler command line. This definition determines which declarations, etc., will be pulled in from the MFC header files.
Regular DLLs must have a CWinApp-derived class and a single object of that application class, as does an MFC application. However, the CWinApp object of the DLL does not have a main message pump, as does the CWinApp object of an application.
The following MFC capabilities are not applicable in DLLs, either because of technical limitations or because those services are usually provided by the application.
CWinApp::Enable3dControls
CWinApp::SetDialogBkColor (color is ignored for message boxes)
Note that the CWinApp::Run mechanism does not apply to a DLL, since the application owns the main message pump. If the DLL opens modeless dialogs or has a main frame window of its own, the application's main message pump must call a routine exported by the DLL which in turn calls the CWinApp::PreTranslateMessage member function of the DLL's application object.
For an example of this function, see the sample.
Symbols are usually exported from a regular DLL using the standard C interface. The declaration of a function exported from a regular DLL would look something like this:
extern "C" __declspec(dllexport) MyExportedFunction( );
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.
It is safe to pass pointers to memory that were allocated by the C run-time libraries between an application and a DLL only if you make a copy of the data. You must not delete or resize these pointers or use them without making a copy of the memory.
A DLL that is statically linked to MFC cannot also dynamically link to the shared MFC DLLs. A DLL that is statically linked to MFC is dynamically bound to an application just like any other DLL; applications link to it just like any other DLL.
The standard MFC static link libraries are named according to the convention described in the topic Naming conventions for MFC DLLs. However, with MFC version 3.0 and later, it is no longer necessary to manually specify to the linker the version of the MFC library you want linked in. Instead, the MFC header files automatically determine the correct version of the MFC library to link in based on preprocessor defines, such as _DEBUG or _UNICODE. The MFC header files add /DEFAULTLIB directives instructing the linker to link in a specific version of the MFC library.