COM的前世今生，未来展望

2007年06月27日 星期三 上午 09:36

原文：http://community.csdn.net/Expert/topic/5615/5615144.xml?temp=.9632227
作者：feimingbiao()

(一)
楼主这坑挖得太深，想了半天是不是往里跳，怕出不来给砸里面，赶上周末，还是灌桶水吧，都是亲身体验，也全凭记忆，没去图书馆调研，记错了你们轻点儿砸。

我接触COM是98年（大约在冬季），断断续续也快10年了。 98年夏天从学校里出来，进入公司。当时COM开始火起来了，公司也决定在下一个产品(InstallShield Professional 6.0,这里可能有人知道）全面使用COM。当时公司没有COM很熟的人（除了做过MFC ODL那样儿的），我在学校里的时候弄过CORBA和Java的集散系统，另外最主要的是当时公司都在做IS5.5的后续工作，怕我乱碰花花草草碍手碍脚，就让我去学COM，不管COM好与坏，多多少少这么多年让我能养家糊口，也见证了我从菜鸟到老鸨的历程，所以还是很有感情的。

先说说我记忆的COM的历史吧。COM的前身是OLE（ou-lei，Object Linking and Embedding),用中文说是目标连接和嵌入。任何东西出来都是有原因的，微软当时一直在弄一个进程间通讯的模型，最早是从OS/2沿袭下来的DDE(Dynamic Data Exchange),这个东西功能比较局限，几乎没有人用了（好像现在只有WinZip还在用，很晕）。后来Office组遇到了麻烦。Office想搞一个不同组件儿间能够互相很容易编辑的技术，比如在Word里面可以很方便地编辑Excel的东西，而不需要再另外打开Excel。这东西现在大家好像觉得很平常，但是在当时是个很大的挑战。一堆高手想破了脑袋，弄出来了OLE技术，其实有点儿像今天的OCX。93年的时候已经比较成熟，后来微软的前项目经理Kraig Brockschmidt（后来出家当和尚去了）写了一本儿当时很流行的书，叫《Inside OLE 2》。这本儿书我觉得是够难懂的了，有兴趣的可以去翻翻。可以看出来当时OLE已经有了现代COM的影子，很多Interface一直沿用到现在，比如IPersistPropertyBag等等。另外Serialization，Persistence等技术现在Java到.net也没什么大变化。OLE的出现我个人感觉和当时业界转入OO的大形势很有关系。这个大形势下出现了很多关于Component Model的技术，比较著名的当然还有CORBA。设计理念当然都是OO的核心精神: Program to interface, not to implemention。（对界面编程，而不是对实现编程）。OO现在当然是卖冰棍儿的老太太都讲个12345，不过当时对业界的影响还是划时代的，复杂的工程可以分成很多模块，甚至可以由不同的组或者公司开发，中间只要遵守合同 - Interface就好了。CORBA和COM就是这个时期的产物。IDL语言也跑了出来。楼上sarh2onacy说这个就是对一些设计模式的应用，是很有道理的。实际上《设计模式》这本书（94年出的），也是这个大时代的产物。（那是个英雄辈出的年代。。。），COM里面几乎包括了所以常用的模式,比如class factory, aggregation, delegation, adapter, bridge, facade,chain of responsibility, 等等等等。

OLE太复杂，另外开始是针对Office开发的，不太有普适性，也不大好掌握，所以后来微软在OLE的基础上进行了改进，为了吸引眼球儿，连名字也改了，用了当时非常时髦的几个OO术语, Component, Object, Model,这样一个以IUnknown为招牌的COM技术出炉了。这大概是Windows 95的前后。

COM的设计并不是局限在Windows上的，后来成了这样是万恶的商品社会造成的。COM建立在RPC基础上，RPC并不是微软的专利。后来也确实有人在UNIX上实现了COM。正如现在的.net也不是针对Windows的，不过估计也就局限到了Windows平台，这个不是微软的问题，是别人不买帐。

再回头来说我自己，开始学COM的时候先买了一本英国人写的ATL COM，这当然跟当时ATL的兴起有关。这个决定后来证明太害人了，开始好多精力都花在和ATL眼花缭乱的Template叫劲上了。Visual Studio的Wizard也把COM一个朴实的小姑娘完完全全一顿浓妆艳抹给包了起来。这个让我对COM的理解走了几乎半年的弯路。从ATL开始学COM基本上是和从MFC开始学Windows是一样危害的。以至于我开始一段时候只会用ATL Wizard，只知其然，不知其所以然。基本上对COM的哲学没有什么很深刻的理解。每次遇到问题，就犯愣，公司里面又没有别人懂，最惨的是当时没有csdn,每天只能抓耳挠腮，和大便干燥一样痛苦。后来公司还送我去培训，Dan Box开的培训课。Dan Box当时是业界公认COM大拿，我当时想得好好利用这个机会，学点儿书上没有的东西，就不自量力地报了个COM高级教程。Dan Box口才很好，课也上得眉飞色舞，记忆力也好，十几个学生的名字，公司一遍全记住了。可惜课程当时对我来讲太难了，上来就是COM的实现，Channel Hook什么的，我是云里雾里，基本上相当于公款玩儿了一周。不过也奇怪，大概榜样的力量比较无穷，虽然没有学到什么东西，不过回来好像咣裆一下开了窍儿，我估计以前红卫兵见过毛主席就是我那种感觉。有一天发呆的时候突然一休小和尚一样“叮”地一下，突然明白了，啊，原来COM的实质，其实就是那个看了两万遍的AddRef，Release和QueryInterface啊。这个想通了，以后就容易了。看蔡志忠的漫画，说小和尚问老和尚什么是“禅”，老和尚伸出一个指头，说这就是禅。后来有新手问我什么是COM的时候，我也会很深沉地伸出三个指头：AddRef，Release，QueryInterface，这就是COM。

刚才提到Dan Box，后来微软2000年的时候在芝加哥发布.net,又见了面，当时他已经加入微软，给.net当说客，猛吹.net，狂扁COM,要知道当年他就是靠极力鼓吹COM发了财，开辆宝时捷，车牌子就是IUnknown，几年时间抱了粗腿就调转枪口，让我当时极其粉特。高大形象轰然倒塌。当然我后来生活所迫也卖了身为虎作怅，后来居然有次上厕所的时候和Dan Box站在一起撒尿，当时想着真是他妈人生何处不相逢。

扯远了，跑题了，下篇扣回楼主的问题，写写我自己感受的COM优缺点，和它的前途。

（二）
（我有些词中文不知道如何翻译，所以放英文了，见谅）

扣回楼主的主题，谈COM的优缺点以及前景。这个题目有点儿大，好比“谈改革开放的优缺点”。像我这种COM半瓶子水的水平如果列出个一二三四，明天估计全国人民都笑了。另外谈到优缺点，这个主观的东西就多了，好比有人喜欢苗条的，有人喜欢丰满的。所以肯定是个砖头乱飞的题目。所以我就谈我自己的感受，见淫见妓，不对，是见仁见智。

首先楼主问COM解决了什么问题。我觉得COM第一是解决了模块之间数据封装和隐藏的问题。当然这个C++的Abstract Class和Java的Interface也解决了。进一步，COM也实现了在这个基础上模块与模块之间，甚至是进程与进程之间（包括局部进程和其他机器上的进程）通讯的一个标准。和CORBA一样，COM首先把Client和Server端的实现分开（de-couple)。OO的一个很重要目标就是降低模块之间的coupling，COM和CORBA都是符合OO的这一精神。这样Server和Client端完全可以独立为政，只要是满足了他们之间的合同（IDL里面的Interface），具体如何实现，用什么编程语言，都无所谓。这个实现让开发大规模的程序更容易了。大家都知道，写100个100行的程序比写一个10000行的程序要容易得多。传统的程序，写Client端和写Server端基本要同一个开发团队，因为每方随便改变些东西，就会影响到另外一段。比如一个简单的例子数据格式，同样描述一个人的信息，可以用很多形式来表达，传统的通讯格式，Pipe也好，tcp/ip也好，都只认数据流，所以通讯的两端得规定好数据的格式，这个东西很繁琐，也很容易出事情，一出事情找起问题来也很麻烦。这个我自己有亲身体会，我上学的时候打工给人做一个OS/2上的软件，客户端搜集好数据以后，都传到一个Server机器上做计算。复杂的数据结构要变成数据流然后通过TCP/IP传来传去，经常出错的时候得一个byte一个byte地检查，很头疼。而COM的Marshalling(中文？）提供了一个标准的serialize 和 de-serialize的方法，这大大减轻了开发人员的负担，使得他们可以专心做自己的东西。这无疑提高了开发效率。如果说从C到C++是OO的一个里程碑，我觉得CORBA/COM等技术的出现应该是另外一个里程碑。

还有一个解决的东西应该是C＋＋缺少的类描述。给一个C++的Object，你无法知道它的Class是什么样子的，作为OO语言，C＋＋缺乏MetaClass的支持绝对是个天生不足。其他一些流行的OO语言都有类似的支持，比如SmallTalk的MetaClass，Java和.net的Reflection。COM用IDispatch试图来弥补这个缺陷，当然解决得好不好个人观点不同，不过毕竟可以让Script语言能用COM，还是很有意义的。反过来也可以用数据来定义COM Object本身。比如InstallShield的Script语言里面用户定义的变量，可以通过COM来修改，Script的函数也可以由客户端直接调用，这都是通过实现IDispatch来做到的（当然是得自己实现，靠ATL那东西不行，是死的）。说到这个顺便提一下很多人说到VB的Client是用IDispatch，这个是不对的，VB/VC的Client因为效率考虑，都是直接用VTable的，VB Script是用IDispatch。不要搞混。

说起COM的优点，当然首先是刚才提到的，它使得大规模软件更容易模块化了。一些OO模式的应用让设计，开发，维护都变得容易了很多，这些理论的东西大家都知道，我就不罗嗦了。除此之外，我很喜欢的就是COM这个二进制标准。一个COM组件写好后，无论是C++还是VB还是Script，都可以用（Java通过Jni也很容易）。头一个好处是测试容易了，比如我们开发的时候，都是用VB来测试，因为写起来比较快。另外一个好处就是一个东西写好以后，客户端的程序很容易延展。比如InstallShield的Build引擎(MediaBuildxx.dll) 是COM组件，IDE(C++)里面可以用，CabViewer(VB)可以用,大公司做Automated Build可以用 (VB/Java Script) ，等等，后来的用途不下十几种。而且一个带着Type Library的COM模块本身就是个帮助文件，比如我们当时用msxml的时候，微软的SDK里面还没有提供头文件。没有问题，拿OleView打开，一个Copy/Paste，问题就解决了。传统的DLL光看Export是无法知道函数的Signature和用法的。

COM和其他现有的支持Component Module的技术相比，有一个很大的优点是本身是机器吗，不需要虚拟机（当然VB也可以写COM，这里拿C++比较），这有如下优点：
1. 执行速度高
2. 调试容易。任何带虚拟机的东西，一旦事情出在虚拟机里面，调试是很麻烦的，因为你不知道虚拟机是如何工作的。
3. Dependency少。虚拟机开发的东西，往往换了虚拟机以后，要么不工作，要么有行为变化。比如我们后来Java版的Installer，需要在10个平台一共56个虚拟机上测试，这个工作量是惊人的。COM的东西不会受到这些东西的干扰，NT上能跑的东西，放在2000各种SP，XP各种SP，基本上都不大会出问题。

另外一个我比较喜欢的COM功能就是它把客户端和Server端弄透明化了。同样一个outproc server,既可以放到本机上，又可以原封不动放到其他机器上。关键是Client不知道，也不需要知道Server在什么地方，一个CoCreateInstance，其他的就交给系统了。一些小的功能，比如用IMoniker来实现Name到Object的Binding，也设计得很巧。用过InstallShield 6.0的朋友可能知道Installshield Object,就是事先封好的一些redistributable,比如DirectX，MFC，ADO等等，做安装程序的时候如果你的程序需要这些东西，就把这些Object加到你的项目里面。这些Object每个都是个小的COM Object, 需要不断更新，比如DirectX会不断出现新的版本，但是IDE和Build工具不会更新，所以无法用CoCreateInstance来找到它们，因为写IDE的时候，这些东西还没有出来。而且这些Object本身都是数据描述的，也没有什么CoClass （用另外一个COM软件来封装）。当时我解决的办法就是写了个实现IMoniker的小组件(ismk.dll),负责Name到Object的Binding。IDE和Build工具只需要向ismk提出请求：“嘿，这个顾客想要一个叫DirectX 9.0的COM Object”，其他跑腿儿的事情就不用管了，这样IDE和Build工具的设计就相对干净得多。

还有一个优点应该是稳定性吧，大家知道，微软的OS大量运用COM（到Vista仍然如此），再加上这么多年好多COM的应用，这么大量的测试，COM本身的问题应该是比较少了。而其他虚拟机，比如Java，版本提升太快，测试跟不上，问题频出。每每提心吊胆。

COM的优点肯定还有很多，随便翻本儿书应该比我在这里瞎扯总结得好。

下面谈我感觉的COM缺点和心酸泪吧。

（三）

这个世界上很多事情，往往优点最后就是缺点，中文讲成也萧何，败也萧何，用洋文说是Live by the sword, die by the sword。前面提到的COM的优点也成了它衰退的最主要原因。

COM
98年的时候红透半边天，我也曾天真地想着能靠它吃一辈子饭。几年间没想到过了气。到底出了什么问题？比较公认的一个观点就是COM违反了OO的一些原则。
大家知道COM模块之间的合同是IDL里面定义的那些Interface。按照OO的核心精神，Program to interface, not to implementation, 这个Interface应该比较简洁，只定义行为，而不能掺杂其他实现方面的东西。可是大家看COM的Interface定义，里面很多乱七八糟的东西，比如Pointer是不是Unique啦，是不是支持oleautomation啦，还有其他一些什么size_of, length_of等等，很多都是实现层的一些东西。最要命的是为了支持前面提到的二进制标准，COM的实现是通过VTable来实现的，VTable的次序就是你在IDL里面定义的次序，也就是说你的函数在IDL里面的排序直接影响到你COM组件的行为。这个太致命了，一个设计人员，比如架构师，他应该不需要对COM了解的很深，按理说他只需要定义一些行为（函数），就可以了。 COM IDL的这些特性，要求一个设计人员还要操心实现，连VTable的顺序都得留神，从宏观上造成了开发人员和设计人员的Tight Coupling, 直接违反了OO的精神。这个想想比较郁闷，COM作为第一批投入OO洪流的老革命，最后竟成了老反革命被打倒了。

另外一些个人总结的缺点如下：

1。难学，也可能我天资愚笨，不细说了。
2。Threading Model（线程模型）太复杂了，又是单身公寓又是集体公寓，再加上个裸体公寓。一大堆规则，不留神招招致命。说两个亲身经历的事情吧。（都是InstallShield时期的，后来不怎么做COM了）

第一件是当时微软的一个游戏Flight Simulator（飞行模拟）是用Installshield来安装的，他们安装有一些自己的逻辑，所以决定自己写setup.exe，然后通过COM来和IS的安装引擎联络，流程不复杂：

setup.exe(MS) ---> CoCreateIntance ----> IKernel.exe -------> CoCreateInstance IScript.dll等其他组件

通常安装都是项目的最后时期做，微软游戏组披星戴月，最后好不容易赶在计划内弄完了，想着用InstallShield一过，就回家农夫山泉了。令人激斗人心的最后关头，双击setup.exe, 一架飞机图片出现在屏幕上，然后。。。安装程序挂住了，飞机图片再也不下去了。

当时电话会议那头微软的项目经理绝对是在咆哮，这也让我在很长时间内对微软的人极其鄙视。四十分钟的会，我们副总几乎一句话没说，结束后从椅子上站起来的时候，说了句,"狗娘养的！"

气愤归气愤，工作还是得做，我当然先是看哪儿锁住了，Debugger里面一看，嗯，上面图右半边从Ikernel到IScript的CoCreateInstance死了，这是以前从来没有遇到过的。   先是检查程序，再对着MSDN进行核实，做各种猜测，试验这个试验那个。没有结果。后来急了跟踪到了CoCreateInstance汇编程序里面，真是天昏地暗，一会儿就不知道CoCreateInstance在做什么了。（后来到MS后看到C＋＋的CoCreateInstance代码都晕头转向）。副总一会儿过来一趟，这对个小菜鸟来说压力太大了，当时直觉得喘不上气来。最终也想不明白出了什么错。后来转念一想，是不是微软的CoCreateInstance有什么特殊参数我们没有弄对？想过之后开始Debug敌人的程序。由于人不给源程序，只能在Win32的API层设断点。当时不像现在Debugger可以自动下载Public Symbol（kernel32.pdb),想设个Win32 API的断点很麻烦，先得找到Symbol下载安装，配置IDE，最后设定断点，格式是_CoCreateInstance@20,这个中年同志们大概还有印象，折腾了一气，总算是停下来了，查Stack上的参数，没有什么稀奇古怪的东西。当时已经晚上八点多了，再加上饿，真是垂头丧气，想着先去吃饭再说吧，就一顿狂按F5，不想跟踪了。就在这时候，一件意想不到的事情发生了。

我这个人记忆力不好，Debug的时候，尤其是汇编吗的时候，经常就忘了在哪儿了，所以有个习惯，就是把Stack上每层都设上断点，这样不会跟飞了。我拍过第一个F5之后，期望着上层Stack上那个断点被击中，所以啪啪啪敲了好几个F5想跳出来，让我想不到的是，我的F5敲过之后，程序没有回到上层来，就是说微软的程序等到叫CoCreateInstance的函数里面了。这个作为GUI程序是不太常见的，因为主线程不能Block，副线程通常应该回来。我很好奇，赶快让Visual Studio断下来，定睛仔细观瞧。。。我Call！ 程序逻辑大致如下：

While (某个Registry Key没有建立）
{
    Sleep(500);
}

很显然，他们在等InstallShield的安装程序创建某个Registry Key之后，做一些后续工作。问题是如果是STA（single threaded model),这样会堵住COM依赖的Windows Message Queue，然后什么怪事情都来了（不过我至今没有完全明白为什么最后Block到我们的进程里面去了，猜想大概是因为一串儿的CoCreateInstance都是用的同一Causality ID，第二个CoCreateInstance的时候，COM通过Channel Hook给最早的公寓发了个信息，有高手儿明白的请指点一下）。

剩下的事情就是验证我的理论了，设个断点在CoInitialzeEx上，果然不出所料。这下轮到我们来电了，我在电话会议里面很爽地教训了微软的开发人员一顿，这次轮到他们一声儿没吭。这件事情倒是让我一夜成名，结果基本上没有经历过菜鸟开始给人打杂儿的过程直接去搞核心设计去了，等同批菜鸟开始做真东西的时候，我已经混成了架构师。所以还是得感谢模拟飞行。那个游戏我没有玩儿，后来CD让同事拿走了。再后来看到报道说本拉登用这个游戏训练基地组织造成911，不知真假。。。

对了，上面这段程序，正确的写法应该是：

while (某个Registry Key没有建立)
{
    while(peekMessage( ))
    {
       TranslateMessage();
       DispatchMessage();
    }
   
    Sleep(500);
}

就是说应该保持Windows的Message Pump。这也是STA应该注意的地方，微软自己的人犯错误，也说明了COM Threading Model不是很直观。

（写成老太太的裹脚布了，下次一定结束）。

(四）

还有一次，在强化试验中，我们的Build突然出问题了。InstallShield IDE基本上抄袭的Visual Studio，Build的时候当然得让用户做别的事情，所以做法是把Project 的COM Object Marshal一下（CoMarshalInterThreadInterfaceInStream，Win32最长的API名字），然后送到Build Thread，那边CoGetInterfaceAndReleaseStream后开始Build。开发的时候一切都是好好的，可是实验室发现如果项目大到一定程度，过一段时间，Build会失败，错误是RPC_E_DISCONNECTED。做测试的那个人很细心，说好像每次都是6分钟左右出这个错误。这个信息太重要了，我脑袋里面一下子想到了培训的时候好像专门讲到了这个6分钟。一翻教材，一下明白为什么了，这是COM的垃圾回收机制起作用了。当Marshal和Unmarshal的时候，COM内部创建Stub和Proxy，类似于相当于Server和Client的关系，Server端不能没完没了地等，因为Client可能不辞而别。所以每两分钟Server就会Ping 客户一下，如果三次还没反应，就把这个Client踢出去了。我们Build Thread一直在忙，所以一直没有回音。最后我只能直接用CoMarshallInterface，选择了TableWeak方式，让Server端不要退出去。

提这个也是说COM Threading Model比较复杂，像中国演艺界一样，潜规则太多，不知道什么时候你就被张导娱乐了。我也和别的公司开发人员聊过，他们也感觉项目复杂到一定程度，线程一乱，就经常不是这悬起来了，就是那儿挂了。

3。安全模式也很复杂，COM Security我一直没有吃透，欢迎哪个高手给深入潜出一下。

4。错误处理。IErrorInfo，不是很直观，最讨厌地是没有一个推荐的错误处理的框架。还有现在这个Template那个Library的，都是Exception Based的，COM偏偏要回HRESULT。一不留神，一个Exception就扔墙那头儿去了，也不知道谁家孩子。RPC_E_SERVER_FAULT,想去吧。

说起错误处理，罗嗦几句。我看到很多项目，设计时候都没有先考虑错误处理，上来先开发Feature，等最后做好了，再加错误处理。对于稍微复杂点儿的项目，基本上已经无法弄对了。另外谁也不喜欢最后大批加入错误处理程序。（平时随时加是很容易的）。设计的时候，错误处理一定要当做一个Feature来开发。这是血泪经验之谈。看一个项目，一看错误处理就能看出来设计准备程度，这个地方很看水平。当然也看过很多开发人员干脆没有错误处理，尤其是小公司的。对这样的朋友我无语，就像楼上朋友的笔名一样 － 彪悍的人生不需要解释。

5。Helper和Wrapper太多太乱。比如说字符串儿吧，BSTR，_bstr_t, CComBSTR,满天乱飞，不细心的随便儿用。另外这些功能都不强大，于是STL wstring, MFC CString也来了,几乎所有公司最后都自己来了个string库，换一个项目得先学string.还有那个SafeArray,都身有体会吧？我觉得可以告它反人类罪了.

6。缺少一个整体的解决问题的框架。比如Java有Hibernate，J2EE，什么Structs等等可以拿来就用的解决方案。COM这方面差很多，家庭制造的东西很多，某种程度上限制了它的发展。

说起COM的前途和微软的计划，我说这个就成COM版宋祖德了。说自己感受吧。COM肯定不会再像以前那么火了，但是像这个版儿上有人说过时了，也有些太武断了。就像曾经有人说C要被VB淘汰啦，C＋＋要被Java淘汰了，结果无论是C还是C++都活崩乱跳的。只能说COM慢慢转入幕后了。Vista的程序，User Mode的程序遍地都是COM，不用的还真不多。新的用户Authenticate的模式（就是登陆界面，以前那个GINA），也是COM，反正微软自己的程序里面，COM绝对是只多不少。.net CLR的源程序我没有看过，不过你看看那什么Domain，Context，哪个没有COM的影子？只不过包了层玻璃纸。COM也偷偷儿在发展，比如以前Server那端一出事情，即使是Crash爆机了，也是回个RPC_E_SERVER_FAULT,其实这时候Server已经没法儿用了，还不如直接歇了我们好Debug Core Dump。这个现在就加进去了，这都是COM不那么火以后的事情。所以我个人觉得COM还有很强的生命力，除非微软哪天改行卖龙胆泻肝丸了。

说到这里，我来给从事软件开发不久的朋友忽悠下自己的体会，当然我也不是什么老资格，话说出来没有赵忠祥老师那么有感染力。其实各种技术，COM也好，.net也好，J2EE也好，都是些解决问题的工具，每种工具都有它的优点和缺点。复杂有复杂的灵活性，简单有简单的代价。而且通常简单的东西出了事情以后就麻烦大了，都是黑盒子。所以什么复杂，什么简单都是辨证的。用什么不用什么要看自己的需要决定，这个一定不要赶时髦。技术毕竟不是头型儿。感觉很多开发人员什么火追什么。所以现在.net满天飞。适合不适合就不管了（和市场也有关系，找工作容易）。拿微软来说，Vista拖延了很多年，一个原因就是操作系统里面盲目上.net, 忘了现在还是社会主义初级阶段了。看到很多人现在埋怨Vista慢，呵呵，没试过.net的Shell吧。其实任何技术推出，后面都是有很强的商业动机。所以一定不要盲从。

没学过COM的朋友，我也建议多多少少了解一下，毕竟在OO各种技术进化过程中这也是很重要的一段里程。就好比了解历史，就更能理解我们为什么是今天的我们。我从来没有写过Java，但是没事儿也去关注一下Java的技术，尤其是多想想，为什么C++，COM，J2EE，.net,等等，为什么设计成那个样子，如果是你设计，你会设计得有什么不同。一个技术可能过时，但一种理念不大会过时，只不过换了马甲罢了。看穿了本质其实都一回事儿。比如Java Hibernate的OR Mapping，一帮人吹捧，其实十几年前很多人就用C＋＋在搞，只不过现在有了XML，有了Reflection，样子不一样罢了。还有各种Remoting，从tcp/ip,DCOM,Java的RMI，到.net Remoting，有时间多比较比较，想想为什么是这样和为什么不是这样。这样融会贯通，用起来就会更得心应手，而且这些东西都是大师弄出来的，里面的哲学理念我们也可以用到平时自己的东西里面。

有时候想一个好的开发人员应该是什么样子的。记得我们中学踢球儿，有段时间一开角球大家就背对球门准备来凌空倒钩，因为这个动作和.net一样新潮。后来想想这个境界就差了，真正好的凌空倒钩都是随心所欲的时候踢出来的。我想软件开发也是这样吧，什么时候能做到可以为之，也可以不为，随心所欲，大概就成了真正的武林高手。

希望大家都成为高手。欢迎切磋交流，也欢迎拍砖。（完）

（五）

回答些楼主和楼上朋友们的问题。(得一点儿点儿来）

wishfly一个字道出了我一大堆话的意思，“难”。举个例子，随便找个 Windows上比较流行的程序，比如SkyPE的用户界面来说（VoIP那部分不讨论了），如果用C++来开发，你要学： C++ + Windows + Win32 另外可能带着MFC。这个学习时间太长了，同样的界面学.net一样儿就行了。所以在抢占有市场速度的今天，.net一类的解决方案确实很诱人。大公司有 的是钱和人，可能用C++/Win32/COM等技术达到最好的运行效果和微调能力，Startup的公司占领市场才是第一位的。难学的一个直接后果就是 市场上人员少，2000年的时候好像VB和C程序员的比例是10：1。用VB做Web/数据库的开发人员肯定比用C++ 写Windows程序的要多得多。所以.net对这些VB人员还是很有吸引力的。

至于微软会不会回到COM，我个人感觉不会，这是我的分 析。首先COM的强项是在Windows的应用软件上（有待于推敲），我们再看看微软的市场情况。微软是做客户端的OS发家的，所以打个比方Client OS是微软的大老婆，这个大老婆预计的一段时间内估计还受不到挑战（Linux还有很长的路要走，上周看到Linux选手热捧Ubuntu，装了一个，我 用的DELL的显示屏，普通得不能在普通了，折腾了半天才弄出1600X1200分辨率，我可能是笨点儿，不过你也千万别和我说隔壁魏淑芬她二姨10分钟 能sudo 编辑X11的Config文件搞定。） 大老婆之后，就是二奶时代了。都得花钱，如果大老婆死心塌地了，有人会没事儿再给她买件貂皮大衣什么的？反正你也不能说没有，少。再看看一些二奶市场：

1。办公软件，几年Office终于打翻了情敌WordPerfect，没人人竞争了，也不得宠了，市场太饱和了，Office2007的最大敌人是Office2003。
2。搜索，投入巨资，反正我还是用Google。
3。企业软件，这个东西不是会写程序就行了，得有商业模型，短时期内还是SAP和Oracle的天下。
4。家电，游戏：Windows Mobile, XBox, Zune, 不知道如何评价。
5。服务器市场

服 务器市场是微软现在最有可能突破的领域。实际上，在Vista出来之前的的几年，微软收入上升最快的领域就是服务器市场，养了微软4年，基本上是从 Linux虎口拔牙。服务器和客户端不同，用户关心的不是泡泡卡丁车和视频聊天。更主要的是全套解决问题的方案。比如做网站的，主要关心数据库，Web Server（+AppServer），开发工具，MiddleWare的集合。高端的服务器UNIX+Orable/DB2，微软玩儿不了，所以只能在 低端的打主意。这方面开源软件确实是个很大威胁。当然这个威胁不是来自王开源等人高呼的英特纳雄耐尔一定要实现，而是一些工业巨头利用开源人员的劳动果实 谋自己的私利（很遗憾很多开源软件开发人员的血汗最后还是流到了资本家手里）。低端服务器这个二奶现在这么几家争：

无产阶级：Linux + MySQL +　Ａｐａｃｈｅ + PHP/JBoss + J2EE + (Jbuilder, IntelliJ, Eclipse，Emacs/vi 等等）
IBM： AIX/小红帽 +　DB2 +　Ａｐａｃｈｅ　＋　ＷｅｂＳｐｈｅｒｅ/JBoss　＋ J2EE + Eclipse
Oracle： Linux + Ｏｒａｃｌｅ　＋　Apache + OC4J + Fusion + JDeveloper
微软： Longhorn 2008 + ＳＱＬ２００５　＋ IIS + .net + Visual Studio

无 产阶级就不说了，IBM和Oracle，都是财大气粗，扔得起钱的主儿。不要说IBM还造硬件。这两家大概是最大的情敌，所以微软如果想追求这块儿，肯定 得使劲花钱。说来说去，技术是次要的，最终的目的卖操作系统是真的。所以微软没有理由大力推广COM了。当然也不能扔，OS和Office毕竟都是 COM，不能家里红旗倒了。