【问题标题】:Why is it so hard to make 64-bit versions of software?为什么制作 64 位版本的软件这么难?
【发布时间】:2011-04-07 11:00:21
【问题描述】:

在将您的软件设计到 64 位环境时必须考虑哪些方面?为什么相同的代码不能与 32 位和 64 位一样工作(在谈论应用程序时)?

驱动程序显然是另一种野兽,缺少 64 位驱动程序是几乎所有硬件的臭名昭著的问题。该领域有什么不同以至于几乎不可能找到驱动程序?

为什么制作 64 位版本的软件这么难?

编辑:让我们忘记带有幻数等的旧软件的基本缺陷,并认为您应该自己创建软件,以兼容两者。您需要考虑哪些方面,以及当前编译器设计无法克服的问题?所有缺少的 64 位软件不能仅仅因为人们喜欢带有幻数的代码吗?! :)

结论:似乎都是人的懒惰和历史原因,而不是技术原因。

【问题讨论】:

  • 如果你想要一个好的答案,你应该更具体。例如,制作 64 位版本的 .NET 应用程序是无脑的——将其设置为编译为 Any CPU 或 x64。很明显,您不是在谈论 .NET 应用程序,而是您在谈论什么? :)
  • 我一般来说是什么技术原因导致无法使用完全相同的代码库来构建 32 位和 64 位应用程序。因为如果只是重新编译,所有库也可以作为 64 位等使用,那么所有应用程序也可以重新编译为 64 位 -> 即。没问题。
  • "所有丢失的 64 位软件不能仅仅因为人们喜欢带有幻数的代码吗?!" - 很多丢失的 64 位软件可能是因为不需要它。如果我错了,请有人纠正我,但我听到的经验法则是:除非您可能寻址超过 4 GB 的内存,否则您应该编译为 32 位。
  • @Nate - 至少在 Windows 上,32 位程序在仿真层 (WOW64) 上运行。此外,Windows 上的 32 位程序不会像 64 位程序那样看到 Windows,因为注册表/文件重定向和其他向后兼容性的事情。
  • @In silice:WOW64 不是(总是)仿真层。在最常见的 AMD64 架构上,CPU 只是简单地切换到 32 位模式以用于 32 位线程,并且不需要仿真。见en.wikipedia.org/wiki/WoW64

标签: compiler-construction 64-bit 32bit-64bit


【解决方案1】:

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

如果某处的软件通过 C++ 中的 reinterpret_cast 将一个指向 int 的指针插入到 int 中,就会出现问题(这可能发生在一些非常低级的代码中),并且它恰好可以工作,因为 int 的大小和指针大小相同。基本上,代码假定指针具有一定的大小。

另一种可以反击的方法是,如果代码中充斥着神奇的数字,例如 4 而不是 sizeof(void*),或 0xffffffff 而不是 INT_MAX 或类似的东西。

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

请注意,即使在 64 位窗口上,Internet Explorer 也默认在 32 位上运行,因为它的大部分插件仅在 32 位中可用。一个很好的例子是the Adobe Flash Player,它仅在 32 位中可用。因此,显然即使对于像 Adob​​e 这样的大公司来说,移植 64 位也并非总是那么简单。

位移操作可能会受到影响。例如,将0x80000 在 32 位中左移 10 次得到0x0,但在 64 位中将0x80000 左移 10 次得到0x200000000

话虽如此,如果代码写得好,将应用程序移植到 64 位太困难并没有真正的技术原因。 最好的情况是简单的项目重新配置和只需完全重建即可。

我愤世嫉俗的一面说,公司将此作为实施计划淘汰的一种方式 - 强迫或鼓励人们升级/购买最新产品!

【讨论】:

  • 但是为什么会有这样的问题呢?编译器不应该知道得更好吗?
  • 可以,但是如果代码使用reinterpret_cast,编译器不会发出诊断信息(这就是为什么需要仔细进行类型转换的原因)。
  • 我说的是质量合理的软件,没有用幻数等填充。如果有帮助,请考虑自己创建软件以在两个世界上兼容。
  • 感谢您更新您的答案,但如果只是重新编译,那么库问题将不是问题。所有库也将作为 32 位和 64 位版本存在。我正在寻找答案为什么不是这样:)
  • @Tuminoid - 这取决于图书馆作者实际花时间来做这件事。 :-) 库源代码甚至可能不再可用。
【解决方案2】:

合理编写的软件通常很容易移植到另一个架构。看看 NetBSD、Debian 或其他大型免费操作系统……许多开源软件都适用于两种以上的架构。

问题在于,很多软件都是在无视良好实践的情况下编写的。让“它”工作通常是典型程序员唯一想到的事情,而忽略了进一步的问题。典型的解释是:如果客户没有看到代码,为什么还要打扰良好的做法,并且它有效?为什么要花更多时间在已经有效的事情上?

这里的驱动程序略有不同。不同的架构可能以不同的方式处理低级的东西。 Windows 上的x86amd64 有另一个问题:微软为amd64 驱动程序制定了更严格的标准——硬件公司不会费心为符合更严格要求的旧硬件生产驱动程序(再次:为什么要麻烦?客户通常已经用他们的新 64 位机器购买新硬件;如果他不这样做,我们将通过不提供驱动程序让他这样做)。同样,开源驱动程序通常同时适用于 amd64x86

我的声卡在 Linux 上的x86amd64 系统上都能很好地工作,但由于这个问题,它不能在amd64 Windows 上工作。所以为它写一个amd64的驱动也不是不可能的;硬件公司只是不想这样做。

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

【讨论】:

  • 我有一台 6 个月大的佳能彩色激光打印机,但他们没有提供 64 位驱动程序,这是 *** 的主要痛苦。所以购买新硬件并不能带来快乐......
【解决方案3】:

简而言之:在最流行的语言家族(C 及其子语言)中,数据类型的大小和结构非常重要,实现定义。事实上,C 有很多依赖于实现的特性。这意味着编写不可移植的代码很容易。编写不对底层架构做出假设的代码并非不可能,但是在尝试在不同的环境中运行代码之前,很容易依赖 x86 特定的行为而没有意识到自己做了什么。

主要是这些低级特性使架构独立变得困难。在 Python 和 C# 等高级语言中,这要容易得多。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2023-03-03
    • 1970-01-01
    • 2010-09-24
    • 2012-01-10
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多