Difference between using MFC in shared DLLs and using MFC in static libraries

With VS2008, there is a use of MFC in the project properties, there are three settings:

1. Use the standard Windows library

2. Use MFC in shared DLL

3. Use MFC in a static library

       The first is as the name implies.

       The second refers to the fact that the contents of some MFC DLLs are not included in the EXE file when they are packaged, so the EXE file is small, but the relevant DLL file is required in the system at runtime.

       The third is to write the relevant code in the DLL into the EXE file. The file is large, but it can be run on a machine without the relevant DLL.

       At the same time, if the program is originally the second way, sent to a colleague, when running on a colleague's machine, an error may occur: "Unable to start the program ... The application was not started because the application configuration is incorrect." I think that it is better to choose the third kind of program in the development stage. Regardless of size and efficiency, you can use spy and other tools to detect DLLs and so on during later packaging. (http://blog.csdn.net/xiexievv/article/details/6314874)

       "Using MFC in a shared DLL" refers to the fact that the contents of some MFC DLLs are not hard-coded into the EXE file at the time of packaging, so the EXE file will be smaller, but the relevant DLL must be available in the system environment at runtime. file.

     "Using MFC in a static library" is hard-coding the relevant code in the lib static library corresponding to the DLL into an EXE file. The file is large, but it can be run on a machine that does not already contain a DLL. Of course, not all of them DLLs are hard-coded into Exe, so some DLLs are still necessary. For example, some DLLs in Redistributable Package.

      The executable file compiled from the static library can also be run on other machines. The executable file compiled from the shared DLL can be executed on this machine. If it is obtained from other machines, the corresponding dynamic library support is required.

     In addition, the size of the project under the shared DLL will be slightly smaller, but when running on another machine, you must ensure that that machine has dynamic library support.

Original: http://blog.csdn.net/zhongguoren666/article/details/8187207