VS与VC++60的各种区别和移植代码问题总结Word文件下载.docx
《VS与VC++60的各种区别和移植代码问题总结Word文件下载.docx》由会员分享，可在线阅读，更多相关《VS与VC++60的各种区别和移植代码问题总结Word文件下载.docx（11页珍藏版）》请在冰豆网上搜索。
没多久VC5就出来了，好在这两个版本的用户界面变化不大（MFC的版本稳定在4.2），我就在《VisualC++4.0从入门到精通》这本书的指导下“精通”了VC5。
1998年的时候VisualC++6.0推出了，但是我一直坚持用VC5，1999年我毕业设计还是选择用VC5，不为别的，就是因为当时盗版的VC6都没有帮助文件，就是缺少MSDN，没有这个还怎么写代码？
毕业设计完成之后我从朋友那里弄到了传说中的两张MSDN光盘，于是开始用VC6，从此以后，VC6就一直存在于所有我用过的电脑中，后来VC7（7.1），VC8出来以后，VC6的地位也一直没有动摇过，用C++开发软件我首选VC6，我还为VC6开发了一个文件标签栏插件Tabbar，可以通过标签栏在打开的代码文件之间快速切换，除此之外还具有很多其它功能，比如自动打包压缩项目代码。
唉，又跑题了，打住。
做人要与时俱进，这不，今年VC9也随着VisualStudio2008发布了，再不赶上就真的老套了。
说是这么说，不过心里还是有些余悸的，2006年的时候我曾经试图将我的一个工具软件的代码升级到VC8，但是我低估了新的编译器的兼容性（当年从VC5到VC6可是没有那么多麻烦），上来就是一大堆编译错误，警告就更是牛毛，当时因为急着为工具软件开发一个新功能，没有时间解决这些问题，只好放下了，这一放就是两年。
我这个人喜欢自己做工具软件，目的是为了方便自己，以前用VC6，觉得在代码源文件之间切换很麻烦，但是WndTab太占用资源，于是就借鉴WndTab的部分代码自己做了个标签栏插件Tabbar，还把从CodeProject上看到的好的创意都添加进去，后来用SourceInsight，觉得它没有文件标签栏太土，就给它做了个标签栏外挂（TabSiPlus），就这样几年下来竟然有几百兆的工具代码，这个移植的工作量可是非同小可，想着都怕怕呀！
不过也没办法，这两年主要用GCC做嵌入式开发了，没有时间维护这些工具，自己在使用过程中累计下来的BUG和新需求也有一大堆，需要进行升级了，适逢这次机会将其移植到VC9到也是个不错的选择。
其实程序员自己给自己写工具很有好处，比如我喜欢边写代码边听音乐，于是我就把自己写的MP3播放器集成到VC开发环境中，这样就可以象操作VC的其它功能一样选择音乐文件，还比如。
又扯远了，回到正题，讲讲移植过程中遇到的问题。
首先可以直接用VisualStudio2008的打开VC6的工作区文件和项目文件（dsw和dsp），并将其升级为VS2008的解决方案格式和项目格式（sln和vcproj），VC9的编译器相对于VC6有了很大的变化，一些编译参数和链接参数被废弃（比如/map:
line），有一些改变了名称,还有新增的选项，不过不用担心，升级过程会自动对其进行转换，最终都会得到一个正确的解决方案和VC项目文件，这个过程不会遇到太多的麻烦，问题都出在随后的编译过程中，下面就将我在移植的过程中遇到的问题和我的解决方法总结一下，希望对还在用VC6维护代码的朋友有所帮助。
一、_WIN32_WINNT与_WIN32_IE设置冲突
_WIN32_WINNT与_WIN32_IE设置不兼容会导致如下C1189致命错误：
StdAfx.cpp
c:
/programfiles/microsoftsdks/windows/v6.0a/include/sdkddkver.h（217）:
fatalerrorC1189:
#error:
_WIN32_WINNTsettingsconflictswith_WIN32_IEsetting
StdAfx.cpp通常是项目中第一个编译的文件，这个错误将导致编译无法继续进行。
产生这个错误的原因是原因是_WIN32_WINNT的版本定义太老，老的VC代码对_WIN32_WINNT的典型设置是：
#ifndef_WIN32_WINNT
#define_WIN32_WINNT0x0400
#endif
0x0400相对于VS2008所带的PlarformSDK（在文件sdkddkver.h中）中_WIN32_IE的定义来说太老了，导致不兼容，可以将其改成0x0501或更高的版本避免这个问题，如下所示：
#define_WIN32_WINNT0x0501
也可以将这三行_WIN32_WINNT定义删除，这样就会使用PlarformSDK中的_WIN32_WINNT定义，自然就不存在不兼容问题了。
不过出于对老版本VC的兼容考虑（毕竟以后可能还要使用VC6编译代码），最好这样修改：
#if_MSC_VER<
=1200//MFC6.0orearlier
二、afximpl.h文件中的语法错误
MFC出现的时候STL还没有成为C++的标准，所以MFC使用一套自己的模版库，比如CArray、CList、CMap等等，这些类型声明都在afximpl.h文件中。
原来在VC6编译器适用的模版语法可能不适用VC9，特别是当以下四个环境变量设置不兼容时，就会出现这个编译错误，大致情况如下：
e:
/software/microsoftvisualstudio9.0/vc/atlmfc/src/mfc/afximpl.h（625）:
errorC2059:
syntaxerror:
'
<
L_TYPE_raw>
'
errorC2238:
unexpectedtoken（s）preceding'
;
/software/microsoftvisualstudio9.0/vc/atlmfc/src/mfc/afximpl.h（629）:
合理调整stdafx.h中WINVER、_WIN32_WINNT、_WIN32_WINDOWS和_WIN32_IE的设置可以避免这个问题，将三个与Windows版本有关的环境变量设置为0x0501或更高版本，将IE版本的环境变量设置为0x0500以后的版本就可以解决这个问题。
当然，考虑到与旧的VC6代码兼容，可以采用上一个问题中提到的最后一个解决办法，用_MSC_VER进行隔离。
三、旧的CRT库和新的安全CRT库引起的C4996告警
解决了环境变量设置不匹配导致的问题后，编译过程就真正开始了，不过首先映入眼帘的应该是成堆的C4996编译告警，对每个使用了含字符串参数的CRT库函数都会有C4996编译告警，一个典型的输出如下所示：
f:
/project/...../commonfunc.cpp（280）:
warningC4996:
strcpy'
:
Thisfunctionorvariablemaybeunsafe.Considerusingstrcpy_sinstead.Todisabledeprecation,use_CRT_SECURE_NO_WARNINGS.Seeonlinehelpfordetails.
/software/microsoftvisualstudio9.0/vc/include/string.h（74）:
seedeclarationof'
MSDNonline是这样解释的：
为了显著增加CRT库的安全性，许多CRT函数都有了一个更安全的新版本，新版本和旧版本的区别就是新版本函数名多了一个_s后缀。
只要一个CRT函数有新的安全版本，编译器就会产生一个C4996告警，不过，出现这个告警的目的并不是说旧版本的CRT函数将淡出CRT库，告警出现只是为了提醒程序员这个函数有更安全的版本存在。
一种安全的或者是被鼓励的做法是用安全版本的函数替换现有的CRT函数，不过对于一个有相当代码量的项目，替换工作量也是巨大的，这可不是用名称查找、替换就能简单解决的问题，因为许多安全版本的CRT函数参数个数也发生了变化。
也可以用预处理指令消除这个告警：
#pragmawarning（disable:
4996）
或者定义_CRT_SECURE_NO_WARNINGS压制这个告警（在stdafx.h中define或在项目属性中设置预处理符号,PreProcessorDefinitions）。
除了C语言的CRT函数外，POSIX兼容函数也存在这个告警，解决方法是用POSIX标准名称替换（比如access换成_access）或者是定义_CRT_NONSTDC_NO_WARNINGS压制这个告警（方法同上）。
四、“CWinApp:
Enable3dControls”引起的C4996告警
这个是编译使用了老的向导生成的MFC代码时遇到的问题，一个典型的告警信息输出如下所示：
CrpFileCrack.cpp
/project/...../crpfilecrack.cpp（52）:
CWinApp:
Enable3dControls'
CWinApp:
Enable3dControlsisnolongerneeded.Youshouldremovethiscall.
/software/microsoftvisualstudio9.0/vc/atlmfc/include/afxwin.h（4818）:
通常向导生成的代码是：
#ifdef_AFXDLL
Enable3dControl
升级会员 