译自:http://stackoverflow.com/questions/6871836/how-does-mfcs-wwinmain-end-up-in-the-executable
在VS的解决方案管理中右击你的MFC项目:属性-》链接器-》命令行,在命令行的其他选项中添加链接参数:/verbose . 然后重新生成项目,
此时在输出窗口会显示出链接器所找到的一系列的符号的追踪情况。在其中搜索“winmain” 会找到如下信息:
1> 已找到 _wWinMain@16
1> 已在 msvcrtd.lib(wcrtexew.obj) 中引用
1> 已加载 mfcs100ud.lib(appmodul.obj)
很明显,我们知道appmodul.cpp中包含着_tWinMain()的源码。从这里可以看出,已编译好的appmodul.obj早已存在于mfcsxx.lib静态库
中了。
注意该库的名字:mfcs100ud.lib,它是个静态库. 在输出窗口查找mfcs100ud.lib会发现该库的如下引用:
1>Link:
1>
1> 正在启动传递 1
1> 已处理 /DEFAULTLIB: mfc100ud.lib
1> 已处理 /DEFAULTLIB: mfcs100ud.lib
1> 已处理 /DEFAULTLIB: msvcrtd.lib
1> 已处理 /DEFAULTLIB: kernel32.lib
1> 已处理 /DEFAULTLIB: user32.lib
1> 已处理 /DEFAULTLIB: gdi32.lib
etc..
如果在MFC的源码中搜索“mfcs”,会发现这些/defaultlib选项是这样被注入的(在afx.h中):
#ifdef _DEBUG
#pragma comment(lib, "mfc" _MFC_FILENAME_VER "ud.lib")
#pragma comment(lib, "mfcs" _MFC_FILENAME_VER "ud.lib")
#else
#pragma comment(lib, "mfc" _MFC_FILENAME_VER "u.lib")
#pragma comment(lib, "mfcs" _MFC_FILENAME_VER "u.lib")
#endif
简单地说,一个MFC应用程序会链接两个库:mfcxxu.lib库是对应DLL的引入库;mfcsxxu.lib是包含winmain()在内的诸多信息的静态库,
它将被链接到你的可执行文件中。
注意:此处作者只考虑_AFXDLL、_DLL即使用动态CRT、MFC库的情况;而使用MFC静态库与之类似,不过上述信息包含在静态库uafxcwd.lib中.如使用静态CRT和MFC库
时,情况如下:
1> 正在搜索 d:\Microsoft Visual Studio 10.0\VC\atlmfc\lib\uafxcwd.lib:
1> 已找到 _wWinMain@16
1> 已在 libcmtd.lib(wwincrt0.obj) 中引用
1> 已加载 uafxcwd.lib(appmodul.obj)
1> 已找到 "int __stdcall AfxWinMain(struct HINSTANCE__ *,struct HINSTANCE__ *,wchar_t *,int)" (?AfxWinMain@@YGHPAUHINSTANCE__@@0PA_WH@Z)
1> 已在 uafxcwd.lib(appmodul.obj) 中引用
1> 已加载 uafxcwd.lib(winmain.obj)