Longhorn不会构建在dotnet framework之上

http://www.csdn.net/news/newstopic/21/21653.shtml

在csdn 上面看到了这条关于Microsoft Longhorn的小道消息。如果属实，那么也证明了我指出的问题，在桌面应用中，响应能力永远是最重要的，本地代码的地位无法被虚拟机上面运行的托管代码取代。这也意味着dotnet winforms应用的普及更加遥遥无期，并且未来的xaml的普及应用也只可能是雾里看花。因此未来的RIA应用技术并没有一个清晰的未来，即xaml 也只是一个遥远的符号。

本来我更欣赏dotnet在客户端的技术进步，但是这几年来，dotnet在服务器端有长足进步的同时，在客户端技术方面，一直并不成功，前景看起来也不甚明朗。在服务器端，dotnet很难和Java竞争（原因前面已经分析过），有些行业的性质就决定了不可能用 dotnet。客户端技术本来应该是dotnet的强项，但是现在看起来似乎不如预期发展的那么顺利，也许这是缺乏竞争导致的结果吧。Borland Delphi不构成对dotnet的威胁，Python/Ruby还开始流行。

希望这个消息是确实的，我可不希望，我的C/C++技能到了Longhorn时代无用。

Longhorn 之前说用.net framework，结果要求配置很高，现在换成c++后，
现在主流配置就可以流畅运行了。
   内核不使用c#，但一些服务、组件可能用的。

dotnet winforms的普及，取决于集成.net framework的操作系统的普及。微软显然希望第一个集成.net framework的桌面操作系统是longhorn，这样longhorn才会有更多的卖点。Longhorn的内核用c和C++编写，是当然的事情，本来就没有什么可奇怪的。但是今后windows平台上的应用开发，以.net为主是必然的趋势，不仅仅是企业应用系统的开发，甚至包括游戏、网络方面，.net都会成为主流。微软已经提供了directx的.net开发包。.net的应用程序，响应速度并不慢，有些应用甚至超过c++。一旦集成.net的操作系统普及，winforms和smart client技术的应用就会爆发。
dotnet仅仅经过三年的时间，现在已经拥有了大量的用户。从语言本身的设计上、表现层技术上来讲，C#要超过java。.net的不足之处有两点，一是企业级开发框架的不足，二是微软对.net framework的控制，正是微软的控制，大大阻碍了.net framework的发展。.net framework本来是可以实现跨平台的，由于它的创造者是微软，所以才不能跨平台。
.net 实际上已经流行了。很多公司都在研发.net的项目。电子政务和政府项目、电信项目中，.net开始崭露头角。大量的开发人员在学习.net。.net在很多领域正在蚕食原本属于java的市场。而且份额越来越大。在中低端市场，.net将会占据越来越大的市场份额。在高端市场，由于windows安全性方面的坏名声，短期内不会有太大起色。
对于公司来说，适应市场是生存之道。.net技术在很多方面可以降低软件的生产成本。比如优秀的开发工具visual studio,asp.net的表现层技术，详细的开发文档等等。很多客户提出希望采用j2ee的平台时，其实他们并不了解j2ee是什么。
在服务器端，.net并非一无是处。很多java的开源项目，都推出了.net的移植版本，如Nhibernate、NAnt、NUnit、log4net、Aspect#、spring.net等等。可以说，java有的，.net都会有。smart client技术和xaml技术在集成.net framework的客户操作系统普及以后，可能会改变软件开发的观念。从Cs到bs再到smart client,看似复古，实则必然。xul之类的东西，对于商业运营的公司来说，可以不考虑。客户端还是微软说了算的。如果smart client开发成为主流的话，那么java的服务器端技术，会受到很大的冲击。恐怕很少有公司愿意在一个项目中混合使用.net和j2ee技术,微软也不会为此提供帮助，只会制造障碍。
未来是难以预测的。对于公司来说，也不应该把赌注押在一个平台上。对于开发人员来说，同样如此。对于合格的架构师来说，掌握流行的面向对象编程语言，更是必修课。

mooniscrazy 分析的相当透彻！佩服

关于XAML的安全性，robbin在一些文章里面做了分析，认为它可能会有很大问题。我倒是觉得不会有很大问题。
先来看看ActiveX的安全性为什么有问题。ActiveX控件的安全性问题主要是权限控制划得太粗，要么有所有的权限，要么什么都没有。所以，一旦不小心下载了一个不安全的ActiveX控件，就会拥有系统的全部权限。而XAML的运行不是这样。XAML程序能够访问的.net framework Api，在默认状态下只能访问一个安全的API子集。就如同Java的applet。具体能访问到什么API，取决于客户端.net framework安全策略的控制。在默认状态下，它是安全的。
在客户端可以通过改变.net framework安全策略来给予Ie以更多的访问权限，当然这样安全程度降低了。但是无论如何，比ActiveX的"要么没有，要么全部"的控制方式高明多了。所以，XAML的安全性是可以信任的，不会有多少问题。

Smart client/server 桌面远程系统，M$ 应该占上风，因为Longhorn操作系统直接支持。RCP/WebStart 毕竟需要额外的下载。
如果能够选择，并保证客户机都是windows，我倾向于 .net smart client.

但 smart c/s desktop 处于一种尴尬的境地。
它到底要rich, fat 到什么程度？
如果太瘦，那么B/S + ajax 也可以实现，而且分发更方便。
如果太胖，那么分发更新的下载安装速度 是一个问题。如果胖到一定程度，和 Non-smart c/s 有什么区别？

---

再来看XAML。是否 HTML killer？
HTML一开始的目的主要是布局展现，而不是互操作。一开始是为了Link, HTTP Get, 而不是 HTTP Post。
XAML, XUL 等主要描绘的是 互操作控件，而不是展示，主要处理的也是 HTTP Post 之类的信息交互。
同样意味着，XAML, XUL 是针对 Application Developer, 而不是 Page Designer 的。
至少在Page Design / publish 领域，XAML, XUL 无法成为 HTML-killer.
这方面的HTML的强有力的竞争对手，倒是PDF.  现在PDF 也转向XML格式，XDP...
PDF 相比于HTML的特点是，PDF是绝对布局，这对于精确打印的需求，是非常必要的特性。HTML是相对布局。

---

Web B/S 领域，M$ 从来不擅长，要做也只是为了用Desktop 模拟 B/S，如asp.net。
B/S 领域在搜索的时代，地盘会越做越大。Web B/S 领域中，Java 还是具有强大的优势。

---

注：不希望引起 java vs .net 的情绪化争论。

这个容易解决，制订一个组件化的标准，将整个系统切割为标准化的单元部件，客户端根据实际需要组装就可以了，关键是要有单元部件的标准协议。

组件化是个理想。组件化带来的开发维护成本比较高，少有公司能做到。这要求 组件之间的 interface 不能随意变化。
更新某个DLL，就相当于打个Patch 的情况，只是一些大公司才做得到。其他的，就比如Tencent, 每次更新都需要下载整个new install file.

不过，XAML 和 Code 部分，确实可以分开。XAML部分可以单独下载，换Skin。Code部分也可以单独下载，换功能。这里的Code部分相当于隐含了一个内置XAML Browser。这毕竟继承了一些 HTML B/S 的些许优点。XAML属于XML，对于designer来说，应该比code 容易学习一些。

sql 2005的Management Studio就是基于托管代码的，那叫一个慢，不是数据处理慢，是响应慢。任何时候点右键，要过3秒才出菜单。我的机器是pm1.8，1g内存，尚且如此。