(在这里仅讨论进程内的COM,而非DCOM或COM+,他们肯定比DLL有分布式，安全性，事务性等一些优点，因为他们有系统所提供的企业基础设施做保障)
查了许多贴子，基本都是Copy概念，可能回贴人自己都不清楚！
看过几本有关于COM的书,如深入COM什么的，看完一遍之后一点感觉都没有！
我就想不明白了，Windows用DLL好好的，为什么都向COM方向转？
我想到的
1.是DLL封装对象的能力差？所以用COM技术来代替？
这个可以变通嘛，为防止DLL中的对象结构发生变化，而必须重新编译一遍主程序，可以仿COM的设计方式，生成一个接口让客户端使用啊！
2.是DLL封装的对象不具的通用性？所以用COM技术来代替？
.................................................
3.难道MS是为了避免传说中的DLL Hell?
................................................
对不起，僵哥，好多概念不清楚，说对说错您就将就着理解吧:)
为什么Office\MSSQL都用COM来实现其功能，用DLL不行吗？
难道只能用COM才能把自己的软件组件化，DLL不可以？
区别在于：
1. COM接口，相对更加规范，有各种约定，从而可以实现更大范围内的兼容性，而API DLL则相对灵活，比如说参数，你可以是任意的类型。
2. 对于接口函数的起始地址查找来说，COM可以依赖本身的接口来查找，甚至可以说，你可以为同一个ID根据不同的使用者而发放不同的函数体，而API则只能依赖于导出表(export address table)。
3. 对于加载来说，COM DLL有一个位置查找源：注册表，从而可以事先不用关心DLL的位置，API则只能在搜索路径表或者指定的（已知的）路径当中加载。
4. 也是最为重要的区别（虽然楼主有一个提前是不讨论，但是还是得提到），进程内的COM DLL，可以很容易升迁为进程外的COM，比如COM+，在这一点当中API DLL是做不到的。暂时只能想到那么多。下面针对三个问题回复：
1. 两者的封装能力是一样的，COM更规范，API更自由;
2. 主要是没有一个特别的规范，由于API当中对参数没有特别的约定，特别是不具备标识性，在没有事先做出声明或者约定的前提下，第三方很难能够对其做出有效利用。
3. 对于DLL Hell，COM并不能解决问题。
1. COM接口，相对更加规范，有各种约定，从而可以实现更大范围内的兼容性，而API DLL则相对灵活，比如说参数，你可以是任意的类型。
对您回复的理解：
在COM或WebService中，对其参数以及数据类型做了进一步的规范，也就是说，在COM或WebService这个环境下，有一套标准的COM或WebService数据类型，任何语言想访问COM或WebService的接口函数必须遵循其数据类型。
这样有1点好处：
可以避免在DLL时代经常发生的用不同语言写的DLL的参数类型，可能与主调语言存在一些差别(这句话的假设前提为:主调程序与DLL开发程序为不同的开发语言)，最终导致发生一些错误！
另：是不是正是因为COM数据类型与主调语言中的数据类型不一致，在设计COM过程中会有一个功能来起到中介作用，把主调程序的数据类型与COM或WS的类型做一个映射，来方便主调调用？？
2.对于接口函数的起始地址查找来说，COM可以依赖本身的接口来查找，甚至可以说，你可以为同一个ID根据不同的使用者而发放不同的函数体，而API则只能依赖于导出表(export address table)。
对您回复的理解：
个人认为这不是COM所特有的：在DLL中先设计2接口，再用类实现2个接口类，在主调语言中同样能实现与COM一样的效果！ (也能这个疑问有点傻，明知没什么意义，我还钻牛角尖，没什么意义，敬请僵哥原谅)
3.对于加载来说，COM DLL有一个位置查找源：注册表，从而可以事先不用关心DLL的位置，API则只能在搜索路径表或者指定的（已知的）路径当中加载。
对您回复的理解：
这个与问题2相似，无非就是动态加载DLL路径，而路径写在注册表中，每次通过一个GUID来查询
4.没有疑问
再次感谢僵哥！