为什么制作64位版本的软件如此困难？

Question

在将您的软件设计成64位环境时，必须考虑到所有方面，为什么相同的代码不能像32位和64位那样工作(在讨论应用程序时)？

显然，驱动程序是另一个猛兽，缺少64位驱动程序是几乎所有硬件都臭名昭著的问题。在这个领域有什么不同，以至于几乎不可能找到驱动程序？

为什么制作64位版本的软件如此困难？

编辑:让我们忘记旧的，错误的软件与神奇的数字等的基本缺陷，并认为你会自己创建软件，以兼容两者。您需要考虑哪些方面，而在当前的编译器设计中，是否有些事情是您无法克服的？所有丢失的64位软件不可能仅仅是因为人们喜欢有神奇数字的代码吗？！:)

结论：似乎都是人类懒惰和历史原因，而不是技术原因。

Answer 1

这可能很难的一个具体原因是指针大小会有所不同。指针不再占用32位，指针现在将占用64位。

如果软件在某个地方通过int中的reinterpret_cast (可能发生在一些非常低级别的代码中)将指针缩进C++中，那么这就是一个问题，而这个问题发生的原因是，int和指针的大小是相同的。基本上，代码假定指针的大小是一定的。

另一种可以反击的方法是，如果代码中到处都是神奇的数字，比如4而不是sizeof(void*)，或者0xffffffff而不是INT_MAX或类似的东西。

如果软件依赖于64位中不可用的库或函数，则可能没有64位版本的软件。您不能拥有一个32位和64位的应用程序。例如，在Windows中，有一个名为SetWindowLong的函数只能接受32位的数据，所以如果需要将指针传递给函数，它对64位程序就不太有用了。这就是为什么有一个叫做SetWindowLongPtr的函数，它可以处理64位程序和32位程序中的64位。

请注意，Internet默认在32位上运行，甚至在64位窗口上运行，因为它的绝大多数插件只能在32位中使用。这方面的一个很大的例子是Adobe播放器，它只在32位中可用。因此，很明显，即使对于Adobe这样的大公司来说，64位数据的移植也并不总是那么简单。

比特转移操作可能会受到影响。例如，在32位中左移10次的0x80000给出了0x0，而在64位中左移了10次的0x80000给了您0x200000000。

尽管如此，如果代码编写得很好，那么将应用程序移植到64位并没有真正的技术原因。--最好的情况是，一个简单的项目重新配置和完全重建就足够了。

我愤世嫉俗的一面说，公司利用这一方式实施计划淘汰-强迫或鼓励人们升级到/购买最新的产品！

Answer 2

简单地说，在最流行的语言(C及其子语言)中，数据类型的大小和结构是非常重要的，并且是由实现定义的。实际上，C具有许多依赖于实现的特性。这意味着编写不可移植代码很容易。编写不对底层体系结构进行假设的代码并不是不可能的，但在尝试在不同的环境中运行代码之前，依赖x86特定于x86的行为是非常容易的。

主要是这些低层次的特性使得架构独立性变得困难。在诸如Python和C#这样的高级语言中，这要容易得多。

Answer 3

合理编写的软件通常很容易移植到另一个体系结构。看看NetBSD，Debian或者其他免费的OSes.许多开源软件工作在两种以上的架构上。

问题是，很多软件都是无视良好实践而编写的。使"it“工作通常是典型程序员所想到的唯一事情，而忽略了进一步的问题。典型的解释是:如果客户没有看到代码，并且它可以工作，那么为什么还要考虑良好的实践呢？为什么要花更多的时间在已经奏效的事情上？

这里的司机略有不同。不同的体系结构可能以不同的方式处理低级的东西。x86和Windows上的amd64还有另一个问题:微软为amd64驱动程序设定了更严格的标准--硬件公司不愿意为符合更严格要求的旧硬件生产驱动程序(同样:为什么要麻烦呢？客户通常已经用新的64位盒购买了新的硬件；如果他不购买，我们会让他通过不提供驱动程序来做到这一点)。同样，开源驱动程序通常同时工作在amd64和x86上。

我有一个声卡，它在Linux上的x86和amd64系统上都能很好地工作，但是由于这个问题，它不能完全适用于amd64 Windows。因此，为amd64编写驱动程序并非不可能；硬件公司只是不想这样做。

所以，你的问题的最终答案是:钱。