新手对COM的认识及疑惑
2003.7.1
我对与COM编程、开发、应用的相关问题进行了一段学习、琢磨后，初步形成了以下一些认识及疑惑，敬请大家给指点指点。
一、使用一个COM组件
1. 想办法知道 COM 组件的 CLSID （一个编号，16字节长，全球唯一）；如果不知道 CLSID，则要知道名字（ProgID），如 Excel.Application。
2. 开始与 OLE32.DLL 打交道吧 ! 如果进程尚未装载它，那就 LoadLibrary，然后再 GetProcAddress ...
3. 不管三七二十一，先运行调用 CoInitializeEx，OLE32.DLL 内的一个函数，以便 OLE32.DLL 内部为线程记录相应的数据，并允许你调用 OLE32.DLL 内的其他函数。
4. 如果已知道 CLSID，则此步跳过。否则调用 CLSIDFromProgID 根据名字计算出 CLSID。
这个 OLE32.DLL 内的函数实际上是在注册表中进行查找，位置在：
\HKEY_CLASSES_ROOT\名字（ProgID），其下有一个 \CLSID，里面就是CLSID，其实自己去注册表查找也可以。
Excel.Application 对应的 CLSID = {00024500-0000-0000-C000-000000000046}。
5. 调用 OLE32.DLL 内的 CoGetClassObject 建立一个 CLSID 的 Object。也可以调用 CoCreateInstance / CoCreateInstanceEx。
这个 Object 可以想象成操作系统在内存中加载了一个动态链接库，或独立启动了一个进程，它不返回 Object 的句柄，所以不要想通过一个句柄进行进一步访问——像 GetWindow（HWND， ...），也趁早放弃通过 GetProcAddress 取得函数入口位置进行进一步访问的想法。到底怎么访问呢，往下看...
6. 调用 CoGetClassObject 建立一个 CLSID 的 Object 的同时，根据一个接口编号参数 IID_I... （全世界统一固定编号）返回一个接口指针，一个接口可以想象成一个函数的集合。
根据 CLSID 产生的 Object 可能有若干个不同的函数集合，每一个函数集合都有一个接口编号与其对应，IUnknown 这个编号对应的接口是每个 Object 都有的。每个函数集的前三个函数都一样：QueryInterface、AddRef、Release。把其他接口编号作为参数调用 QueryInterface 就可以找到其对应的函数集。
7. 关于 CLSID 和 接口 IID
CLSID 是一个 16 字节长的全球唯一编号，OLE32.DLL 根据它在注册表中寻找对应的Dll文件（也可以是Exe文件）。参考程序与进程的概念，CLSID 的实例化是加载一个 DLL，或运行一个 Exe 进程。Dll 或 Exe 被 OLE32.Dll 加载后，在 OLE32.DLL 的地址空间为其建立若干函数入口地址表（当然根据 Dll 或 Exe 的自身定义），并为每一个函数入口表建立一个保存其开始地址的指针（这个指针是地址中的一个长字）。
IID -- 接口，也是一个 16 字节长的全球唯一编号，OLE32.DLL 根据它在 CLSID 的实例的所有 函数入口地址表的 指针 中找到一个对应的，返回来。所以接口的实例就是那个返回来的指针。
C 程序员可以把接口认为是一个结构，其成员是若干函数；C++ 程序员可以把接口认为是一个类 Class。
至于通过 IID 找到的 函数入口表 中的各函数如何调用，去看那个 Dll 或 Exe 的开发接口文档吧。在调用一个具体的函数时，当然可以把参数压入堆栈，然后 Call 那个函数，不过这好像是汇编中的低级做法，比较麻烦，在 VC 中定义一个类指针来保存接口返回来的指针，然后访问类成员，用起来比较方便——参数压入堆栈的问题编译器替你解决了。
8. COM
所以 COM，概括起来说，就是用两级编号，通过 OLE32.DLL 调用某个 Dll 或 Exe 提供的函数的方式。
当然在这基础上还有 Automation 等，定义了更多标准的接口编号及访问方式，完成更复杂的功能。
9. 为什么要用 COM
以前，大家访问 Dll 中的函数主要是由 Kernel32.Dll 加载，然后通过直接访问函数入口实现的。为什么现在要把这个过程套上一层 OLE32.DLL 呢？
9.1. 填补Dll黑洞。
多年以来，Dll写好以后是需要升级的，即使不升级有时也要修改 Bug，于是微软（当然还有其它公司）不停的推出改进、升级版的Dll，各版本的Dll的名字是一样的，虽然竭尽全力保证兼容以前的版本，但接口函数的差别（包括Bug的差别）还是导致自己的程序及客户的应用程序莫名其妙的崩溃（我还记得为了自己写的程序能够正常运行而珍藏SQL Server 6.x 的ODBC驱动程序的某个版本），怎么办？ 给每个Dll文件名加个序列号吗（当然Dll内部有版本号），然后操作系统的系统目录下有 同原名+不同序列号的多个Dll？ 那太难看了吧！最后的解决办法是把这不同序列号的Dll文件打包成一个Dll，在其内部分开，然后用不同的序列号访问，这些序列号的实施结果就是现在的 CLSID + IID。但是这样一来这个Dll由 Kernel32.Dll 加载是不行了，于是做个新的 OLE32.DLL 来支持这种模式，由 OLE32.DLL 来保存一个加载后的 Dll 中的多个子 Dll 的函数入口，供应用程序调用。当然在这种模式也是考虑了兼容远程调用的问题。但是对于远程调用需要调用者告诉 OLE32.DLL 那个远程 DLL 在什么地方而不能自动寻找，这看来是以后微软改进的有一个方向。这种模式起名叫 COM。但是我还有疑问，那 OLE32.DLL 自己如果版本更新了或改正了 Bug 怎么办，自己内部也是一堆子OLE32.DLL？每一个也通过 CLSID + IID 访问？
我的想法是不是有点过分？
9.2. Dll卖钱
多年以来，微软在 Windows 成功之后，也就是写好内核及系统API之后，组织了更多的程序员开发之上的应用软件，每个应用软件的开发过程中都产生了大量中间产品（如Dll）——微软肯定也是大量复用中间产品的。在应用软件继续成功之后，是不是微软看着这些辛辛苦苦做出来的中间产品又两眼放光？搞一套模式开始卖中间产品？
10. COM+ 及 .Net
是不是 COM+ 就是在 COM 上强化了组件（就是 CLSID 的实例）间的通讯功能，以便保证互相远程调用的质量？
.Net 是不是重写了 OLE32.DLL（或又套上了一个新的DLL），加上了一个什么 FrameWork？
是不是以后我们写的程序的文件名不重要了，重要的是程序中有若干个 16 字节长的编号我们一定要记住，然后对着一个 IP 地址（以后也变成16字节了）发一串编号过去，对方的系统中就启动我们写的程序、或我们的程序的某个函数被调用，不管对方是一台计算机、一个手持设备，或人体中的某个植入芯片？
我的脑子里不停地出现《黑客帝国》中的镜头...
二、COM 对程序员的影响
1. 对 Windows 内核及 API 的影响
Windows 的内核不会用 COM 的方式重写一遍吧？
在内核之上表现出来的基本 API 也不会改变吧？ 所以以前的应用程序以后可以继续运行。
但是，有消息说 Windows 的文件系统的基础要以 SQL Server 为基础，那显然是 COM，那么实际上是在原 File I/O API 的基础上套一层 SQL Server 的 COM 呢？ 还是倒过来，以SQL Server 的 COM 为基础，在此之上为以前的应用程序做一个保持兼容的 API 动态连结库？
我觉得这个担心不是多余的，看看 DirectX 吧，看看 ODBC 到 ADO 吧，看看 GDI 到 GDI+ 吧。
那以后是不是窗口机制及消息机制也要改造成 COM 模式？
是不是从 UNIX 抄来的 TCP/IP API 也要彻底换成 Winsock COM 了？
最终的结果是不是从内核开始，Windows 就是一堆 COM，启动首先启动一个 基本 COM （内核COM），然后这个 COM 创建更多 COM ？
2. 对 VC - SDK 程序员的影响
是不是以后不用写 CreateWindow 及 WndProc 了，也不用处理 WM_...了，把 C 的编程技术及资料锁到珍藏箱子里去吧？ 然后把当年经历过的从 DOS API 到 Windows API 转变的痛苦再经历一遍，拼命苦学一把 C++ 的理论，重新熟记 n 多的 COM 里的 n 多 的 Object 的 n 多的 Interface 的 n 多的 Method，然后动手开始写 CreateObject ？
是不是 COM 的 ProgID 的实例是变化的，而 Interface 一旦定义好是不变的，所以一个 COM 的 Interface 数量会不停的增长下去？ 打开 MSDN 随便看一个 Interface 下的函数个数吧，我开始发晕。
3. 对 VC - MFC 程序员的影响
是不是 MFC 本来是为封装 Common Controls 还有其他 API 而定义的一种编程接口（本身不是API）？ 是不是 MFC 也有天生的缺陷，支持 COM 的后劲不足或历史包袱太多（如 Document/Frame/View），将来也要面临被淘汰的命运？
是不是大家已经对 C++ 有深入认识，换一个开发环境也不太困难？
4. 对 VC - ATL 程序员的影响
是不是扬眉吐气的时候到了？ 革命的大好形势就在眼前？
那 C# 又是什么东西？
5. 对 VB 程序员的影响
显而易见，看看 VB6 到 VB.Net 的变化就知道了。
学习了 QBasic 之后，又学习了事件处理之后，是不是我们又得学新东西了？
是不是这次的变化像从 Foxbase 到 VB 3.0 一样痛苦，但过来之后发现我们可以使用更多别人已经写好的东西？
6. 对 ASP 程序员的影响
是不是我们的 ASP 代码本身也能编译成 COM 了？ 跟 Java/Jsp 叫板？ 反正编译后谁也看不到我们 ASP 代码的优劣。
是不是我们必须开始使用 XML COM，以便我们的 ASP COM 能与其他人的 ASP COM 互相沟通？
三、COM 对软件公司的影响
1. 对项目开发过程的影响
是不是我们的开发过程会从以函数、模块为单位进行分工、管理变成以 COM 为单位进行分工、管理？
是不是我们的项目开发的各 COM 写文档时格式一样，而 Coding 时会以不同的语言进行编写，以留住公司的各语言的优秀人才。
是不是按这种方式开始运行了一段时间后，我们实际上面对着一堆有各种各样问题的 COM，完成时间一推再推、Bug及兼容性问题没完没了，再加上客户不时的功能修改，我们会痛不欲生？ 是否会发生项目组被干掉或项目经理被干掉的悲剧？
是不是高层管理根本不管技术的进步及开发过程的变化而一味的要求工期？ 也不因为我们利用了新的技术而加薪？
会不会因为我们向高层吹牛我们使用 COM 开发模式后会利用别人的 COM 组件而加快开发进度、降低开发成本，高层听后立即决定减少项目组的人数？
是不是我们还得等一个与 COM 开发模式配套的新的项目管理理论、体系成熟后，再开始吃螃蟹？
2. 对产品开发的影响
是不是以后我们维护产品的文档及代码会变成维护若干相互独立的 COM 的文档及代码？
是不是我们以后的产品升级会变成自动从网站上下载并更新某个 COM ？
是不是使用 COM 后我们的产品的可靠性、稳定性大幅度提高？
是不是过了一段时间发现微软的某个 COM 比我们公司自己写的 COM 要好，然后换掉？
会不会产品的发展过程就是我们不停地换用微软的 COM ，然后写微软尚未写出来的 COM，如此交替循环，直到微软追上我们，或我们因精疲力竭而倒下？
或者到最后，一个产品中的 33 COM 中只有 2 个是我们自己写的，其他的都是微软写的，然后我们挣产品售价的 20%，其余 80% 按产权费上缴微软？
3. 对销售的影响
是不是销售人员很难说服客户为我们升级到 COM 技术而多付费？
是不是很长一段时间内销售人员及客户都不会了解 COM 是什么东西？
是不是我们的技术及产品升级到 COM 后客户压根就没看到变化，根本不愿意多付钱？ 反而听说了 COM 组件复用而要求降低合同额？
是不是客户可以为应用系统的千年虫问题而增加IT预算，但根本不会为系统 COM 升级准备预算？
是不是销售人员一听我们给他们讲 COM 升级就困得一塌糊涂？
有没有听说哪个公司把 COM 技术包装成一个新概念到处吹牛？
4. 对市场及行业的影响
是不是行业采用 COM 升级后行业的总销售额能增加 10 百分点？
是不是采用 COM 技术后一些国外的大软件公司能把 COM 的开发任务外包出来，交给低成本的地区制作？
是不是采用 COM 技术后软件开发行业变得与传统行业一样了，都是按照设计图纸（COM设计文档）加工制造出零部件（COM这个词准确极了），然后由大的总装公司（如微软，就像通用汽车、丰田）总装发售？
参照传统行业的说法，是不是软件行业的以非标（准）设计为主的时代快结束了，而要开始以标准件制造为主的年代？ 就像工业革命以来的各种技术及产品的发展过程一样，如军工、造船、汽车、家用电器，特别是，由 IBM 开创的 PC 兼容机硬件系统。
四、写我自己的 COM 组件——我到底要干什么
在一头扎进 COM 的深渊之前，在被 C++ 语法及 COM 的相互实现套牢半年之前，我觉得有必要先搞清楚我到底要干什么。
1. 我是要重写一个我自己以前写好的Dll（非 COM）吗？
为了赶时髦也藏在 OLE32.DLL 后面，然后定义好几个16字节的接头暗号？ 而且把不合乎 COM 函数调用规范的函数头（参数）统统改造一遍？ 把函数内字符串处理、内存申请的部分全部检查一遍并适当重写？
在以前的Dll内的函数的基础上再增加：
QueryInterface
AddRef
Release
CreateInstance
LockServer
DllRegisterServer
DllUnregisterServer
等等...
告诉自己别着急，继续：
把原来的 Dll 配套的测试程序也重写一遍？
把原来的 Dll 配套的说明文档也重写一遍？ 要在说清楚 COM 方式的基础上尽量保证原来的语言。
在原来的 Dll 配套的说明文档上增加一个巨细无比的 What's new？
通宵达旦的质检、修改、质检、修改......之后，兴高采烈的告诉原 Dll 的调用者们：我的新 COM 接口准备好了，你们可以开始改写你们的应用系统了？
如果这是我自己启动的革命行动，他们会不会突然表现出不受理智控制的行为？
如果我是一个 COM 的 Interface，会不会有人调用我的 Release 函数？
2. 我是要把现在的一个产品或项目（传统exe应用程序）改造成 COM 模式吗？
100% 的改造是不行的，至少我们还得有一个传统 Exe，以便它向 OLE32.DLL 发出第一个 CoGetClassObject 调用，好让我们的程序被加载并开始运行，就像 IEXPLORE.EXE 与 shdocvw.dll （这个举例不太准确，凑合看吧）。
那改造完的结果呢？ 是不是我们的开发效率提高了？ 是不是我们的产品/系统维护工作减少了？ 这个改造过程与一个 Dll 的改造过程相比是个什么比例呢？
如果组件单独销售，市场部能做出我们的“工资录入 COM 组件”的销售计划吗？
算了，这个问题让公司的高层去开会讨论吧。
3. 我是不是要把以后的新产品/新项目设计分成两大部份，一部分是传统 Exe 部分，另一部分是 COM 组件（是指我自己写的 COM 组件，不是指微软的 COM）？
是不是这样一来 COM 组件就可以多项目/多产品复用？ 是不是在此基础上可以一定程度的解决客户定制的麻烦？ 是不是可以把某些 COM 组件外包出去？
是不是这样一来整体系统中每个 COM 的设计都是非常非常重要的？ 是不是因为它一旦设计好就会对今后若干产品/项目产生重大、深远的影响？ 是不是一旦我们以后发现某个 COM 存在设计失误，则它就作废了——它的那些 16 字节的接口编号不能再用了？ 是不是针对这种情况我要在 COM 的设计方面进行大量的投入，并且要在实现中逐步试验、积累，把 COM 看成是与产品一样重要的东西予以管理。
是不是这种模式将是未来若干年的主流开发模式，是真正的大规模工业化模式？
是不是公司的开发流程、管理制度需要与之配套改造？ 是不是只有深入明白这些道理的人当上开发部经理，甚至总经理后，公司才能朝着这个方向发展？ 否则就很容易东施效颦、邯郸学步？ 是不是我得在学习中耐心等待——不会发生条件尚未成熟而我盲目推进 COM 最后失败被干掉？
是不是我的那些几千行的小应用程序套用这种模式后，大多数代码都是框架代码，有用的代码没几行，大多数的文档都是套话，就像 CMM 认证以后？ 会不会吃了若干苦头后发现用宰牛的刀杀鸡太累？
4. 我是不是要在不断学习 COM 技术的同时，开始积极的与国外的大软件公司联系，学习人家的 COM 设计规范、文档写作规范、Coding 规范——了解国际惯例，然后努力去接他们的 COM 外包活来做？
我是不是别再当软件的农业自然经济里的软件农民艺术家了？ 我是不是别再笑话自己遇见的美国程序员、印度程序员都狗屁不会了？ 我是不是应该也参与到世界的软件工业化流程中去，把青布长衫换成蓝领工作服，从拧螺丝、扫地板开始，吃日本人、台湾人、韩国人、印度人吃过的苦，走他们走过的路，不断发展壮大，若干年后我们来制定后 COM 时代的标准，不用象这么多年来，人家不停的发布标准，我们不停的接圣旨？
是不是我们从国内的客户身上糊弄出来这么多钱之后，应该知足了，应该去跟外国人真刀真枪的竞争？
会不会今天晚上下班时领导告诉我加班赶工期，这不小心蹦出来的一丁点儿雄心壮志立刻不见了？
五、写我自己的 COM 组件——谁来定义那些16字节的编号
好了，向 COM 再迈近一步吧。是不是那些16字节的编号的定义是首先应该做的？
实现起来很简单，调用 OLE32.DLL 中的 CoCreateGuid 返回一个就是了，连续调用可以返回一大堆。但是想一想这个东东以后影响巨大，是不是应该慎重对待? 当然 ProgID 也是很重要的，但是不是不如 CLSID 及 IID 影响大？
为了后面说起来方便，我把相关的人员分成 COM 的编写人及 COM 的使用人。
1. COM 编写人定义那些16字节的编号
这应该是牛人做的事情。“我已经定义好了若干16字节的编号，你们用就是了！”，这些编号应该是程序员圈子里的商标、身份证号码。这些编号意味着其内部有武林密藉，一般程序员是根本写不出来的，其表现出来的函数都是独门功夫。这些编号会作为程序开发高手（不一定是一个人，也可能是一个公司）的实力的体现将长期被 COM 使用人所敬仰——老老实实的用人家的吧；并将伴随着 COM 使用者做出来的应用系统长期活在世界的很多角落——名作家看着作品流传后世是一种乐趣，年事已高的程序高手退隐江湖后，找个工具搜索互联网上的主机的注册表内的 CLSID 及 IID，数数自己定义的编号的个数是不是也是一种乐趣？即使自己的密籍的源代码早在某一次事故中消失了，或者即使尚存自己也看不懂了。
是不是程序高手不再必须用源代码来表现自己精深的内力了？是不是以前贴出来的超过 1000 行的源代码就会把大多数菜鸟震晕，以至于连其中的一招都没学会？是不是只要贴个 COM 出来，附上若干编号及少量说明可以更好的解决菜鸟的问题——尤其是对那些急着出活的菜鸟？
是不是程序高手们（包括其所在的公司）可以开始钻研独门武功了，其它方面需要时可以使用其他高手的 COM，不用像以前那样各门功夫都练，结果哪个都不精？反正高手合作时只是二进制 COM 的调用，不是源代码，不用担心秘籍外泄。
是不是以后高手们在推广自己的 COM 时会毫无保留？
是不是以后对 Windows API 其熟无比的人成不了高手了，反而是那些对算法、专项技术有深入研究的人才会成为高手？
找个高手看看，梁肇新先生的超级解霸（本文中如果有对梁先生及超级解霸论述的不实、不敬之处，绝非本意，请多多见谅）是不是也可以做成 COM 销售？让大家的程序中也能嵌入一个播放电影的 Window，当然在目前的情况下可能几乎没人给梁先生付版权费，但长远呢？显然梁先生不用担心有人在超级解霸 COM 外面套一个 Exe 就做成了什么“超级电影播放器”然后公开叫板——如果他付了版权费则正合本意，否则让他卖，卖出钱来就起诉他，也可以挣钱。这又不是源代码级的复用，是二进制复用，他还敢抵赖？
过一段时间后，会不会在中关村的街头某人提着一个破包小声问过路人：“要不要光盘，最新的超级解霸 COM 组件”？
如果梁先生不出超级解霸 COM，是不是我们只能用微软的 Media Player 了？
2. COM 调用人定义那些16字节的编号
这大概会是我这样的程序员要面对的大多数情况。我们去接某个公司的 COM 设计任务（或参加投标），听甲方宣布：“COM 的编号及其成员函数头我们已经定义好了，你们照此设计！”，这些公司显然知道16字节编号的重要性，并且逐步积累起来一整套管理机制（会不会已经把那些16字节编号申请了专利或商标），我们只能是那些函数的实现者。是不是感觉人家发布设计图纸，而我们只是施工队？
是不是最近几年来我们施工队做出来的函数 Bug 太多，结果越来越多的国际工程包给印度人做了？最终到现在我们还是蹲在桥头，印度人已经做大了？而且，是不是真的——印度人开始往外转包工程了？
是不是学校的学生可以在校期间自己努力，实现某个公司的某个16字节编号下的成员函数，把这一小部分做精，毕业后到那个公司应聘时说：“这是我为贵公司实现的某个16字节编号，这里是源代码。这个 COM 、源代码及其文档 已经通过了贵公司的标准检验。我很愿意加盟贵公司，我的薪水可以比现任程序员的薪水低 20%”？
我们去做国际市场是否也可以如此？
六、对 .Net Framework 的进一步认识
1. 是不是 .Net Framework 抛弃了 OLE32.DLL 了——保留它是为了继续对以前的应用程序做支持，新写了 mscoree.dll、mscorlib.dll ... 一堆 Dll？
2. 是不是用 Framework 以前，我们对 COM 还只是想用才用（打个不太准确的比方，我们想写一个工资录入程序，想用 COM 就用 VB6——其内部是 COM，不想用 COM 我们就用 VC6-SDK/MFC 直接去调用 User32.Dll 的 CreateWindow），而用 Framework 之后，我们就别无选择？是不是我们将永远告别 LoadLibrary 与 GetProcAddress ——尽管 Windows 自己还在使用他们？也永远别想“连接程序”及 CreateProcess 能把 Windows 的基本 API 的函数入口放到我们的进程地址中？我们面对的只有 COM？只有那些 16 字节编号对应的函数表，只有通过它们才能延续以前熟悉的调用方式，然而找到函数时已发现面目全非？
3. 是不是在远离了操作系统内核后（DOS年代），又要再次远离操作系统基本 API？是不是我们每一次通过函数表与 Windows 内部进行通讯时都会遇到安全审查？是不是黑客高手们得在成功进入 Windows 内核之前先闯过这些函数表的安全审查？
4. 是不是我们在让我们的 VB 程序员明白继承、重载、聚合的同时，要让我们的 C 程序员放弃与操作系统内部函数一致的编程调用方式？是不是在这些统一的函数表的基础上，我们用哪种语言开发应用程序就像是用普通话表达还是用广东话表达其实写在纸上没什么区别了？
5. 是不是 Sun 的 J2xE 的内部也是一堆函数表？是不是从此 Java 程序员改写 .Net 应用基本没什么障碍了？是不是过一段时间微软会推出一堆函数表，能直接建立与 J2xE 内部的函数表的对应关系，Java 写的应用就直接能在 .Net 上运行了？是不是 .Net 与 J2xE 就算在服务器端差不多，但在客户端（绝大多数用户的 Windows ）的表现要比 J2xE 要好得多，J2xE 如果不通过 Windows 的 IE 的 HTML/DHTML 是不是压根在客户端就没表现力？是不是微软挨了 J2xE 多年的打后要开始反攻？
6. 是不是我千万不能告诉老百姓其实他们的 Windows 只要装上总共不超过 30 M 的 Framework 安装文件（在安装 IE6 之后）就可以运行 .Net 上的应用程序了？是不是我准备对竞争对手新开发的 .Net 应用程序视而不见，告诉客户那个不稳定，然后继续写我的 Studio 6 的程序？
7. 是不是我不得不疲于应付领导没完没了的改设计、赶工期的要求的同时，对微软没完没了的大规模技术升级气愤至极？会不会终于有一天忍无可忍找个大铁榔头把计算机连同 Windows 一块砸个稀巴烂，然后迈步去开饭馆或去饭馆打工，结果走到门口想起来还没给 QQ 上的朋友们说一下，而且晚上还约好了几个好哥们在 MSN Messeger 上讨论游戏中那把宝刀到底藏在什么地方......
8. 是不是毕业多年、拖家带口的程序员感觉适应某一个开发环境还可以，但跟随这种大的环境变化感觉越来越力不从心了？是不是短期内还可以努力拼一个管理岗位躲避一下，但考虑长期问题的时候看着传统国营单位的职工下岗自己心里也很茫然......
9. 更正：我的第 8 个认识是杞人忧天，时间会证明的。
七、为什么 Framework 不叫 COM++ ？
1. 是不是 Framework 的 COM 与 OLE32.DLL 的 COM 是不一样的？是不是虽然 Framework 可以继续兼容以前的 COM，但 Framework 之上根本就没有 COM 了？是不是从 Framework 开始组件已经不是指 COM （至少不是专指）了？是不是 Framework 只保留了16字节编号的接口（ Interface ）的访问方式，但是 Interface 已经不再是 CLSID 内部的东西了，而是属于 NameSpace？
2. 是不是 Framework 对接口（Framework上的接口）的访问与 OLE32.DLL 对接口（COM 上的接口）的内部访问方式完全不同？是不是在注册表中的存储位置、存储方式也完全不同？尽管写成代码后看起来有些相似。
是不是我在 Framework 上写的组件只能建立在它的 Interface 之上？
是不是微软在 COM+ 之后不再发展 COM 技术了？
3. 是不是我以后想要写组件的话，必须在 COM 与 Framework 之间做出选择？是不是从 Framework 开始，我写的程序就不可能不是组件了？
是不是我做选择时需要考虑的因素如下？
a. 继续写基于 Win32 API 及 COM 的组件：不需要应用系统安装 Framework；可以继续被非 Framework 应用程序使用；未来发展前景不明朗。
b. 开始写基于 Framework 的组件：应用系统必须安装 Framework；不能被非 Framework 应用程序使用；未来发展前景良好——仅指跟随微软的方向。
4. 是不是我一生气准备去写个自己的 Runtime？
5. 在我从 SDK/MFC 编程转到 COM 后，是不是又必须要转到 Framework？为什么微软不能把 Framework 做成 COM++？
在我适应了 Framework 之后，又过多长时间就需要再转到另一个环境中去？
我禁不住开始怀疑微软的世界顶级的研究员的视野到底有多远。微软的研究员到底在研究什么？
在研究如何把 DOS 转手卖给 IBM ？
在研究如何学习 窗口/消息 原理开发 Window 3.0？
在研究如何把 VMS（DEC VAX 机的无比稳定的操作系统） 的项目负责人挖过来做 Windows NT？
在研究如何学习 Lotus 1-2-3 然后做 Excel？
在研究如何学习 Netscape 然后做 IE？
在研究如何把 Sybase 的人马挖过来做 SQL Server？
在研究如何把 Foxpro 买过来以便提高 Access 的运算速度？
......
在研究如何学习 J2xE 然后做出来 Framework？
我承认微软每一次都学得很好，而且在整体精良的商业运作下大获成功。
6. 是不是我们真正应该学习的是微软的学习技术及商业运作能力？是不是 MSDN 上写的那些东西其实值不了多少钱？我是不是一直在微软的商业运作中实现着我的崇高的程序员理想，但经常痛苦的发现他的商业运作导致我没日没夜积累起来的程序代码、经验在几年间就统统作废？
7. 做程序员的未来是什么？我又开始迷惑.…..
8. 更正：我的第 7 个认识是错误的。老婆大人刚下达了命令：“发什么呆呢？！领着儿子到公园转一圈儿去！”
本文地址：http://com.8s8s.com/it/it1657.htm