奔向64位：64位.NET Framework
软件世界
“Java代码不是运行在某个平台上，Java本身就是平台。”C++之父B.Stroustrup如是说。作为最重要的J2ME/J2EE竞争对手，.NET Framework在微软公司的研发工作中是具有基础意义的。“Windows正在变成虚拟机”。现在看来，估计是正确的──Windows已经一步步地把基础服务从COM+移植到.NET上。看来COM+变得过时已经成为定局，它在Longhorn中有了一个新名字Indigo，它正是基于.NET的。
64位.NET：被排除了吗
去年，几乎所有满怀期待的Visual Studio用户在发现Windows Server 2003 64-bit Edition中并不包含.NET Framework时都会大吃一惊。难道在64位环境下，.NET Framework不再被支持？其实不是这样的，.NET Framework的Linux版本MONO首先支持了64位，并很好地支持了C#，而且声称在下一个版本中将包括VB.NET──但是微软在做什么呢？
微软当然没有闲着，软件设计师Christopher Brownell说：“下一个版本的.NET Framework将同时包含32位和64位本地代码生成的支持，托管代码的程序员将非常容易地移植他们的旧代码。大多数情况下，只需要简单地把这些代码拷贝到新环境中即可。”于是，今年，我们看到在.NET Framework 2.0 Beta中已经包含了这个令人激动的新特性。
而Longhorn则完全建立在64位环境中，也许.NET Framework需要发布下一个版本了。
代码移植：托管还是不托管
托管是一种本地化，而本地化会破坏可移植性。但现在托管代码却是快速、可靠地开发.NET应用程序的基础。因为托管代码有.NET平台的完全移植保证(Full-portability guarantee)，而Linux下又有Mono Project。所以托管的代码可以在Windows和Linux下平滑移植──在Windows下连重编译的必要都没有。
C++更是更改了语法以适应最新的Runtime，它引入了在受控堆上分配对象的关键字gcnew以及新的token“^”，明确地区分托管与非托管的代码。微软Visual Studio 2004架构师Stan Lippman在TechEd 2004上说：“CLR将是不多的、明确决定未来的事物之一”这当然会使更多的C++用户受到召唤使用托管代码，但是，Stan会不会在其下一版本的C++ Primer中，把这个看起来属于某个平台的东西引入“标准C++”的教材呢？我想可能性不大──毕竟嵌入式的操作系统还是有除了Windows/Linux之外的不小份额，即使用了Windows/Linux，也有一些实时系统无法负担.NET Framework的开销而选择更轻便或更专用的Framework。一句话，托管没有问题，但别把标准忘记了。
64位，灼热的话题，从硬件CPU架构到软件操作系统的支持，可谓一路“烧”来。新生的事物，太多的不确定，往往只能给大家一个整体的介绍。当程序开发也要奔向64位的时候，我们也是抱着这样的初衷来为大家勾画一个未来开发的轮廓。
从最微观的数据结构到最宏观的.NET架构，从痛苦神秘的平台升迁到通达四方的数据库应用，七期的连载直至今日结束，希望倾心程序的你嗅到未来“花朵”的馨香。