COM基础之COM在注册表中的相关键值及其意义
COM在系统注册后,会在系统注册表中产生相应的表项。与COM相关的几个常见概念包括:
1. 类型库 Type Library
COM是一种基于独立于开发语言的编程模型。因此在描述COM功能和接口的时候采用了与编程语言无关的接口描述语言(IDL)来编写接口的抽象定义,该接口定义文件(*.IDL)经过Platform SDK自带的Microsoft IDL编译器编译之后将生成相应的头文件、类型库等。
如下是一个简单的类型库定义文件(OOPCOM.idl)
Interface和Class就不用多说了。
需要说明的是,在系统中为了注册一个COM,采用了用GUID(16Bytes)来描述其相关内容的方法,包括类型库,COM接口定义和COM Class的定义。
// OOPCOM.idl : IDL source for OOPCOM.dll
// This file will be processed by the MIDL tool to
// produce the type library (OOPCOM.tlb) and marshalling code.
import "oaidl.idl";
import "ocidl.idl";
[
object,
uuid(DB20D9BF-FAA4-4D23-9243-19860EB4482A),
dual,
helpstring("ISimpleClass Interface"),
pointer_default(unique)
]
interface ISimpleClass : IDispatch
{
[id(1), helpstring("method HelloWorld")] HRESULT HelloWorld([out,retval]BSTR *result);
};
[
uuid(FE0FAA57-2E27-425F-9FA3-518E73F729FB),
version(1.0),
helpstring("OOPCOM 1.0 Type Library")
]
library OOPCOMLib
{
importlib("stdole32.tlb");
importlib("stdole2.tlb");
[
uuid(1CF4A019-A754-44F1-B164-047A3F0AC184),
helpstring("SimpleClass Class")
]
coclass SimpleClass
{
[default] interface ISimpleClass;
};
};
2. COM Interface
3. COM Class
4. Application ID &Name
当我们编写好一个COM并将其在系统中注册之后,对于初学者来说,这些注册表项到底位于Register中的什么位置,系统是如何通过这些注册表项在Runtime时候找到某个COM的,可能有点一头雾水。其实,总的来说,系统是通过GUID来查找每个对象的,比如TypeLib,Interface和Class都有其相应的GUID(16bytes的字符串)
下面简单列出这些用来描述COM的相关表项在注册表中的位置及其意义:
表项一:COM Interface
Path : HKEY_CLASSES_ROOT/Interface/[X]
或者: HKLM /Software / Classes/Interface / [x]
图1
在以上的OOPCOM.idl,我们看到其Inferface ID (IID)为DB20D9BF-FAA4-4D23-9243-19860EB4482A,其在Register中的位置如上图1所
在COM的Interface表项中包含
1. ProxyStubClsid :该键值的具体内容请参考下图2
2. ProxyStubClsid32 :该键值的具体内容参考下图2。该键值与ProxyStubClsid相同值。
3. TyleLib: 与该interface相关的COM 类型库定义
在Interface中,有关ProxyStubClsid和ProxyStubClsid32所指向的CLSID值如下图2所示:
图2
那么,这个ProxyStubClsid键值和ProxyStubClsid32起什么作用呢?这就需要对COM client和COM service是如何进行通讯和数据交换的有所了解。
我们知道,当COM client和COM Server application不在同一个进程地址空间时,COM会建立一个客户端的proxy和server端的stub。例如当client调用CoCreateInstance()时,在服务器将接口指针返回给COM之后,COM将接口指针返回给client之前,COM为指定的接口创建proxy和stub并将指向proxy的指针返回给client。我们把类似这样的过程叫做Marshaling (汇集)。
开发人员可以implement IMarshal这个interface来支持自定义的Marshaling。而如果对象不支持自定义Marshaling,则COM使用proxy和stub程序执行标准Marshaling,因此COM必须从注册表中获得提供proxy和stub程序生成器的DLL的CLSID。这就是我们为什么ProxyStubClsid(32)的意义所在。
一般来说,如果开发的COM支持自动化技术,即实现了IDispatch interface(支持解释型语言的调用,如vbscript等),则其Marshaling的dll一般为以上所示的oleaut32.dll (16bit系统则为ole2disp.dll)。而如果其不支持该技术,则其Marshaling的Dll一般为ole32.dll
表项二:COM Class
Path : HKEY_CLASSES_ROOT / CLSID/ [X]
或者: HKLM /Software / Classes/CLSID / [x]
by default,在CLSID下面包含以下一个键值(如上图所示)
1. LocalServer32
2. ProgID
3.TypeLib
4.Programmable (omitted)
下面对每个键作简要解释:
LocalServer32:
该键用来指定运行在进程外的COM Server Application的.EXE文件path。与之相似的一个表项是:InprocServer32。我们知道,COM运行模式有2种,一种为进程内模式,即COM与Client在同一个进程内存之内,运行在这种模式下的COM必须只能为*.dll,指定其具体COM module的path的时候,即用InprocServer32来指定;另外一种是Out of Process(OOP),即Client和COM Server Application位于不同的Process地址空间,而这种COM必须为*.EXE,指定其具体COM module 的path时候,即用LocalServer32来指定。
而这两种模式下的COM调用过程也不尽相同。
1.服务器为*.dll时,调用过程如下所示:
2. 当服务器为*.EXE 时,其过程如下所示:
ProgID:
实际上ProgID和CLSID都是一回事,只不过是2种不同的叫法而已,ProgID可以说是CLSID的nickname吧。相对于CLSID一串16bytes的难以记忆的数字, ProgID显得更为人性化,系统提供了相应API: GetClsIdFromProgid(t_ProgID) 可以实现ProgID和CLSID之间的互换。
TypeLib:
不用多讲了, 该键在COM interface键中也出现过,用来指定该COM的类型库文件。
既然在COM Interface和COM class中都出现了Type Libray,那就看看TypeLib 键吧。
COM Type Library
Path : HKEY_CLASSES_ROOT/TypeLib/ [X]
TypeLib的各项键值如上图所示。
还有一项不太注意的Regeister Entry就是AppID。当我们把COM注册到系统之后,系统会在 HK_ROOT/AppID 下面生成一个指向该COM的AppID Entry。缺省情况下,会使用COM module name作为该Application name,从而使得该COM/DCOM readable.如下图在dcomcnfg.exe中所示,该AppID和一个readable的Application Name对应起来。
COM Application相关注册表项:
Path : HKEY_CLASSES_ROOT/AppID/ [X]