| |
更多内存更好性能 Windows64位软件世界 |
|
时间: 2006-02-08 来自：天极开发 |
 |
|
今天，64位计算正在逐步取代32位计算，并且，这个转换的过程会对当前软件的形式带来巨大的冲击。其中，转换需要移植相关的应用程序及重写系统软件，这当中还包括操作系统等等。在本文中，将主要探讨64位软件世界中的主角--64位Windows及64位的通用语言运行时库（CLR）的结构，另外，还将涉及移植到64位平台的种种有利之处。
当64位处理器面世之后，它们也存在一个逐渐被接受的过程，主要是因为缺乏相关软件的支持。为了利用64位处理器的特性，软件也必须重新构建--这可不是一晚上就能搞定的事情，不管怎样，近来由于软件与硬件开发商的共同努力，64位处理器的发展势头已越来越快。
比如说，直到去年的早些时候，Intel和AMD的64位处理器才逐渐出现在人们的视野之中，最开始，Intel的Itanium处理器基于IA-64架构，而AMD的Opteron及Athlon64基于x86-64架构。此外，在去年也出现了一些其他的变化，首先，AMD在64位处理器销售上，表现出一个领导者的姿态；其次，惠普也开始接受了AMD的处理器，并推出了基于AMD Opteron的HP ProLiant服务器；最后，Intel也对x86-64架构妥协了，宣布以EM64T（Extended Memory 64 Technology）的名称推出自己的x86-64处理器。
Microsoft Windows的64位版本
在软件方面，Microsoft已经研发出为桌面电脑准备的64位Windows--Windows XP Professional x64 Edition（http://www .microsoft.com/windowsxp/64bit/evaluation/upgrade.mspx），和为服务器准备的Windows Server 2003 x64 Edition（http://www.microsoft.com/windowsserver2003/64bit/x64/trial/default.mspx）。
64位Windows与32位Windows相比，其明显优势在于性能方面的提高及可伸缩性（因为64位处理器可在一个时钟周期处理更多的数据）、更快的速度、更精确的数字计算、及可访问更多的内存。可访问更多的内存意味着在单个计算机上，64位CPU可比32位CPU支持更多的用户，正是因为单个计算机与以往相比可支持更多的用户及运行更多的程序，对一个部门组织来说，它可以减少服务器的数量，以达到降低信息化总成本的目的。
话说回来，64位Windows想要获得市场接受，很大程度上还取决于对32位程序的支持程度，因此，程序从32位移植到64位，还需要一定的时间，在此期间，还必须可同时运行32位及64位程序，64位的Windows对此的支持是--广为人知的"WOW64"子系统。
WOW64
WOW64是"Windows 32 on Windows 64"的简称，它在系统层中另提供了一层，以支持老式的32位程序。首先，在64位版本的Windows中，系统文件不会全放在Windows\System32文件夹中，而是分开放在两个文件夹中，以区分32位程序与64位程序。WOW64子系统截取32位程序对系统文件的调用，并重定向到Windows\SysWow64文件夹，见图1。如果是64位程序的调用，则会直接转到Windows\System32文件夹。此处值得注意的是，Microsoft仍保留了System32文件夹，其主要用于保存64位系统文件。图2是运行着Windows Server 2003 x64 Edition系统的一个截图，重点标出了Program Files文件夹，其用于存储64位程序，而Program Files(x86)用于存储传统的32位程序。
 图1：文件系统重定向 |
 图2：运行Windows Server 2003 x64 Edition的系统 |
其次，WOW64子系统也提供了对注册表访问的重定向，见图3。如果是32位程序，那么WOW64将会截取对HKLM\Software访问，并重定向到HKLM\Software\Wow6432Node；如果是64位程序，就直接到HKLM\Software。图4是一个Windows 2003 Server x64 Edition系统上的注册表，说明了Wow6432Node。
 图3：注册表重定向 |
 图4：Wow6432Node |
尽管对32位应用程序而言，兼容性的目标是达到了，但对于驱动程序而言，却不是这样；64位的Windows对所有硬件都要求本地类型的64位驱动程序。
64位通用语言运行时库（CLR）
为了让64位平台得到更大范围的接受，必须在更大的范围内支持开发者可用的工具及开发平台，Microsoft对此的做法是，在其自己的核心开发平台-- .NET Framework上，增加64位支持。
.NET Framework 2.0现在已经可以单独下载或从Visual Studio.NET 2005中得到（与Visual Studio.NET 2005一起提供的版本提供了开发64位程序的平台），而且它有两个版本，一个为32位，另一个为64位（http://msdn.microsoft.com/netframework/downloads/ updates/default.aspx），也就是说，在64位的Windows上，有通用语言运行时库的两份拷贝。32位版本的 .NET Framework在文件夹\Windows\Microsoft.NET\Framework中，而64位版本的在\Windows\Microsoft.NET\Framework64文件夹中，参见图5。对此两个版本的Framework的配置选项也在"管理工具"中分别列出，见图6。
|
图5：.NET Framework 32位版本在\Windows\Microsoft.NET\Framework文件夹中，而64位版本在\Windows\Microsoft.NET\Framework64文件夹中
|
 图6：管理工具菜单 |
为什么要有两个Framework呢？其实，把源代码编译为MSIL中间语言代码的一个好处，就是可以充分照顾到各种硬件平台相关的细节。但在这种情况下，还必须考虑一些其他的因素，如：PInvoke和Interop，这些都是需要被特殊处理的；而使用Visual C++ .NET，也很容易创建程序集，其包含了托管与非托管的代码，这种程序集被称为"混合模式"程序集或"IJW（It Just Works）"程序集，不论是哪种情况，都涉及到平台相关代码，因此，就需要两个Framework，每一个都是针对于特定的平台。正是因为此，Microsoft发布了两个版本的Framework。请参见图7所示的全局程序集缓存（GAC），以加深了解，图中需重点注意的是"Processor Architecture（处理器架构）"，有三种类型--x86、AMD64和MSIL，其中，AMD64只在运行64位Windows的机器上显示；在运行基于Intel Itanium处理器的系统中，处理器架构一栏中，AMD64将会由Itanium取代，此处，处理器架构指明了程序集构建的特定平台。
 图7：全局程序集缓存（GAC） |
但是，在此处只有一个程序集会被编译为MSIL，因为MSIL对处理器架构来说是中立的，同一程序集可以不作任何修改而运行于x86或AMD64平台上。而这些MSIL程序集也被称作"可移植程序集"，例如，在图7中的System.xml只有一个版本，其处理器架构为MSIL。
然而，针对特定处理器架构构建的程序集需要分开存放，如AMD64架构的程序集或x86架构的程序集，这些程序集通常称为"特定平台程序集"，举例来说，请看图7中的System.EnterpriseServices程序集，就有AMD64与x86两个版本。
Visual C++ .NET 2005开发小组已经竭尽全力提供了尽可能多的基于MSIL的程序集，所以有时候只有一个版本。但是，在某些情况中，有必要重新编写代码以利用COM Interop或特定平台的某些功能--如指针大小。这些程序集不会出现在全局程序集缓存的特定平台栏中。
实际上，为在内部分开存放这些程序集，是把它们组织成不同的文件夹，图8在命令行中显示了\Windows\Assembly文件夹的情况，而表1则描述了这些文件夹的相关用途。
 图8：命令行中显示的\Windows\Assembly文件夹 |
| 文件夹 |
描述 |
| GAC |
存储 .NET Framework 1.0/1.1程序集 |
| GAC_32 |
存储使用 .NET Framework 2.0构建的32位程序集 |
| GAC_64 |
存储使用 .NET Framework 2.0构建的64位程序集 |
| GAC_MSIL |
存储可移植程序集；即那些处理器架构表示为MSIL的程序集 | 表1：GAC的组织结构
|
|
|
|
|
|
|
|
