BUILDING 64位版本的二进制文件有什么大不了的？

Question

有大量的驱动程序和着名的应用程序没有64位.例如,Adobe不为Internet Explorer提供64位Flash播放器插件.正因为如此,即使我运行的是64位Vista,我也必须运行32位IE.Microsoft Office,Visual Studio也不提供64位AFAIK.

现在个人而言,我在使用64位构建应用程序时没有遇到太多问题.我只需记住一些经验法则,例如总是使用SIZE_T而不是UINT32来获取字符串长度等.

所以我的问题是,是什么阻止人们为64位构建？

Answer 1

如果从头开始,64位编程就不那么难了.但是,你提到的所有程序都不是新的.

从头开始构建64位应用程序要容易得多,而不是从现有代码库中移植它.移植时有很多问题,尤其是当您进入已经完成某种程度优化的应用程序时.程序员使用许多小的假设来获得速度,并且这些并不总是很容易快速移植到64位.我必须处理的几个例子:

• 正确对齐结构中的元素.随着数据大小的变化,假设结构中的某些字段将在最佳内存边界上对齐可能会失败
• long整数的长度会发生变化,因此如果将套接字上的值传递给另一个可能不是64位的程序,则需要重构代码
• 指针长度发生变化,因为编写的代码难以破解,导致公司调试变得有点棘手
• 底层库还需要64位支持才能正确链接.如果您依赖任何非开源的库,这是移植代码问题的很大一部分

Answer 2

除了@ jvasak帖子中的内容之外,还有可能导致错误的主要内容:

• 指针大于整数 - 大量的代码假设大小相同.

请记住,Windows甚至不允许应用程序(无论是32位还是64位)处理地址高于0x7FFFFFFF(2GB或更高)的指针,除非它们被特别标记为,"LARGE_ADDRESS_AWARE"因为很多应用程序会将指针视为某些时候的负值并且会倒下.

Answer 3

我将C/C++代码移植到64位的最大问题是来自第三方库的支持.例如,目前只有32位版本的Lotus Notes API以及MAPI,因此您甚至无法链接它们.

此外,由于您无法将64位DLL加载到64位进程中,因此再次尝试动态加载动作.我们再次尝试在64位下支持Microsoft Access遇到此问题.来自维基百科:

在可预见的未来,Jet数据库引擎将保持32位.微软没有计划在64位版本的Windows下原生支持Jet

Answer 4

只是猜测，但我认为很大一部分是支持 - 如果 Adob​​e 编译 64 位版本，他们必须支持它。即使这可能是一个简单的编译开关，他们仍然需要进行大量的测试等，然后培训他们的支持人员正确响应，当他们确实遇到问题时，修复它们要么会产生新版本的32 位二进制文​​件或代码中的分支等。因此，虽然看起来很简单，但对于大型应用程序来说，它最终仍然会花费大量成本。