有大量的驱动程序和著名的应用程序在 64 位中不可用。例如，Adobe 不为 Internet Explorer 提供 64 位 Flash 播放器插件。正因为如此，即使我运行的是 64 位的 Vista，我也必须运行 32 位的 IE。 Microsoft Office、Visual Studio 也不提供 64 位 AFAIK。
现在，就个人而言，我在 64 位中构建应用程序时没有遇到太多问题。我只需要记住一些经验法则，例如对于字符串长度等，始终使用 SIZE_T 而不是 UINT32。
所以我的问题是，是什么阻止人们构建 64 位？
【问题讨论】：
如果您是从零开始，64 位编程并不难。但是，您提到的所有程序都不是新的。
从头开始构建 64 位应用程序要比从现有代码库移植它要容易得多。移植时有很多陷阱，尤其是当您进入已经完成某种程度优化的应用程序时。程序员使用许多小假设来提高速度，而这些并不总是容易快速移植到 64 位。我不得不处理的几个例子：
long 整数的长度发生变化，因此如果通过套接字将值传递给可能不是 64 位的另一个程序，则需要重构代码【讨论】：
除了@jvasak's post中的东西之外，主要会导致bug的东西：
请记住，Windows 甚至不允许应用程序（无论是 32 位还是 64 位）处理地址高于 0x7FFFFFFF（2GB 或以上）的指针，除非它们被特别标记为 "LARGE_ADDRESS_AWARE"，因为有很多应用程序会在某个时候将指针视为负值并跌倒。
【讨论】：
我在将 C/C++ 代码移植到 64 位时遇到的最大问题是来自 3rd 方库的支持。例如。目前只有 32 位版本的 Lotus Notes API 和 MAPI，因此您甚至无法链接它们。
此外，由于您无法将 32 位 DLL 加载到 64 位进程中，因此您再次尝试动态加载内容会被烧毁。我们在尝试支持 64 位下的 Microsoft Access 时再次遇到了这个问题。来自维基百科：
Jet 数据库引擎将保留 32 位在可预见的未来。 微软没有计划在本地 64位版本下支持Jet 窗户
【讨论】：
只是一个猜测，但我认为其中很大一部分将是支持 - 如果 Adobe 编译 64 位版本，他们必须支持它。即使它可能是一个简单的编译开关，他们仍然需要进行大量测试等，然后培训他们的支持人员以正确响应，当他们遇到问题时修复它们会导致新版本的32 位二进制文件或代码中的分支等。因此，虽然它看起来很简单，但对于大型应用程序来说，它最终仍然会花费很多。
【讨论】：
许多公司没有努力创建 64 位版本的另一个原因是他们根本不需要。
Windows 具有 WoW64（Windows 上的 Windows 64 位），Linux 可以与 64 位一起使用 32 位库。这两者都允许我们在 64 位环境中运行 32 位应用程序。
只要软件能够以这种方式运行，就没有转换为 64 位的主要动力。
例外情况是设备驱动程序之类的东西，因为它们与操作系统的联系更深，并且无法在基于 x86-64/AMD64 的 64 位操作系统提供的 32 位层中运行（IA64 无法做到据我了解）。
我同意你对 Flash Player 的看法，但我对 Adobe 没有更新这个产品感到非常失望。正如您所指出的，它在 64 位中无法正常工作，需要您运行 32 位版本的 Internet Explorer。
我认为这是 Adobe 的战略错误。必须为 flash player 运行 32 位浏览器对用户来说是一种不便，许多人不会理解这种解决方案。这可能会导致开发人员担心使用闪存。对于一个网站来说，最重要的事情是确保每个人都可以查看它，疏远用户的解决方案通常不受欢迎。 Flash 的受欢迎程度来自其自身的受欢迎程度，使用它的网站越多，系统上拥有它的用户就越多，系统上拥有它的用户越多，愿意使用它的网站就越多。
零售市场推动了这些事情的发展，当普通消费者去购买一台新电脑时，他们不会知道他们不需要 64 位操作系统，因为他们听说它是最新和最伟大的事物，计算的未来，或者只是因为他们不知道其中的区别。
Vista 已经发布了大约 2 年，而 Windows XP 64 位在此之前就已经发布了。在我看来，如果 Flash 等主要技术想要保住自己的市场，那么不升级的时间太长了。这可能与 Adobe 接管 Macromedia 有关，这表明 Adobe 并不认为 Flash 是他们未来的一部分，我很难相信，因为我认为 Flash 和 Dreamweaver 是他们从 Macromedia 中获得的最重要的部分，但是为什么他们还没有更新呢？
【讨论】：
这并不像在编译器上打开一个开关那么简单。至少，如果你想把它做好，就不会。最明显的例子是您需要使用 64 位数据类型声明所有指针。如果您有任何代码对这些指针的大小做出假设（例如，每个指针分配 4 个字节内存的数据类型），您需要更改它。所有这些都需要在您使用的任何库中完成。此外，如果你错过了一些，那么你最终会导致指针被向下投射并位于错误的位置。指针不是唯一的难点，但肯定是最明显的。
【讨论】：
主要是支持和质量检查问题。对于大多数代码而言，为 64 位构建的工程工作相当简单，但测试工作和支持成本却不会以同样的方式缩减。
在测试方面，您仍然必须运行所有相同的测试，即使您“知道”它们应该通过。
对于许多应用程序而言，转换为 64 位内存模型实际上并没有带来任何好处（因为它们从不需要超过几 GB 的 RAM），而且实际上会使事情变慢，因为指针更大大小（使每个对象字段大两倍）。
再加上需求不足（由于先有鸡/先有蛋的问题），您就会明白为什么它对大多数开发人员来说不值得。
【讨论】：
他们的Linux/Flash blog 在某种程度上解释了为什么还没有 64 位 Flash Player。有些是特定于 Linux 的，有些不是。
【讨论】：