保留32位Microsoft Windows桌面操作系统的充分理由

这个问题来自2012年。如果您在2019年或以后阅读此书，那么答案确实是：不会。在2019年没有充分的理由维护32位桌面操作系统。

以下是原始问题：

服务器软件现在只有64位了一段时间（自Windows Server 2008 R2起，甚至对于Exchange和Sharepoint来说更早），甚至Ubuntu也使您远离服务器操作系统的32位版本。

但是，是否有任何良好的，可量化的理由来维护32位桌面操作系统？我们正在准备Windows 8映像，以便为（不幸的？）少数将是早期采用者。

我们大多数台式机具有4gb或更少的RAM，但是我希望不必再麻烦地支持32位调味的操作系统。

我为什么要这么做？

• 在某些使用情况下，32位可能会稍快一些-地址越小，意味着代码越紧凑，意味着缓存效率越高。在我看到的基准测试中，在繁重的计算环境中，效率往往被64位更高的计算效率所掩盖。但实际上32位确实偶尔会在某些基准测试中获胜。YMMV。软件的年龄很重要，因为较新的版本会利用64位的东西，而较旧的版本则不会。

• 代码更紧凑意味着磁盘空间更少。只需下载64位和32位版本的您最喜欢的OS的ISO，即可了解它们之间的区别。这不是小事。这也是不少更当你解压缩二进制文件。正如OrangeDog指出的：这种空间消耗大部分来自以下事实：64位OS除了64位OS之外，还附带32位库。

• 您仍然可以获得与32位旧组件和软件的更好兼容性。这在可以在主机上动态编译但同时提取第3方二进制库的系统中尤其明显。微软的.NET框架就是一个很好的例子：虽然这些程序在理论上是与体系结构无关的，但是只要您链接到本机二进制文件，就可以绑定到一个或另一个拱门。许多开发人员甚至都不知道这种情况的发生，并且会交付生产组件，这些组件将无法在64位系统上运行，而无需进行一些调整即可明确指示.NET以32位模式运行。大多数人不知道该怎么做。

• 正如Daniel B指出的那样：在64位计算机上进行Windows .NET开发会导致令人沮丧的不一致，在某些情况下操作系统会掩盖异常。

• 旧版硬件。您不能在64位内核上运行32位驱动程序。

对于大多数人来说，这些都不是一个令人大跌眼镜的事。不过，您必须决定这些因素如何影响您的环境。

我可以想到保留32位桌面操作系统的唯一原因是，如果您使用旧的16位（例如DOS）程序，并且没有支持Windows Virtual PC的Windows版本。

（即使那样，我仍将安装64位OS并使用DOSbox之类的东西）。

编辑：实际上还有另一个原因：硬件无法处理超过4GB的地址空间。例如，FireWire尝试执行DMA。或任何没有64位驱动程序的（旧）硬件。

除非您碰巧拥有一些第一代Intel Atom上网本，否则所有将运行Windows 8的设备都已具备64位功能（我对此非常怀疑）。那是我唯一能想到的。

AMD于2003年发布了首款支持64位的Opteron。从那时起，实际上他们制造的每个处理器都具有64位功能。

一年之后，英特尔于2004年发布了其首个64位Xeon（Nocona），并在2006年扩展到几乎整个产品线。除了上述早期的Atom芯片以外，今天的每个Intel处理器都是64位。

如果您对古代历史感兴趣，那么Wikipedia的处理器列表将有所细分。

与古代软件/硬件的兼容性。

如果一切都在x64下工作，我就不用32位了。

64位计算机中的内存地址自然需要64位。这些相同的地址在32位计算机中占用32位。在某些非常特殊的情况下，所需位数的“增加”可能是内存受限机器上的良好性能与不良性能之间的区别。

除此之外，由于您可能在一台可能始终运行64位软件的计算机上运行32位软件，并且32位支持在64位计算机上相当有效，因此硬件方面的差异不会改变游戏规则。有时，您会发现没有64位硬件驱动程序的旧设备，但是由于64位操作系统已经使用了十多年了，所以这种设备现在非常罕见。

需要考虑的一点是，许多较旧的32位应用程序在许多方面都比其位型更旧。在Windows操作系统方面，如果32位应用程序正在“程序文件”（x86）中查找“程序文件”中的文件，则可能会感到困惑。某些注册表项同样可能需要手动注意。再次，这更多是一些应用程序编写有误的功能，这些应用程序现在需要您的帮助才能“发现”如果机器恰好是32位，则本应“正常工作”。

许多人不知道64位程序和库比32位等效程序和库占用更多的内存。

例如，当使用低内存虚拟机时，建议使用32位操作系统以最大程度地提高该VM内的内存可用性。

说到Ubuntu，我们已经在LTSP下运行64位12.04 LTS了几周了。

最初的Beta测试人员遇到的唯一麻烦是我们使用的LTSP终端（Dell GX2xx）需要32位内核，因此我们必须编译第二个LTSP内核并为这两种体系结构维护两倍的软件包。

LTSP非常适合边缘环境，除非您的特定测试表明存在缺陷，否则我认为64位已经可以使用了。

尽管我个人建议尽快升级到64位，并且尽早而不是迟早地解决问题，但这不会对您的IT支持团队造成影响。如果支持团队的带宽已经扩展到最大（即，人员不足），那么我实际上会考虑等待。

因此，这是一个涉及人力资源的答案，而不仅仅是软件的兼容性。

当然，应该仔细计划部署（最好是逐步而不是一次）。每位用户都将需要花费数小时才能解决“发现”的问题。一旦确定了更常见的问题，“操作方法”可以为支持呼叫和自助服务提供更快的解决方案。

通常，（例如）我正在考虑操作系统，特定软件包和相关插件之间的所有32位和64位（in）兼容性问题。，例如在单个64位操作系统上同时安装了32位和64位浏览器（和/或多个浏览器），“以管理员身份运行”与“以普通用户身份运行”的快捷方式，对于32以及适用于这些浏览器的64位插件（有时可能仅限于只能在一种版本的浏览器中使用的32位插件），这些都破坏了基于这些插件构建的应用程序和工作流。（通过“插件”，我的意思是从Java到Flash，嵌入式pdf阅读器再到网络会议软件-可以是内部构建的，也可以是广泛使用的，包括商业版本和免费版本。）您可以尝试测试所有这些问题，但是很难预测用户是否会无意中在插件A之前安装了插件B，这导致的结果与另一个在插件B之前安装了插件A的用户的结果不同（基本上是

保留所有内容的32位版本的唯一原因是支持“旧版”应用程序和系统。如果您可以在64位OS上运行所有程序，请指望自己并继续前进。您可能就像一些穷人SA，他们在一家非技术公司的公司环境中，从用户群从XP迁移到Windows 7的计划始于2014年第四季度。

< 哭声 >

无论如何，我不了解Shift+ Del，并且可能会在环境的某个角落将它们忽略，以防万一发生无法言状的情况并且您发现自己需要Windows XP某些东西。绝对不要再费心去维护，更新，测试或进行其他任何操作，但是在需要它们时，请保留它们。有一天，客户希望我支持一些Windows 2000PoS，我可以这样做，因为出镜时我并没有丢掉我所有的Server 2000图像Server 2003（我也确实想这么做）。

正如您祈祷并希望时间永远到来一样，“以防万一”周围的东西总是很高兴，而且保持它的成本如此之小，以至于我认为不这样做是愚蠢的。

由于遗留软件问题而遇到了很多问题，我只能说要确保您运行的所有内容都可以在64位OS上运行。如果确实如此，那么假设许可不是一个因素，那么您就没有理由不进行迁移。

以我为例，我能够重新配置系统，以便所有32位仅应用程序都可以在一台计算机上运行，​​从而使所有其他工作站均为64位。最终，我什至将该32位计算机迁移到了运行在Debian主机上的Virtualbox上的VM，主要是因为那里有容量，并且我想减少存储盒数。

如果CPU不支持虚拟化（例如VT-x功能），则上述所有虚拟机和几个虚拟机都无法运行x64位代码。

但是，一些便宜的缺少VT-x的64位CPU对于“自制”集群很有吸引力。

来自维基百科：

英特尔没有为其x86-64实现（英特尔64）添加分段支持，从而使得在英特尔CPU上不可能进行仅64位软件的虚拟化，但是英特尔VT-x支持使在英特尔平台上可以进行64位硬件辅助的虚拟化。