PlatformSDK也来添乱

 最近几天真是麻烦不断，装了最新的PlatformSDK for Windows 2003 R2 （5.2.3790.2075.51.PlatformSDK_Svr2003R2_rtm.img）并与我的Visual Studio 2005 Proffessional集成后发现原来能够编译的程序不能编译了，错误如下：
test.obj : error LNK2019: unresolved external symbol "wchar_t * __stdcall _com_util::ConvertStringToBSTR(char const *)" (?ConvertStringToBSTR@_com_util@@YGPA_WPBD@Z) referenced in function _main test.exe : fatal error LNK1120: 1 unresolved externals
说是ConvertStringToBSTR这个函数找不到，我记得我的程序没有使用这个函数，在MSDN中查了一下发现在comutil.h中声明的，链接代码在comsupp(w).lib中，具体看wchar_t是否作为内部类型，从错误消息来看应该链接comsuppw.lib才对，把这个库文件加上可以链接了。但是我以前不用加这个也可以编译的，怎么回事呢？因为我同时安装了VS2005Sp1，难道是与这个安装包也有关系，先一个一个排除吧。我先去掉PlatformSDK，rebuild OK!加上还是链接错误，另外我调整一下头文件目录的顺序，重新编译也是成功的。真是纳闷！什么原因呢？
       仔细想了想过去使用VC的经历，通常一个头文件对应一个库文件，但是我们添加头文件时如果在集成环境中通常不需要手工添加对应的库文件，这是怎么实现的呢？如果让我来解决这个问题我会怎么办？最开始我想到的是项目文件，但是没有找到任何lib文件，MFC程序至少有好几个lib得连接的，通过什么方式指定的呢？项目模板，这种类型的项目可能使用这些库，但是感觉很不灵活。而且只是改变头文件目录的顺序，问题就消失了，项目文件和项目模板都没有改变，应该不是他们的原因，问题应该出在头文件上。另外我想到了defaultlib，今天一早我到MSDN上一查，结果发现了很有用的线索：

#ifndef _UNICODE
    #ifdef _DEBUG
        #pragma comment(lib,  " nafxcwd.lib " )
    # else
        #pragma comment(lib,  " nafxcw.lib " )
    #endif
# else
    #ifdef _DEBUG
        #pragma comment(lib,  " uafxcwd.lib " )
    # else
        #pragma comment(lib,  " uafxcw.lib " )
    #endif
#endif...

太让我高兴了，我先查了一下#pragma comment的解释，如下：

#pragma comment( "comment-type" [, commentstring] )

lib

Places a library-search record in the object file. This comment type must be accompanied by a commentstring parameter containing the name (and possibly the path) of the library that you want the linker to search. The library name follows the default library-search records in the object file; the linker searches for this library just as if you had named it on the command line provided that the library is not specified with /nodefaultlib. You can place multiple library-search records in the same source file; each record appears in the object file in the same order in which it is encountered in the source file.

If the order of the default library and an added library is important, compiling with the /Zl switch will prevent the default library name from being placed in the object module. A second comment pragma then can be used to insert the name of the default library after the added library. The libraries listed with these pragmas will appear in the object module in the same order they are found in the source code.

然后我到VS2005的include目录下去搜索pragma comment，前面的#还给我惹麻烦后来去掉了，搜到了四个文件comdef.h,crtdefs.h,omp.h,use_ansi.h，很快就锁定为comdef.h，里面找到这样一段代码：

#ifdef _NATIVE_WCHAR_T_DEFINED
    # ifdef _DEBUG
        # pragma comment(lib,  " comsuppwd.lib " )
    #  else
        # pragma comment(lib,  " comsuppw.lib " )
    # endif
# else
    # ifdef _DEBUG
        # pragma comment(lib,  " comsuppd.lib " )
    #  else
        # pragma comment(lib,  " comsupp.lib " )
    # endif
#endif

终于看到我要找的东西了，然后到PlatformSDK的目录下找了一下，有两个comdef.h，另一个在crt目录下，因为包含的是include目录下的，于是我就打开这个看了一下，代码如下：

#pragma comment(lib,  " comsupp.lib " )

#pragma comment(lib,  " user32.lib " )
#pragma comment(lib,  " ole32.lib " )
#pragma comment(lib,  " oleaut32.lib " )

问题就是出在这里，一堆的判断全部没有了。
解决办法也很简单，一个是在link选项中加上comsuppw.lib，另一个解决办法是在源代码中加上如下的代码：
#pragma comment(lib, "comsuppw.lib")
后来发现这个用法用得挺多的，很好的一个特性！

但是问题远没有结束，我发现Intel C++ 9.1编译不了我的代码了，可能是补丁惹的祸，麻烦不断啊！

联系MFC和ATL的版本，我终于明白为什么了？
wchar_t作为内部类型从VS2003才支持，以前都是unsigned short的别名而已，这套PlatformSDK为了支持VS60，所以不会用到comsuppw.lib这个库。