【讨论1】COM的前世今生，未来展望

序：
    开篇帖子来讨论，于我而言，希望这些将留下的讨论，能有留下的价值，若干年后，某一新人偶然拾得这篇口水与板砖乱飞的文字，能从中看到一两句印象深刻的话，如果能因此而触发一些顿悟，几乎是可遇而不可求的想法了。于大家而言，技术以外，大家可以舒展筋骨，尽情八卦，将自己的心得，体会，埋怨，冤屈都一一倒在这里。成天板着脸，咬牙切齿地写程序，慌不择路的回复帖子，对自己的成长不利，对同事的眼球不利。
    我规定的主线诚如题目，但根据社区一贯的跑题精神观之，前景不容乐观，所以外延是起码你得是说和编程相关的话。
    COM已经发展了这么多年，有些程序先行者也做了那么多年，今天就闲谈趣话一番。

解决方案 »

免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货

暂定主题如下：
1.COM是什么？COM的年龄？
2.COM解决了什么？
3.COM的优缺点？
4.COM和.NET的关系？
5.COM的前景
6.征文：另一种风情
限写与COM有关的感受
目前还是不太懂，但感觉COM太重要了。
COM很重要,一直在学习中,哎,感觉这东西太深奥了
小菜程序员,com还没用过呢.书瞄过一本,在云雾中转一圈又出来了.感觉两个字:麻烦.等用的上的时候再去研究吧.
com有个很麻烦的地方：系统依赖性太强，双接口效率太低，瓶颈啊
确实COM接口效率低，不过com系统依赖性太强的观点不敢苟同。COM是一种二进制重用规范，系统无关，理论上也可以在其他系统支持，不过貌似现在还只在Windows系统上使用。感觉COM就是在微软的保护源码情况下，的一种重用方式。当然比Dll形式好的地方就是一定程度上可以防止“Dll地狱”（好像中文是这么说的吧？）所以我觉得还是开源比较好。
COM-> 二进制重用规范, 好处是跨机器, 跨语言, 比较不错的一种开发组件规范.
只是没有做一种语言专门支持COM规范的, 用多种语言都可以实现COM对象, 但都有弊端, 为了解决各种弊端, 又出现各种COM编程技巧, 增加了COM的复杂性,  比如C++ 用它写COM对象需要对C++内存模型有比较好的掌握.模型是好的, 实现是复杂的, 使用是漫长的.
普天之下，有windows的地方到处充斥着com，windows本身是个大com集，以至于很多人在之上开发应用(ie插件 msxml dx ....)
在Vista上的一些权限提升问题，用COM来通信解决还不错...
当作业来完成
1.1.COM是什么？COM的年龄？
The Component Object Model组件对象模型。
Dale Rogerson在《COM技术内幕》中提到微软四年前提出COM的概念，写书的时间是1997年，那COM产生的时间大概是在93年左右。
我按照COM的原理自己写了个小框架,感觉收益良多
最近程序中要用到COM，看了一些资料。感觉COM作为分布式程序设计的接口，很不错！
做为分步式的框架，COM的表现到底怎么样？性能？编程模型的难易度？可扩展性？和CORBA以及EJB的对比，是输还是赢？
一直想认真学下COM还没这机会，惭愧..
刚开始接触COM，感觉这个东西就是对一些设计模式的应用。思路是很好的。只是微软把一个通用的思路局限在自己的平台上了。
感觉学习COM 可以提高自己的设计能力
楼主这坑挖得太深，想了半天是不是往里跳，怕出不来给砸里面，赶上周末，还是灌桶水吧，都是亲身体验，也全凭记忆，没去图书馆调研，记错了你们轻点儿砸。我接触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优缺点，和它的前途。（待续）
>>feimingbiao
从InstallShield 到了 MS?
写出自己的体会，满有意思：）
我们也要在产品中使用COM技术，十分想了解其在速度，稳定性方面对产品的影响，以及其优缺点期待下文！
COM和.NET assembly都是Binary级别重用的组建框架，只不过一个是原生代码，一个是托管代码。
Component Object Model 组件对象模型
还没想好，想好再说...
一定要Mark，feimingbiao好强的说……
正在学习,现在关于COM的书怎么都绝版了!
feimingbiao
顶，哥们幽默诙谐，go on
正在学习,现在关于COM的书怎么都绝版了!
COM的书是不好找了，因为是很老的技术了，很多书都绝版了
感觉MS还会回到COM这条路上来！。NET除了作为JAVA的对手，实在看不出有什么用！
.NET的推出，有利于现有的开发向VISTA开发的平滑过渡， .NET的WEB编程方式，有了很大改进，ASP.NET提高了WEB开发的效率
（二）
（我有些词中文不知道如何翻译，所以放英文了，见谅）扣回楼主的主题，谈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缺点和心酸泪吧。
而COM的Marshalling(中文？）Marshalling是列集的意思
COM用IDispatch试图来弥补这个缺陷，当然解决得好不好个人观点不同/////////////
IDispatch这个作用能不能说详细一些？
比如我们当时用msxml的时候，微软的SDK里面还没有提供头文件。没有问题，拿OleView打开，一个Copy/Paste，问题就解决了。传统的DLL光看Export是无法知道函数的Signature和用法的。/////////////
这一点的确是很方便的
请就微软对于COM的态度,以及它的前途多谈谈.
期待下文,下下文 ....
.NET  对COM的封装和支持还是不错的，哈哈哈
接口的出现，的确是将Server端和Client从物理上分开了，也是解决了软件分发特别是升级的问题，在JAVA里的接口也是同样的作用，有了接口才使得多层设计成为可能。
COM里面，为了保持向下兼容，接口一旦公布，是不能更改的，不然会导致以前的应用瘫痪或者无法工作。后续的新需求维护中，通过公布新接口的方式实现。
com我到底什么时候可以学习你啊
我来找找值得回味的话：）！
feimingbiao
1。从ATL开始学COM基本上是和从MFC开始学Windows是一样危害的
2。这个世界上很多事情，往往优点最后就是缺点，中文讲成也萧何，败也萧何，用洋文说是Live by the sword, die by the sword。
我不懂.net和COM是怎么紧密地联系起来的？谁能详细说说。我使用COM只停留在简单的调用和对理论的理解上，
我觉得COM技术，把太多细节暴露在外面了，以至于勾引我看了很多ATL的源码。
但是到了出现问题的时候，又不知道所以然。感觉.Net实现取代COM实现，是一件好事，以后的程序开发变得简单了。
(四）还有一次，在强化试验中，我们的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一样新潮。后来想想这个境界就差了，真正好的凌空倒钩都是随心所欲的时候踢出来的。我想软件开发也是这样吧，什么时候能做到可以为之，也可以不为，随心所欲，大概就成了真正的武林高手。希望大家都成为高手。欢迎切磋交流，也欢迎拍砖。（完）
（先把这段弄完，然后一并回答楼主和其他朋友的问题。另外好多中文搞错了，比如interface，应该是接口，弄成“界面”了，见谅）
feimingbiao() 太强了,呵呵.
好多地方讲得通俗易懂,哈,都可以去写书了. :D
强COM接触的很少只是偶尔翻书看看没有怎么用各种接口把头都搞晕了
feimingbiao讲的太好了
还有不少应用,我也做COM了一段时间,只是理解了常用的东西,像错误处理这些,根本没用,只是返回一个S_FAIL完事
feimingbiao:
能否说说.net的实际用途？反正.net作的程序，慢就一个字？用了SQL server管理端，那个慢啊！
难道就为了开发效率，来牺牲使用效率？
微软会否重新重视COM？
feimingbiao:
总结你对COM缺点的看法，就如同许多人理解对C＋＋的看法－－难！
但事情都有俩面－－它难，但是因为它给你更多选机会。而这一点往往对开发产品很重要。
而且，随着你对所开发产品理解的深入，这些“更多选择机会”就更加显得重要！
所以我说COM更适用于产品开发，.net择则更适用于要求速度的产品开发。
纠正--->，.net择则更适用于要求速度的项目开发。
3。安全模式也很复杂，COM Security我一直没有吃透，欢迎哪个高手给深入潜出一下。4。错误处理。IErrorInfo，不是很直观，最讨厌地是没有一个推荐的错误处理的框架。还有现在这个Template那个Library的，都是Exception Based的，COM偏偏要回HRESULT。一不留神，一个Exception就扔墙那头儿去了，也不知道谁家孩子。RPC_E_SERVER_FAULT,想去吧。说起错误处理，罗嗦几句。我看到很多项目，设计时候都没有先考虑错误处理，上来先开发Feature，等最后做好了，再加错误处理。对于稍微复杂点儿的项目，基本上已经无法弄对了。另外谁也不喜欢最后大批加入错误处理程序。（平时随时加是很容易的）。设计的时候，错误处理一定要当做一个Feature来开发。这是血泪经验之谈。看一个项目，一看错误处理就能看出来设计准备程度，这个地方很看水平。当然也看过很多开发人员干脆没有错误处理，尤其是小公司的。对这样的朋友我无语，就像楼上朋友的笔名一样－彪悍的人生不需要解释。
////////////////////
这一点，我也是深有体会，一般来说，程序员特别是新手都没写错误处理的习惯，一是懒，二是自信，程序跑的结果不对，就得很辛苦地去跟源代码。要是MS能把API的错误查看接口(::GetLastError())扩展到COM里就好了，COM的错误走了自己的一套路数
6。缺少一个整体的解决问题的框架。//////////////
难道ATL，WTL不算框架么？这一点不认同feimingbiao()
>>6。缺少一个整体的解决问题的框架同样的争议也出现在对C++的讨论中.
我以为,主要看其定位了.如果定位于底层开发的工具,没有那些框架是对的.
就像C++没有框架一样.感觉com气质有点象C++ :)
to ouyh12345(五岭散人) >>我现在就碰到了雷区，好象是线程模式的问题，调试起来，从这个线程蹦到那个线程，理不清楚。

你们都说COM的线程不好掌握，怎么会呢？我觉的COM的线程规则很清晰呀
回答些楼主和楼上朋友们的问题。(得一点儿点儿来）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，不能家里红旗倒了。
像看小说一样读了feimingbiao() 文章
我现在还没有接触过com,但feimingbiao()的文章让我觉得没有再学的必要了,如果工作不需要,这部分东西还需要去了解吗
feiminigbiao()形容得太贴切了.
顶!!!
>>但feimingbiao()的文章让我觉得没有再学的必要了我想这不是feiminigbia写这些帖子的初衷：）
当你需要将client与server端分开，当你需要为你的程序提供开发接口，。你需要COM！
当你的服务器程序需要对BROWSER支持。。
你需要COM！（欢迎接龙－－当你××××时，你需要COM！）
从业五年，除了侯杰和Mayers的文字以外，已经很久很久没有这么痛快的阅读过技术文章了！向feimingbiao深鞠一躬。
开始学编程很久了，比较迷茫，所以还停留在SDK阶段。
看到过这么一段话：现在Win32编程很多，.Net开发速度快但是运行效率低了，ATL/WTL附带COM功能强大，但就是一个字：难。而MFC就尴尬了，一方面和COM一样麻烦，另一方面开发效率也不高。最重要的是运行就一个字：慢（相对SDK），而SDK又太原始……
好像忘了那段文章里到底是个什么观点了。反正既然百花齐放。我就坚持自己的观点吧，反正是个学生，没到大的项目开发，自己偶尔写个WinMain弄几个Switch/Case也不是不可以。偶尔赶赶潮流用用MFC快速开发（相对SDK）也无所谓。原始了点，但是安全。要是专心MFC万一哪天变天了那还不哭死？
结果在写一个自己用的小程序时卡壳了。诸位都牛烘烘的，我这一点家底也不算什么。就是一个图形处理程序。自己用呗，也懒得重现什么jpeg编解码器，想当然系统有，也就必然有那么个API可以用。翻了半天MSDN傻眼了，开始在CSDN疯狂搜索。最后发现了IPicture，算是和COM的第一次亲密接触吧，不过也是不欢而散，后来用上了GDI+，功能弱点，也没办法，谁叫是在别人的屋檐下呢？（后来知道，GDI+对图片的解码也是用的COM，呜呼哀哉……）
程序是越写越大，渐渐开始觉得SDK力不从心了。MFC是铁了心的不想去了，剩下的选择似乎就是WTL/ATL了。也不知道前景如何。编程群里的老前辈悉心教导：你才大一呢，多学学.Net，将来衣食无忧。是，小弟的确资格不够，不过软件工人还是不想做的。feimingbiao那个“架构师”把小弟给羡慕坏了。不过自己还有点自知之明，知道那不是自己这种愚人的去处。COM过时，COM风光不在。有什么办法呢？好像自己就只好往这条路钻了。刚刚学编程（那时可能才初二吧）看了一篇文章，说凡事信任自己的东西，自己的效率最高。于是被惯坏了，人家MFC开始学Win32，我嗤之以鼻，自己钻WndClass，钻Message Loop，浑然忘了哪朝哪代，人家DOS下的老古董现在还可以奉为圣旨吗？！都什么时候了，哪个项目不是几万行代码，自己一个人搞得定吗？于是几年下来没学会什么，倒是谦虚了很多：自己的？自己又不是上帝，别人的还不是要用？渐渐的开始关注了下新技术。别的不敢说，.Net出来时倒真的是赶了下潮流。不过往年艰苦环境下养成的缺点是改不过来了。看看Java“虚拟机，真慢啊”，MFC“一个实例滚雪球实例化这么多类，又大又慢”，.Net“中间代码？即时编译？免了……”到头来什么都没学深，那些编程哲学什么的是浑然未觉，还是自己复制/粘贴一个又一个WinMain，等着Prefect的东西，出来，殊不知，世界上好像还没有什么是Perfect的。领悟过来准备学了，也快大二了，说实在这么多年自学电脑是白学了，走了无数条弯路最后只好转回来，想想也只好苦笑。
小弟年纪小，还不清楚商场上的那些争端。写些东西也是成不了器。学习啊，努力啊，群里的人天天在嘱咐，不过也不知道可以努力到什么地方去。唯一知道的是Java要学，.Net要学，MFC要学，COM要学，用不用是自己的事，到时候毕业了没人要就真的要挂了……反正现在中国就这个行情。想不赶时髦？钱包同意吗？老婆同意吗？车不敢想，房子总要吧？？
今天下了决心。还是潜心钻研COM吧，虽说难，虽说有这样那样的缺点（我一本.Net的书将COM批得一无是处），但是还是比较符合自己的理念。各位大大，有没有一些介绍COM的书看呢？原理方面都懂，但是真正用起来都不会。常常感叹，过去DOS下的幸福日子哪去了……
仔细想想，其实还是有点收获。接触了这么多Framework，那么多Library，大师们的思想在那里。自己稍稍领略一点就受用不尽。想想看自己也就真的没有抱怨的资格了……
不过话说回来，技术在进步，我们都站在巨人的肩膀上。不要老是唠叨身下的巨人怎么怎么不好，你可是被别人托着呢，还是少点怨言吧……
COM就是一个标准。而且这个标准已经被大家所接受，事实上工作的也很好。
在没有另一个标准能取代它之前，COM不会淡出。呵呵。其实我觉的COM永远不会淡出(再来一个标准也还只能是换个名字而已，那为什么要再来一个标准？)。所以COM只是越来越“由台前到幕后”。
很多年了，感觉并没有推广使用，原因是什么呢/////////////////////////稍微大点的基于WINDOWS的项目，就会有COM的身影
应用的范围并不校
很多年了，感觉并没有推广使用，原因是什么呢/////////////////////////稍微大点的基于WINDOWS的项目，就会有COM的身影
应用的范围并不窄
dd做了版主了，hoho恭喜！
COM这东西我觉接着刚开始学的时候觉得挺神，等真正了解它了也就是个dll，只不过写了个注册表而已，微软把它发挥到了极致，但是有几个公司真正把它用的和ms一样的我还没有见过，新东西太多，我们也只能跟着ms跑了，一个字“累”。
建议大家去真正理解，只是个技术，看我们怎么去用它了，你可以不写注册表COM同样的用，我也是从那时候走过来的，得有个过程，理解了它对你好处大大的！如果你理解了COM，那么大家试着手工写个com组件来，不用atl和mfc。好久没有来回帖了！
初写COM感觉有很多东西搞不明白很难理解，写了东西，完了也只知道了一个大概，想往里头走，卡了，郁闷啊！
刚开始看
com就一编程规范。编程的时候按此规范写了就成了com组件。
COM对许多人来说也许都是比较困难的.
C++的基础上看COM基本上能看得懂,但要讲应用到实际中的确很难.
这种规范有些烦琐,而且到目前为止几乎没发现太大的好处.
接口与实现的分离，是COM的主要目标之一，模块之间关心的是接口，而非实现，所以COM的开发关注点原本应该是接口的设计。有很多方式实现了COM架构，所以学习COM的两个层次，一个是COM架构的设计和实现，另一个就是接口的设计和实现。现在的主流观念比较能够接受接口，而不愿接受组件对象模型这个说法，因为组件这个概念带有太多的windows烙印，COM的一个目标是异构甚至不同硬件架构系统之间的通信，所以COM被弱化，而接口则随着更多新名词概念而被重新包装。
并不是说COM一无是处，学习一下里面的精髓还是很有用的。虽然现在技术领域的新东西太多，但是老的技术的精华往往就是新技术的基础。不管是否能够以此作为生活的饭碗，都应该了解技术的轨迹，这样也有助于自己在技术领域的触类旁通。再者，COM既然能够广泛应用，并且形成了相应的技术产业链，其价值已经得到肯定。新技术的目的不是为了推翻旧技术，而是衍伸和发展。利用早期技术和成熟的技术所创造的价值接触和产业基础，才能走得稳。这本身也是一种继承，再继承所以说COM与学习新技术没有任何冲突，也不会让你误入歧途。前人的经验就是路标。现在所要做到的仅仅是抽出一点时间来了解一下，已经成熟成型的技术的养分。仅此而已
我没用过COM里的异常接口   有哪位说说COM的异常处理细节呗
我没用过COM里的异常接口   有哪位说说COM的异常处理细节呗关键是一个ISupportErrorInfo，至于如何使用，请参照以下URL
http://www.vckbase.com/document/viewdoc/?id=1520
com在windows平台的确应用广泛。但仅仅是和Windows打交道的地方才能显示其重要性。
其他地方，原来说com比dll有优点，比如解决了dll黑洞的问题。但是实际中，我自己用的多的还是dll、lib。原因是开发简单。而且这种开发方式也很通用（比如在Unix上也是如此）。
当然com还有优点是，跨语言的特点。VB、VC、Delphi都可以用来开发。虽然《com本质论》里说“com是更好的C++”。
现在来说com用的最多的地方可能就是ActiveX。而类似于DCOM来做客户端、服务器的应用的话，Corba应该是个不错的替代选择。
（我自己学习了一段时间com，现在用corba比较多。水平有限，大家见谅：）
跋:
    在结束的时候，虽然我觉得讨论的东西不够热烈，但是已经涵盖了我所定义的主题，所以可以暂将这个讨论结束，感谢各位的参与，特别感谢feimingbiao() 分享他的小前半生，文字活泼，内容充实，颇值玩味。
    这仅仅是个开始,我们会有更多的讨论，精彩的永远是下一个。