The current Character Set in the project configuration is set to UNICODE. The original file gave a compiler error, so a fixed version is included.ġ>- Build started: Project: MFCDLL, Configuration: Release Win32 -ġ>C:\Program Files (x86)\Windows Kits\10\Include\2.0\ucrt\corecrt_memcpy_s.h(50):Įrror C4789: buffer 'var' of size 24 bytes will be overrun Ģ4 bytes will be written starting at offset 8ġ>Done building project "MFCDLL.vcxproj" - FAILED.Īpparently, there are still bugs present in MFC after all those 28 years! So no original MFC source files are included in the Solution except for one file: ctlpset.cpp. To overcome copyright issues, the MFC source files are not included but read during compilation from the $(VCToolsInstallDir) folder. When you clone the Github project, and run the Solution with Visual Studio 2019, a default wizard created MFC application is compiled and run but it uses the private MFC DLL! Luckily, once when we have generated a DEF file, it can be used in a future LTCG build. The object files the compiler generates when using LTCG cannot be read by dumpexts.exe. When building the DLL the first time, also be sure Link Time Code Generation (LTCG) is not used. Be sure to first clean the MFCDLL project so that no old obj files are hiding in it. Because Visual Studio has no macro with a list of all obj files, a DOS command enumerates all obj files in the Intermediate directory before calling dumpexts.exe. The tool is run as a pre-link Build Event for the MFCDLL project. I found the source code of it and modified it a little so it could create a DEF file for all the objs created by the compiler. I couldn't use the old VC++ 2005 DEF file because the MFC feature pack added a lot of new functions.Īfter some internet search, I discovered the tool: dumpexts.exe. The linker uses this DEF file to create the LIB file for the DLL. The MFC DLL exports its symbols via a provided Module Definition File or DEF file.
The first hurdle was the missing DEF file.
The github project has all the necessary files to build the MFC sources as a DLL. So I took the road to build my own MFC vcxproj files. With statically linked MFC, I provided my own versions of the DAO classes (which internally use MySQL) by overriding the *dao*.obj files, but MFC object files cannot be overridden when using the DLL form of MFC. In a LOB software project, I needed a x86 MFC DLL without the DAO database classes. The necessary files, i.e., makefiles like atlmfc.mak and a DEF file are not provided anymore.
With the latest Visual C++ versions (since 2008), it is not possible anymore to compile the bundled MFC sources.
0 kommentar(er)
