Windows 64 位体系结构.docx
- 文档编号:5805903
- 上传时间:2023-01-01
- 格式:DOCX
- 页数:14
- 大小:241.78KB
Windows 64 位体系结构.docx
《Windows 64 位体系结构.docx》由会员分享,可在线阅读,更多相关《Windows 64 位体系结构.docx(14页珍藏版)》请在冰豆网上搜索。
Windows64位体系结构
Windows64位体系结构(转自微软)
发布日期:
2006-7-10|更新日期:
2006-7-10
1.重要概念
本节介绍Windows64位体系结构,以及迁移一个32位解决方案(包括C++和.NET托管应用程序)最有效的策略。
多数情况下,迁移到64位是比较简单的。
当然,也可能存在一些难题,本文将介绍一些最与之相关的问题。
迁移策略示例包括托管代码和非托管代码。
对于非托管代码(C/C++),迁移到64位的重点在于64位指针以及如何在代码基中处理它们。
对于托管代码,迁移路径甚至比在C++中更加简单。
在多数情况下,可验证的托管代码无需进行任何更改即可在64位机上运行—它已经是64位了。
此外,本节还阐释为什么要迁移到64位,以及此举有诸多优势(技术和商业上的益处)的原因。
同时,还介绍相关的Microsoft技术(包括COM和COM+)及其对迁移产生的影响。
1.1从16位到32位以及从32位到64位
从16位迁移到32位通常是一个痛苦的过程。
很多细节(例如,指针对齐、类型大小、函数入口点、API更改和库调用模型)使该迁移变得复杂且容易出错。
现在,在从32位迁移到64位时,虽然该过程也需要一些更改,但更改数量远比从16位迁移到32位时所需的更改要少,而且也不像它们那样至关重要。
例如:
•
内存模型保持一致(基本数据类型保持一致)。
•
没有入口点问题。
•
焦点在指针和派生类型上,它们现在是64位。
32位中的内存模型是ILP32;而64位中是IL32P64。
该内存模型和Unix64位内存模型(I32LP64)之间最显著的区别是,该内存模型的长整型仍然是32位的,而在Unix中是64位的。
API
数据模型
int
long
pointer
Win32
ILP32
32
32
32
Win64
IL32P64
32
32
64
UNIX
I32LP64
32
64
64
此外,有一些新类型的内存模型,它们利用诸如INT64、LONG64等的64位体系结构。
但是,由于基类型保持不变,因此迁移到64位的过程对开发人员的代码基的影响将是很小的。
这对于Microsoft的64位迁移策略而言是一个重要的考虑事项。
该策略极大地简化了开发人员的迁移路径,同时既允许开发人员继续使用64位数据类型的扩展功能,又允许他们打破32位的4GB限制。
1.2WindowsAPI
从32位迁移到64位并非只是重新编译这样简单。
实际上,开发人员可以设计代码,以便它可以针对32位和64位进行编译。
没有针对64位的新API集或Win64模型;同样,我们熟知的Win32API现在称为WindowsAPI。
开发人员所有的Win32API经验和知识均可直接用在64位API。
64位迁移的重点在于支持64位指针;这是Windows对于32位处理器和64位处理器的主要区别。
1.364位处理器
今天的64位处理器是结合了最新的创新和研究成果的先进技术。
这些新处理器不仅仅支持大型服务器;64位也适用于工作站和其他方案。
首先,让我们看一下Itanium处理器家族(IPF)的64位Itanium2处理器:
•
该处理器的EPIC体系结构相对于旧式32位芯片集而言,极大地提高了性能。
•
EPIC表示显式并行指令代码(ExplicitParallelInstructionCode),它是一个新的指令集,用于高级别的并行操作并允许最多并行执行9条指令。
•
Itanium专用于特大级别的可伸缩性。
•
它能够构建最多具有512个处理器的系统
•
目前有很多32位系统可用,甚至有少量64位系统可用。
•
大量寄存器(特别是浮点寄存器)首选择Itanium做为其用于浮点操作的类。
IPF的替代品是x64处理器。
实际上有两组x64处理器;AMD64位处理器(Athalon和Opteron)和IntelXeonEM64T。
AMD已决定,截止到2004年底完全启用64位处理器。
带有64位扩展的Xeon是X64市场中的Intel芯片。
Intel已经交付了具备64位支持的Pentium。
由于AMD和Intel处理器运行相同的二进制文件,因此这两者都称为x64。
X64的一个优点是可以本机运行32位和64位代码,这意味着在64位系统上运行32位应用程序时不会有性能损失。
而IPF的情况则不然。
IPF有自己的二进制文件,该二进制文件不兼容X64二进制文件;但是,Windows64位在这两种处理器上是等同的。
从开发的角度看,相同的源代码可以在这两种平台的任意之一上进行编译,而不会有任何问题。
虽然MicrosoftWindowsServerTM2003和WindowsXP64位的二进制文件是不同的,但是它们的功能百分之百地兼容。
开发人员应该了解,Windows64位与Windows32位几乎是完全相同的。
Windows64位是由同一个团队创建的,他们使用相同的过程和源代码树并经过相同的测试环节。
Windows64位版本与Windows32版本是完全同步的。
然而,它们之间也存在一些差异。
例如,这两者之间有5个API是不同的。
由于两个API之间的区别不明显,因此开发人员知道他们的应用程序无论是作为32位运行还是作为64位运行,其行为都会是一致的。
在多数情况下,他们可以针对三个平台使用相同的源代码基,只是体系结构优化上略有区别。
2.内存比较
64位的基本原理是什么?
它的优势在哪里?
64位的最大优势就是内存很大。
下表列出用户和操作系统目前可用的内存,以及32位4GB边界的限制如何遭到淘汰。
64位提供的内存访问是平面的;没有任何内存减损,就像使用/largeaddressaware或AWE一样。
体系结构组件
Windows 32位
Windows 64位
虚拟内存
4 GB
16 TB
页面文件大小
64 GB
512 TB
页面缓冲池
470 MB
128 GB
非页面缓冲池
256 MB
128 GB
系统缓存
1 GB
1 TB
系统页表项(PTE)
1.2GB
128GB
与32位相比,用户进程现在可用的内存要大得多;从2GB到8万亿(TB)字节不等,而这只是虚拟内存空间的一半。
对于许多解决方案提供商而言,这是一个巨大的优势,但额外的内存并不限于用户进程;内核也从中受益。
现在有更多的空间(例如,与32位的1GB相比,现在有1TB的系统缓存)进行操作,因此,操作系统可以提供比32位系统更高级别的并行操作和有效性。
较之于类似的32位系统,这使64位系统能以更线性、更可靠的方式进行伸缩。
由于32位系统的可操作内存空间有限,因此可伸缩性很有限,而且很快就会随着负载的增加而“吃不消”。
对于需要大量内存分配或密集型计算的工作负载而言,64位系统在性能和伸缩性方面的优势通常是令人心潮澎湃的。
通过多达1TB的物理RAM,较大的数据集可以完全加载到内存中,而无需较慢的磁盘访问。
物理RAM的限制属于硬件范畴;目前,可以配置1TB的物理RAM。
Windows64位的自由度使开发人员可以采用新方式(利用最新的1TB可用RAM)来构建解决方案。
以下是迁移到Windows64位的其他原因:
•
更快的文件I/O:
64体系结构利用较大的数据块。
•
应用程序可以使用高达16TB的虚拟内存。
•
更多的并发进程意味着更高的数据传输速率。
•
更多的到服务器的同时客户端连接意味着更高的事务处理速率。
•
64位文件系统允许使用千兆兆大小的文件。
3.Windows64位(WoW64)上的Windows32位
32位应用程序如何在64位系统上运行?
答案是WoW64:
Windows64位上的Windows。
WoW64通常被认为是一个x86模拟器、一个子系统、或者是一个操作系统层。
但事实并非如此。
实际上,它是三个DLL的一个特定集,它允许64位操作系统无缝、透明地将32位应用程序的请求重定向为特定于32位的资源。
它旨在运行软件开发人员和管理员所需的提高个人工作效率的应用程序。
WoW64启动并无缝地运行32位应用程序。
该系统将32位应用程序与64位应用程序分隔开来,包括防止文件和注册表发生冲突。
它既支持控制台又支持GUI应用程序,此外还支持服务应用程序。
对于某些方案(例如,剪切并粘贴以及COM),该系统提供跨32/64位边界的互操作。
然而,32位进程无法加载64位DLL,而64位进程无法加载32位DLL。
WoW64子系统将所有32位应用程序定向到一个单独的文件系统和注册表。
这确保了32位应用程序不会访问64应用程序的注册表项或系统资源目录。
同样,64位应用程序也无法访问32位文件系统或注册表项。
该重定向是完全透明且无缝的;开发人员一方无需进行任何操作。
WoW64在X64和IPF芯片集上的执行和操作方式不同。
由于X64旨在本机运行32位代码,因此对于32位应用程序而言不会有性能损失。
由于X86二进制文件必须动态转换为EPIC,因此Itanium2需要一个执行层。
在很多情况下,32位应用程序在Itanium2上运行要比在32位处理器上运行慢,就是由执行层造成的。
应用程序的特定要求和技术规范会指出最能满足它的需要的处理器。
4.不支持的功能
虽然从32位迁移到64位很简单,而且多数情况下是直接的,但64位也有一些不支持的功能:
•
16位应用程序无法在Windows64位上运行,这主要是因为64位Windows上的句柄有32位之多。
因而无法在不丢失数据的情况下将句柄截短并传递给16位应用程序。
•
只有64位安装程序才可以加载并注册64位DLL,同样,只有32位安装程序才可以加载并注册32位DLL。
•
不支持OS/2和POSIX子系统。
•
不支持32位内核模型代码,例如:
•
病毒检测或文件系统筛选器
•
视频适配器或网络适配器驱动程序
•
内核模式的打印机驱动程序
不兼容的32位应用程序通常分为以下两类:
1.
16位安装程序
2.
32位内核模式驱动程序
请注意,对于.NETFramework版本2.0以及之前的版本(版本1.0和1.1),.NET应用程序将运行在Windows64位上。
本白皮书的第6节对此有详细的介绍。
经过充分的关注和准备,开发人员能够迅速识别应用程序的哪些组件得不到支持并需要迁移到64位。
5.迁移策略
开发人员在迁移应用程序之前,需要考虑以下几个问题:
•
应用程序的体系结构对迁移会产生怎样的影响?
•
需要特别关注哪些集成技术?
•
有需要迁移的第三方依赖项吗?
请记住,64位进程无法加载32位库或DLL。
与从16位迁移到32位形成鲜明对比的是,该过程无需将所有32位代码迁移到64位。
开发人员应该认真分析应用程序的哪些组成部分将从64位迁移中受益。
将所有组件和应用程序完全迁移到64位可能是不切实际的,这是因为64位中存在资源约束、不可用或丢失的源代码,或不可用于64位的依赖项。
分析解决方案以确定迁移的最佳路径(如果有)是很重要的。
开发人员可能觉得应用程序不会完全从Windows64位技术受益,从而想保持现状。
如果这是结论的话,那么开发人员必须确认,32位应用程序可以在WoW64上正确运行。
5.1Nile应用程序
下面的示例使用以前的技术(例如,ISAPI扩展和COM)基于32位C++MSDNNile应用程序进行迁移。
Nile应用程序不使用.NETFramework作为它的核心技术。
该应用程序是一个具有客户和定单跟踪功能的在线定单实用程序。
该示例使COM、ISAPI和SQLServer进行互操作以实现一个N层应用程序。
以下是64位迁移过程的一些相关特征:
•
体系结构为一个三层的应用程序:
表示层、逻辑层和数据层。
•
表示层完全包含在一个ISAPI模块中
•
针对它的业务逻辑与COM组件交互
•
将SQLServer用作它的数据存储
该应用程序使用32位工具集设计和生成,因此在需要时必须迁移代码以支持64位。
在开发过程中没有针对将来向64位的迁移考虑一些特殊事项;在开发该应用程序时,64位技术还没有发展起来。
它由一个非专业的工程师小组开发,旨在使用Microsoft技术最好地呈现一个实际的代码基。
该关系图阐释Nile应用程序的哪些部分进行了转换。
由于将表示层迁移到64位没什么直接的好处,因此它仍保持为32位。
中间层将从64位获益,因此它已经进行了迁移,从而使应用程序更具伸缩性、更加健壮。
数据层迁移到64位,这是因为随着数据库的增长和客户端请求的增加,64位SQLServer将能够按需增长。
数据库迁移非常容易,只需分离数据库,然后将数据库文件移动到64位服务器并重新附加该数据库即可。
这通过使用标准的企业管理器完成,该过程只需几分钟。
多数工作是在实现业务逻辑的中间层完成的。
以下是迁移NILE应用程序过程中的几个要点:
•
需要对涉及到应用程序基础结构的实用程序类进行一些更改。
•
所有核心逻辑保持不变。
这一点非常重要:
应用程序向64位迁移时不需要开发人员重新设计应用程序体系结构或修改核心业务规则。
•
无需对COM+组件予以过多关注,但也需要对它们进行一些修改:
•
轻微的指针调整:
改进并修改指针语句以便符合64位体系结构。
•
一些64位调整:
针对使用指针引用的语句和获取内存的语句。
迁移到64位需要:
1.
涉及到大约7000行代码中的70行(仅占1%)。
2.
多数更改包括修改诸如从LONG到LONG_PTR的32位数据类型
转换该应用程序的小组只有三个人,仅仅工作了四天。
他们都没有64位经验或深入的C++技能。
他们将大量时间用在学习如何调试ISAPI应用程序DLL方面。
之前没有人看过该代码,也没有针对ODBC进行过编程。
这里显示的修改说明了迁移过程并不复杂,实际上所有开发人员都可以很好地完成它。
5.2PetShop应用程序
MicrosoftPetShopArchitecture提供了另一个迁移示例。
这是一个具有两个数据库的分布式应用程序,它例证了.NETFramework和其他Windows技术的用法。
该应用程序是一个具有客户和定单跟踪功能的在线定单实用程序。
它是一个可使用MicrosoftVisualStudio®.Net和.NETFramework轻松生成的简单应用程序示例,可以将它看作是典型的.NET连接的应用程序。
以下是64位迁移过程的一些相关特征:
•
体系结构为一个三层的应用程序:
表示层、逻辑层和数据层
•
表示层使用ASP.NET实现
•
针对它的一些业务逻辑与COM+组件交互
•
将SQLServer用作它的数据存储(通过ADO.NET)
该应用程序使用现有的32位.NET工具集设计并生成,因此在需要时必须迁移该代码以支持64位。
表示层使用ASP.NETWebForms和.NETWebServices。
中间层组件使用ADO.NET与数据层交互。
无需将表示层迁移到64位,因为这样做并没有什么好处。
但是,如果开发人员以后想将表示层迁移到64位,也无需更改代码;开发人员可以直接使用64位CLR。
将中间层迁移到64位以便极大地提高性能。
64位体系结构的功能特别适用于提高COM+组件的性能。
64位体系结构中的COM+将很好地处理不断增加的同步用户事件。
因而系统的整体可伸缩性和性能将从中获益。
数据层的转换对于提高可伸缩性和性能而言也很重要。
迁移到SQLServer64位是相当简单的;SQLServer32位中使用的相同数据文件也要复制到SQLServer64位并立即投入使用。
SQLServer64位支持极高的事件处理速率:
使用每秒进行200多次磁盘I/O操作的系统,您可以看到速度和可伸缩性方面的显著改进。
通过缓存大量数据,减少了磁盘I/O次数,而且性能也得到了充分提高。
迁移基于.NET的解决方案比迁移基于C++的应用程序更简单。
由于.NETFramework中组件固有的兼容性,使得跨32位和64位边界的交互非常简单。
6.技术概述
本节介绍诸如ActiveX和COM的Microsoft技术,以及关于将它们迁移到64位体系结构时的意义和注意事项。
6.1COM
COM技术包括进程内和进程外组件。
32位和64位组件无法混合。
使32位和64位代码交互的唯一方式是通过进程间通信。
Windows64位支持64位和32位进程(在同一台计算机上或跨多台计算机)之间的远程过程调用(RemoteProcedureCalls,RPC)。
以下是用于在32位和64位应用程序之间进行通信的技术:
•
针对命名对象(例如,Mutex和Semaphore)的句柄和文件句柄可以共享。
•
针对窗口的句柄(HWND)可以共享。
•
可以使用IPC/RPC。
•
可以使用COM本地服务器。
•
如果内容不依赖于指针,则可以使用共享内存。
对于进程外组件而言,32位COM服务器可以与64位客户端通信,而进程外64位COM服务器可以与32位客户端通信。
因此,如果32位DLL不识别COM,则开发人员可以将它包装到一个进程外COM服务器中,并使用COM封送处理对64位进程的调用。
6.2ActiveX
不需要修改ActiveX可执行文件,因为它们必然会通过RPC进行通信并与64位兼容。
由于ActiveX可执行文件是进程外的,因此64位进程可以与32位ActiveX可执行文件通信,反之亦然。
可以使用DLL,但进程内限制仍然适用。
64位进程无法调用32位ActiveXDLL,而32位进程也无法调用64位ActiveXDLL。
受其影响最大的是InternetExplorer。
Windows64位提供两个版本的InternetExplorer,一个是32位的,另一个是64位的。
64位版本无法加载32位ActiveX控件,这限制了它的功能。
Microsoft建议在多数情况下使用32位版本的InternetExplorer。
使用32位InternetExplorer不会限制向64位技术的迁移,原因是客户端层通常保持为32位(如前面的迁移示例所示),因为迁移到64位对于客户端层没什么直接的好处。
6.3远程过程调用(RPC)
对于分布式应用程序而言,在从32位Windows迁移到64位Windows时,无论是直接使用远程过程调用还是使用DCOM,其本身都不会有任何问题。
RPC编程模型指定定义完善的数据类型大小,它们在该连接中是统一的。
此外,在Windows64位中,只有指针扩展到64位—其他所有整型数据类型均保持为32位。
由于指针对于客户端/服务器连接的每一方而言都是本地的,而且通常作为NULL或非NULL标记传输,因此封送处理引擎可以在连接的任一端透明地处理不同的指针大小。
但是,当开发人员将新数据类型或方法添加到一个接口,那么更改以前的数据类型或适当地使用数据类型时,会产生一些向后兼容问题。
6.4COM+
将COM+迁移到64位很简单。
COM+可以在Windows64位上安装并使用,不会有任何问题。
组件服务仍然可用,而且开发人员可以自由地使用任何语言来创建COM+对象。
7.小结和建议
Windows32位和Windows64位之间只有少数几处不同。
有两种不同的64位处理器体系结构,开发人员可以根据应用程序的要求选择使用其中的一个或将两者结合使用。
单个源代码基应该用于所有目标平台(x86、x64和IPF)。
64位体系结构与32位非常类似,但WoW64除外。
编写针对WoW64的32位应用程序的最佳实践就是正常进行开发;WoW64无缝且透明地提供到32位资源的重定向。
必须对内核模式代码和内联汇编程序的使用进行修改。
迁移应用程序的主要任务涉及中间层和数据层。
所有关键的Windows技术在64位上都是可用的,它们包括COM、COM+、RPC和ActiveX。
以下是几点重要建议:
•
当迁移到64位能明显获益时才进行迁移。
•
并不总需要将应用程序的所有组件都迁移到64位。
•
每个系统在迁移到64位时都有它自己的要求。
•
提前了解可能发生的迁移问题,以便使迁移所需的工作量最小。
•
无法直接从64位受益的已验证代码应该保持原样。
•
正确迁移的解决方案对于32位和64位而言应该具有单个源代码基。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Windows 64 位体系结构 体系结构