64位Windows急需更多内存来捧场

 今天，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的组织结构通用语言运行时库（CLR）的变化
CLR已经作了内部的修改以支持64位计算，在很大程度上，此修改涉及到代码生成、垃圾回收、例外处理、和调试等等。
·代码生成。64位版本的CLR需支持64位本地应用程序的开发，这通常意味着对每一个新平台，都必须重新构建一个Just-In-Time（JIT）编译器，也就是大家所看到的IA64与x64平台。
·垃圾回收。64位处理器可寻址更大的内存，突破了32位系统中存在的4Gb内存界限。因此，垃圾回收机制也必须作相应修改，以支持更大的内存。
·例外处理。在对最终用户的使用方法保持不变的前提下，64位系统的例外处理已经彻底修改并重写。
·调试。调试器依赖于代码生成与例外处理子系统，因为一旦这两个子系统变了，调试器也必须跟着改变。
开发工具
在Visual Studio 2005中，Visual C++ .NET、Visual C#、Visual basic .NET已经支持64位应用程序的开发，而作为Visual Studio 2005另一个组成部分的Visual J#却不支持。图9描述了在Visual Studio 2005中对不同语言的支持，及这些托管语言所支持的平台环境。图9：Visual Studio 2005中的语言及平台支持
Visual Studio 2005集成开发工具仍会作为32位程序发布，并在WOW64系统下运行。大多数在32位平台上具有的功能，在64位平台上同样也具有，但要注意的是，此处没有'编辑并继续（Edit and Continue）'功能。
除了Visual Studio 2005，Windows platform SDK同样也提供了64位编译器工具集，其中包含了一个可用于开发64位应用程序的Visual C++编译器。
预防性措施
在开发64位本地应用程序之前，有必要弄清楚：我们到底应采取哪些步骤，以保证今天的程序将来可移植到64位？
在此，可参考以下一些预防性措施或使用一些工具，例如，Visual C++编译器支持/Wp64选项，以探测当前代码中存在的潜在移植性问题。
另外，在Visual Studio 2005的集成开发环境中，还有一个类似的工具--FxCop，通过在FxCop中加入一些规则，便可在编译时探测到移植性问题。
在托管语言方面，以下情况涉及到移植性问题：
·涉及COM Interop与平台调用的Interop相关代码：本地64位程序不能加载32位COM DLL，这就是说，一个64位的进程不能转变为32位代码，并在同一进程中成为一个32位DLL的宿主程序；不同处理器架构间的Interop也不能在同一进程中做到这一点。因此，当一个64位程序必须要调用COM DLL时，此COM DLL最好也是64位的。
·在许多情况中，这些COM DLL是第三方代码，所以你可能没有源代码。如果这样的话，程序就必须针对x86架构重新构建，并且运行于WOW64子系统中。还有一个解决的办法，在另一个单独的32位进程中加载此32位的DLL，由64位程序对此进行RpC调用。
·浮点数的相等比较。不能保证同一IL中间语言代码在32位与64位平台上有相同的结果，因此，推荐不要直接进行浮点数的相等比较。浮点数在64位计算机上的表示法基于IEEE-754标准，其允许差分计算，这会对那些对精度要求非常高的金融程序与图形程序带来很大的影响，必须重新设计算法以应对此问题。有关更多信息，请参考：http://docs.sun.com/source/806-3568/ncg_goldberg.html
·使用StructLayout属性对结构数据排列方式的显式控制。属性 StructLayout可应用于结构和类，当它被显式地指定时，必须精确地控制非托管内存中对象的每一个成员的位置。相对于32位平台，因为数据类型长度有所变化，所以结构的打包也有所不同，因此，必须避免显式地控制结构的排列方式。
·对数字的位操作。C#提供了位操作符，包括了AND、OR、左移位和右移位操作符。对数据类型的位操作，在32位与64位计算机上会有所变化，这是因为平台间数据类型的内部表示方法会有所不同。
·自定义串行化。 .NET Framework对串行化提供了两个选项--通过使用Serializable属性实现自动串行化，或对类型实现ISerializable接口达到自定义串行化的目的。当使用 .NET Freamwork提供的最基本的串行化机制时，不会发生什么问题，然而，当通过ISerializable实现自定义串行化时，得出的结果会因为32位与64位平台而有所不同，具体依赖于为实现自定义串行化而采用的方法。当然，也许程序中会多次用到涉及上述的功能，在这种情况下，必须分别构建和测试32位与64位版本的程序。使用Visual Studio 2005进行开发
回头再看，Visual Studio 2005可支持64位应用程序的开发，其所支持的平台如表2中所示。平台 描述 AnyCpU 生成不依赖于特定平台的程序集，通常称为'可移植程序集' x86 生成针对x86平台的32位程序集 x64 生成针对x64平台的64位程序集 Itanium 生成针对Itanium平台的64位程序集
表2：针对不同平台，Visual Studio 2005所支持的64位程序开发
在编译程序期间，可在'工程'的'属性页'中设置目标平台，属性页包括一个构建栏，可以让你指定相关的平台。例如在图10中，C#和Vb.NET的编译器选项为'/platform'，在Vb.NET中，也可在'高级编译器设置'对话框中找到同样的选项。图11中所示的目标CpU下拉框允许设置程序所需的特定CpU类型。图10：编译器目标平台可选项图11：目标CpU下拉框
当然，使用特定的设置依赖于特定的情况：
·AnyCpU选项生成平台无关程序集，这也是集成开发环境（IDE）的默认设置。一个通过AnyCpU选项编译的程序集可毫无问题地运行在x86、x64及Itanium平台上，而生成的程序集基于pE32格式（pE32是所有EXE及DLL用到的格式）。
·x86选项用于生成特定于32位Intel x86兼容处理器平台的代码。所生成的程序集同样也基于pE32格式，可运行于WOW64子系统中。
·x64选项用于生成特定于x86处理器架构的64位本地程序的代码。所生成的程序集基于pE32 {+}格式（其为现有pE32格式的扩展），只能运行在64位x64架构的计算机上。
·Itanium选项用于生成特定于Itanium（IA-64）处理器架构的64位本地程序的代码。所生成的程序集同样也基于pE32 {+}格式，只能运行在基于64位Itanium的计算机上。
也许开发出来的程序不必运行在所有的平台上，因此，就不必构建成一个平台无关的程序，这样的话，开发过程中就能充分利用诸如 #define、#if之类的预编译指令，可以用这些预编译指令带上条件编译常量，来包装针对特定目标平台的代码。
以下是推荐的条件编译常量：
·_AMD64_ 用于针对AMD64平台的代码
·_IA64_ 用于针对IA64平台的代码
·_WIN64_ 用于指定任一64位Windows平台代码
加载一个 .NET可执行文件
在编译生成可执行文件时，指定的编译器选项会被嵌入到所生成pE32或pE32{+}可执行文件中。而pE32{+}格式是pE32格式的扩展，含有关于机器类型的更多信息。
在pE32中，CLR头包括一些额外的标志，如：ILOnly和 32bitRequired，ILOnly只出现在当平台被设置为AnyCpU时，而32bitRequired出现在平台被设置为x86时，而当平台被设置为x64或Itanium时，就会生成嵌入了机器相关信息的可执行文件。
OS Loader（操作系统加载器）根据这些设置来加载相应的可执行文件，图12演示了OS Loader加载可执行文件时的控制流程。图12：OS Loader（操作系统加载器）加载可执行文件的流程
当OS Loader发现可执行文件为pE32 {+}时，会把它作为一个64位进程加载；如果不是，接下来会检查ILOnly标志，如果也没有，则会使用WOW64子系统把它作为一个32位可执行文件加载。
当设置了ILOnly标志时，会进一步地检查是否32bitRequired标志也设置了，如果是，也会被WOW64子系统加载，否则，将重映像为pE32+，并作为一个64位程序加载。
那程序速度更快了吗？
大多数人在想到64位计算时都会问同样一个问题：64位程序与32位程序相比，是不是更快一些呢？这也许是关于64位技术的一个误区，对此的回答是：'也许吧'。这样回答的原因是，程序的速度或者说性能，基于许多的因素，不可能立马下结论表示 64位程序一定就更快。64位计算的好处在于，它打开了更先进软件设计的大门--这些软件能充分利用64位处理器访问更大的内存、在单个时钟周期能处理更多的数据，相对于类似的32位程序，新生的64位程序可表现出惊人的效果。
业界的64位趋势
许多Windows软件开发商，现在已开始发布基于64位Windows的软件产品了。
·AMD发布了一个Windows上的性能分析器--AMD Code Analyst，参见http://www.amd.com/us-en/processors/DevelopWithAMD/0,,30_2252_869_3604,00.html
·InstallShield 10.5已支持64位程序的安装。参见http://www.installshield.com/downloads/installshield/aag.pdf
·Compuware发布了名为'Devpartner64'的64位Devpartner Studio。参见http://www.compuware.com/products/devpartner/64.htm
·针对AMD64平台的Java 2 platform Standard Edition 5.0 (J2SE)现在也可以获取了。参见http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&partDetailId=jdk-1.5.0-rc-windows-amd64-JpR&SiteId =JSC&TransactionId=noreg
·硬件生产商也为它们的产品发布了64位的驱动程序。此处可找到一个完整的列表：http: //http://www.amd.com/us-en/processors/DevelopWithAMD/0,,30_2252_875_10454,00.html；其中NVIDIA已经为它的全系列GpU与nForce 4芯片组发布了64位驱动程序。
·游戏总是会用到最新最强大的硬件，例如Unreal Tournament (http://www.amd.com/us-en/processors/productInformation/ 0,,30_118_10220_9486%5E9621~75301,00 .html)、Far Cry (http://www.amd.com /us-en/processors/DevelopWithAMD/ 0,,30_2252_875_10543,00.html)、和Shadow Ops: Red Mercury (http://www.amd.com/us-en/processors/ ComputingSolutions/0,,30_288_11054_ 11705,00.html)。(Shadow Ops的64位增强版本http://www.atari.com/shadowops/us/amd.html)
总而言之，64位Windows将会带领我们进入一个崭新的64计算时代，让我们一起期望这一天的早日到来。

 

来源:http://www.96pc.com/Jc/Jq/476.html