桌面文件我的 x64 经历

Wes Miller

Windows XP 本身对 64 位体系结构支持已有五年之久。但除非您是 Intel Itanium 处理器的先行采纳者之一（与 Windows XP 同一天发行的 Itanium 专用 Windows XP），您也许最近才听说有可以在 x64 体系中应用的 Windows XP 和 Windows

用于 x64 系统的 Server 2003 版本。x64（在业界也称为 x86-64）是对 AMD 的 AMD64 体系结构和 Intel 的 EM64T 的统称。而如果您是去年前后才购买的新 PC ，那么它很可能支持 64 位，即使当前还只是 32 位系统（最有可能的情况）。

如今我为德克萨斯州奥斯汀市的一家小型创业公司工作。由于我们产品之一的体系结构，我们对利用 x64 体系结构中某些特定的优点很感兴趣 — 这很像 Microsoft® Exchange 2007 团队，他们开创了只面向 x64 体系结构单独开发的先河。类似地，我所管理的开发和测试团队在开发工作站、笔记本电脑、服务器和生产服务器的时候，只在 Windows® XP 和 Windows Server® 2003 的 x64 版本上进行部署。此外，我还在自己的笔记本电脑上运行 Windows XP Professional x64 Edition 以便测试并调试我们的产品。

有趣的是，当我提到运行 64 位 Windows（尤其是在移动系统上）时，大多数人的第一反应都是非常困惑的神情。而如果他们熟悉 64 位计算，就感觉像怀疑遭到了别人的不屑与惊讶 — 因为人们通常都认为很难为 64 位系统找到设备驱动程序。在本月的专栏中，我将说明自己如何并且为什么在 x64 系统中的 64 位模式下使用 Windows XP 和 Windows Server 2003，同时我还会介绍一些您可能会遇到的部署优势（和障碍）。我还会深入探究 Windows Vista™ x64 的支持、迁移和部署事宜。

历史一瞥

正如我前面所说的，最初 Windows 中的 64 位支持确实是从支持 Intel Itanium 处理器开始的。（虽然 Windows 支持 64 位 Alpha 处理器，但却从未真正在 Alpha 上运行过 64 位。）Windows XP 和 Windows Vista 不支持 Itanium，所以 x64 体系结构目前也只是对 64 位 Windows 客户端计算的单相思。如今许多版本的 Windows Server 2003 都支持除 Itanium（基本上它已经只面对超高端数据中心负荷）外的 64 位，我认为这种趋势会持续应用到发售代码名为“Longhorn”的下一个 Windows Server 版本。

安装 Windows Server 2003 Service Pack 1 (SP1) 之后，Windows即可支持 x64 平台。这虽然有些令人困惑（当 x64 版本的 Windows XP 可用时也是如此），但也意味着 Windows XP 32 位产品和 64 位产品来源于 Windows 内部截然不同的代码树。现在 32 位产品已经有了第二版可用的 service pack；而从技术上来讲，64 位版本的 Windows XP 还根本没有 service pack（或者您可以认为它已经补充集成了 Windows Server 2003 SP1）。

为了运行 64 位 Windows（Windows XP、Windows Server 2003、Windows Vista 或 Windows Server“Longhorn”），系统的需求实际上是相同的。显然，首先要拥有 64 位处理能力的处理器。对 AMD 而言，这意味着寻找极力推崇 AMD64 兼容性（请参阅 amd.com/us-en/Processors/ProductInformation/0,,30_118,00.html）的单核、双核或四核系统。对 Intel 而言，这意味着寻找推崇 EM64T 支持或 Intel 64 体系结构（请参阅 intel.com/technology/intel64）的单核、双核或四核系统。请注意，细节决定一切。例如，Intel Core Duo 系统不支持 64 位。而 Intel Core 2 Duo 系统却是支持 64 位的 — 虽然它可能只是称为 Centrino Duo（我的笔记本电脑所使用的）。

与 x64 同在

一旦您确定了系统是否原本就支持 64 位 Windows 版本，您就需要处理设备支持的问题。遗憾的是，尽管 Microsoft 一直在鼓励供应商和 OEM（至少在过去两年的 WinHEC 会话中是如此）为其设备和系统创建并验证 64 位驱动程序，但您在使用 Windows x64 时遇到的最大难题依然是找到硬件设备的驱动程序或软件。以我的经验来看，要在服务器（其中必要的设备支持受到限制）上运行 x64 取得最大的成功，利用 x64 的优点则是最合乎逻辑的。

最困难的是寻找桌面和移动系统的驱动程序。通常情况下，如果您主要的 OEM 供应商或系统创建于企业级组件（商用的可能性迫使供应商或 OEM 创建并签署支持 x64 的驱动程序），那您就交到好运了。

对于 Windows Vista，这一情况变得越来越好。但人们都喜欢 x86 体系结构，而忽视大多数硬件可用驱动程序都很有限的 x64 体系结构，这也是事实。对于 Windows Vista，设备供应商必须提交 x64 驱动程序进行兼容性测试。事实上，提交不需要也包括 x86 驱动程序，当然也可以包括在内。从概念上来讲，这意味着某些硬件（尤其是那些利用 Windows Vista 新性能的设备）也许实际上只能支持 x64 Windows，而不支持 x86。

现实是，当您尝试运行 64 位 Windows 本身时，驱动程序只是您将遇到的其中一个问题。还有更棘手的问题（或者说迁移）等待解决，我会在后面讨论。

为什么使用 64 位？

当然了，AMD、Intel 和 Microsoft 并不是为了寻开心才涉足 64 位体系结构的。转移至 64 位会带来几个主要的益处。正如您在图 1 中所看到的，x64 体系结构提供的最重要的改进就是寻址更多的内存（最高可达 16TB）；相对而言，32 位 Windows 却只能寻址 4GB 内存。请注意，虽然 64 位指针寻址的上限为 16TB，但应用程序却只能访问最多大约 8TB。

Figure 1 内存地址空间限制

此外，Windows 的 x64 版本还提供了基于硬件的数据执行保护 (DEP) — 在有 NX（无执行）支持的 x86 系统上同样适用。这样做可以防止 Windows 利用的硬件驱动解决方案缓冲区溢出。它还防止从内存的数据页进行代码执行 — 请参阅 support.microsoft.com/kb/875352 了解关于本主题的更多信息。

与 x86 版本的 Windows 一样，x64 版本的 Windows 允许本身支持多处理器或多核 CPU。但在所有 Windows x64 安装过程中，单一硬件抽象层 (HAL) 的使用消除了映像 Windows XP 系统这个最复杂的难题 — 再也不必为识别非 ACPI 或单 CPU 系统中的 HAL 而烦恼了。

从本质上讲，Windows x64 作为体系结构允许使用现有的管理基础结构和现有的 32 位软件（通过模拟）以及拥有访问这种增强内存能力的 64 位软件。实际上，向 Windows x64 转变唯一的负面影响是：完全不支持 16 位应用程序（包括象带有 16 位安装程序的 32 位应用程序）；当硬件 DEP 启用时应用程序不能可靠运行的问题（尽管可以逐个进程停用 DEP，并且 Windows Application Compatibility 团队修补了一些 DEP 启用后无法正确运行的应用程序）；最后，事实上 64 位 Windows Vista 中的所有驱动程序必须进行数字签名。

加入最后一项是为了防止对内存中 Windows 内核的恶意篡改，这是 rootkit 经常使用的技术。我们的预期是，既然 x64 是第一个 Microsoft 鼓励供应商开发驱动程序（目的是通过 Windows 硬件质量测试得到驱动程序）的体系结构，那么要求也许并非象过去那么可怕。

在考虑面向 x64 系统的 Windows 时，还要注意其他一些要点。面向 x64 系统的 Windows XP 版本中并没有 Windows Media® Center Edition 或 Windows Tablet PC Edition 中所包含的功能。然而，这一情况在 Windows Vista 中却发生了改变，其中 Windows 的 x64 版本拥有与 x86 版本相同的功能。

虚拟化

有一件事之前我并没有提到，那就是虚拟化。我说的并不是 Microsoft Virtual PC 或 VMWare PC 虚拟化产品；而是指面向 32 位执行程序的操作系统虚拟化。在 Windows 的 32 位版本中，16 位应用程序全部运行于 NTVDM（一个 MS-DOS® 虚拟机）环境中。正如之前我提到的，Windows 的 64 位版本不支持 16 位应用程序。相反地，大多数 Windows 集成组件本身都以 64 位二进制程序运行，而部分组件和许多第三方程序以 32 位应用程序运行。

Windows 为您提供了一个全新的称为“窗中窗”(WOW) 的模拟层，以便查看这些 32 位应用程序在操作系统中的不同视图 — 在 Windows 的 32 位版本中运行颇为有效。在 WOW 下，x86 应用程序可以轻松地将 Program Files (X86) 看作“程序文件”。同样地，%WINDIR%\SysWOW64 对于 x86 应用程序显示为 %WINDIR%\System32。x86 应用程序查看注册表项 HKLM\SOFTWARE\Wow6432Node 就像查看 HKLM\SOFTWARE 节点本身一样。

通过使用 Process Explorer 工具，您可以从虚拟化的另一个角度进行查看。由于许多 32 位应用程序都预期与集成的 32 位 Windows 二进制程序相交互，因此许多这类二进制程序都同时提供 64 位和 32 位版本。通过对 Process Explorer 添加附加列，您可以方便地观察到这一点。在图 2 中，您会注意到 cmd.exe 的两个实例 — 一个是 32 位版本而另一个是 64 位版本。请注意，在突出显示的 32 位实例中，您可以看到若干加载于 32 位进程中的 wow64* DLL。这些文件显示了虚拟化的执行，即在 64 位 Windows 下实现 32 位应用程序的功能。同时注意 cmd.exe 64 位和 32 位版本使用的工作目录（路径）。

图 2** Process Explorer 显示 cmd.exe 的 32 位和 64 位版本 **(单击该图像获得较大视图)

关于虚拟化问题最后要注意的一点 — 当 Windows 将 explorer.exe 作为本机 64 位应用程序运行时，有利也有弊。最大的弊端就是要使任意 Explorer 外壳扩展工作必须面向 64 位重新编译（大部分尚未重新编译）。

相反的 Internet Explorer® 也一样 — 它本身默认以 32 位版本运行。这基本上已经实现，因此如今已大量运用于 Internet 上的 ActiveX® 控件还将继续取得成功。但如果不是这样，由于 64 位应用程序不能加载 32 位的 DLL 或进程中的驱动程序，因此也就无法有效的加载 32 位 ActiveX 控件，而在 64 位浏览器中，几乎所有目前可用的 ActiveX 控件都是 32 位的 — 这意味着将无法访问 Internet 上相当数量的内容。结合实例看一下，尝试在一个 64 位 Windows 系统中加载 C:\Program Files\Internet Explorer\iexplore.exe 并任意访问一个加载 ActiveX 控件内容（甚至是 Windows Update）的站点 — 结果就是会出现不同程度的加载失败。Windows Update（参见图 3）现在已经更新了在这种情况下打开 Internet Explorer 的 32 位实例的方式。将来，一些更新内容并利用 64 位 Internet Explorer 的 ActiveX 控件一定会出现。但在大多数 Windows 系统都运行纯 32 位 Windows 的今天，更新 ActiveX 控件内容并不是至关重要的。我希望这一转变不要来的太晚。

图 3** 32 位 ActiveX 控件在 64 位 Internet Explorer 中加载失败 **(单击该图像获得较大视图)

Pluck 公司的 x64 Windows

在本文的开始部分我曾说过，Pluck 公司已经开始转向 x64 Windows。我们已经在三个不同版本的 Windows 中完成了这项工作：Windows XP Professional x64 Edition、Windows Server 2003 Enterprise Edition x64 和 Windows Vista x64。

当我们最新的产品开发起步时，我们的组织规模很小，但我们已经可以进行向面对 x64 的 Windows 迁移并且利用了它的优势。这样做意味着确保我们定购的所有新硬件均支持 x64。实际上，正是虚拟化对 x64 扩展性能的影响才促使我们以这种方式运行产品。我们所有的物理服务器都作为 64 位虚拟服务器运行在 64 位主机服务器上。每一台主机服务器拥有 16GB 的 RAM，然后分配到位于其中的虚拟服务器中（大体是每一个分段虚拟主机或 VM 分配 2GB，而每一台生产 VM 分配 3GB）。

同时通过使用 tier 1 系统和虚拟的硬件，我们几乎实现了 100％ 的设备支持率。例如，我的笔记本电脑就有三个没有可用 x64 驱动程序的设备。这些如背板类型的设备并不重要，缺少了它们系统依旧可以正常运行。有趣的是，Windows Vista RC1 x64 有一项安装的设备支持完全相同 — 虽说我的系统有支持 Windows Vista 的徽标，然而供应商还是会在最短的时间内将您缺少的驱动程序交到您手中。

由于我们使用的系统主要限于 Microsoft Office、Visual Studio® 和一些开发和构建流程中用到的附加工具，因此在迁移的过程中不会遇到太多原有应用程序所引起的兼容性问题。在许多组织还在使用 Windows 的 32 位版本时，我们就已经在新硬件上开始了相对顺利的 64 位迁移历程。

x64 部署与迁移

关于部署需要考虑以下几点注意事项。Microsoft 提供了一个特别针对 x64 体系结构的 Windows 预安装环境 (Windows PE) 版本。然而，由于在 x64 系统上也有相同的 x86，那么您可能也打算使用 x86 Windows PE 进行部署 — 尤其当您使用的是映像解决方案时。如果您正在使用无人参与的安装来部署 Windows XP，那么 Windows PE 就必须拥有特定的体系结构 — 因为 winnt32.exe 必须在它所部署的相同体系结构下运行。由于 Windows PE 不具备 32 位兼容性层，而在 x64 下的 winnt32.exe 又是 64 位应用程序，因此 32 位的 Windows 就需要 32 位的 Windows PE。这同样适用于 Windows 的 64 位版本，它要求的是 64 位的 Windows PE。

在这方面远程安装服务 (RIS) 却是不同的，出于此原因，我们 Pluck 应用 RIS。RIS 最早应用于 Windows Server 2003 SP1，它可以部署 Windows 的 x64 及 x86 或 Itanium 体系结构。当一个 x64 系统连接到一台 RIS 服务器时，服务器（在默认配置下）将提供 x86 和 x64 的 RISetup 或 RIPrep 映像。我们还可以配置 RIS 同时提供 x64 客户端专用 x86 映像或专用 x64 映像。这一默认选项为 x64 硬件的应用带来了最佳体验。

请注意，我还没有提过升级。这样做是有原因的。不幸的是，对整个操作系统进行从 x86 到 x64 的升级是一件相当繁琐的事情。出于此原因（以及对 Windows XP Pro x64 Edition 的部署加以限制），您既不能从任何 x86 版本升级到 Windows XP x64，也无法从任何 Windows XP (x86 或 x64) 版本升级到 Windows Vista x64。同之前的 Windows XP Pro x64 Edition 一样，x64 系统上的 Windows Vista 也是只能进行全新安装的产品。因此，许多组织只有在硬件经常刷新时才会考虑移植到 x64 — 他们期望使用同 Windows Vista 本身类似的策略（同时使用双跳可能是个合乎逻辑的选择）。

但那却并不意味着从 x86 Windows 转向 x64 Windows 的个人或组织没有任何现成的工具 — 事实上肯定是有的。面向 Windows XP 和 Windows Vista 的两个用户状态迁移工具 (USMT) 版本都已扩展，用以支持从一个 Windows 安装到另一个安装的迁移（相对于操作系统的带内升级）。这是如今多数组织在不考虑擦除并重新加载的情况下最常用的方式（甚至是在同一台 PC 上），因此利用相同的机制迁移到一个全新体系结构的 Windows 时不应制造比原来更大的麻烦。

结束语

尽管我们这个小型组织向 x64 的逐步迁移也许会比大型组织所面对的庞大迁移进程简单许多，但每个 IT 专家都应该开始考虑最终转向 x64 体系结构了。事实是，虽然在今后十年间 x86 体系结构和 x86 本身的 Windows 版本仍将占有一席之地，但 x64 体系结构肯定是企业计算的将来。随着 Microsoft Exchange Server 和其他一些产品全面转向 x64，您首先需要开始了解 x64 系统将在安装在您体系结构中的何处，它们在您的 Windows Vista 迁移计划中起到什么作用，以及您正在使用的 Windows XP 或 Windows Server 2003 本身是否如今已经运行于 x64 系统中。

Wes Miller 是德克萨斯州奥斯汀市 Pluck 公司 (www.pluck.com) 的一位开发经理。在此之前，他在 Winternals Software 公司任职，并曾在 Microsoft 担任 Windows 程序经理和产品经理。Wes 的联系方式如下：technet@getwired.com。

© 2008 Microsoft Corporation 与 CMP Media, LLC.保留所有权利；不得对全文或部分内容进行复制.