我有一个有很多服务和一个UI模块的应用程序。 所有这些都是在VC ++ 6.0中开发的。 KLOC的总数是560 KLOC。
它使用multithreading,MFC和所有的数据types,如word,int,long。
现在我们需要支持64位的操作系统。 我们需要对产品做出什么样的改变。
通过支持,我的意思是既像在64位操作系统上运行应用程序,也使用64位内存。
编辑:我排除迁移到VS2005或任何高于VC6.0由于时间限制。
那么需要做些什么改变。
64位Windows包括通过WOW的32位。 任何32位应用程序应该继续工作。
(只有驱动程序必须匹配操作系统的位数。)
[注释:注释:任何类型的插件都不是单独的应用程序,而是其他应用程序使用的dll,这些应用程序需要与主机匹配。 在这种情况下,在64位扩展与32位主机不兼容的情况下,您也会遇到同样的问题。]
正如理查德所说,32位版本应该继续工作,除非你有一个驱动程序或外壳扩展或什么的。
但是,如果您确实需要升级代码,您也必须升级编译器:我不认为MFC在VS2005或更高版本之前获得了良好的64位支持。 我建议你在VS2010中建立32位代码 – 这不会是微不足道的 – 然后开始考虑将其转换为64位。 你当然可以将生产32位版本留在VC6中,但是这会增加维护人员的负担。
通过翻译编译器到64位并打开完整的警告,你可能会转换大部分的转换方式 – 特别是考虑到你的代码的大小,它可能是不切实际的。 有一点需要注意的是存储整数,双字等指针,现在可能太短,不能容纳指针 – 现在需要DWORD_PTR等 – 但是我认为警告确实能够捕捉到这一点。
或者,如果这是在许多组件,那么你可能会逃脱,只有几个组件迁移到64位。 然后,不幸的是,你有两个版本之间的通信数据长度问题。
你必须转换成一个更新的编译器。 时间限制几乎无关紧要。 VC6编译器根本无法生成64位代码。 它产生的每个指针是32位,对于初学者来说。 如果你需要访问“64位内存”,即0x00000000FFFFFFFF
以上的内存,那么32位是不够的。
如果你不想改变你的IDE到本质上支持64位编译和调试的IDE,那么你的工作就会变得更加复杂。 你确定这不值得打?
只是为了在64位操作系统上运行,你不需要做任何改变。 这就是WOW64的目的。
但是,如果您想要本机运行64位(即访问64位内存空间),则必须编译为64位。 这意味着使用支持64位的IDE。 这是没有办法的。
如果用正确的编码标准(主要是没有关于指针大小的假设,如int指针转换)编写,大多数程序应该没有问题转换为64位。 你会得到很多关于std :: size_t转换的警告,但是这些转换是毫无意义的。