当前位置:编程学习 > VC++ >>

代码高处走 从VC6到VC9移植代码问题说明

首先可以直接用Visual Studio 2008的打开VC6的工作区文件和项目文件(dsw和dsp),并将其升级为VS2008的解决方案格式和项目格式(sln和vcproj),VC9的编译器相对于VC6有了很大的变化,一些编译参数和链接参数被废弃(比如/map:line),有一些改变了名称,还有新增的选项,不过不用担心,升级过程会自动对其进行转换,最终都会得到一个正确的解决方案和VC项目文件,这个过程不会遇到太多的麻烦,问题都出在随后的编译过程中,下面就将我在移植的过程中遇到的问题和我的解决方法总结一下,希望对还在用VC6维护代码的朋友有所帮助。
 
  一、_WIN32_WINNT 与_WIN32_IE 设置冲突
 
  _WIN32_WINNT 与_WIN32_IE设置不兼容会导致如下C1189致命错误:
 
  StdAfx.cpp
 
  c:\program files\microsoft sdks\windows\v6.0a\include\sdkddkver.h(217) : fatal error C1189: #error : _WIN32_WINNT settings conflicts with _WIN32_IE setting
 
  StdAfx.cpp通常是项目中第一个编译的文件,这个错误将导致编译无法继续进行。产生这个错误的原因是原因是_WIN32_WINNT的版本定义太老,老的VC代码对_WIN32_WINNT的典型设置是:
 
  #ifndef _WIN32_WINNT
 
  #define _WIN32_WINNT 0x0400
 
  #endif
 
  0x0400相对于VS2008所带的Plarform SDK(在文件sdkddkver.h中)中_WIN32_IE的定义来说太老了,导致不兼容,可以将其改成0x0501或更高的版本避免这个问题,如下所示:
 
  #ifndef _WIN32_WINNT
 
  #define _WIN32_WINNT 0x0501
 
  #endif
 
  也可以将这三行_WIN32_WINNT定义删除,这样就会使用Plarform SDK中的_WIN32_WINNT定义,自然就不存在不兼容问题了。不过出于对老版本VC的兼容考虑(毕竟以后可能还要使用VC6编译代码),最好这样修改:
 
  #if _MSC_VER <= 1200 // MFC 6.0 or earlier
 
  #ifndef _WIN32_WINNT
 
  #define _WIN32_WINNT 0x0400
 
  #endif
 
  #endif
 
  二、afximpl.h文件中的语法错误
 
  MFC出现的时候STL还没有成为C++的标准,所以MFC使用一套自己的模版库,比如CArray、CList、CMap等等,这些类型声明都在afximpl.h文件中。原来在VC6编译器适用的模版语法可能不适用VC9,特别是当以下四个环境变量设置不兼容时,就会出现这个编译错误,大致情况如下:
 
e:/software/microsoft visual studio 9.0/vc/atlmfc/src/mfc/afximpl.h(625) : error C2059: syntax error : '<L_TYPE_raw>'
e:/software/microsoft visual studio 9.0/vc/atlmfc/src/mfc/afximpl.h(625) : error C2238: unexpected token(s) preceding ';'
e:/software/microsoft visual studio 9.0/vc/atlmfc/src/mfc/afximpl.h(629) : error C2059: syntax error : '<L_TYPE_raw>'
e:/software/microsoft visual studio 9.0/vc/atlmfc/src/mfc/afximpl.h(629) : error C2238: unexpected token(s) preceding ';'
 
  合理调整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) : warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
 
  e:\software\microsoft visual studio 9.0\vc\include\string.h(74) : see declaration of 'strcpy'
 
  MSDN online 是这样解释的:为了显著增加CRT库的安全性,许多CRT函数都有了一个更安全的新版本,新版本和旧版本的区别就是新版本函数名多了一个_s后缀。只要一个CRT函数有新的安全版本,编译器就会产生一个C4996告警,不过,出现这个告警的目的并不是说旧版本的CRT函数将淡出CRT库,告警出现只是为了提醒程序员这个函数有更安全的版本存在。一种安全的或者是被鼓励的做法是用安全版本的函数替换现有的CRT函数,不过对于一个有相当代码量的项目,替换工作量也是巨大的,这可不是用名称查找、替换就能简单解决的问题,因为许多安全版本的CRT函数参数个数也发生了变化。也可以用预处理指令消除这个告警:
 
  #pragma warning( disable : 4996 )
 
  或者定义_CRT_SECURE_NO_WARNINGS 压制这个告警(在stdafx.h中define或在项目属性中设置预处理符号,PreProcessor Definitions)。
 
  除了C语言的CRT函数外,POSIX 兼容函数也存在这个告警,解决方法是用POSIX标准名称替换(比如access换成_access)或者是定义_CRT_NONSTDC_NO_WARNINGS 压制这个告警(方法同上)。
 
  四、“CWinApp::Enable3dControls”引起的C4996告警
 
  这个是编译使用了老的向导生成的MFC代码时遇到的问题,一个典型的告警信息输出如下所示:
 
  CrpFileCrack.cpp
 
  f:\project\.....\crpfilecrack.cpp(52) : warning C4996: 'CWinApp::Enable3dControls': CWinApp::Enable3dControls is no longer needed. You should remove this call.
 
  e:\software\microsoft visual studio 9.0\vc\atlmfc\include\afxwin.h(4818) : see declaration of 'CWinApp::Enable3dControls'
 
  通常向导生成的代码是:
 
  #ifdef _AFXDLL
 
  Enable3dControls(); // Call this when using MFC in a shared DLL
 
  #else
 
  Enable3dControlsStatic(); // Call this when linking to MFC statically
 
  #endif
 
  这两个函数的调用是旧的MFC版本对新版本的操作系统特性的支持,在新的(那个时候是新的)Windows 95平台上要这样调用一下才能使用新的Windows 3D样式的控件,否则就是老的Win 3.2样子的控件。想当初喜欢OWL就是因为感觉它的控件比较“酷”,比如那个带底纹的对话框,菱形的checkbox,还有带图标的“OK”按钮,看到MFC作出来的灰灰的界面就觉得土,不过后来就知道MFC做界面也是很漂亮的,比如我做的。。。。,再打住。对于新的MFC版本来说已经不需要再调用这两个函数了,参考前面的方法,用_MSC_VER对其隔离就行了:
 
  #if _MSC_VER <= 1200 // MFC 6.0 or earlier
 
  #ifdef _AFXDLL
 
  Enable3dControls(); // Call this when using MFC in a shared DLL
 
  #else
 
  Enable3dControlsStatic(); // Call this when linking to MFC statically
 
  #endif
 
  #endif
 
  五、.def文件引起的连接告警
 
  对于普通的DLL项目中使用的.def文件通常会引起LNK4017链接告警,如下所示:
 
  .\ComFunc.def(4) : warning LNK4017: DESCRIPTION statement not supported for the target platform; ignored
 
  Creating library .\..\Debug/ComFunc.lib and object .\..\Debug/ComFunc.exp
 
  一个典型的.def文件通常有以下内容:
 
  LIBRARY "XorCryptor"
 
  DESCRIPTION 'XorCryptor Windows Dynamic Link Library'
 
  EXPORTS
 
  ; Explicit exports can go here
 
  ..................
 
  消除这个连接告警的方法就是从.def文件中删除DESCRIPTION描述信息,不过这个告警也不是什么大问题,不删也可以。另一个可能产生的连接告警是LNK4222,通常出现在ocx控件和com组件的项目中,一个典型输出是:
 
  Linking...
 
  .\PlusInModule.def : warning LNK4222: exported symbol 'DllCanUnloadNow' should not be assigned an ordinal
 
  .\PlusInModule.def : warning LNK4222: exported symbol 'DllGetClassObject' should not be assigned an ordinal
 
  .\PlusInModule.def : warning LNK4222: exported symbol 'DllRegisterServer' should not be assigned an ordinal
 
  .\PlusInModule.def : warning LNK4222: exported symbol 'DllUnregisterServer' should not be assig
补充:软件开发 , Vc ,
CopyRight © 2012 站长网 编程知识问答 www.zzzyk.com All Rights Reserved
部份技术文章来自网络,