Regular DLLs Statically Linked to MFC
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. As the name describes, this kind of DLL is built using the static link library version of MFC. Functions are usually exported from a regular DLL using the standard C interface. For an example of how to write, build, and use a regular DLL, see the sample DLLScreenCap.
Note that the term USRDLL is no longer used in the Visual C++ documentation. A regular DLL that is statically linked to MFC has the same characteristics as the former USRDLL.
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, and so on); 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 is 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.
Note that the CWinApp::Run mechanism does not apply to a DLL, because 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 that in turn calls the CWinApp::PreTranslateMessage member function of the DLL's application object.
For an example of this function, see the DLLScreenCap 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 need to pass MFC-derived objects between the calling executable and the DLL, 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 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.