随着Intel全面发布了自己的64位中央处理器，我们已经可以感受到64位时代的呼吸了。但是现在就开始欢呼雀跃似乎为时尚早，系统平台的过渡通常并非坦途。远的按下不表，单说16位向32位的过渡，也是在兼容16位应用的前提下经过了多年的发展才逐渐确立了32位应用的主流地位，并一直演化出32位一统天下二十年的大好江山。如今64位想重复32位的老路，颠覆32位的统治地位，无疑也将面临很多阻挠。我们就来看看在向64位时代迈进的道路上，需要跨过哪些门槛。
硬件驱动问题
现在AMD和Intel已经开始在市场上大量投放64位处理器，而其它一些个人级处理器厂商也在积极动作。但是一台计算机并非只有一个处理器就能运行，它还需要大量周边设施的辅助。由于目前进行过的所有测试都表明在64位操作系统中运行64位应用程序比运行32位应用程序要更加高效，所以用户也应该尽可能在自己的操作系统中安装64位的驱动和应用。根据微软发布的信息，32位的驱动程序是无法在64位Windows操作系统中使用的。现在硬件产品多如繁星，不可能所有的产品都具备64位驱动程序供用户使用。目前单就主板来说，市场上就有成百个品牌在供应产品，而能够生产其它配件的厂商更是数不胜数。相对较大规模的厂商具有比较良好的技术研发能力，而一些依靠降低成本价格进行竞争的小厂商就很难保证附属程序的研发了。在这种情况下，相对实力较弱的厂商通常会使用元件附带的公版驱动，甚至根本不提供经过验证的与产品匹配的驱动。所以在使用64位硬件平台的用户，应该特别注意自己现在购买的硬件是否带有针对64位平台的驱动程序。并且在可能的情况下，尽量选择大厂的产品，以免无法充分发挥硬件设备的性能。在新购设备这一方面问题还不是特别严重，对于我们之前购买的设备来说问题可就没那么轻松了。毕竟很多用户只通过更换主板和处理器进行升级，而非购买整套配件进行升级或者购买整机。一般核心的部件受这个问题的影响相对较轻，而外设型的设备所受波及就相当严重，例如打印机、扫描仪等。现在有大量的用户仍在使用几年前购买的打印机，甚至某些厂商的型号已经投产了超过5年的时间，有成百万的用户。在这种情况下，硬件厂商的责任不仅仅在于为新产品搭配64位驱动程序，而且还要考虑为所有仍在使用的旧有机型开发64位驱动。在很多情况下，我们只能更多的寄希望于所使用的64位操作系统包含了正在使用设备的驱动程序。不过相信会有相当多的用户要为此烦恼。全球的硬件厂商都应该加快脚步，为他们的产品提供各种平台的64位驱动支持，这也是64位硬件大范围普及的一个重要前提。目前已经有一些厂商走在了前面，例如罗技已经表示将在今年6月份推出其产品的64位驱动程序，尽管其大部分设备不使用驱动也可以很好的在64位操作系统下使用。
缺乏应用程序
除了硬件方面的问题之外，应用程序方面的情况也不是特别乐观。虽然现在很多32位的应用程序都可以使用兼容模式运行在64位模式下，但是总体来说，64位应用程序仍处于严重缺乏的境地。我们就目前已经确认的信息，来概览一些重要软件的64位版本情况。
Office办公套件
占有市场统治地位的微软Office套件正在筹划64位版本，在32位版本的Office 12推出后将很快推出64位版本的Office 12。但是据目前的情况看来，Office 12的推出时间很可能会是2006年的中旬或者下旬。届时微软不但面临着Office套件64位化的问题，还需要进一步将Office与其它的微软系统整合以及推出更多新功能，因为Office 2003版本相对前面版本的Office改进太少已经为不少激进的用户所诟病。开放源代码的Open Office套件虽然没有明确推出64位的版本，但是在64位Linux操作系统上确实可以正常的运行该办公套件。我们认为开源的套件对于64位的支持应该相对比较简单，因为我们可以很容易的自己进行编译和部署套件的工作。
服务器软件
Web服务器方面，除了Windows服务器系统自带的IIS之外，另一个主要的Web服务器软件Apache也提供了自己的64位版本，但是目前还没有看到Apache在Windows平台上有64位版本发布。就运行速度而言，64位的Apache在同等级别的硬件平台上相对于32位的Apache有一定的提升。而且我们相信64位技术会给Apache的性能带来更大的收益，毕竟Web服务器软件对内存的要求是相当高的。数据库服务器方面，微软的SQL Server已经提供了64位支持。在2005年的5月，微软发布了SQL Server的SP4补丁包，使用该补丁包用户将能够在64位平台上运行基于SQL Server的应用程序。支持64位X86硬件平台的64位商业数据库还包括IBM的DB2和Oracle。而MySQL，这个最流行的开源数据库系统，更是早在2004年初就已推出了基于HP-UX和Itanium 2处理器的64位版本，其对64位平台的支持还是相当全面的。相对来说，数据库服务器对64位技术的支持是相对较好的，毕竟数据库应用需要海量的存储空间。
工具软件
目前工具软件厂商还很少推出专门针对64位平台的版本，但是在微软64位操作系统上，影音播放、图片浏览、文件下载等常用的32位工具软件都能够较好的运行，而对于Linux等将应用程序打包发布的操作系统，各种工具软件也能够正常工作。
以上只是描述了很小一部分软件的64位版本情况。综合来看，大部分软件厂商还没有推出针对64位平台的产品版本，所以说目前可供用户使用的纯64位应用还非常稀缺。大家可以查询所需使用软件的官方网站，进一步了解64位版本的发布情况。
兼容性问题
从32位到64位，如何能够平稳的完成又一次计算平台的巨大变迁？回首历史，X86架构经历了8位到16位、16位到32位等数次变革。离我们最近的一次也是影响最深远的一次就是从16位到32位的平台转换。在这次影响久远的过渡之中，我们的主流中央处理器由286演变为极具变革意义的386，PC开始成为信息时代舞台上的主角。因为当时16位应用居于统治地位，硬碰硬的革命既使成功也会损失惨重。所以X86架构处理器的生产商极为明智的选择了一条兼容16位处理器、逐步推广32位处理器的发展路线。当兼容16位应用的32位处理器上市之后，用户惊喜的发现这种处理器同样能够顺利的运行16位应用程序，而且其运行速度大大超过当时的16位处理器。在这种情况下，购买新机的用户当然对性能更好而且还能够在未来运行32位应用的32位处理器情有独衷，并且带动了大量准备升级计算机的用户投向32位阵营。正确的策略赋予了32位变革足够的初始动能，当雪球越滚越大之后，终于使32位入替16位成为必然。在此期间，信息产业中的各个行业获得了充分的时间使自己向32位技术过渡，这一方便保证了过渡的平稳，另一方面也位32位技术打下了扎实的根基。值得一提的是，在这个迁移过程的同时，还出现了一种被成为RISC的架构。凭心而论，RISC架构从技术层面要比X86所使用的CISC架构更加优秀。但是由于与占据了极大市场份额的X86架构不兼容，所以无法被大众所接受，越来越被挤向高端市场，最终成了一种曲高和寡的技术。从这段历史我们不难看出，在发生深层次技术平台迁移的时候，往往由于涉及面过广，而无法迅速的完成转变。只有很好的顾及就有系统的价值，以自然的方式平稳地引发需求，才能获得最大限度的成功。历史总是惊人相似，我们相信32位技术向64位技术的转化也是如此。AMD也是选择了在64位技术的基础上兼容32位技术的战略，从这一年多的市场反应来看可以充分说明AMD的睿智。微软也顺应时势的在64位Windows XP中集成了WOW（Windows-32-on-Windows-64）子系统，用于提供32位应用与64位应用的兼容。现在剩下的问题就是，目前这些主力厂商所提供的兼容性，是否能够满足应用的要求呢？我们在个人用户最常用的Windows平台下针对兼容性问题进行了一系列的实验，大家可以根据实验的结果得出自己的答案。
在我们的测试中，下列程序可以正常的在64位Windows系统中工作，没有发现任何问题：
文档处理：Microsoft Office 2000/2003；Adobe Acrobat 7.0；UltraEdit 11；
图像处理：Adobe Photoshop CS；Paintshop Pro 9；CorelDRAW 12；Firework MX 2004；
三维制作：3D Studio Max 6；Maya 6.5；
光盘处理：Ahead Nero 6；Ultra ISO 7；MagicISO；
网页制作：Dreamweaver MX 2004；Flash MX 2004；
网页浏览：Firefox 1.2；Opera 8；
媒体播放：Media Player Classic；Power DVD 6；Quicktime 6.5；
系统工具：Partition Magic 8；WinAce v2.6；JRE 1.5；VMWare 5；
即时通讯：MSN Messenger 7.0；ICQ 5；

文件下载：eMule 4.6a；
游戏软件：魔兽争霸3；星际争霸；
无法工作的应用软件：
所有使用32位底层驱动的软件无法顺利的在64位操作系统中。大部分32位防病毒软件都应用Windows底层驱动进行病毒监控，所以都无法正常工作。个人防火墙软件也是如此，例如Zonealarm和Sygate的防火墙软件就无法在64位系统下工作。而我们能够找到的所有虚拟光驱软件都无法执行。一个让我们比较意外的情况是微软的Virtual PC 2004虚拟机软件也无法在64位Windows上运行，要知道他的主要竞争对手VMWare可是能够运行的，可能是Virtual PC需要对Windows的底层进行了一些调用。还有很多微软的套件无法在64位Windows下运行，希望微软尽快推出64位版本吧。
另外有很多软件能够完成基本的工作但是存在一些问题。WinRAR 3.5和Winzip 9都可以正常工作，但是问题在于右键菜单中的快捷选项无法正确加载。我们估计原因在于这些加载项只能工作在32位的Explorer环境中，估计其它利用该技术修改右键菜单的软件也会受到影响。另外，一些老版本的Acrobat程序需要使用32位的驱动，所以不能使用打印PDF文档的功能。另外我们还发现，在安装Office 2003 sp1的时候会显示一组错误消息，但是对使用不造成任何影响。
开发工具问题
64位应用软件的缺乏，同样需要开发工具厂商的投入。只有64位开发环境达到了足够的成熟度，程序员才会有学习64位环境软件开发的热情。64位处理器的字长从32位提升到64位，使内存地址范围大量扩充，内存的容量、处理速度和精度等指标随之大幅提升。在32位系统下，一旦数据处理量及会话连接突破一定界限之后，就非常容易出现系统崩溃。所以在高端应用领域，一直是64位系统的天下。Intel虽然在高端推出了安腾处理器，但是由于所能运行的应用软件相对较少，一直没有能够有效的占据市场。如今X86架构的处理器开始投放市场，所有立足于X86架构的厂商当然希望用户可以继续有丰富的软件可用。想要在64位平台上开发软件，首先要有完善的编译器软件。因为目前绝大多数主流的高级编程语言都是编译式的，如果没有高质量的编译器，就很难开发出性能优异的软件程序。以C语言编译器来说，除了可以从Intel这样的处理器厂商处获取之外，还可以使用GCC提供的开放源代码的64位版本编译器。凡是总有例外，并不是所有的主流开发平台都是基于编译技术的，例如Java。Java也会将源代码编译为可在虚拟机中执行的字节码，但是由于Java并不针对处理器指令集编译生成平台本地化的代码，所以在严格意义上不应将其划归为编译性语言。在使用虚拟机技术的编程平台中撰写的源代码，是不受平台限制的。以Java为例，在32位平台下生成的字节码是可以直接运行在64位平台上的，只要运行的环境中安装了版本匹配的Java运行时环境（JRE）。另外，Java开发平台为了实现在不同字长环境中运行Java程序，对数据类型也做了相应的处理，程序员并不会为这些问题花费太多的心思。谈到开发我们无法忽略微软的存在，毕竟全球大部分计算机都在运行微软的操作系统。由于微软现在主推的.net计算平台使用了和Java类似的技术，所以严格来说从32为转换到64位对.net程序也没有什么影响。我们从32位的微软开发库转换到64位开发库的难度应该是很小的。现在微软已经发布了Visual Studio .Net 2005的Beta版本，据称这款微软最新的开发工具中提供了64位开发的更多支持。这两个开发平台所具有的这种特性对程序员具有相当的吸引力，因为这意味着程序员可以使用同样的知识基础同时为不同的系统平台开发程序。而且这对企业移植应用程序带来了巨大的便利，如果企业选择的开发环境是Java或者.net的话。这从侧面说明了为什么Java和.net是企业级开发市场的主宰力量，选择了投入这两个阵营的企业现在一定会满意自己的决策。
实施成本问题
IT行业一个常用的衡量尺度是TCO，即总体拥有成本。这个衡量方式的主要原则在于我们在实施IT设施的时候不但要考虑显性成本，同时也要重视隐性成本。以32位向64位迁移来说，隐性的成本包括了对原有设备的影响、用户知识结构的变化、不同平台的整合以及程序移植等等。应该说目前X86架构的64位系统从一定程度上解决了这些问题。AMD从最开始就选择了兼容32位应用的策略推广其64位处理器，而Intel在百般权衡之后，也尾随AMD的脚步走上的同样的道路。在这种情况下，32位和64位的平台过渡工作将省却很多麻烦。但是尽管有这些有利条件，平台过渡仍是一个非常巨大的工程，会涉及到组织的方方面面。这就需要所有参与其中的人与过渡工作紧密配合，如果没有积极的态度和严谨的心态，会带给IT设施的运作造成无可估量的损失。另外，我们在注重TCO的同时，也不能忽略系统的扩展能力。就是说，我们不但要注重短期的效益，还要估算长期的利益。只将目光集中于眼下的成本节省，代价很可能是在将来付出更大的成本。特别是在相对大型的计算环境中，一定要制订好详细的迁移计划，评估各种应用的重要性等级和对64位系统平台的需求，开展足够的培训和教育工作，这样才有可能成功的完成32位平台向64位平台的过渡。