注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

_

_

 
 
 

日志

 
 

Windows 64Bit移植心得  

2013-12-01 22:24:22|  分类: 默认分类 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
Windows 64Bit移植心得

分类: Windows 2010-12-16 16:43 416人阅读 评论(0) 收藏 举报

64bitwindows编译器dll代码分析正则表达式

目录(?)[+]

  1. 移植基本步骤
    1. 调整项目文件目录结构
    2. 追加64Bit编译配置项调整编译环境
    3. 修改部分代码或者重写部分代码
    4. 进行系统以及应用程序兼容性测试

下半年公司有一个Windows下64Bit移植的项目,已经厌倦之前百无聊赖的维护工作的我,有幸接到了这项工作。废话不多说,接下来谈谈Windows下64Bit移植的心得。

项目特点: Visual Studio 2005 (包括MFC应用程序以及Win32 DLL) + WDK7000 (驱动程序) 环境

移植基本步骤:
1. 调整项目文件目录结构

心得1: 调整目录结构的原因是同时支持64Bit和32Bit的编译,这时候可能对应的要修改很多脚本来应对这些目录的变化。

2. 追加64Bit编译配置项,调整编译环境

心得1: 对于VC项目,记得在追加了x64编译选项的时候,追加_WIN64的宏定义。 按照MSDN的说法,_WIN64和_AMD64_对于64Bit编译环境应该是默认存在的,而且_WIN32宏并不需要去掉。 (因为像RC文件也许要这样的宏,直接在Visual Studio中一个一个添加实在会把人累死,建议可以通过脚本修改)

心得2: 对于使用WDK环境,如果支持从XP到Win7的多个操作系统,一定要注意NTDDI_VERSION, _NT_TARGET_VERSION, _WIN32_WINNT的指定(否则可能编出来的DLL压根不能用)。 32Bit项目支持一些较早的系统(如Win2000),显然64Bit项目应该是与时俱进的。

心得3: 记得WinSXS与DLL Hell的事情,一定要检查manifest文件,或者linker声明中对于系统特定版本DLL的依赖关系。32Bit项目下可能支持了特定版本的DLL(比如6.0的comctl32.dll)。 64Bit也一定要支持。

心得4: 如果整个项目(VS+WDK)由统一的脚本控制编译,一定要注意编译器,链接器的路径冲突问题(防止用VS2005的编译工具去编WDK的代码)。 还有就是一些lib文件引用的冲突问题。控制好各种PATH环境变量很重要。

心得5: 不要相信VS的版本移植所执行的conversion。如果从VS2003升级到VS2005, 记得检查一下配置中有哪些配置被弄丢了。比如对manifest文件的依赖

3. 修改部分代码,或者重写部分代码

??? 其实这里本应是64Bit移植的重头戏,如果之前的代码写的好的话, 这里基本不用什么大的调整了。可是大部分年代久远的系统,多半在产生之初都没有考虑过64Bit系统,可能那个时候amd64还没有, ia64又太激进。 代码中存在着各种稀奇古怪的bomb,一定要扫干净。

心得6: 类型,类型, 还是类型

数据类型的扩展可谓是64Bit系统与32Bit系统最大的不同,数据寻址范围增大到64位长度,指针类型扩展到64位长度,数据结构变成8字节对齐,位操作的变量很可能需要应对高32位的扩展。因此,类型,特别是各种数据类型的长度应该是bomb最密集的区域。

??? 应对这些问题,有以下几种实践中好用的方法:

??? 1. 重视编译过程中产生的warning。现在的编译器都很强大,对于类型及长度发生的变化,它是最直接的反应。

??? 2. 除了编译器,可以使用静态代码分析工具。

??? 3. 一定要检查每一处强制类型转换,"每一处"听起来有点可怕。可以通过正则表达式将这些强制类型转换都找出来。

??? 4. 在Windows系统中,特别要注意DWORD类型,WPARAM, LPARAM, LRESULT, size_t等, 以及各种PTR结尾的类型。 因为32Bit系

??????? 统中,他们很可能都用来保存指针或者范围。

心得7: 与长度有关的函数

?? 一定要小心这些与长度相关的函数,文件长度,数组长度,内存范围, 这些东西从2^32次方的访问范围,增大到了2^64次方的范围,一个不小心,溢出就等着你。

心得8: 如果能回到过去

?? 如果回到32Bit项目编码的一开始,你必须要记住以下几件事情,否则噩梦会伴随着你的:

????? 1. 函数声明,定义一定要匹配。 特别是C代码,编译器有时候对是检查不错来这种事情的。

????? 2. 尽量不要用强制类型转换,也不要图方便用一些被typedef或者#define出来的同类型不同名的类型声明。

?????????? 不要随便使用你认为的类型相同类型名,应该好好阅读系统建议你应该使用的类型名。也就是针对特定的场合,使用特定的类型名。

?????????? 表示长度的时候,尽量使用size_t

?????????? 表示指针操作的时候,尽量使用ptrdiff_t

?????????? LPARAM, WPARAM 不要用DWORD取代

?????????? LRESULT以及各种PTR结尾的类型不要用int或者unsigned int取代

?????????? 指针不要存在DWORD变量中

?????????? 。。。。。。

????? 3. 要注意数据接口,特别是保存或者度入的数据。

?????????? 因为程序导出和读入的数据有可能需要在32Bit和64Bit系统上共享。因此,到出的数据中,尽量不要使用长度发生变化的类型。对于数

?????????? 据存取,最好限定在BYTE, WORD, DWORD, QWORD这些固定的数据类型上。

4. 进行系统以及应用程序兼容性测试

??? 移植有时候会有一些不那么显而易见得问题产生,特别是Windows系统之间也有许多差异。步骤3中的动作,基本上是移植中的已知问题,但是还有许多未知的潜在不兼容性存在。而这些,是在设计之出很难考虑到的。所以兼容性测试是必须要做的,而且是大规模的回归测试。

??? 尽管如此大规模的全面测试,这里我已经有一些应该牢记的兼容性问题,

心得9: 子进程与权限提升

??? WinExec, CreateProcess函数与ShellExecute函数都是用来创建子进程的函数。根据微软官方的说法,WinExec, CreateProcess函数并不支持子进程的权限提升。在Vista以后的系统中,用这两个底层函数创建安装程序进程将导致无法安装(没有权限)。 而ShellExecute被是较为高层的用户函数,它是支持权限提升的。 虽然微软这么说,但实际上这只发生在64Bit系统上。(可能默认情况下32Bit已经被修整了) 。 因为实际上32Bit下WinExec, CreateProcess仍然可以提升权限,这可能导致这个问题被忽视。

心得10: ToolTipInfo结构体大小与comctl32.dll版本

??? 奇怪的问题,ToolTipInfo结构体大小必须剪掉一个指针的长度,才能在多数64Bit系统中正常运作。

心得11: MFC中的OnCancel事件与OnQueryCancel事件

??? 两者的用法有区别,但32Bit下有人把它们随意的使用。结果,64Bit下会发生你把电脑砸了也想不到的现象发生。

以上就是这半年来在64Bit移植上的心得。暂时想到这么多,还比较凌乱,以后慢慢整理吧。

  评论这张
 
阅读(449)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017