OLE(五)

       我们可以从中看出DDE协议跟使用套接字进行网络通信很相似，虽然不算复杂但也比较烦琐。尽管微软给出了精确的定义，不过恰是这种定义会把人搞的晕头转向的，而且里面还有汇编语言的影子，使程序员不得不小心了。有意思的是，微软自己使用那个DDE的扩展技术:OLE,也花了很大的力气来演示如何将图片嵌入到Word中去。

       那么既然如此费劲，为什么还要搞出这么一个东西来呢？这主要是用户的需求造成的。OLE没有出来之前，word文档本质就是一个文本文件。比如：在Word1.1插入一个位图文件，结果显示一堆乱码。然而在实际应用中，用户很希望在word文档里弄一张图片，比如：流程图之类的。虽然也就解决办法，比如：通过键盘的“PrtSc“键来打印屏幕，通过截取和组合最终也可以在打印机上也可以同时打印出文本和图片。刚开始或许还令人满意，但要是如果有大量的图片和文本的话，就不那么令人乐观了。因为这将变成一件机械枯燥令人乏味又无聊的工作。好在计算机不知道什么叫做无聊，只要有指令，再多的活它也会干，而且不会叫苦叫累。于是人们就竭尽全力开发这一功能，以便让一切变的简单起来。所以当软件开发出来后，微软便大势宣传这是多么令人激动的技术啊，我们将进入一个复合文档时代。

       这确实令人激动。然而这种基于DDE的OLE最终还是暴露出它的弱点。由于DDE是通过PostMessage来传输数据的，这就使得OLE在速度上不那么令人满意。因为PostMessage函数指负责投递消息，至于消息能不能被接收方处理则不管。如果接收方恰好因某种原因没有处理，那么整个通信就显得延时了。那么为何不用SendMessage？SendMessage尽管很可靠，因为它要等接收方处理完消息后才返回。但这种可靠在有两个或者两个以上的相互通信的应用程序中就不那么可靠了，如果其中一个程序崩溃，那么就很有可能给另外一个造成死锁。还有数据就存储在一个全局内存句柄里，如果传送一个位图的时候，那么Windows会使用虚拟内存管理机制来分配一块很大的内存（通过内存映射文件实现），这使的Windows只能把数据交换到硬盘上去。我们应该都知道在内存和硬盘交换数据是比较长的时间的，所以这也不太令人满意。

        于是，为了解决这些不足，微软马不停蹄的又开发出一种全新的OLE,这种OLE实际上就是OLE2.0。说它新，是因为它不再是DDE的扩展，而是基于一种叫做组件对象模型(COM)的技术。通过这种技术程序员开发软件如同堆积木一样简单。真的如此吗？答案确实如此。所以后来COM成为微软的核心技术，就连Windows也集成了COM。