Comments - 30391
先做人，再做技术人员，最后做程序员。打造国内最好的.NET技术博客。
2010-02-03 00:49
Jeffrey Zhao,
visits,
昨天晚上，
）老师的无心之语却引起了推特上一次前后长达1个多小时的讨论——当时他似乎只是随手发了一句“A le告诉我们的铁律是：表面功夫一定要做足”便不见了踪影，但是这句话立即引起了众果粉的共鸣。此后，我（
）的一句评论又引起了众人对微软开发平台的批判之声。在这次讨论中，几乎只有我孤军奋战为.NET平台进行辩解。因此事后有人给出一副对联为此次争论作出总结：
上联：李笑来激起千层浪
下联：赵姐夫力拒众强敌
横批：全民扯谈
自然，无论是我还是其他人，在参与讨论的时候都抱有明显的个人倾向性。不过与常见的吵架不同，虽然大家观点向左，但是并没有任何谩骂的成份，同时也没有假惺惺的客套话。可以说所有人从头到底都保持着就事论事，据理力争。因此从旁观者的角度来看，这次讨论并非只是意气之争，其中还是包含了比较丰富的内容。
参与讨论的
（@virushuo）和
（@tinyfool）都是老程序员，他们在上世纪末也都是微软平台的开发人员，但是因为难以忍受微软在那时候“毫无克制”的技术更迭（如VC = COM = .NET），最终一前一后都转投了*nix平台。我昨天谈到，我
之一是想了解苹果机的妙处究竟在哪里，而他们两位便是让我产生这一想法的重要因素。而我，由于入行较晚，虽然“从理论上”说也经历过这一历史阶段（如VB，Delphi，以及Java开发环境混战的那一时期），但是在真正全身心投入微软平台时已经是.NET时代了，因此对于霍郝两位的观点并没有切身体会，而我坚持的观点便是：.NET平台发布至今并没有“革命性”的改变，而目前也可以看出微软已经在.NET平台上投入了未来5年甚至10年的心力，因此如今.NET程序员并不用担心遭遇当年的悲剧。
从这次讨论中可以了解到一些老程序员对（当年）微软开发平台的一些典型看法，这些看法放到现在究竟正确与否我认为并不重要，重要的是我们能够从中总结出哪些信息，这些信息又可以如何对我们将来的发展产生借鉴意义。因此，我详细地总结了这次讨论的完整内容——不过毕竟是人肉整理，不排除遗漏少量条目的可能。因此，我建议您可以上一下推特，follow一些人，这样下次再出现有价值的讨论也不会遗漏了。
由于讨论内容较多，我还是把它们放在下面的链接中了。其中，缩进代表了“回复”关系，但是由于推特的谈话性质，条目的上下位置并不表示发表时间的先后。
标签:
绿色通道：
Categories:
163 条回复
1774762
评论共2页: 2 2010-02-03 13:49
rad：其实我想问大大们都是用什么***工具上twitter的....求........
懒得上 专门看老赵八卦转播的飘过
　 2010-02-03 14:07
又详细的看了一遍。。。。
我不知道我算不算老程序员啊，反正写程序七八年了，要算上小时候玩BASIC，那历史就久远了。。。。。
从C、C++、PHP、C#这么一路走来。语言都换了N次，就更别说平台了。要说操作系统内核，微软的确是没有*nix阵容稳定，但事实上自从NT后，到现在和可预见的将来，操作系统的内核都不会有太多改变了。要说API，我是不明白.NET到底改变了什么？如果说Vista不支持原来的WIN32的API了，那还情有可原，但那样估计微软已经被口水埋掉了，显然绝大多数的应用程序将无法运行。。。。直到我今天装的最新的Windows 7，他的Windows\System32目录下还一大堆MFC的DLL。所以我不知道那些所谓的老程序员到底被强奸了什么？
如果说是UI，如果说是原来的那些所谓的技巧在新的技术面前变得一文不值，那我非常乐意他们投身开源界，在那里没有微软这样的财团雇一堆程序员抢他们的饭碗。
要说被QJ，现在的.NET程序员哪个不是天天在被QJ呢？ADO.NET才出来多久？现在就有了Entity Framework。WinForm眼看就要被WPF取代，你今天才研究LINQ，昨天老赵就在写F#了，你怎么不被技术QJ呢？水果取消的项目比MS多多了，水果玩的跳票也不见得比MS少多少。无非是找个借口掩饰自己腿脚不灵便罢了。。。
据说以前的马拉松比赛，总有些人能从小街小巷、疏于防范的地方找到小路抄到别人前面，然后沾沾自喜。但这个比赛终归还是要看谁跑得快的。
我记得.NET刚出来的时候，原来的COM程序员泾渭分明的分为两派，一部分人赌咒骂娘说被微软QJ，另一部分人说盼星星盼月亮终于有了完美的COM。其实每次技术的跃迁都是这样，技术的发展道路不是微软的员工决定的，而是那些聪明的、拥抱变化的程序员所决定的。
事实上现在不也有WinForm程序员骂娘么？好吧我搞Web的确有点站着说话不腰疼。但是ASP.NET 2.0与1.1几乎全部代码都重写了，我Reflector的几万行代码一下成了历史，但我还是很喜欢ASP.NET 2.0甚至不惜在VS 2005还是beta的时候就重写自己的类库。
反倒是，我现在觉得.NET 4.0改的太少了，闲着没事干。
　 2010-02-03 14:12
Ivony...
ADO.NET才出来多久？现在就有了Entity Framework。
这个例子不合适啊，被束之高阁的只有Dataset而已 其他的还都辛勤的在EF下面努力呢~~~
你的意思我是完全赞同的，一部分人的被***
往往是另一部分人的不被***造成的
土地改革叫苦的都是地主富农
但是劳动人民站起来了
　 2010-02-03 14:14
韦恩卑鄙 alias:v-zhewg：
@Ivony...
ADO.NET才出来多久？现在就有了Entity Framework。
这个例子不合适啊，被束之高阁的只有Dataset而已 其他的还都辛勤的在EF下面努力呢~~~
但是以前要DataTable、DataAdaptor啊，现在只需要关心Entity就可以了。。。。。
API不一样的是天翻地覆么？
　 2010-02-03 14:16
Ivony...：
韦恩卑鄙 alias:v-zhewg：
@Ivony...
ADO.NET才出来多久？现在就有了Entity Framework。
这个例子不合适啊，被束之高阁的只有Dataset而已 其他的还都辛勤的在EF下面努力呢~~~
但是以前要DataTable、DataAdaptor啊，现在只需要关心Entity就可以了。。。。。
API不一样的是天翻地覆么？
所以才有Entity DataReader啊， 其实还是扩大了的东西
没谁扔下谁啊
ADO。net更好更强大啦~~~
　 2010-02-03 15:18
至于是否被qj，这算yin者见yin的问题。很老土的话：唯一不变的是变化。不拥抱变化，没积极的心态，最好别在业界混，很痛苦。（上面说DCOM/COM+,remoting,winform被淘汰也许有点煽情，现实很残酷：比如你想做.net下的桌面应用，你仅熟悉winform，但又想产品在未来10年内保值，你不得不学WPF。同理，可以把“COM+/ES/remoting”换成“WCF”）
　 2010-02-03 15:27
声明：本人所说的话都是来源于网络，请勿跨省！也请不要删，
也请不要对号坐！
SB年年有，今年特别多！
] 2010-02-03 15:31
Ivony...
即使变，提高生产力是实打实的。
其实我不知道mac的情况如何，所以我不好发表意见。
但是我了解Java的一些情况，没发现它和.NET有什么区别，但也没见Java程序员感觉被qj了吧……
对了，你了解mac的情况吗？水果的折腾情况有哪些，能具体说说吗？
　 2010-02-03 16:07
Jeffrey Zhao：
@Ivony...
即使变，提高生产力是实打实的。
其实我不知道mac的情况如何，所以我不好发表意见。
但是我了解Java的一些情况，没发现它和.NET有什么区别，但也没见Java程序员感觉被qj了吧……
对了，你了解mac的情况吗？水果的折腾情况有哪些，能具体说说吗？
所以非常期待老赵的mac和mono体验后的文章
　 2010-02-03 16:08
Jeffrey Zhao：
@Ivony...
即使变，提高生产力是实打实的。
其实我不知道mac的情况如何，所以我不好发表意见。
但是我了解Java的一些情况，没发现它和.NET有什么区别，但也没见Java程序员感觉被qj了吧……
对了，你了解mac的情况吗？水果的折腾情况有哪些，能具体说说吗？
我不太了解水果的情况，但我想从众所周知的情况来说，水果都不是一个很好的借口。。。。
这个公司曾经因为内讧自己把自己玩死，尽管不是第一个把创始人踢出去的公司，但是又把他找回来是第一个。这个公司近几年来业务从电脑切换到MP3播放器、机顶盒、手机、电纸书。。。。
我不知道如果微软这样玩会被说成什么，令人发指的LJ？
相较而言，微软同学操作系统一个产品做了几十年，Office也是，面向企业和后来的操作系统虽然使用了新的WinNT核心，但事实上也并非是颠覆式的改动。某水果公司连CPU的架构都可以换，微软这又算得了什么呢？
从历史的观点看来，将来被水果QJ的可能性绝对远大于被微软QJ。毕竟微软的头头已经全身而退去度假了，水果的头头最近身体不太好。
水果公司著名的忽悠人事件123：
发布手机，公司从苹果电脑更名为苹果公司。
使用Intel架构CPU。
使用Mac OS X。
　 2010-02-03 16:22
韦恩卑鄙 alias:v-zhewg：
@Ivony...
ADO.NET才出来多久？现在就有了Entity Framework。
这个例子不合适啊，被束之高阁的只有Dataset而已 其他的还都辛勤的在EF下面努力呢~~~
你的意思我是完全赞同的，一部分人的被***
往往是另一部分人的不被***造成的
土地改革叫苦的都是地主富农
但是劳动人民站起来了
劳动人民站起来了，又向后走了两步，坐下来了
　 2010-02-03 16:47
我觉得看问题一定要深入本质。比如，winform的本质是什么？——USER32.DLL/GDI32.DLL的托管代码封装。USER32.DLL/GDI32.DLL以及它们的16位老兄，少说也有17、8年了吧。不管raw win32 programming,MFC,WTL,还是winform，本质是一样的,命令式GUI：在WM_PAINT中指示画这样，画那样。WPF属于呈现式GUI：申明object tree，WPF包办其呈现，如同浏览器呈现HTML tree。呈现式GUI对命令式GUI是革命的，天啊，从85年windows 1.0到05年的WPF，20年啊20年，ms才革命令式GUI的命，ms完全是不思进取嘛！：）
（对GUI研究不深，随口说的，请高手指正）
　 2010-02-03 16:47
不知道为什么每一次遇到技术更迭的时候我都会很爽，又有新东西可以学了。
　 2010-02-03 16:48
老实说，Joel Spolsky那篇《微软如何输掉API之战》还是有些道理的。
微软现在的做法是当它认为现在的机制解决不了问题或者很难解决问题时，就会引入一套新的机制并试图以新的机制解决问题，不过很多时候这样只会让问题变得更加复杂。
并且微软解决问题的方式让微软的技术体系背着沉重的包袱，win32 api为了兼容win16 api已经显得比posix笨重，再往后的com和.net则更甚。
其实看看C# 4就知道了，C#只发展到第4个版本就已经显出老态（当然，很多语言标准十几二十年才发展两三个版本，而且改动非常小），或者说C#已经开始老化，老化的特点就是不得不为了平衡新特性和向后兼容而加入丑陋的设计，例如C# 4.0的协变/逆变中那个著名的菱形歧义，还有命名参数在父子类中的不同行为。我想，大部分无法自我扩展而只能通过加入语法或语义元素来引入新特性的语言都存在老化的问题。
　 2010-02-03 16:56
话虽这么说，但学习是有成本的。不过我觉得学习成本只占总成本的很小一部分——大头是问题域本身的成本。比如，你从龙书、Programming language pragmatics等书中活了出来，炼成一身盖世武功，至于用lex&am yacc或ANTLR或Oslo中的M语言做剑，以及学用这些剑，不是小菜一碟么？！
　 2010-02-03 16:59
韦恩卑鄙 alias:v-zhewg
似乎涉及到了政治了。这个比喻不好，毕竟真实情况可能和你说的正好相反。所以还是不用zz打比喻。
　 2010-02-03 17:00
还能上Twitter啊，幸福啊。
　 2010-02-03 17:09
看完google的内容
心里蹦出几个字：可怜的老赵
其实有时候觉得，英雄总是孤单的。
在Tech Ed 2009上，看着老赵一个人坐在问答区，孤单的背影。
我只是个菜鸟，学.net也是完全不明白jave写个从控制台输入需要用到stream(好久不看了，说错了别鄙视哈),而c#只需一个Co ole.ReadLine()。
我算是微软的铁杆
但是论战上我帮不了老赵，我是菜鸟
但是，从我看来
支持一个公司，跟爱一个人一样
没有理由的。
如果你发现你爱一个人有了很多理由
那么就是你不爱他（她）的时候了。
技术都是相通，
无论.net,java,c++。
我们学的一种思路，而不是语言。
但是任何一种的封闭
都会葬送自己的。
在我看来
微软的优势就是让你很容易的入门。
好比找老婆，
别的技术，好比那种你喜欢，但是你要付出很多才能得到的女人
而微软，很容易答应做你的女朋友
当然，想结婚，也得付出心血
与其费半天劲去追一个女人
我更愿意去找个答应做你女朋友的人
两个人慢慢去创造爱情，创造幸福。
我喜欢微软，但是我也在研究google a engine,
也在看A le SDK
不要把自己封闭在一个平台上。
所以说，请大家也不要难为老赵了。
学到本领
找到老婆
就好了。
也许你的老婆不如别人的好
但是，你爱她，她爱你，就好了。
　 2010-02-03 17:27
幸存者：
老实说，Joel Spolsky那篇《微软如何输掉API之战》还是有些道理的。
微软现在的做法是当它认为现在的机制解决不了问题或者很难解决问题时，就会引入一套新的机制并试图以新的机制解决问题，不过很多时候这样只会让问题变得更加复杂。
并且微软解决问题的方式让微软的技术体系背着沉重的包袱，win32 api为了兼容win16 api已经显得比posix笨重，再往后的com和.net则更甚。
其实看看C# 4就知道了，C#只发展到第4个版本就已经显出老态（当然，很多语言标准十几二十年才发展两三个版本，而且改动非常小），或者说C#已经开始老化，老化的特点就是不得不为了平衡新特性和向后兼容而加入丑陋的设计，例如C# 4.0的协变/逆变中那个著名的菱形歧义，还有命名参数在父子类中的不同行为。我想，大部分无法自我扩展而只能通过加入语法或语义元素来引入新特性的语言都存在老化的问题。
菱形歧义是啥？
　 2010-02-03 17:31
“C#只发展到第4个版本就已经显出老态”——天啊，我等C# 5.0都要等得发狂了，因为Anders同学许诺compiler as a service！
　 2010-02-03 17:48
Ivony...
菱形奇异的这个词让我想到了C++的多重继承，难道指的是
IEnumerableDerived - IEnumerableBase - IEnumerableIAnimal
IEnumerableDerived - IEnumerableIDog - IEnumerableIAnimal
　 2010-02-03 18:01
cla Base { }
cla DerivedA : Base { }
cla DerivedB : Base { }
interface IFooout T {
void Bar();
cla MyCla : IFooDerivedA, IFooDerivedB {
void IFooDerivedA.Bar() {
Co ole.WriteLine(DerivedA);
void IFooDerivedB.Bar() {
Co ole.WriteLine(DerivedB);
cla Program {
static void Main(string[] args) {
IFooBase x = new MyCla ();
x.Bar();
猜猜会输出什么？当然，代码是我随手写的，可能会有错。
　 2010-02-03 18:08
会输出结果！人人都知道
　 2010-02-03 18:10
关于C#4中协变/逆变的歧义问题，可以去
看看，不过要翻*墙。
那个博客之前有一系列文章都是讲这个的，有时间的话我推荐都可以看看。
　 2010-02-03 18:16
Steven Chen
随便瞎说的， 勿怪~
　 2010-02-03 18:22
韦恩卑鄙 alias:v-zhewg
韦恩卑鄙 alias:v-zhewg：
.net和com本来就没有不兼容，com/ole只是一个二进制接口规范嘛，.net各种方式包装实现起来都是很完备的
MFC，DCOM/COM+也不算淘汰啦，在.net 库低下跑的还是这些东东啦
虽然思路差不多， 但就像你说的：
韦恩卑鄙 alias:v-zhewg：
我觉得 .net是那些玩win32和 com到深层的人为了改善当时怨声载道的状况，欢天喜地的作品，而且真正服务到了很多用到深处的人。
.net的出现， 真的是大快人心。 极大的提高了生产力（从商业角度说）， 以及代码的美感（从技术角度说）。
　 2010-02-03 18:23
hoodlum1980：
@OwnWaterloo
不要胡言乱语。讨厌你们这种不负责任的随意评论。从你的结论来看你根本就不懂COM，还评论什么。
分享下你的高见？
　 2010-02-03 18:27
编译所有程序还在用2.0的路过。
毕竟给公司做事，还是要考虑用户的系统环境的说。
如果win7普及了，或许会转向3.5，但是除了wcf以外，也不觉得有什么特别需要引入的东西。
单就.net来说，这10年间，除了1.1到2.0时，泛型的增加和命名空间结构的一些改变以外，改进一直不都是挺平滑的么？
何况就算linux，虽然市面上的发行版都是kernel 2.6，但是还不是分debian和freeBSD等很多派系么？有的时候想找到能直接在自己机器上跑得***包也很麻烦。
　 2010-02-03 18:28
幸存者：
关于C#4中协变/逆变的歧义问题，可以去
看看，不过要翻*墙。
那个博客之前有一系列文章都是讲这个的，有时间的话我推荐都可以看看。
匹配第一个符合的接口 倒还可以理解啊
　 2010-02-03 18:36
out是4.0新增的关键字吧？类似于Listint和Listobject的转化问题那种。
　 2010-02-03 18:38
韦恩卑鄙 alias:v-zhewg
反正我是觉得靠顺序来匹配接口实在太不直观了，像有两个以上可匹配的重载方法时编译器就直接报错了，不会按顺序来匹配。
不过，这个问题恐怕也很难有更好或者更合理的解决方案。
　 2010-02-03 18:44
幸存者：
@韦恩卑鄙 alias:v-zhewg
反正我是觉得靠顺序来匹配接口实在太不直观了，像有两个以上可匹配的重载方法时编译器就直接报错了，不会按顺序来匹配。
不过，这个问题恐怕也很难有更好或者更合理的解决方案。
我是觉得实现接口的时候要注意一些就可以了
搞不好这个还能“不是Bug是feature呢” 当成职责链用
哈哈哈
　 2010-02-03 18:53
幸存者：
@韦恩卑鄙 alias:v-zhewg
反正我是觉得靠顺序来匹配接口实在太不直观了，像有两个以上可匹配的重载方法时编译器就直接报错了，不会按顺序来匹配。
不过，这个问题恐怕也很难有更好或者更合理的解决方案。
我觉得这样使用泛型是有问题的，泛型应该本身是对实体类进行切入的，而这个例子明显是把泛型作为实体使用了，就比如cla A:IEqualtableB这种，写法上是允许的，但是用法是怪异的。
　 2010-02-03 19:02
Jeffrey Zhao
Jeffrey Zhao：
我觉得传统Web开发，无论是什么平台，都不会学歪的。
比如， xhtml vs html？
其实我也是支持比较严谨的前者。
但基于xml的技术都有一个毛病……
对机器友好， 对人…… 要欠缺一些……
如果是机器生成xml， 那当然没什么问题。
如果是手写……
举2个例子：
有篇介绍rst的文章， 拿了一段rst的代码和docbook使用的xml的代码作对比； 前者90%是内容， 后者至少30%是标签。
标签具体多少都不是很重要了， 关键是给人的整体感觉是：虽然前者没有那些结构化的标签， 但相比后者， 人更容易看出文档的结构。
代码在这里：
还有， 手写xhtml的时候…… 对于一些小文档，body部分只占整个文档的2/3甚至1/2 ……
html好像连body标签都可以省略？
虽然不够严谨， 但那些多余的标签真的是很伤眼睛， 让人一眼看不出内容。
它们再加上 html5呢？这个没太关注……
老赵有什么看法与建议？
还有js那些hack…… 是尽可能采用各浏览器的交集？ 还是尽可能利用各浏览器的特点？
] 2010-02-03 19:14
@麦穗：所以说，请大家也不要难为老赵了。
靠，我都没觉得我被为难了，我觉得很爽啊……
] 2010-02-03 19:17
OwnWaterloo
原来你说的是前端开发啊，这是我的弱项，我给不了好的建议。
我刚才说“学任何平台都不会学偏”是指服务器端，因为客户端就不分平台了……
　 2010-02-03 19:23
Jeffrey Zhao
我不懂应该怎么分类…… 我弱……
因为xiaotie提到这些了， 所以就问问……
如果是说前端开发不会学偏还好理解一些，搞来搞去大家都是用的那些东西……
那么， 服务器端的技术又包含哪些呢？
　 2010-02-03 19:51
OwnWaterloo
数据写成http流
] 2010-02-03 19:56
OwnWaterloo
每种技术都可以开发Web的，.NET，Java，Ruby，Python等等。
感觉现在除了php不建议学外，其他都差不多，呵呵。
　 2010-02-03 20:19
是不是有点偏了？
你们觉得软件开发技术有银弹吗？
汽车不就四个轱辘就可以开了吗？
打个比方，40年前的汽车，和现在的技术相比，你觉得变化不大吗？
你可以狡辩：但至少基本原理没变啊！
是，基本原理没变，同理可证，学软件就是要增大基础投资，软件工程投资上，学好一门编译语言，加上软件工程。成了，以不变应万变。
可能你会拿出上面什么COM之类的投资浪费出来给我找碴，我想问问。你觉得给你一把老实来复***射击还是给你一把AK47更容易集中目标？
告诉你，如果你是神***手，哪把***都是一样的，别人稍微熟悉一下***的性能，别人就比你打得准！
看明白没？永远要找你的“***法”来投资，学好***法，走遍天下都不怕。套用个老话，一招鲜，吃遍天！
朋友，你找到什么是你要学习的“***法”了么？
　 2010-02-03 20:39
要是有wave就好了，还可以录播。
　 2010-02-03 21:21
Jeffrey Zhao
谢谢~
　 2010-02-03 21:22
韦恩卑鄙 alias:v-zhewg
请求呢？ 请求也需要先从某种协议流中分析？ 然后将请求结果转化为某种协议流发送取出？
　 2010-02-03 23:50
OwnWaterloo：
hoodlum1980：
@OwnWaterloo
不要胡言乱语。讨厌你们这种不负责任的随意评论。从你的结论来看你根本就不懂COM，还评论什么。
分享下你的高见？
Hi OwnWaterloo, 我也同意hoodlum1980的看法，你真的不懂COM。说句实话，不懂COM没什么关系，毕竟现在大多数人都不懂，而且不是有.net嘛。
不过我鼓励你花两个小时读一下DON BOX的《E ential COM》（别读潘爱民翻译的那本），读第一第二章就够了。对理解CTS/CLI绝对有帮助。如果看明白了的话，你就明白为什么会有第二个人跳出来说你不懂了。;)
-msolap
　 2010-02-03 23:58
@virushuo: 当年可不是这么说的来着。但是现在已经找不到什么当年的宣传资料了。当年还说WINDOWS内核要CLR化，这现在也没实现吧？当年说longhorn要完全使用CLR...
@jeffz_cn: 炒作，炒作……其实这些都是1.0时期的炒作了，.net 2.0时微软自己也不炒作这些了，炒作别的了，比如winfs啥的。可惜jim gray一失踪，没人搞得定这东西了……
李开复的书中说道当年微软确实是这样做的，不过最后发现根本不能实现，最后放弃了。
] 2010-02-04 00:09
Star Peng
深表怀疑，当年看到这句话我就觉得是炒作了，我真不信有人会这么想啊。
就算技术可行，微软可能重写windows内核吗？这是什么样的代价啊，不可能的。
　 2010-02-04 00:40
Jeffrey Zhao
内核倒是不用重写，事实上clr也无法代替内核的作用，clr还得构建在内核之上呢。作为对比，可以参考google的android，其实android可以认为是构建在jvm上的一个操作系统，但是内核仍然是linux。
我猜windows完全使用clr大概是指像android一样仅提供.net的api，windows所有的应用都使用.net编写，不过那样仍然不现实，这样等于完全放弃windows平台所有构建在win32 api上的软件，这和自杀没什么区别。
不过微软有个代号为Singularity的实验性质的操作系统就是完全建立在托管代码之上的，甚至连设备驱动也可以用托管代码写。
　 2010-02-04 01:09
幸存者：
@韦恩卑鄙 alias:v-zhewg
反正我是觉得靠顺序来匹配接口实在太不直观了，像有两个以上可匹配的重载方法时编译器就直接报错了，不会按顺序来匹配。
不过，这个问题恐怕也很难有更好或者更合理的解决方案。
嗯这问题是
还是没辙，现在就这样的了……
@幸存者
hmm... .NET Micro Framework是可以跑在裸机上的，底下有操作系统并不是实现VES的先决条件。
Android的话，Dalvik及其之上的更像是“应用平台”而不是“操作系统”。Bionic更底层些，然后下面是Linux内核，那才是“操作系统”。
当年说Windows要大量是用托管代码是真的要用很多……不记得是不是
了，记得以前看Patrick Du ud的访谈视频时听到他描述当年跑去跟Windows team吵到底有GC的托管环境放在底层能不能行。虽然过程我们很难知道，但结果很明显，Windows team不肯把CLR放下去。
Singularity、传说中的Midori，还有Cosmos和SharpOS，Java的JNODE等，托管代码写的操作系统倒也不少，呵呵。
　 2010-02-04 03:13
msolap：
不过我鼓励你花两个小时读一下DON BOX的《E ential COM》（别读潘爱民翻译的那本），读第一第二章就够了。对理解CTS/CLI绝对有帮助。
你怎么就知道我没看过呢？
不巧啊， 我还就是看的《COM本质论》， 怎么办呢？
msolap：
我也同意hoodlum1980的看法，你真的不懂COM。
我也觉得你们是一路人。 抛出一个观点， 然后走人。
你还好一些， 列出一个论据：
msolap：
如果看明白了的话，你就明白为什么会有第二个人跳出来说你不懂了。;)
不过这算论据吗？ 姑且放下看明白了的话 —— 你怎么知道我没看明白呢 —— 人多==有理， 是吗？
msolap：
我也同意hoodlum1980的看法，你真的不懂COM。说句实话，不懂COM没什么关系，毕竟现在大多数人都不懂，而且不是有.net嘛。
我也没觉得我多懂。 我确实不了解COM的很多细节。 而且我很坦然的：
—— 我在面试的时候就曾明说： COM那玩意， 我不（屑）会。
括号里的字实在不好意思说出来， 显得太高调。
但是我说到的那部分， 我没觉得有说错，或者欠妥的地方：
—— COM用了一种非常丑陋的方式去实现一种OO的二进制协议， 这种思路是错误的。
我在学完C/C++之后， .net是早就出现了。那时候我就预感COM肯定会被淘汰 —— .net才是一种正确的OO的二进制协议。
如果要求使用COM， 我会劝说不要使用这种恶心的技术； 如果劝说失败，我可以去学（而且在我看来也没什么复杂的）。
但我绝对不会主动的在这种丑陋的技术上浪费我的时间。
如果上面的观点有错误的地方， 请不吝指出。
如果仅仅是因为这些论调侵犯了COM在你们两位心目中那圣洁的地位 —— 我接触过一些对COM无比崇拜的家伙， 什么东西都想实现为一个COM组件才安心 —— 也请指出， 我会考虑顾及你们的感受， 说得委婉一些。
否则，随你俩怎么说去吧， 我的时间可不像浪费在这种人身上。
　 2010-02-04 09:31
OwnWaterloo
所以说你没看懂嘛，另外是建议你看《E ential COM》，不是潘爱民翻译的《COM本质论》。
我并非在和你讨论COM和.net孰优孰劣。即使是今天也依然有COM/COM+适用而.net不适用的场景。相信我，相比COM/COM+，我绝对更痴迷于.net。自从2000年夏天听了DON BOX做的一个培训《E ential .net》后，就爱上了.net。(当时还不叫.net，叫NGWS，C#叫cool语言，a .net叫a lus。本来是去听DBOX的COM+，结果他老人家神秘兮兮地掏出了一个没有题目的课程，连讲了两天。)
搞技术的，怎么轻轻拍一下，就反应那么激烈呢？
你自己在面试的时候都说不懂COM，和别人说有什么区别呢？一个事实自己说可以，别人说不得，是吗？这哪里是做好技术应该有的心态呢？
-msolap
] 2010-02-04 09:58
幸存者：
@Jeffrey Zhao
内核倒是不用重写，事实上clr也无法代替内核的作用，clr还得构建在内核之上呢。作为对比，可以参考google的android，其实android可以认为是构建在jvm上的一个操作系统，但是内核仍然是linux。
android还是个纯粹的linux，只是上面提供了一个jvm，和Singularity还是大不同……
而且，android还是可以写native c/c++的，这也是开发人员强烈要求下做出的让步。
] 2010-02-04 10:00
Galactica:
@OwnWaterloo
关于COM,我罗列了下面的问题:
1,COM组件能运行在Unix下吗?
2,JavaScript能调用COM组件吗?
3,标准C能调用COM组件吗?
4,Java能调用COM组件吗?
5,标准C能调用Java Bean 吗?
6,c/c++/Java/JavaScript能调用一般.Net 程序集吗?
7,如何在您公司的Java项目组中复用C++/C#项目组已编译程序集?
不好意思，你的回复破坏版式了，所以我删掉了……
　 2010-02-04 10:44
我最后插句嘴，我虽然不太懂COM技术，但我知道COM的全称是什么：
COM = Component Object Model
即组件对象模型。
那么从这个名字就可以看出来，COM要解决什么问题？组件对象化。后来微软发现，不同语言技术写出来的组件不能通用，COM的目标又增加了语言无关化。
好！我们现在看看.NET，运行在CLI上的各种高级语言，在统一的规范下，所有的组件都是面向对象的，语言无关的。这不是COM的理想大同世界么？真正的大同世界到来的时候，那些所谓的先锋烈士随便找个借口说不玩了，这种行为实在令人费解。
从OLE到COM最终的.NET，尽管A lication从最开始的文档处理演变到现在复杂多变的软件。思想却是一脉相承，组件化，组件化，组件化。。。。
　 2010-02-04 12:30
@OwnWaterloo
说.net实现二进制协议，也许没错，但很外行：）。可以像Don Box那样“忽悠”——CLR as a better COM——COM是个physical contract，CLR是个virtual contract。COM可分为狭义与广义，狭义COM就是个二进制协议，即实现IUnknown，遵从特定的vtable规定，认为狭义COM就是COM的精髓，虽然没错，但头脑似乎简单了点：）。我喜欢广义的COM，因为它们是用来建设世界的：IDL,marshal/unmarshal,co ection point,structured storage,IMoniker,IDi atch,,IDataObject,IOleObject,IViewObject,IOleInPlaceObjectWindow...................................。最后，你可以去看下CLR hosting，大把大把赤裸肮脏丑陋恶心的COM细节啊！
　 2010-02-04 13:03
Ivony...：
我最后插句嘴，我虽然不太懂COM技术，但我知道COM的全称是什么：
COM = Component Object Model
即组件对象模型。
那么从这个名字就可以看出来，COM要解决什么问题？组件对象化。后来微软发现，不同语言技术写出来的组件不能通用，COM的目标又增加了语言无关化。
好！我们现在看看.NET，运行在CLI上的各种高级语言，在统一的规范下，所有的组件都是面向对象的，语言无关的。这不是COM的理想大同世界么？真正的大同世界到来的时候，那些所谓的先锋烈士随便找个借口说不玩了，这种行为实在令人费解。
从OLE到COM最终的.NET，尽管A lication从最开始的文档处理演变到现在复杂多变的软件。思想却是一脉相承，组件化，组件化，组件化。。。。
小学数学奥林匹克竞赛学深了 发现初中根本不用那些玩意用方程式，一怒之下再也不爱数学了，改从文科。
　 2010-02-04 14:31
韦恩卑鄙 alias:v-zhewg：
Ivony...：
我最后插句嘴，我虽然不太懂COM技术，但我知道COM的全称是什么：
COM = Component Object Model
即组件对象模型。
那么从这个名字就可以看出来，COM要解决什么问题？组件对象化。后来微软发现，不同语言技术写出来的组件不能通用，COM的目标又增加了语言无关化。
好！我们现在看看.NET，运行在CLI上的各种高级语言，在统一的规范下，所有的组件都是面向对象的，语言无关的。这不是COM的理想大同世界么？真正的大同世界到来的时候，那些所谓的先锋烈士随便找个借口说不玩了，这种行为实在令人费解。
从OLE到COM最终的.NET，尽管A lication从最开始的文档处理演变到现在复杂多变的软件。思想却是一脉相承，组件化，组件化，组件化。。。。
小学数学奥林匹克竞赛学深了 发现初中根本不用那些玩意用方程式，一怒之下再也不爱数学了，改从文科。
小学数学奥林匹克竞赛学深了 发现初中根本不用那些玩意用方程式，一怒之下再也不爱数学了 这句话年看了有感觉啊....不过相信大都喜欢数学的，很少真的改文科了..
　 2010-02-04 17:14
msolap：
所以说你没看懂嘛，另外是建议你看《E ential COM》，不是潘爱民翻译的《COM本质论》。
理由就是因为那是翻译过的？
因为你看过ECOM而我没看过， 所以你就觉得你的眼界比较高？
这样？
我并非在和你讨论COM和.net孰优孰劣。即使是今天也依然有COM/COM+适用而.net不适用的场景。相信我，相比COM/COM+，我绝对更痴迷于.net。
.net不适合的地方多了去了。 有人打算什么都让.net做的吗？
.net不适合的地方， 就是COM的天下了？
而我在上面的讨论， 是为了一个什么观点， 我估计你也没看懂。
自从2000年夏天听了DON BOX做的一个培训《E ential .net》后，就爱上了.net。(当时还不叫.net，叫NGWS，C#叫cool语言，a .net叫a lus。本来是去听DBOX的COM+，结果他老人家神秘兮兮地掏出了一个没有题目的课程，连讲了两天。)
没看懂也来留言？ 就为了来秀秀你的资历？
msolap：
搞技术的，怎么轻轻拍一下，就反应那么激烈呢？
你自己在面试的时候都说不懂COM，和别人说有什么区别呢？一个事实自己说可以，别人说不得，是吗？这哪里是做好技术应该有的心态呢？
我没说你说不得啊 —— 你怎么又看不懂中文了 —— 我哪句说的是“别说我不懂”？ 我说的是“说我不懂时，请同时出示你的理由”。
再次强调，
你倒是说说我哪说错了？
搞技术的， 怎么思维这么混乱呢？
说话没头没脑， 扯东拉西。
你是搞开发的么？ 还是搞seals或者marketting的？
　 2010-02-04 17:40
在批评别人外行， 头脑简单时， 请理解别人到底在说什么。
你是不是找到一个机会就想来摆弄你的COM和.net学识？
还真逗， 狭义COM、广义COM。
说.net实现二进制协议，也许没错，但很外行：）
.net是否是实现了二进制协议？
请注意下面两句话的区别：
.net实现了二进制协议 vs .net仅实现了二进制协议。
btw： 如果你觉得
你很内行
， 你很想show一下你的学识，你也可以分享一下.net除了实现二进制协议还实现了什么。
认为狭义COM就是COM的精髓，虽然没错，但头脑似乎简单了点：）。我喜欢广义的COM，因为它们是用来建设世界的：IDL,marshal/unmarshal,co ection point,structured storage,IMoniker,IDi atch,,IDataObject,IOleObject,IViewObject,IOleInPlaceObjectWindow.......
谁在说狭义COM是COM的精髓？ 我吗？
你的中文能力还真是够外行的， 头脑能再灵光一些么？
我说的只是COM实现（你所谓的）广义COM的
太龌鹾 —— 当然， 这是口味问题。
也许在你看来， 它无比优美？ 也许COM构建的世界在你看来也很优美？
我只能说， 你的审美观很别致。
最后，你可以去看下CLR hosting，大把大把赤裸肮脏丑陋恶心的COM细节啊！
哪又怎样？ .net上的语言不恶心就行了。
boost内部也很恶心， 但是只要它
内部实现恶心的代码不会流散到客户代码中
就可以了。
但是COM做不到， 它就是要让客户的代码变得四不像。
　 2010-02-04 18:10
@OwnWaterloo
首先我得认个错，上面那一段有些不是针对你的，完全是我在自言自语在显摆。其次，佩服下你的彪悍，难道你是传说中的肖老师的学生？
　 2010-02-04 18:19
@OwnWaterloo
还得佩服你剽悍的逻辑思维，我喜欢COM，难道就意味着我排斥CLR？Waterloo同学，狂是好事，我喜欢狂人，因为我也是个狂人，年轻人不狂，和咸鱼有什么区别？关键是：狂完之后自我反省是否狂得很SB？
regards
　 2010-02-04 18:26
zzfff：
其次，佩服下你的彪悍，难道你是传说中的肖老师的学生？
我觉得0 bug在某些方面可以做我的学生。
zzfff：
还得佩服你剽悍的逻辑思维，我喜欢COM，难道就意味着我排斥CLR？
我也很佩服你， 我哪句话说了你排斥CLR了？？？
我表达的只是对你喜欢COM这样丑陋的东西感到十分不理解。
zzfff：
Waterloo同学，狂是好事，我喜欢狂人，因为我也是个狂人，年轻人不狂，和咸鱼有什么区别？关键是：狂完之后自我反省是否狂得很SB？
你先照照自己 —— 至于使用什么方式就看你的审美观了 —— 是否应该补习语文？ 是否显摆得很SB？
　 2010-02-04 18:33
我还真奇怪。
我说.net 实现了oo二进制协议，为什么你为认为我说的是.net 仅实现了oo二进制协议？
我说COM实现oo二进制协议的手段太龌鹾， 为什么你为认为我在说你排斥CLR？
为什么你把你自认为的一些东西
到我头上？
我的思想是否
你代表了？
逻辑帝， 你能给我一个合乎逻辑的解释吗？
你是宣传部的还是外交部的？
] 2010-02-04 19:46
OwnWaterloo
两位冷静
　 2010-02-04 20:02
COM，或我所谓的“广义COM“，或更广义的，Win32 API，对现在的Windows开发者来说很尴尬很鸡肋。一方面，它们的性（投入）价（产出）比很低，而.net framework library基本上提供了对它们的封装；另一方面，当“你”跳出，或不得不跳出CLR这个温暖舒适的matrix时，“你”不得不面对它们，向它们“下跪”。纯CLR的操作系统，我悲观的认为未来10年，乃至15年内，不会出现。现实总是这样的不完美，如同你我也不完美一样：）
　 2010-02-04 20:10
...它们的性（产出）价（投入）比很低...
　 2010-02-04 20:40
zzfff：COM，或我所谓的“广义COM“，或更广义的，Win32 API，对现在的Windows开发者来说很尴尬很鸡肋。
1. 你所谓的广义， 我真的无法理解……
你指的是更底层？ 没有托管环境？
2. 我没觉得我很尴尬啊
虽然Win32 API有设计得不好的地方（可以说是很多）。 但总体思路是没错的 ： 想要二进制兼容吗 —— Windows一个很重要的目标 —— 那老老实实用C。
2.1 OO不是万灵药， OP也不是绝对应该被淘汰的东西
想想前2天首页上还出现一个约瑟夫OO解在哪…… 脑子坏掉了。
2.2 C里面实现OB是很容易的， 简单的OO也可以
3. 我真正感到尴尬的时候
是我不得不使用dshow， 不得不去写COM客户端代码的时候。
COM的代码 —— OO的思想， OP的实现 —— 一切都那么不自然。
COM是在技术准备不成熟的情况下， 强行推出的一个二进制OO协议。
小结：
要想二进制兼容， 用C api不好吗？
同时想要OO（以及你觉得.net环境提供的其他功能）， 用.net不好吗？
COM夹在中间怎么都是不伦不类， 高不成低不就。
一方面，它们的性（投入）价（产出）比很低，而.net framework library基本上提供了对它们的封装；另一方面，当“你”跳出，或不得不跳出CLR这个温暖舒适的matrix时，“你”不得不面对它们，向它们“下跪”。
性价比是商业公司的选择。 我在上面的留言里也说了： 我的言论更多是从个人角度， 希望后后背分清什么是产品技术， 什么是通用技术。
我从来都不在CLR这个温暖舒适的matrix中 。 我是C/C++程序员。
C/C++开发慢确实是实情， 所以我也曾考虑过深入学习C#。 可后来接触python后， 就对C#没爱了。
对产品中使用COM， 我上面也列举过我的态度。
同时， 在这个回复中也提到有不得不使用COM的时候。
但是你的逻辑存在错误 ——
从利益角度权衡后决定采用某种技术
， 并不能成为
这种技术很优美
的理由 —— 相反的是， 这通常说明该技术非常龌鹾， 否则就不需要权衡了。
　 2010-02-04 21:28
又想了下，如果真会出现纯CLR的OS的话，我觉得并不是把Win32 API/COM赶尽杀绝，而是把它们深深的打入冷宫，如同把汇编语言打入冷宫。现在CLR/.net framework library并没有一统江湖（企业开发好点，消费娱乐开发很糟），只能说明它不够强大，以及硬件不够快，还有老赵传道不够积极。
　 2010-02-04 22:17
全民扯淡，名不虚传。“参与讨论的霍炬（@virushuo）和郝培强（@tinyfool）都是老程序员，他们在上世纪末也都是微软平台的开发人员，但是因为难以忍受微软在那时候“毫无克制”的技术更迭（如VC = COM = .NET）”——我怎么觉得越想越奇怪，微软发展新技术，但并没有拒绝老技术啊，m$的技术的向后兼容性，在这个星球上应该没哪个公司做得比它更好。“你”老技术用得好，用得绝，用得难以替代，自然有“你”的一席之地，还怕什么？又怨个what？难道是人笨怪刀钝？
　 2010-02-05 00:22
虎年将至，怎么牛人们一点霸气也没有了呢？给刚入门的小弟***提个醒：那些看起来很牛的人通常不怎么牛，因为他们把大部分精力花在如何让众人觉得他们更牛上。
我呢？叫我职业扯蛋犯，谢谢。千万别人肉搜索我啊，虚拟世界就玩虚拟世界的规则。
　 2010-02-05 00:53
zzfff：
给刚入门的小弟***提个醒：那些看起来很牛的人通常不怎么牛，因为他们把大部分精力花在如何让众人觉得他们更牛上。
这个说法很有意思， 应该能够解释一些问题。
　 2010-02-05 02:07
有点插不上嘴了
Com丑并不是底层实现上丑 是众多组件封装的不漂亮
大量com的开发权掌握在vc++程序员的手中 而这些开发com的vc++程序员带有大量win32api和vc非标准/安全/公共/托管类型的习惯，导致市面上的com带有大量语言特性和平台特性，可以说是vc++对api的垄断地位导致com那一代组件丑的非常丑！非常丑！
所以 ADO没有人说丑 Fso没有人说丑 htmldom xmldom 也没有人说丑
　 2010-02-05 12:37
所以 ADO没有人说丑 Fso没有人说丑 htmldom xmldom 也没有人说丑——因为它们实现了IDi atch接口，或者说实现了双接口，或者说实现了自动化接口，数据类型仅限于VARIANT能表达的，所以脚本语言可以调用。
而下面的IDL：
HRESULT Method([in]long cMax,[in,out]long *pcActual,[in,out,size_is(cMax),length_is(*pcActual)]short *rgs);
基本上只有C/C++ client啃得动了，COM的变态有时赶超老学究。
COM组件实现自动化接口，如同.net组件声明CLSCompliant(true)，是强烈强烈强烈推荐的。
　 2010-02-05 19:38
zzfff：
所以 ADO没有人说丑 Fso没有人说丑 htmldom xmldom 也没有人说丑——因为它们实现了IDi atch接口，或者说实现了双接口，或者说实现了自动化接口，数据类型仅限于VARIANT能表达的，所以脚本语言可以调用。
而下面的IDL：
HRESULT Method([in]long cMax,[in,out]long *pcActual,[in,out,size_is(cMax),length_is(*pcActual)]short *rgs);
基本上只有C/C++ client啃得动了，COM的变态有时赶超老学究。
COM组件实现自动化接口，如同.net组件声明CLSCompliant(true)，是强烈强烈强烈推荐的。
:)，看起来倒是zzfff比那些看起来很牛的人更懂COM(不过上面的IDL不只是C/C++才能啃得动，Delphi啃起来也不费劲)。
同感，国内很多搞技术的太浮躁，在自己根本没弄明白前，就咆哮着说这平台不好那系统很烂。学COM的，以为读过《E ential COM》和《I ide COM》就懂COM了，他们不知道还有一本书叫《E ential IDL》。玩了两下COM玩不动，就说被伤了，他们大概连Apartment/Context都没搞明白。出了问题搞不定，就说平台烂。
那些所谓上世纪末玩微软平台的先烈们，在我看来就一句话：上世纪他们根本就没入门(抱歉)。真正的“大家”从不贬低任何技术，正所谓见多识广、得道其中。
-msolap （国内技术论坛充斥着骂声，满目浮躁，叹！)
　 2010-02-05 20:55
@msolap
握手。嗯，C#也啃得动。上论坛，基本上随口说，没怎么去考证，最尴尬的是，当初学COM认知不深，现在又n久没用。Don Box最招牌的两句话应该是：COM as a better C++,CLR as a better COM。诚然，COM有很多令人不爽的地方，但它是为解决实际问题而生的，它早已与Windows融合在一起，更是component-oriented programming的无冕之王。
回首历史，C++-COM-CLR，技术在多么和谐自然的进化。让人唏嘘的是：art is long,life is short。
　 2010-02-05 21:07
哈哈，白头宫女话天宝：）
谈到Context，我立马想起了Tim Ewald的大作《Tra actional COM+:Building Scalable A licatio 》，读起来大呼三声不亦快哉！我亲切的称它为E ential COM+
　 2010-02-05 22:31
zzfff：
哈哈，白头宫女话天宝：）
谈到Context，我立马想起了Tim Ewald的大作《Tra actional COM+:Building Scalable A licatio 》，读起来大呼三声不亦快哉！我亲切的称它为E ential COM+
你不说这本书我倒是忘了。DevelopMentor在COM年代出了不少好书，几乎本本都是精品，当时只要有DevelopMentor出的书一定找来看。但自从DON BOX的《E ential .net》这本书出了后，几乎就成了分水岭，DevelopMentor就再也没见过什么好书了。Don Box这本《E ential .net》写得实在不敢恭维，我的总结是书没有思想也就没了生命。最要命的是他老人家在书里花了大量篇幅介绍一个要命的东西CBO(ContextBoundObject)，以至谋杀了N多人的时间去用CBO搞AOP。
COM在1993年就诞生了，那个时候中国有什么？记得当时流行的是DOS/Win3.1+Turbo C+软盘。局域网是凤毛麟角，而且还是同轴电缆。互联网更连影子都没有。大学里大多还是DEC的VAX机。我们单位有钱，买了一台COMPAQ的486机，花了5万大洋(以现在的眼光看来是在抢钱)。最有意思的是那时候搞微软平台算是时髦的，UNIX根本算不得什么，绝对不像现在那帮所谓的先烈们眼里成了香饽饽。因为遍地都是UNIX，DEC有OSF/1，SGI有IRIS（SGI出的Indy/Indigo蓝色工作站堪称计算机经典），PC机上有XENIX（后来成了SCO UNIX)。知道XENIX是谁弄的吗？呵呵，是微软。一想到这里，我就觉得COM在当时简直是神来之笔。
很多现在觉得理所当然的事情在当时根本是天方夜谭，我想这也是很多人觉得有些技术很丑陋的原因，他们没有经历过那个年代，不知道很多技术的前因后果和历史变迁。这当然怪不得他们。
很怀念过去的时代，当时搞程序的碰到一起都是相互交流相互仰慕。哪像现在各各都觉得自己很牛气，相互踩来踩去。可笑的是，现在IT业早已迈过了让人引以为傲的年代。既然都是程序员，都在IT圈，都为了自己的梦想，为什么还不相互抬举、相互促进呢？？？
-msolap
　 2010-02-05 23:11
@msolap
受教。关于.net中的context，我的理解就是拦截器，pre-及post-proce me ages（method call），目的，嗯，AOP。AOP这个东东，理论上很美，但我没什么实践。AOP是remoting的基石。说到这，我不得不抱怨微软，因为从
应用层面
上看，WCF与remoting是重叠的，ms的东西很复杂，人的精力有限。理性的说，这不怪ms，WS-* protocol stack在大概在04年才基本成熟，indigo才启动。
，深挖WCF的实现，会发现它使用了System.Runtime.Remoting里的内容，除非是redmond的人，感兴趣的应该不多。
抱怨都是主观原因。不过人是感性动物，抱怨是正常。说到这，我是不是该假惺惺的给霍炬和郝培强两位道个歉呢？算了，我信奉人性本恶，圣人不是我的奋斗目标。
下一秒作恶。
　 2010-02-06 02:22
:)，context不是拦截器，不过拦截器是context/apartment的衍生物，或者说是一部分。COM+中的context其实和传统我们说的context(比如thread context)概念是一样的。如果我们把COM对象比喻成一位大家闺秀，那么可以把context想象成她的闺房(这也正是'apartment'名字的来源。实际上context是COM对象声明的一组基本属性以及COM system维护的一些高级属性）。Thread Context包含寄存器属性，thread没有这些context是存活不了的。类似的，COM object离不开赖以生存的context属性，大家闺秀也离不开她的闺房。同一个闺房里的人可以直接对话(方法调用)，因为她们属性一致。不同闺房的人则未必能直接对话，除非两者的属性兼容。如果不能直接对话，那么必须要通过翻译才行。这个时候proxy/stub就出现了，也就是你说的拦截器，拦截器把一个闺房里的语言翻译成另一个闺房能接受的语言(这里的语言并非只是指编程语言)。在COM的世界里，IDL是世界语。
在.net的世界里，context依然存在，每一个a domain都有一个default context，由于.net对象大多都在一个a domain的default context中，他们可以直接对话，因此context也就不太引人注目了。但必要时还是会出现的，比如ContextBoundObject、remoting，还有跨a Domain。其实从这里就可以看出.net骨子里流的依然是COM的血，因为COM的理念从来就没有过时。COM+的对象可以设置它需要的属性(attribute)，因为COM+的一个梦想就是面向attribute的编程，我想这也是为什么.net里面会有大家熟知的attribute。
当然Context现在没人关心有其更重要的原因，回到COM时代，COM是不同子系统之间的粘合剂，一个大的应用可以分成很多子系统，某个子系统可能是C++写的，而另一个子系统可能是VB写的。某个子系统是运行在应用服务器上的，而另一个子系统是跑在客户端的。COM充当了重要粘合加翻译的作用。反过来COM又是一个应用系统的分割器，将一个大系统分成了一个个子系统。子系统内部用什么语言，什么OO的方法实现都可以，COM不关心。但如果子系统间要对话，就得遵守COM法则，用IDL说话。这就是为什么谈到COM，必然要谈到接口谈到IDL语言。COM接口才是COM的本质，COM不是better C++(语言)，COM是better C++ interface。Don Box的一句COM as better C++把大家都带到沟里去了，那显然不是他老人家的本意，呵呵。
在.net世界里，大家都说CTS语言(Common Type System)，语言部分接口问题(不是全部)消失了。所以Context没人关心是一件好事(但不等于Context没有了，不等于COM is dead)。
写了这么多，也是顺便告诉楼上那位仁兄，他的理解错在哪里。COM从来就不是以一种面向对象的语言或框架出现的。再告诉那位仁兄，为什么建议他读英文版：1)语言的障碍是很大的。2)当时潘爱民翻译《E ential COM》的时候，“传闻”微软GTEC COM su ort team集体写信抗议潘爱民他老人家不要糟蹋了那本书。:D，可能完全是个误会。
-msolap
　 2010-02-06 12:26
老兄知识真系统啊
虽然个人理解和你一样 但是多是道听途说 经验产物，不能像老兄你这样有根有据娓娓道来啊
在.net世界里，大家都说CTS语言(Common Type System)，语言部分接口问题(不是全部)消失了。
也不能说是在.net世界里啦，.net所在的时代决定了CTS，或者说托管数据类型必须存在，
不然让每一个想写出漂亮com接口的c++程序员 都要实现“IDi atch接口，或者双接口，或者说自动化接口” 光一个string / safe array 就要花上好长时间调试 对他们来说实在是一种折磨啊
我没那么懂com内部的东西
我一直是一个享受团队中com开发者成品的vb6/脚本用户，那些为我写com的兄弟们在和我联调时候的痛苦
我一直是很难忘怀的
　 2010-02-06 12:37
zzfff：
@msolap
受教。关于.net中的context，我的理解就是拦截器，pre-及post-proce me ages（method call），目的，嗯，AOP。AOP这个东东，理论上很美，但我没什么实践。AOP是remoting的基石。说到这，我不得不抱怨微软，因为从
应用层面
上看，WCF与remoting是重叠的，ms的东西很复杂，人的精力有限。理性的说，这不怪ms，WS-* protocol stack在大概在04年才基本成熟，indigo才启动。
，深挖WCF的实现，会发现它使用了System.Runtime.Remoting里的内容，除非是redmond的人，感兴趣的应该不多。
抱怨都是主观原因。不过人是感性动物，抱怨是正常。说到这，我是不是该假惺惺的给霍炬和郝培强两位道个歉呢？算了，我信奉人性本恶，圣人不是我的奋斗目标。
下一秒作恶。
WCF 本来就不应该remoting放在一起啊兄弟
WCF应该看作是 “WS和remoting重叠的地方太多了，分别实现很丑陋，做了一个新版本更NB的超集”才对哦
深挖WCF的实现，会发现它使用了System.Runtime.Remoting的内容
这个有点怪 依赖公共的序列化还说的过去 可能是有写 支持wcf的remoting binding实现，并不构成wcf的基础
基础应当不会使用 remoting内容
　 2010-02-06 12:40
@msolap
再admire一下。嗯，context是a tract的概念，“拦截器”是physical的实现。模糊记得Don在99年的MSJ上有篇对COM+ ctx的深入思考，找了半天，找不到，罢了。.net下的ctx更进化更透明且完全可定制。我突然羞愧自己没勇气再温当年长征路，给自己找了个理由，兴趣方向变了，compiler,DSL。
关于“XX as a better YY”，我觉得，除了刚入门的同学，有点经历的人都认为这是句煽情的话。再罗嗦一下：煽情!=错了
　 2010-02-06 13:39
@韦恩卑鄙
我觉得System.Runtime.Remoting.*与remoting是有区别的。有点古怪。前者可以看作是，如msolap所言的，ctx，.net中的ctx。后者可以看作是DCOM的托管代码版。后者被WCF替代了，或者说，RPC被XML Web Services替代了。
　 2010-02-06 14:46
学的多就是有争论的资本，呵呵。
我想插句话都不知道说啥捏，呵呵。
　 2010-02-06 15:08
为了消除不必要的误会，申明一下。我所谓的“替代”、“淘汰”什么的全是煽情说法，是不严谨的。只能说明这项技术已不是主流，淡出了公众视线。《国产零零漆》里说：就算是一条底裤，一张厕纸，都有它的用处，更何况一项汇集了无数智慧心血的技术？
@蛙蛙王子
难道你不知道半罐水，响叮当么？（说自己啊，别对号入座）
　 2010-02-06 15:19
@韦恩卑鄙
.net中的ctx，或《E ential .NET》的chap7,Advanced Methods，我认为毫无淘汰的可能，它是.net中的一部分。我只是猜测，WCF的内部实现使用了它们。
（把这一堆东东叫做ctx也许太武断太牵强，叫做“Advanced Methods”又不通俗，就叫这一坨吧！）
　 2010-02-06 16:53
读书多，没有穷尽；扯蛋多，身体疲倦。
　 2010-02-06 17:57
冒泡：）
我说context是抽象的、虚的，也许msolap同学会说它很具体很实在。yes，我还隐约记得IObjectContextInfo,CoGetObjectContext等等，ctx as object确实有点清晰具体了。但，除非去redmond把COM+的source code读个底朝天，即便把《Tra actional COM+》读5遍，它都是虚的——心里虚。
.net中的ctx，当然可以去读SSCLI弄个明明白白。但，在现实世界，一切要讲性价比，或功利性。把SSCLI读个底朝天的人的功利性很明显：去redmond。
想起一个很酷的标题：《雷德蒙与世界的距离》
　 2010-02-06 18:28
我引导你
思考3个问题
msolap：
回到COM时代，COM是不同子系统之间的粘合剂，一个大的应用可以分成很多子系统，某个子系统可能是C++写的，而另一个子系统可能是VB写的。某个子系统是运行在应用服务器上的，而另一个子系统是跑在客户端的。COM充当了重要粘合加翻译的作用。反过来COM又是一个应用系统的分割器，将一个大系统分成了一个个子系统。子系统内部用什么语言，什么OO的方法实现都可以，COM不关心。但如果子系统间要对话，就得遵守COM法则，用IDL说话。这就是为什么谈到COM，必然要谈到接口谈到IDL语言。COM接口才是COM的本质，COM不是better C++(语言)，COM是better C++ interface。Don Box的一句COM as better C++把大家都带到沟里去了，那显然不是他老人家的本意，呵呵。
问题1：在COM出现之前， 是否
不存在不同系统之间的粘合剂技术
错， 无论是COM技术出现之前还是之后， 不同系统之间的粘合剂技术一直存在 —— C语言的api。
写了这么多，也是顺便告诉楼上那位仁兄，他的理解错在哪里。COM从来就不是以一种面向对象的语言或框架出现的。再告诉那位仁兄，为什么建议他读英文版：1)语言的障碍是很大的。2)当时潘爱民翻译《E ential COM》的时候，“传闻”微软GTEC COM su ort team集体写信抗议潘爱民他老人家不要糟蹋了那本书。:D，可能完全是个误会。
写了这么多， 显摆一下即将过时的大量经验； 如果你觉得很光荣， 请你继续。
问题2：既然在COM出现之前， 已经存在不同系统间的二进制粘合剂， 那为什么还要搞出COM？
问题3： 结合问题1，再结合与COM通信的语言，你再想想OO是否是COM的一个目标？
可惜这个目标它完成得很烂。
COM确实还趁这个机会（推出COM的机会）将许多其他设施一并实现了。
这部分我确实没有深入了解， 因为我觉得这种过时的技术不值得我花时间去学习， 更不值得花时间去看《ECOM》。
直觉告诉我，
如果抛弃OO这个目标
， COM提供的其他设施：
1. 要么C api已经提供了
2. 即使没有提供， 也不需要COM这样复杂的协议。
如果你原意， 可以举出一些COM提供的你认为的优秀设施；
而我可以试着告诉你这些设施中， 我认为优秀的那部分应该如何在非c api的环境下达成。
然后我们在回到原来的问题： COM是否是被OO协议所拖累，才会实现得如此丑陋。
同时， 给你一个建议： 深究技术是好事， 国内缺乏（大部分人）缺乏这样的精神 —— 这也是我订阅老赵blog的原因 —— 但别陷进去了！ 要思考这种技术究竟解决了什么问题； 它解决问题的方式的优势与缺陷； 以及它解决的问题， 究竟是否真的是一个问题。
　 2010-02-06 18:52
仔细看了看阁下的评论， 确实对COM了解很深入。
同时我也想请教一个问题： 是否对某技术不如你了解深入， 就没有任何资格评论这种技术了？
我一开始的观点 ——
COM的路线是错误的
。 理由：
做底层？ 它太复杂。
做高层？ 使用COM的代码所做的事， 究竟是
fighting with the requirement
fighting with the protocol of COM
COM的代码是在用编写底层代码的都不需要的复杂度去编写上层逻辑
， 两边不讨好。
这个观点， 有错吗？ 负责任吗？ 是否需要对COM研究到如同你那样的深度， 才有资格评论？
　 2010-02-06 19:00
@OwnWaterloo
补充一下， 上述复杂度特指COM的OO协议所带来的复杂度。
底层用不上， 高层受不了。
　 2010-02-06 20:55
说实话， 和ls各位的讨论引发了我去深入了解COM的冲动。 仅仅是冲动，吃过饭后就打消了这个念头。
我还有其他更重要的事要做， 不包括为一种过时的技术逞口舌之快， 也不包括教育他人非COM的环境下会更美好 —— 从讨论的角度说， 这是几乎不可能完成的任务（原因见下）； 从自私的角度来说， 关我啥事？
关于我在这篇贴里回复， 做个总结。 该贴我会继续关注， 回复可就没那么勤快了。
—— —— 关于COM的思路是错误的：
对某种产品技术而言， 如果它在短时间就沦为小众技术， 是否可以说明这种产品技术的思路是错误的？
COM是否已经沦为（或者是否会沦为）小众技术？ 它沦陷的时间和.net相比如何？
我打算留给历史去见证了， 我只希望没有gates的ms能够挺过那一天， 别让这成为悬案。
也希望那些痴迷COM的人能扪心自问： COM是真的好， 还是你们在自我陶醉？
但是我对此不抱希望：
要承认自己学的东西是废物， 对任何人来说都是痛苦的 —— 学得越多， 越是如此。
各位COM粉如果打算继续讨论COM的优势， 请随意。
如果其中有新颖的观点， 我会跳出来说一句感谢。
甚至， 如果有能够扭转我思想的观点， 我会站出来说一句oh，对不起，我说错了。
如果需要， 我还可以在c logs首页上发道歉贴。
—— —— 关于批评COM的资格：
再次强调， 在下对COM的了解确实不如ls某些同学深入。
但是， 这足以成为不能评论COM的理由吗？
说出他不是什么都没穿嘛的小孩， 不正是因为那小孩不懂人情世故吗？
—— —— 关于负责任的评论：
确实评论不够负责， 所以我在这里更正一下：
我在该篇评论里的所有留言， 都是个人观点， 而且也许是错误的 —— 别听我的！
没有人拿着刀架在你脖子上说： 你必须用COM！
同样， 也没有人拿着刀架在你脖子上说： 你必须不用COM！
请各位看官自己擦亮眼睛： 生活是美好的， 也是有限的； 不要把美好有限的生命浪费在学习无用的东西上（注意， 并不指COM）。
—— —— 关于
装大牛
嫌疑：
说一种技术的思路是错误的 vs 对某种即将沦为小众的技术
津津乐道
究竟哪种更有装大牛的嫌疑， 各位看官自己掂量吧。
　 2010-02-06 21:19
恶善交加，亦悲亦喜——人生的最高境界
华丽丽的匿
----------------------------------
看来某位秀才遇到兵了，不，是会讲人话的黑猩猩！
持续围观 秀才PK黑猩猩
　 2010-02-07 11:51
韦恩卑鄙 alias:v-zhewg 致力于提高回复平均水平：
@msolap
我没那么懂com内部的东西
我一直是一个享受团队中com开发者成品的vb6/脚本用户，那些为我写com的兄弟们在和我联调时候的痛苦
我一直是很难忘怀的
恩，理解这种痛苦，不同编程语言间的调试本身就是一件痛苦的事情。
你最后的这句话触动了我，程序员间的情感正是在日以继夜地Fighting with XXX protocol时建立了(借用OwnWaterloo的话,hehe)。任何技术都会被自己遗忘，让人难以忘却的往往是与自己一起走过一段的兄弟和当时的痛苦。唉，暮然回首，才发现程序员编写的其实是背后的人和自己的人生。如果希望自己写的程序/应用能上一个境界，就请多考虑程序背后的人和人性。
-msolap
　 2010-02-07 12:12
zzfff：
冒泡：）
我说context是抽象的、虚的，也许msolap同学会说它很具体很实在。
其实你说的没错，我前面说的都是逻辑上的概念。在运行时，Context(闺房的建立)是每次COM调用时由stub建立的(想想thread context建立的时机就好理解了)。另外，stub是COM/DCOM的概念，COM+应该已经不叫stub了，好像是叫interceptor之类的，记不清了。如果你调用一个COM接口的方法不是通过proxy，而是通过裸指针，那么context是不存在的（你也因此丧失了COM/COM+提供的特性）。这样的后果是，如果COM object依赖于context才能正确运行，那你用裸指针绕开context就可能出现潜在的问题。问题的严重程度和错误被发现的可能性取决于Object对context的依赖程度。裸指针的表现形式有很多：编程语言的对象引用、函数指针以及函数指针的变种(如事件)、没有经过正确marshal的interface等等。
COM/COM+对大家说，我可以为你提供服务，如果你需要我提供的服务，就请你遵守我的rule，而不是fight with my rule。我肯定fight不过你，因为你是人，我是还未足够进化的代码。
-msolap
　 2010-02-07 12:57
OwnWaterloo：
@msolap
同时我也想请教一个问题： 是否对某技术不如你了解深入， 就没有任何资格评论这种技术了？这个观点，有错吗？ 负责任吗？ 是否需要对COM研究到如同你那样的深度，才有资格评论？
你的这个问题其实是个哲学问题，这个问题等同于：你如果对一个人的了解不够深入，是否就没有资格评论他了？
我想当然不是，你完全可以拥有自己对某个人的评价:“这个人很烂，不要理他”。但问题是，如果把自己的个人评论在公共场合(如论坛)传播的时候，你就得掂量一下，你对他的评价是否符合传统大众层次上的客观？你是否有足够的阅历和对人性的洞察力？
如果你的判断一旦失误，你会给听众造成不正确的引导，特别是那些没有太多阅历的同学们。这就是我说的
不负责任
这里又出现另一个哲学命题，人们怎么知道自己的判断是否失误？我的观点是人们不可能知道。越是了解不够深入，出现失误的概率越大。每个人都有局限，而局限往往会导致他坚持认为一个错误的观点是正确的。就像醉酒的人大多说自己是清醒的。
那大家是否都不要在论坛上发表自己的心得体会了？当然也不是，但是当你发表自己的看法的时候，应该首先秉怀宽容仁慈之心，保持兼收并蓄(diversity)的心态。要不停地对自己说任何技术都有它的优点和缺点，都有它的适用场景和历史使命。那么你落笔时离客观就比较近了。
我这里有一个个人建议，就是在公共论坛上应该多说平台和技术的优点，少说缺点。多用“不完全正确”等正面词汇，少用“错、烂”等负面词汇。特别是那些影响力大的大牛们更该如此。正面的言论会给大众一个正面的推动，容易创造一个良好宽容的环境(context)。而宽容的环境更容易激发程序员的激情和创造力。
批判一种技术，无论你是否正确，往往都会打击这种技术的爱好者，并造成相互攻击的氛围，洁身自爱的人都会逃离这种环境。这样的技术论坛最后会变成被某些“大牛”和他们的簇拥者劫持的“近亲繁殖”的场所。一个找不到公平和兼收并蓄的论坛哪里还能被正确引导并推动技术发展呢？这就是我说的另一种
不负责任
OwnWaterloo，你说呢？
-msolap
　 2010-02-07 17:05
OwnWaterloo：
@msolap
我引导你
思考3个问题
问题1：在COM出现之前， 是否不存在不同系统之间的粘合剂技术？
错， 无论是COM技术出现之前还是之后， 不同系统之间的粘合剂技术一直存在 —— C语言的api。
问题2：既然在COM出现之前， 已经存在不同系统间的二进制粘合剂， 那为什么还要搞出COM？
问题3： 结合问题1，再结合与COM通信的语言，你再想想OO是否是COM的一个目标？
可惜这个目标它完成得很烂。
呵呵，我来回答你这三个问题，作为友好往来，你也不吝赐教回答我的问题吧。
问题1，应该算是你的自问自答吧，这里好像没有人说过COM之前和之后，地球上没有粘合剂技术。
本以为你会说COM之前有CORBA，没想到是C API。这里请教一下[问题A]C API是指什么？ANSI C语言？C runtime library？OS API？
提到ANSI C，想起一份资料说到，当年C++刚出来的时候，C的爱好者针对C++特性与C++阵营进行了激烈的争论。C的爱好者认为C++的所有特性 C语言都能完成，而且完成得更好。我相信C阵营有足够的理由证明这一点，特别是在可移植性上。这是题外话。
C语言可以胜任所有别的系统能做的事情，COM runtime还是用C写的呢。
问题2，为什么还要搞COM？
是因为各种技术都有各自的优缺点和适用场景吧。COM有它独到的优点，特别是在Windows平台。
我们来看一下C语言的一个经典接口问题，type-safe Linkage：
如果某个子系统A用C实现了一个API，接口是：void Foo(int i); // contained in foo.h
另外一个子系统B用C来调用这个API，不幸的是，foo.***件从软盘里读出来的时候，不经意把接口变成了void Foo(double i);
问题在于这个B子系统(#include foo.h)在通过C编译器编译和链接时完全没有任何问题。当B子系统碰巧调用到A子系统的Foo时，悲剧就发生了。
[问题B]请教OwnWaterloo，如何通过C API来避免子系统粘合时接口描述错误问题？
当然我前面说的软盘显然是不靠谱的，咱们现在有U盘有网络，可以保证foo.h在复制到B子系统的编译环境是完全一致。那么请考虑一下子系统A如果在版本更新升级时怎么办？
问题3： 结合问题1，再结合与COM通信的语言，你再想想OO是否是COM的一个目标？
您的回答是：“可惜这个目标它完成得很烂。”
我之前在给zzfff的回复中提到：“COM接口才是COM的本质，COM不是better C++(语言)，COM是better C++ interface。”。我再给你总结一下：“OO从来就不是COM的目标”（因此也不存在它完成得很烂之说，你算是被人带到沟里去了）。OO的大部分事情在面向对象的编程语言里面已经做得很好了，COM不关心OO，COM关心的是子系统和子系统，模块和模块，组件和组件之间如何跨越接口边界。接口边界现在是一种轻松的说法，一种痛苦的说法是接口鸿沟。
子系统和子系统间有哪些鸿沟？
1.编程语言的鸿沟
[问题C]请教OwnWaterloo，C API如何来调用一个VB写的方法？C API如何让网页上的Java Script调用Delphi写的一个组件？子系统A调用子系统B，结果C++写的B子系统抛出了一个异常，C API如何让C语言编写的子系统A捕获到这个C++异常？C API如何解决Windows平台上调用惯例的问题(call convention)？是WINAPI的stdcall？C的Cdecl，C++的thiscall？还是delphi的safecall？
2.跨进程、跨网络的鸿沟
[问题D]请教OwnWaterloo，C API如何实现进程间调用？如何跨越网络的边界？指针是个虚拟地址空间里的概念，那指针如何跨进程和网络传递，指针的指针怎么办，你怎么知道这是指针？整型数据在SUN的solaris系统上和在Intel的Windows上的内存布局是不同的，怎么转换？
3.安全的鸿沟
[问题E]请教，子系统和子系统有不同的安全验证体系和授权体系，C API如何传递Credential？Delegate？Impersonate？Full Trust？
4.两阶段事务提交的鸿沟
[问题F]请教，Component A和B都访问和更新不同的数据库，C API如何实现分布式事务？
5.业务和历史的鸿沟
[问题G] 一个组件OLD是上个开发团队写的，Spec里注明了，本组件不支持多线程同时访问。请教C API如何解决多个组件同时并发调用OLD组件的问题？
6.其他的问题
在此先略过，我急于想知道前面几个问题的***，:)
还是那句话，没有经历过，自然就不知道很多问题的前因后果和历史渊源。前人的贡献今天被当成了想当然，但这就是真正的技术进步吧，:)
最后跟OwnWaterloo兄弟说一句，一种技术如果你看到了它的可取之处，你就真正得到了。如果学一个技术扔一个技术，就像猴子摘玉米，摘一个扔一个，到头来会两手空空。这是对自己的
不负责
COM慢慢淡出历史舞台，COM有太多的问题，其实前面没有任何人否认，更没有人像你说的“陶醉在COM的世界里”。大家都在说一句话：“COM有很多闪光点，COM的思想值得我们去思考去学习”。
-msolap
　 2010-02-07 21:00
老兄的帖子让我学到不少，要说老兄的阐述只是让我觉得你懂得真多，老兄提出的问题就得让我真正有所收获了。
另外，老兄对COM和OO的划分放在10年前的话，不知道能让多少同时学习OO和COM的人少受痛苦，唉唉，唉唉唉
今天没白上博客园。
　 2010-02-07 21:24
讨论的真好 收益啊
　 2010-02-08 11:32
确实 com不是面向对象的， 甚至com是属于面向服务的味道。。。
　 2010-03-05 23:54
看看微软的技术迭代多爽啊，学习WM的孩子又可以学习新的WP7了：
微软：Windows Phone 7完全不兼容Windows Mobile 6.x应用程序
http://news.c logs.com/n/58018/
　 评论共2页: 2 发表评论 昵称：
主页：
邮箱：
(仅博主可见)
验证码：
评论内容： [使用Ctrl+Enter键快速提交评论]
1662320
VRR493NiIGA=
最新IT新闻
最新知识库文章
简洁版式：
网站导航:
，网名
，洋名
Jeffrey Zhao
，目前就职于盛大创新院产品开发部，研究员。
InfoQ中文站编辑，多次受邀于微软TechED，MSDN WebCast及各微软官方或社区会议中担任技术议题讲师。
关注前沿技术，并致力于开源社区与微软平台的组合优化。对函数式编程，并行程序开发，代码之美以及程序员能力与修养等相关问题也有着浓厚的兴趣，同时非常希望能够写程序到60岁。
希望可以给初学者以合适引导。坚定的北大青鸟反对者，强烈愤慨恶劣的培训机构对于处于懵懂期的初学者以误导，强烈抵制各种虚假广告给业界带来的不良影响，强烈建议有理想有抱负的从业青年放弃北大青鸟，不要做冤大头。
This work by
is lice ed under a
. 昵称：
园龄：
荣誉：
粉丝：
关注：
最新随笔
最新评论
不好意思不记得你是谁了……什么叫做改变了原有的方向？
-- Jeffrey Zhao
我就不想冒险呐…
-- Jeffrey Zhao
求稳啊没办法……
-- Jeffrey Zhao
未来架构师
现在就是在为创新院招聘啊，呵呵。
-- Jeffrey Zhao
未来架构师
这是我一年半来亲身体验的。
-- Jeffrey Zhao
未来架构师
至少加班是没有的。
-- Jeffrey Zhao
随笔分类
随笔档案
我参加的小组
团队博客
编程语言
存储相关
其他项目
视频资源
推荐内容
英文博客
英文资源
中文博客
中文资源
资源下载
Copyright 2011 Jeffrey ZhaoPages: ( 1/3 total )
本页主题:
无关风花雪月，只是一场“虹”宴。
陈水－欠扁
【女王殿下。| 滅頂 】
1065 点
3136 片枫叶
贡献值:
小筑金币:
朋友圈:
在线时间:6006(小时)
注册时间:2007-04-04
最后登录:2011-08-05 无关风花雪月，只是一场“虹”宴。
管理提醒：
本帖被 陈水－欠扁 执行加亮操作(2007-07-07)
无关风花雪月，只是一场“虹”宴
U1(1eTyu lV!ecJw$ screen.width-461) window.open('http://dl1.breezecn.com/attachment d9fh4f764fg6dfs/Mon_1011/6_162985_d6d9bc412b9d6ac.jpg');" >
CpHF3o`Z6 1GB$;0 W), 我与L'Arc~en~Ciel
#mY*H^jI]~ T'.U?G 她说，第一是L'Arc~en~Ciel，第二是X Japan，第三是Dir en grey。
($:s}_>s 这是三个日本乐队在她心目中的排名，后来，我给她说，我是X Japan，
i/QE)"B"q L'Arc~en~Ciel，最后是Dir en grey。
A2 r1%}{ v,w/g| 她是璇，我高一的第一个同桌，也是通过她，我才接触到VR，
t(/b'Peq 才得以有了自己最爱的乐队，才能真正去了解音乐的魅力。
HU]Yv+3  Q" BIk
= 三个乐队都是她死命介绍给我的，还从家里带来一些图片，
f?:
o 上课的时候拜出来给我看，我当时对这个实在没什么兴趣，
L?!*HS7m 但碍于她的要求以及那股牛一般的热情，只好听她给我唠叨一切，
;taTdzR_ 还有一起分享耳机。

~PYMtg=i -U;2
b_ 说实在，我现在都不知道自己是如何喜欢起L'Arc~en~Ciel，
:lz@G4=C 似乎就是这么自然而然的事情。现在去挖自己的记忆，也挖不出个所以来，
fR_4L 只好放弃。
UZsL0 4}hPq 对于一些声音，是无法抗拒的，也许hyde就是这样一把自己无法抗拒的声音吧，
@,0W( 连带的是L'Arc~en~Ciel的音乐，然后逐渐一点一滴去挖掘，去熟知所有关于他们的一切。
*gMo(-tN
 看《界音》的时候会看他们的消息，去日韩偶像店会买他们的一些周边……
T+p?VngF 记得第一场关于他们的完整的演唱会是在一个同学家看的，貌似是98年的，
C5mq@$6 有我，有那女孩，还有一个哥们，第一个MV是在璇的家看的，然后是其他的MV，
WVDkCo@ 还有一些演唱会的片段，关于他们的记忆就这么一点点串成圆润的珍珠。
bFIt v|Y:'5`V 任何乐队都无法撼动X在我心目中强悍的地位，听日本的一些乐队的歌曲，
-_&"Q4FR;+ 我都会拿他们和X相比，对L'Arc~en~Ciel也不例外。如果说X是经典的，是风暴，
)U0`?kD 是无法企及的巅峰，那么L'Arc~en~Ciel则是一场盛大的音乐宴会，给我很多惊喜以及愉悦。
Sx{vZS3 4^h_n1A L'Arc~en~Ciel的音乐呈现的是多变化，这可以从作曲上看出来，每个人都有作曲
,e\'Y!' 的作品，而作词则更多是由主唱hyde来完成。X之后，他们就是我所牢记的了，自己骨子里
fLM5L_S}Y 的记忆是太过于顽固了，或者说是死死认定一种东西，不让其他的进入，但对于L'Arc~en~Ciel，
qRk F/ 自己却是抗拒不了，那么地自然，那么地轻易接受。不是自我背叛，而是一种连带的重生。
wyF'
B LLp/ SWe 有时候会把L'Arc~en~Ciel的音乐束之高阁，想抗拒一下，但发觉再次听他们的歌曲的时候，
I =G3 却是越来越爱，上瘾了吧，自己都觉得不可思议。他们给我的是什么呢？自己某些时候是个喜欢
6lW\-h`NG 刨根问底的人，喜欢他们什么？音乐？猪猪的声音？大魔王的笑脸？ken大叔在舞台上的随性？
s|*0cK!K^ 还是yu那和yoshiki截然不同的鼓点？理不清，只知道自己带上耳机，听他们的歌曲的时候，
37C'knW 自己会有股那么久违的熟悉，日子是最强悍的敌人，在不知不觉的时候，他们的音乐已经被
?\|QDJXY 自己一一铭记，然后融入自己的世界。
B#g PeD>mCvL" X Japan的音乐是隐忍在自己心里的，而L'Arc~en~Ciel的音乐于自己则是可以携带

 出门的，可以撩拨自己的情绪，但不会激烈到有手握刀锋的感觉，
K&T[F! 这对于自己来说是最好的了。
e:W]B)0/e zVEG)
Hr 有生之年，不知道是否可以亲自去看一场他们的演唱会，自己都不知道。
2H
A-q),6 05年9月他们来上海，自己去不成，这成了自己的一个伤口。现在只能通过碟，音乐，网络去接触
l', +l{\Z 我所喜欢的他们，这也是个好的方法吧。
i
l8n
K .DX 如此认定，L'Arc~en~Ciel将是自己心中的一道不会消失的彩虹。
> nHaMj 不管多年以后如何，不管自己变得如何，只知道，他们给我的世界，
.wH`9aq;5@ 是一直那么精彩而绚烂，如同他们的音乐，如同他们的乐队名字。 I
68Y4s 'dXGd.V7u #BLx +mLq 
=1MVF ;!~&-I0l [ 此帖被陈水－欠扁在2010-11-26 16:17重新编辑 ] 先生。若言——那些隔过黑暗的花与水，却如何看待如此浮世空落尘灰。
细雨朦朦如线落，五月闺重，长雨更浓。
与您，总归是相见无途。世上的繁荣如花开艳丽，我却已厌世如残叶微露。
您，为我心中想念之人。我，于您犹不及过客，不过人间生命短促之物。
朝生暮死。有如蜉蝣。 Posted: 2007-04-24 00:49 |
陈水－欠扁
【女王殿下。| 滅頂 】
1065 点
3136 片枫叶
贡献值:
小筑金币:
朋友圈:
在线时间:6006(小时)
注册时间:2007-04-04
最后登录:2011-08-05 彩虹专辑清单：
O;V^Fk( 2Og
5e DUNE
5{+2#- zh=0zJ screen.width-461) window.open('http://dl1.breezecn.com/attachment d9fh4f764fg6dfs/Mon_1011/6_162985_9f633280bcdad5d.jpg');" >
2ib,33 Z "fhQ{b$i DUNE1993.4.271. Shutting from the sky [*(1~PrlO, 2. Voice ) t
'
*] 3. Taste of Love < +jl($" 4. Enticher 1i.3P$F 5. Flood of tear 2_3os
P\Z 6. Dune P
Z'|) 7. Be destined pp1Kor 8. 追忆の情景Tsuioku no jookei 9ei'o
Z 9. As if in a dream B:UPSX)A 10. 失われた眺めUshinawareta Nagame Tmu2G/yi qBK68B) Tierra
YWA {E)tzBI;^ screen.width-461) window.open('http://dl1.breezecn.com/attachment d9fh4f764fg6dfs/Mon_1011/6_162985_d4b785ded1997a4.jpg');" >
yil5aUA TxN+- f 1994.7.14
. uGne +8\?7,FY 1. In the Air ,aP5)ZN- 2. All Dead edpRx"_ 3. Blame a Iyzt 4. Wind of Gold o.|36#Fa 5. Blurry Eye A(BjU:D(Oj 6. I er Core #wvGS%
7. 眠りによせて Nemuri ni yosete m432,8 K3r 8. 风の行方Kaze no yukue QFhyidm=] 9. 瞳に映るもの hitomi ni utsuru mono .),9a
, 10. White Feather >}]bKq 9P%?Q VTDnh*\5 Heavenly
K~^o06 Y RASk=B screen.width-461) window.open('http://dl1.breezecn.com/attachment d9fh4f764fg6dfs/Mon_1011/6_162985_cfb9f26c039c73c.jpg');" >
4-'0# a v!FeLW 1995.9.1
-H_#et3&i 1. Still I’m with you z?`7g%Z?{ 2. Vivid Color "8(8]GgYx 3. and She Said [,~ @jz 4. ガラス玉 Garasu dama ~Z#\f5yv@ 5. Secret Sig o(3OChH 6. 夏の忧郁 C’est La Vie ?&U~X)Q 7. Natsu no yuutsu 5Go@1X]I 8. Curele md : Wx 9. 静かの海でShizuka no umi de nvodP"iV 10. The Rain Leaves a Scar O4a~(*f N#:W#C{16w
kCoEdQ_ TRUE
b|@f!lA "(\]-%:7 screen.width-461) window.open('http://dl1.breezecn.com/attachment d9fh4f764fg6dfs/Mon_1011/6_162985_9e955a693836663.jpg');" >
`
n e
9&+ 7Uh/Gl 1. Fare Well ;,B $lgF 2. Care of Venu 7zXX&
S 3. Round and Round Rd1I$| Y 4. flower [;7$ 'lr%D 5. good morning hide "/\-?YJjw 6. the Fourth Avenue Cafe `u;4Z2Lr0 7. Lies and Truth U+ief?;4F 8. 风にきえないで Kaze ni kienaide (True mix) 6
&MATMR 9. I Wish *U|2u+| F 10. Dearest Love  'v&f Ky[-ZQQo=5 Hl*/s Heart
)Yw m_f-N ZG-[Gz screen.width-461) window.open('http://dl1.breezecn.com/attachment d9fh4f764fg6dfs/Mon_1011/6_162985_9d73c2dadb09bc8.jpg');" >
.h>te
f fGDjX!3-S 1998.2.25
UHKE\F 1. LORELEY WH0$v#8`v 2.winter fall c *]6>50 3. Singin’ in the Rai :~dI2e\: 4. Shout at the Devil sRf?JyB 5. 虹Niji (Album version) 6 2#dSd}HG 6. birth! lG!W
e'? 7. Promised Land }6^d/nE*T 8. fate Nh/B8:035 9. milky way dd@-9?6M 10. ぁなたanata
S2EeC&-AR h oL"
K mtg3}etA ARK
HOrD20 g4
G?hv`R screen.width-461) window.open('http://dl1.breezecn.com/attachment d9fh4f764fg6dfs/Mon_1011/6_162985_4c217caab9c8881.jpg');" >
Yr9!/;T gx)!0 1999.7.1 LU7d\Ch 1. forbidden lover *D$[@-7 2. HE***EN’S DRIVE BYBf`F)4 3. Driver’s High 0X"D!G): 4. Cradle LU=`K4 5. DIVE TO BLUE chr^
>%Q_ 6. Larva :6r)HJ5sg 7. Butterfly’s Slee N4JJA+ 8. Perfect Blue /T_@rm 9. 真実と幻想とShinjitsu to Ge ou 3RyB 0
n 10. What is Love ..g?po 11. Piece dq&N;kk
| oju}0h
'1 lS.&>{ Ray
cU^Z=B >)sB#e screen.width-461) window.open('http://dl1.breezecn.com/attachment d9fh4f764fg6dfs/Mon_1011/6_162985_18f79ba58d21173.jpg');" >
E~y@ue: ?7Y6: zo$^ 1999.7.1
)S YVVAl 1. 死の灰Shi no Hai oc"!c;T 2. It’s the end {|;5P.,l 3. HONEY GjmPpKIu\ 4. Sell my Soul ZT\=:X*e 5. ow dro c%N8|!e 6. L’heure QR+{Yp 7. 花葬 Kasou xTy[X"sJ 8. Shi hoku ~lose control~ :j}]nS 9. trick 7 fE
QD?C 10. いばらの涙Ibara no namida `pHlGbrW 11. the silver shining sC/5N Zr&~gXmVS K,VN?th REAL
xS4
B"/ 'q#$^='o screen.width-461) window.open('http://dl1.breezecn.com/attachment d9fh4f764fg6dfs/Mon_1011/6_162985_8f1e09c697be272.jpg');" >
DH#n7s'b N^G:m~> 2000.8.30
6
3J_u-o 1. get out from the shell -asian version- 4
4uM:; 2. THE NEPENTHES K%XQdMv 3. NEO UNIVERSE HG1)q\Xd 4. bravery )9^0Qk' ] 5. LOVE FLIES Hcp)Q76X 6. finale cGevFlnh 7. STAY AWAY DNP%]{J 8. ROUTE 666 (XQBBt 9. TIME SLIP Dlc=[kf9 10. a silent letter FmRCTH 11. ALL YEAR AROUND FALLING IN LOVE
`
)9nBZ /M:R|91:_ X1A~#w> SMILE
>)/,5VSE #].n0[ screen.width-461) window.open('http://dl1.breezecn.com/attachment d9fh4f764fg6dfs/Mon_1011/6_162985_511a94be5cefa4f.jpg');" >
U_/sY9gz( j%2l%Mx( 2003
Lo'P;Sb4} 1. READY STEADY GO 3GH@|id 2. Ki _\HMF 3. Lover Boy `MMh"# xN 4. Feeling Fine *Q?
ZJS~ 5. Time goes o c:
 /Wk 6. Coming Closer NVEjUt/ 7. 永远 8PQn=k9 8. Revelatio B8+J0jdg6% 9. 瞳の住人 kQ
5
sG 10. Spirit dreams i ide
Y{6v
W-z_ q[6tvPfkX `
u#' AWAKE
}T@^wY_Ow Vej [wY-c screen.width-461) window.open('http://dl1.breezecn.com/attachment d9fh4f764fg6dfs/Mon_1011/6_162985_2c1416229e06ef3.jpg');" >
hE|Z~5\Y,> 
~H[ 2005
:n'$Txf 1. New World #fq%903= 2. LOST HE***EN ~U] "
dbQ 3. TRUST ;7id![KI4 4. Killing Me Y ^s_v_s 5. AS ONE W'aZw9 6. My Dear @J`o
pR 7. EXISTENCE xvP=i/SO 8. 自由への招待 &|/@;EA$8 9. Ophelia _?j66-(
Q 10. 星空 )-98 7~BB 11. twinkle, twinkle Gv
'; Ban@$uf c/w曲
z\S#P|; U0%T6*H Anata no tameni 2TFb!?/RQ I’m So Ha y l ga%U~ Sayounara Rz
 sgPk Sai wa nagerareta d#-scv}s5 THE GHOST IN MY ROOM b 7XTOB_HO metropoli /"(`oe Peeping tom gxKL
yZO! A swell in the su .m${yU{3 get out from the shell (japanese) {GH0>

1& Yasouka (:(Imk;9 Brilliant Year DpRGPs Link [ 此帖被陈水－欠扁在2010-11-26 16:30重新编辑 ] 先生。若言——那些隔过黑暗的花与水，却如何看待如此浮世空落尘灰。
细雨朦朦如线落，五月闺重，长雨更浓。
与您，总归是相见无途。世上的繁荣如花开艳丽，我却已厌世如残叶微露。
您，为我心中想念之人。我，于您犹不及过客，不过人间生命短促之物。
朝生暮死。有如蜉蝣。 Posted: 2007-04-24 00:50 |
陈水－欠扁
【女王殿下。| 滅頂 】
1065 点
3136 片枫叶
贡献值:
小筑金币:
朋友圈:
在线时间:6006(小时)
注册时间:2007-04-04
最后登录:2011-08-05 热身完毕，进入听觉宴会：
ptTp63+ < 5sq2 screen.width-461) window.open('http://dl1.breezecn.com/attachment d9fh4f764fg6dfs/Mon_1011/6_162985_8b6e4b8f6033934.jpg');" >
kDWvjT =T|m#*{.L 1 new world
>>0c)uC|W jNP%BNd1f "@@Z{ IHj9n>c)[ N"2P]Zr new world是05年继killing me之后发行的第二张单曲。
Xldz&&@ 不可否认，这个单曲我是非常喜欢的，充满爆发力和速度感，
PA>su)N$ 给自己的耳朵猛的一个冲击，有种应付不来的感觉。
iFaC[(1@a 高三的时候就和两个同学一直听这个歌曲，也不知道为什么，
M}`G}* 就是无法停下