服务器软件现在已经有一段时间了（从Windows Server 2008 R2开始，甚至更早的Exchange和Sharepoint），甚至Ubuntu都推动你远离服务器操作系统的32位版本。
但是有什么好的，量化的理由来保持32位桌面操作系统的维护？ 我们正在准备我们的Windows 8的图像（不幸的？）less数将是早期采用者。
我们的大部分台式电脑都有4GB或更less的内存，但我不想再为32位风格的操作系统而烦恼。
任何理由，我应该？
在某些使用情况下，32位可能稍微快一点 – 较小的地址意味着更紧凑的代码，这意味着更高的caching效率。 在我看到的基准testing中，在重计算环境中64位的计算效率更高，效率往往会被掩盖。 但是32位实际上偶尔会在某些基准testing中获胜。 因人而异。 你的软件的年代很重要，因为新的版本利用了旧版本没有的64位版本。
代码更紧凑意味着更less的磁盘空间。 只要去64位和32位的口味下载你最喜欢的操作系统的ISO，看看有什么不同。 这不是微不足道的。 一旦你解压缩二进制文件，这也是相当多的。 正如OrangeDog所指出的那样 ：这种空间消耗大部分来自于64位操作系统除了64位操作系统外还有32位操作系统。
与32位的传统组件和软件仍然可以获得更好的兼容性。 在主机上dynamic编译的系统中，这一点尤其明显，但是同时引入第三方二进制库。 微软的.NET框架就是一个很好的例子：虽然这些程序在理论上是独立于架构的，但是当你链接到一个本地二进制文件时，你可以连接到一个或者另一个。 许多开发人员甚至不知道发生了这种情况，并且发布了无法在64位系统上运行的生产组件，而无需进行一些调整，以明确指示.NET以32位模式运行。 大多数人不知道如何做到这一点。
正如Daniel B所指出的那样：在64位机器上进行Windows .NET开发，会让你打开一个令人沮丧的不一致之处 ，在某些情况下，操作系统会屏蔽exception。
传统硬件。 您无法在64位内核上运行32位驱动程序。
这些都不会妨碍大多数人的表演。 但是，你必须决定这些因素如何影响你的环境。
我可以考虑保留一个32位桌面操作系统的唯一原因是如果您使用旧的16位（例如DOS）程序，而您没有支持Windows Virtual PC的Windows版本。
（即使这样我会安装一个64位操作系统，并使用像DOSbox的东西）。
编辑：其实还有另一个原因：硬件不能处理超过4GB的地址空间。 例如FireWire试图做DMA。 或者没有64位驱动程序的任何（旧）硬件。
任何运行Windows 8的东西都已经具备了64位的能力，除非你碰巧有一些第一代英特尔Atom上网本（我非常怀疑）。 这是我能想到的唯一的事情。
AMD在2003年发布了第一款支持64位的Opteron， 从那时起，几乎所有的处理器都具有64位的能力。
一年后，英特尔在2004年发布了第一款64位Xeon（Nocona），到2006年，该产品线扩展到了整个产品线。除了前面提到的Atom早期芯片之外，今天的每个英特尔处理器都是64位的。
如果您对古代历史感兴趣，维基百科会列出处理器列表。
与古代软件/硬件的兼容性。
如果一切工作在64位，我不会打扰32位。
很多人并不知道64位程序和库占用的内存比32位的内存要多。
例如，在使用低内存虚拟机时，build议使用32位操作系统来最大限度地提高该虚拟机内的内存可用性。
64位机器中的内存地址自然需要64位。 这些相同的地址在32位机器中占用32位。 在一些相当特殊的情况下，所需比特数的“增加”可能是内存限制机器上性能良好和性能差的区别。
除此之外，由于您可能在运行64位软件的计算机上运行32位软件，并且32位支持在64位计算机上运行得相当好，所以硬件方面的差异不会改变游戏规则。 偶尔你会发现一个没有64位硬件驱动程序的传统设备，但是现在非常罕见，因为十几年来64位操作系统已经可用了。
需要考虑的一点是，许多较老的32位应用程序在许多方面比较老旧。 在Windows操作系统方面，一个32位应用程序可能会困惑，如果它正在寻找“程序文件”，现在位于“Program Files（x86）”中的文件。 某些registry项目也可能需要手动注意。 这又是一个稍微错误的应用程序的function，现在需要你的帮助来“发现”如果机器碰巧是32位，那么“刚刚工作”的东西。
说到Ubuntu，我们现在已经在LTSP下运行了64位12.04 LTS。
我们遇到的唯一麻烦就是我们使用的LTSPterminal（Dell GX2xx）需要一个32位内核，因此我们必须编译第二个LTSP内核，并为这两个架构维护两倍的包。
LTSP是一个极好的例子，我认为64位是相当准备去，除非你的特定testing显示缺陷。
虽然我个人build议尽快升级到64位版本，只是尽快地咬紧牙关，但这不会对您的IT支持团队造成影响。 如果支持团队的带宽已经达到最大（即人员已经不够用了），那么我实际上会考虑等待。
所以，这是一个关于人力资源的答案，不仅仅是软件的兼容性。
推出当然应该是精心策划的（最好是渐进的而不是一次性的）。 将会有“发现”的问题，需要花费数小时才能在每个用户的基础上解决。 一旦发现了更常见的问题，“如何做”可以为支持电话和自助服务提供更快的解决scheme。
大多数情况下（例如），我正在考虑操作系统，特定软件包和相关插件 （如安装了32位和64位浏览器）之间的所有32位和64位（兼容性）问题和/或多个浏览器），“以pipe理员身份运行”和“以普通用户身份运行”的快捷方式，为这些浏览器提供32位和64位插件的选项（有时可能仅限于只能在一个版本的浏览器中工作的32位插件） – 所有这些都打破了构build在这些插件之上的应用程序和工作stream程。 （通过“插件”，我指的是从Java到Flash到embedded式PDF阅读器到networking会议软件的任何内容 – 无论是内部的还是广泛的，商业的和免费的。）您可以尝试testing所有这些问题，但它很难预测用户是否会在插件A之前无意中安装插件B，这会导致与在插件B之前安装插件A的另一个用户产生不同的结果（基本上，当用户的操作改变了插件A的状态时，系统。）
保持……任何东西的32位版本的唯一原因是支持“传统”应用程序和系统。 如果你可以在64位操作系统上运行所有的东西，那就算你自己幸运，继续前进吧。 你可能会像一些非技术公司一样处于企业环境中的可怜的SA，在这个公司环境中，从用户基础从XP到Windows 7的迁移计划从2014年第三季度开始。
< cries >
无论如何，我不知道Shift + Del ，我可能会把它们忽略在环境的某个angular落，以防发生无法形容的情况，而且你发现自己需要Windows XP的东西。 绝对不要停下来维护，更新，testing或其他对他们，但保持他们周围，如果他们永远需要。 前些天发生的事情是客户希望我支持一些Windows 2000 PoS，因为当Server 2003推出时（我真的也想这么做），我没有吹走所有的Server 2000映像。
尽pipe你们祈祷，希望时间永远不会到来，但为了“以防万一”，保留这些东西的代价是微不足道的，我觉得这是愚蠢的。
由于传统软件问题，我们只能说确保你运行的所有东西都可以在64位操作系统上运行。 如果这样做，那么你没有理由不迁移，假设许可不是一个因素。
在我的情况下，我能够重新configuration系统，使所有32位的应用程序能够在一台机器上运行，使所有其他工作站都是64位。 最后，我甚至将这台32位机器迁移到了VirtualBox上的虚拟机上，运行在Debian主机上，主要是因为容量在那里，我想减less箱子数量。
如果CPU不支持虚拟化（例如VT-xfunction），则以上和所有虚拟机都不能运行x64位代码。
缺lessVT-x等的几个更便宜的64位CPU对“自制”集群非常有吸引力。
从维基百科 ：
英特尔没有为其x86-64实现（英特尔64）添加分段支持，使得英特尔CPU无法实现64位纯软件虚拟化，但英特尔VT-x支持使英特尔平台上的64位硬件辅助虚拟化成为可能