在将您的软件设计到 64 位环境中时必须考虑的所有方面是什么，为什么相同的代码不能像 32 位和 64 位(在谈论应用程序时)一样工作？
驱动程序显然是一个不同的野兽，缺少 64 位驱动程序是几乎所有硬件的臭名昭著的问题。这个领域有什么不同，以至于几乎不可能找到驱动程序？
为什么制作 64 位版本的软件这么难？
编辑:让我们忘记带有魔数(Magic Number)等的旧软件的基本缺陷，并认为您会自己创建软件，以与两者兼容。您需要考虑哪些方面，是否存在当前编译器设计无法克服的问题？ 64 位软件的全部缺失不能仅仅因为人们喜欢带有魔数(Magic Number)的代码？! :)
结论 : 好像都是人的懒惰和历史原因，而不是技术原因。
最佳答案
这可能很难的一个具体原因是指针大小会有所不同。指针现在占用 64 位，而不是占用 32 位的指针。
如果某处的软件将指针硬塞进 int，这就是一个问题。通过 reinterpret_cast在 C++ 中(这可能会出现在一些非常低级的代码中)，它碰巧能工作，因为 int 的大小和一个指针大小相同。基本上，代码假定指针具有特定大小。
另一种可以反击的方法是，如果代码中充斥着像 4 这样的神奇数字。而不是 sizeof(void*) , 或 0xffffffff而不是 INT_MAX或类似的东西。
如果软件依赖于 64 位不可用的库或函数，则可能没有 64 位版本的软件。您不能拥有由 32 位和 64 位组成的应用程序。例如，在 Windows 中，有一个名为 SetWindowLong 的函数。它只能接受 32 位数据，因此如果需要将指针传递给函数，它对于 64 位程序不是很有用。这就是为什么有一个函数叫 SetWindowLongPtr 在 64 位程序中最多可以处理 64 位，在 32 位程序中最多可以处理 32 位。
请注意，即使在 64 位 Windows 上，Internet Explorer 默认在 32 位上运行，因为它的绝大多数插件仅在 32 位中可用。一个很好的例子是 the Adobe Flash Player ，仅在 32 位中可用。因此，显然即使对于像 Adobe 这样的大公司，为 64 位移植可能并不总是微不足道的。
位移操作可能会受到影响。例如，位移 0x80000 32位左10次给你0x0 , 但位移 0x80000 64位左10次给你0x200000000 .
尽管如此，将应用程序移植到 64 位太困难并没有真正的技术原因 如果代码写得好。 最好的情况是只需要简单的项目重新配置和完整的重建。
我愤世嫉俗的一面说，公司将此作为实现计划报废的一种方式 - 强制或鼓励人们升级/购买最新产品!
关于compiler-construction - 为什么制作 64 位版本的软件这么难？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3629336/