一、前言 书接上回，话说在 doc(Word) 复合文件中，已经解决了保存 x ls(Ex cel) 数据的问题了。那么，接下来又要解决另一个问题：当 WORD 程序读取复合文件，遇到了 x ls 数据的时候，它该如何启动 Ex cel 呢？启动后，又如何让 Ex cel 自己去读入、解析、显示 x ls 数据呢？ 二、CLSID 概念 有一个非常简单的解决方案，那就是在对象数据的前面，保存有处理这个数据的程序名。（见下图左上） 图一、CLSID 的概念 这的确是一个简单的方法，但同时问题也很严重。在“张三”的计算机上，Ex cel 的路径是："c:\office\Ex cel.ex e"，如果把这个.doc 文件复制到“李四”的计算机上使用，而“李四”的 Ex cel 的路径是： "d:\Program files\Microsoft Office\Office\Ex cel.ex e"，完蛋了 于是，微软想出了一个解决方案，那就是不使用直接的路径表示方法，而使用一个叫 CLSID（注 1）的方式间接描述这些对象数据的处理程序路径。CLSID 其实就是一个号码，或者说是一个 16 字节的数。观察注册表（上图），在 HKCR\CLSID\{......}主键下，LocalServer32（DLL 组件使用 InprocServer32） 中保存着程序路径名称。CLSID 的结构定义如下： typedef struct _GUID { DWORD Data1; // 随机数 WORD Data2; // 和时间相关 WORD Data3; // 和时间相关 BYTE Data4[8]; // 和网卡 MAC相关 } GUID; typedef GUID CLSID; // 组件 ID typedef GUID IID; // 接口 ID #define REFCLSID const CLSID & // 常见的声明和赋值方法 CLSID CLSID_Excel = {0x00024500,0x0000,0x0000,{0xC0,0x00,0x00,0x00,0x00,0x00,0x00,0x46}}; struct __declspec(uuid("00024500-0000-0000-C000-000000000046")) CLSID_Excel; class DECLSPEC_UUID("00024500-0000-0000-C000-000000000046") CLSID_Excel; // 注册表中的表示方法 {00024500-0000-0000-C000-000000000046} 用一个号码间接表示程序名，的确是个 Good idea，实现了组件位置的透明性，并方便地扩展出 DCOM（远程组件）。但，但，但，但.....CLSID 有 16 个字节共 128 位二进制数，干吗用这么长的数字呀？遥想当年......我还在上幼儿园的时候，人们设计了 socket，用 TCP/IP 协议进行网络通讯。每个参与通讯的计算机都有一个 4 字节的 IP 表示编号地址，范围是 0,0,0,0 ~ 255,255,255,255 共 42 ...
