COM复习
[转载自杨老师个人专栏：
http://www.vckbase.com/vckbase/columnist/yangfeng/]
1. COM的起因---复合文档
微软在成功地推出 Windows 3.1 后，开始垂涎桌面办公自动化软件领域。微软的 OFFICE 开发部门，各小组分别独立地开发了 WORD 和 EXCEL 等软件，并采用“自定义结构”方式，对文件进行存储。在激烈的市场竞争下，为了打败竞争对手，微软自然地产生了一个念头------如果我能在 WORD 程序中嵌入 EXCEL，那么用户在购买了我 WORD 软件的情况下，不就没有必要再买 LOTUS-123 了吗？！“恶毒”（中国微软的同志们看到了这个词，不要激动，我是加了引号的呀）的计划产生后，他们开始了实施工作，这就是 COM 的前身 OLE 的起源（注3）。但立刻就遇到了一个严重的技术问题：需要把 WORD 产生的 DOC 文件和 EXCEL 产生的 XLS 文件保存在一起。
复合文件的函数和磁盘目录文件的操作非常类似。所有这些函数，被分为3种类型：WIN API 全局函数，存储 IStorage 接口函数，流 IStream 接口函数。
2. CLSID的起源
话说在 doc(Word) 复合文件中，已经解决了保存 xls(Excel) 数据的问题了。那么，接下来又要解决另一个问题：当 WORD 程序读取复合文件，遇到了 xls 数据的时候，它该如何启动 Excel 呢？启动后，又如何让 Excel 自己去读入、解析、显示 xls 数据呢？
二、CLSID 概念
有一个非常简单的解决方案，那就是在对象数据的前面，保存有处理这个数据的程序名。（见下图左上）
图一、CLSID 的概念
这的确是一个简单的方法，但同时问题也很严重。在“张三”的计算机上，Excel 的路径是："c:\office\Excel.exe"，如果把这个 doc 文件复制到“李四”的计算机上使用，而“李四”的 Excel 的路径是：
"d:\Program files\Microsoft Office\Office\Excel.exe"，完蛋了:-(
于是，微软想出了一个解决方案，那就是不使用直接的路径表示方法，而 使用一个叫 CLSID（注1）的方式间接描述这些对象数据的处理程序路径。CLSID 其实就是一个号码，或者说是一个16字节的数。观察注册表（上图），在HKCR\CLSID\{......}主键下，LocalServer32（DLL组件使用InprocServer32） 中保存着程序路径名称。
3. 关于组件调用
总的来说，调用组件程序大概有如下方法：
4. 关于注册
情况1：当我们使用 ATL 编写组件程序，注册不用我们来负责。编译成功后，IDE 会帮我们自动注册；
情况2：当我们使用 MFC 编写组件程序，由于编译器不知道你写的是否是 COM 组件，所以它不会帮我们自动注册。这个时候，我们可以执行菜单“Tools\Register Control”来注册。
情况3：当我们写一个具有 COM 功能的 EXE 程序时，注册的方法就是运行一次这个程序；
情况4：当我们需要使用第三方提供的组件程序时，可以命令行运行“regsvr32.exe 文件名”来注册。顺便说一句，反注册的方法是“regsvr32.exe /u 文件名”；
情况5：当我们需要在程序中（比如安装程序）需要执行注册，那么：
1. COM的起因---复合文档
微软在成功地推出 Windows 3.1 后，开始垂涎桌面办公自动化软件领域。微软的 OFFICE 开发部门，各小组分别独立地开发了 WORD 和 EXCEL 等软件，并采用“自定义结构”方式，对文件进行存储。在激烈的市场竞争下，为了打败竞争对手，微软自然地产生了一个念头------如果我能在 WORD 程序中嵌入 EXCEL，那么用户在购买了我 WORD 软件的情况下，不就没有必要再买 LOTUS-123 了吗？！“恶毒”（中国微软的同志们看到了这个词，不要激动，我是加了引号的呀）的计划产生后，他们开始了实施工作，这就是 COM 的前身 OLE 的起源（注3）。但立刻就遇到了一个严重的技术问题：需要把 WORD 产生的 DOC 文件和 EXCEL 产生的 XLS 文件保存在一起。
| 方案 |
优点 |
缺点 |
| 建立一个子目录，把 DOC、XLS 存储在这同一个子目录中。 | 数据隔离性好，WORD 不用了解 EXCEL 的存储结构；容易扩展。 | 结构太松散，容易造成数据的损坏或丢失。 不易携带。 |
| 修改文件存储结构，在DOC结构基础上扩展出包容 XLS 的结构。 | 结构紧密，容易携带和统一管理。 | WORD 的开发人员需要通晓 EXCEL 的存储格式；缺少扩展性，总不能新加一个类型就扩展一下结构吧？！ |
以上两个方案，都有严重的缺陷，怎么解决那？如果能有一个新方案，能够合并前两个方案的优点，消灭缺点，该多好呀......微软是作磁盘操作系统起家的，于是很自然地他们提出了一个非常完美的设计方案，那就是把磁盘文件的管理方式移植到文件中了------复合文件，俗称“文件中的文件系统”。连微软当年都没有想到，就这么一个简单的想法，居然最后就演变出了 COM 组件程序设计的方法。可以说，复合文件是 COM 的基石。下图是磁盘文件组织方式与复合文件组织方式的类比图：
图一、左侧表示一个磁盘下的文件组织方式，右侧表示一个复合文件内部的数据组织方式。
复合文件的特点
- 复合文件的内部是使用指针构造的一棵树进行管理的。编写程序的时候要注意，由于使用的是单向指针，因此当做定位操作的时候，向后定位比向前定位要快；
- 复合文件中的“流对象”，是真正保存数据的空间。它的存储单位为512字节。也就是说，即使你在流中只保存了一个字节的数据，它也要占据512字节的文件空间。啊~~~，这也太浪费了呀？不浪费！因为文件保存在磁盘上，即使一个字节也还要占用一个“簇”的空间那；
- 不同的进程，或同一个进程的不同线程可以同时访问一个复合文件的不同部分而互不干扰；
- 大家都有这样的体会，当需要往一个文件中插入一个字节的话，需要对整个文件进行操作，非常烦琐并且效率低下。而复合文件则提供了非常方便的“增量访问”能力；
- 当频繁地删除文件，复制文件后，磁盘空间会变的很零碎，需要使用磁盘整理工具进行重新整合。和磁盘管理非常相似，复合文件也会产生这个问题，在适当的时候也需要整理，但比较简单，只要调用一个函数就可以完成了。
复合文件的函数和磁盘目录文件的操作非常类似。所有这些函数，被分为3种类型：WIN API 全局函数，存储 IStorage 接口函数，流 IStream 接口函数。
2. CLSID的起源
话说在 doc(Word) 复合文件中，已经解决了保存 xls(Excel) 数据的问题了。那么，接下来又要解决另一个问题：当 WORD 程序读取复合文件，遇到了 xls 数据的时候，它该如何启动 Excel 呢？启动后，又如何让 Excel 自己去读入、解析、显示 xls 数据呢？
二、CLSID 概念
有一个非常简单的解决方案，那就是在对象数据的前面，保存有处理这个数据的程序名。（见下图左上）
图一、CLSID 的概念
这的确是一个简单的方法，但同时问题也很严重。在“张三”的计算机上，Excel 的路径是："c:\office\Excel.exe"，如果把这个 doc 文件复制到“李四”的计算机上使用，而“李四”的 Excel 的路径是：
"d:\Program files\Microsoft Office\Office\Excel.exe"，完蛋了:-(
于是，微软想出了一个解决方案，那就是不使用直接的路径表示方法，而 使用一个叫 CLSID（注1）的方式间接描述这些对象数据的处理程序路径。CLSID 其实就是一个号码，或者说是一个16字节的数。观察注册表（上图），在HKCR\CLSID\{......}主键下，LocalServer32（DLL组件使用InprocServer32） 中保存着程序路径名称。
3. 关于组件调用
总的来说，调用组件程序大概有如下方法：
| #include 方法 | IDL编译后，为方便C/C++程序员的使用，会产生xxx.h和xxx_i.c文件。我们真幸福，直接#include后就可以使用了 |
| #import 方法 | 比较通用的方法，vc 会帮我们产生包装类，让我们的调用更方便 |
4. 关于注册
情况1：当我们使用 ATL 编写组件程序，注册不用我们来负责。编译成功后，IDE 会帮我们自动注册；
情况2：当我们使用 MFC 编写组件程序，由于编译器不知道你写的是否是 COM 组件，所以它不会帮我们自动注册。这个时候，我们可以执行菜单“Tools\Register Control”来注册。
情况3：当我们写一个具有 COM 功能的 EXE 程序时，注册的方法就是运行一次这个程序；
情况4：当我们需要使用第三方提供的组件程序时，可以命令行运行“regsvr32.exe 文件名”来注册。顺便说一句，反注册的方法是“regsvr32.exe /u 文件名”；
情况5：当我们需要在程序中（比如安装程序）需要执行注册，那么：
typedef HRESULT (WINAPI * FREG)();
TCHAR szWorkPath[ MAX_PATH ];
::GetCurrentDirectory( sizeof(szWorkPath), szWorkPath ); // 保存当前进程的工作目录
::SetCurrentDirectory( 组件目录 ); // 切换到组件的目录
HMODULE hDLL = ::LoadLibrary( 组件文件名 ); // 动态装载组件
if(hDLL)
{
FREG lpfunc = (FREG)::GetProcAddress( hDLL, _T("DllRegisterServer") ); // 取得注册函数指针
// 如果是反注册，可以取得"DllUnregisterServer"函数指针
if ( lpfunc ) lpfunc(); // 执行注册。这里为了简单，没有判断返回值
::FreeLibrary(hDLL);
}
::SetCurrentDirectory(szWorkPath); // 切换回原先的进程工作目录