COM——到底是什么?——COM标准的要点介绍,它被设计用来解决什么问题?
基本元素的定义——COM术语以及这些术语的含义。
使用和处理COM对象——如何创建、使用和销毁COM对象。
基本接口——描述IUnknown基本接口及其方法。
掌握串的处理——在COM代码中如何处理串。
应用COM技术——例子代码,举例说明本文所讨论的所有概念。
处理HRESULT——HRESULT类型描述,如何监测错误及成功代码。
|
COM——到底是什么?
简单地说,COM是一种跨应用和语言共享二进制代码的方法。与C++不同,它提倡源代码重用。ATL便是一个很好的例证。源码级重用虽然好,但只能用于C++。它还带来了名字冲突的可能性,更不用说不断拷贝重用代码而导致工程膨胀和臃肿。 Windows使用DLLs在二进制级共享代码。这也是Windows程序运行的关键——重用kernel32.dll, user32.dll等。但DLLs是针对C接口而写的,它们只能被C或理解C调用规范的语言使用。由编程语言来负责实现共享代码,而不是由DLLs本身。这样的话DLLs的使用受到限制。 MFC引入了另外一种MFC扩展DLLs二进制共享机制。但它的使用仍受限制——只能在MFC程序中使用。 COM通过定义二进制标准解决了这些问题,即 COM明确指出二进制模块(DLLs和EXEs)必须被编译成与指定的结构匹配。这个标准也确切规定了在内存中如何组织COM对象。COM定义的二进制标准还必须独立于任何编程语言(如C++中的命名修饰)。一旦满足了这些条件,就可以轻松地从任何编程语言中存取这些模块。由编译器负责所产生的二进制代码与标准兼容。这样使后来的人就能更容易地使用这些二进制代码。 在内存中,COM对象的这种标准形式在C++虚函数中偶尔用到,所以这就是为什么许多COM代码使用C++的原因。但是记住,编写模块所用的语言是无关的,因为结果二进制代码为所有语言可用。 此外,COM不是Win32特有的。从理论上讲,它可以被移植到Unix或其它操作系统。但是我好像还从来没有在Windows以外的地方听说过COM。 |
基本元素的定义
我们从下往上看。接口只不过是一组函数。这些函数被称为方法。接口名字以大写的I开头,例如C++中的IShellLink,接口被设计成一个抽象基类,其中只有纯粹的虚拟函数。 接口可以从其它接口继承,这里所说的继承的原理就好像C++中的单继承。接口是不允许多继承的。 coclass(简称组件对象类——component object class)被包含在DLL或EXE中,并且包含着一个或者多个接口的代码。组件对象类(coclasss)实现这些接口。COM对象在内存中表现为组件对象类(coclasss)的一个实例。注意COM“类”和C++“类”是不相同的,尽管常常COM类实现的就是一个C++类。 COM服务器是包含了一个或多个coclass的二进制(DLL或EXE)。 注册(Registration)是创建注册表入口的一个过程,告诉Windows 操作系统COM服务器放在什么位置。取消注册(Unregistration)则相反——从注册表删除这些注册入口。 GUID(谐音为“fluid”,意思是全球唯一标示符——globally unique identifier)是个128位的数字。它是一种独立于COM编程语言的标示方法。每一个接口和coclass有一个GUID。因为每一个GUID都是全球唯一的,所以避免了名字冲突(只要你用COM API创建它们)。有时你还会碰到另一个术语UUID(意思也是全球唯一标示符——universally unique identifier)。UUIDs和GUIDs在实际使用时的用途是一样的。 类ID或者CLSID是命名coclass的GUID。接口ID或者IID是命名接口的GUID。 在COM中广泛地使用GUID有两个理由: 1、GUIDs只是简单的数字,任何编程语言都可以对之进行处理。 2、GUIDs可以在任何机器上被任何人创建,一旦完成创建,它就是唯一的。因此,COM开发人员可以创建自己特有的GUIDs而不会与其它开发人员所创建的GUIDs有冲突。这样就消除了集中授权发布GUIDs的必要。 HRESULT是COM用来返回错误和成功代码的整型数字。除此之外,别无它意,虽然以H作前缀,但没有句柄之意。下文会对它有更多的讨论。 最后,COM库是在你使用COM时与你交互的操作系统的一部分,它常常指的就是COM本身。但是为了避免混淆才分开描述的。 |
使用和处理COM对象
每一种语言都有其自己处理对象的方式。例如,C++是在栈中创建对象,或者用new动态分配。因为COM必须独立于语言,所以COM库为自己提供对象管理例程。下面是对COM对象管理和C++对象管理所做的一个比较: 创建一个新对象 C++中,用new操作符,或者在栈中创建对象。 COM中,调用COM库中的API。 删除对象 C++中,用delete操作符,或将栈对象踢出。 COM中,所有的对象保持它们自己的引用计数。调用者必须通知对象什么时候用完这个对象。当引用计数为零时,COM对象将自己从内存中释放。 由此可见,对象处理的两个阶段:创建和销毁,缺一不可。当创建COM对象时要通知COM库使用哪一个接口。如果这个对象创建成功,COM库返回所请求接口的指针。然后通过这个指针调用方法,就像使用常规C++对象指针一样。 |
创建COM对象
为了创建COM对象并从这个对象获得接口,必须调用COM库的API函数,CoCreateInstance()。其原型如下: |
HRESULT CoCreateInstance ( REFCLSID rclsid, LPUNKNOWN pUnkOuter, DWORD dwClsContext, REFIID riid, LPVOID* ppv );
|
以下是参数解释:
rclsid coclass的CLSID,例如,可以传递CLSID_ShellLink创建一个COM对象来建立快捷方式。 pUnkOuter 这个参数只用于COM对象的聚合,利用它向现有的coclass添加新方法。参数值为null表示不使用聚合。 dwClsContext 表示所使用COM服务器的种类。本文使用的是最简单的COM服务器,一个进程内(in-process)DLL,所以传递的参数值为CLSCTX_INPROC_SERVER。注意这里不要随意使用CLSCTX_ALL(在ATL中,它是个缺省值),因为在没有安装DCOM的Windows95系统上会导致失败。 riid 请求接口的IID。例如,可以传递IID_IShellLink获得IShellLink接口指针。 ppv 接口指针的地址。COM库通过这个参数返回请求的接口。 当你调用CoCreateInstance()时,它负责在注册表中查找COM服务器的位置,将服务器加载到内存,并创建你所请求的coclass实例。 以下是一个调用的例子,创建一个CLSID_ShellLink对象的实例并请求指向这个对象IShellLink接口指针。 |
HRESULT hr;IShellLink* pISL; hr = CoCreateInstance ( CLSID_ShellLink, // coclass 的CLSID NULL, // 不是用聚合 CLSCTX_INPROC_SERVER, // 服务器类型 IID_IShellLink, // 接口的IID (void**) &pISL ); // 指向接口的指针 if ( SUCCEEDED ( hr ) ) { // 用pISL调用方法 } else { // 不能创建COM对象,hr 为出错代码 }
|
首先声明一个接受CoCreateInstance()返回值的HRESULT和IShellLink指针。调用CoCreateInstance()来创建新的COM对象。如果hr接受到一个表示成功的代码,则SUCCEEDED宏返回TRUE,否则返回FALSE。FAILED是一个与SUCCEEDED对应的宏用来检查失败代码。
|
删除COM对象
前面说过,你不用释放COM对象,只要告诉它们你已经用完对象。IUnknown是每一个COM对象必须实现的接口,它有一个方法,Release()。调用这个方法通知COM对象你不再需要对象。一旦调用了这个方法之后,就不能再次使用这个接口,因为这个COM对象可能从此就从内存中消失了。 如果你的应用程序使用许多不同的COM对象,因此在用完某个接口后调用Release()就显得非常重要。如果你不释放接口,这个COM对象(包含代码的DLLs)将保留在内存中,这会增加不必要的开销。如果你的应用程序要长时间运行,就应该在应用程序处于空闲期间调用CoFreeUnusedLibraries() API。这个API将卸载任何没有明显引用的COM服务器,因此这也降低了应用程序使用的内存开销。 继续用上面的例子来说明如何使用Release(): |
// 像上面一样创建COM 对象, 然后, if ( SUCCEEDED ( hr ) ) { // 用pISL调用方法 // 通知COM 对象不再使用它 pISL->Release(); }
|
接下来将详细讨论IUnknown接口。
|
基本接口——IUnknown
每一个COM接口都派生于IUnknown。这个名字有点误导人,其中没有未知(Unknown)接口的意思。它的原意是如果有一个指向某COM对象的IUnknown指针,就不用知道潜在的对象是什么,因为每个COM对象都实现IUnknown。 IUnknown 有三个方法: AddRef() – 通知COM对象增加它的引用计数。如果你进行了一次接口指针的拷贝,就必须调用一次这个方法,并且原始的值和拷贝的值两者都要用到。在本文的例子中没有用到AddRef()方法。 Release() – 通知COM对象减少它的引用计数。参见前面的Release()示例代码段。 QueryInterface() – 从COM对象请求一个接口指针。当coclass实现一个以上的接口时,就要用到这个方法。 前面已经看到了Release()的使用,但如何使用QueryInterface()呢?当你用CoCreateInstance()创建对象的时候,你得到一个返回的接口指针。如果这个COM对象实现一个以上的接口(不包括IUnknown),你就必须用QueryInterface()方法来获得任何你需要的附加的接口指针。QueryInterface()的原型如下: |
HRESULT IUnknown::QueryInterface ( REFIID iid, void** ppv );
|
以下是参数解释:
iid 所请求的接口的IID。 ppv 接口指针的地址,QueryInterface()通过这个参数在成功时返回这个接口。 让我们继续外壳链接的例子。它实现了IShellLink 和IPersistFile接口。如果你已经有一个IShellLink指针,pISL,可以从COM对象请求IPersistFile接口: |
HRESULT hr;
IPersistFile* pIPF; hr = pISL->QueryInterface ( IID_IPersistFile, (void**) &pIPF ); 然后使用SUCCEEDED宏检查hr的值以确定QueryInterface()的调用情况,如果成功的话你就可以象使用其它接口指针那样使用新的接口指针,pIPF。但必须记住调用pIPF->Release()通知COM对象已经用完这个接口。 |
仔细做好串处理
这一部分将花点时间来讨论如何在COM代码中处理串。如果你熟悉Unicode 和ANSI,并知道如何对它们进行转换的话,你就可以跳过这一部分,否则还是读一下这一部分的内容。 不管什么时候,只要COM方法返回一个串,这个串都是Unicode串(这里指的是写入COM规范的所有方法)。Unicode是一种字符编码集,类似ASCII,但用两个字节表示一个字符。如果你想更好地控制或操作串的话,应该将它转换成TCHAR类型串。 TCHAR和以_t开头的函数(如_tcscpy())被设计用来让你用相同的源代码处理Unicode和ANSI串。在大多数情况下编写的代码都是用来处理ANSI串和ANSI WindowsAPIs,所以在下文中,除非另外说明,我所说的字符/串都是指TCHAR类型。你应该熟练掌握TCHAR类型,尤其是当你阅读其他人写的有关代码时,要特别注意TCHAR类型。 当你从某个COM方法返回得到一个Unicode串时,可以用下列几种方法之一将它转换成char类型串: 1、调用 WideCharToMultiByte() API。 2、调用CRT 函数wcstombs()。 3、使用CString 构造器或赋值操作(仅用于MFC )。 4、使用ATL 串转换宏。 |
WideCharToMultiByte()
你可以用WideCharToMultiByte()将一个Unicode串转换成一个ANSI串。此函数的原型如下: |
int WideCharToMultiByte ( UINT CodePage, DWORD dwFlags, LPCWSTR lpWideCharStr, int cchWideChar, LPSTR lpMultiByteStr, int cbMultiByte, LPCSTR lpDefaultChar, LPBOOL lpUsedDefaultChar );
|
以下是参数解释:
CodePage Unicode字符转换成的代码页。你可以传递CP_ACP来使用当前的ANSI代码页。代码页是256个字符集。字符0——127与ANSI编码一样。字符128——255与ANSI字符不同,它可以包含图形字符或者读音符号。每一种语言或地区都有其自己的代码页,所以使用正确的代码页对于正确地显示重音字符很重要。 dwFlags dwFlags 确定Windows如何处理“复合” Unicode字符,它是一种后面带读音符号的字符。如è就是一个复合字符。如果这些字符在CodePage参数指定的代码页中,不会出什么事。否则,Windows必须对之进行转换。 传递WC_COMPOSITECHECK使得这个API检查非映射复合字符。 传递WC_SEPCHARS使得Windows将字符分为两段,即字符加读音,如e`。 传递WC_DISCARDNS使得Windows丢弃读音符号。 传递WC_DEFAULTCHAR使得Windows用lpDefaultChar参数中说明的缺省字符替代复合字符。 缺省行为是WC_SEPCHARS。 lpWideCharStr 要转换的Unicode串。 cchWideChar lpWideCharStr在Unicode 字符中的长度。通常传递-1,表示这个串是以0x00结尾。 lpMultiByteStr 接受转换的串的字符缓冲 cbMultiByte lpMultiByteStr的字节大小。 lpDefaultChar 可选——当dwFlags包含WC_COMPOSITECHECK | WC_DEFAULTCHAR并且某个Unicode字符不能被映射到同等的ANSI串时所传递的一个单字符ANSI串,包含被插入的“缺省”字符。可以传递NULL,让API使用系统缺省字符(一种写法是一个问号)。 lpUsedDefaultChar 可选——指向BOOL类型的一个指针,设置它来表示是否缺省字符曾被插入ANSI串。可以传递NULL来忽略这个参数。 我自己都有点晕菜了……!,万事开头难啊……,不搞清楚这些东西就很难搞清楚COM的串处理。何况文档中列出的比实际应用的要复杂得多。下面就给出了如何使用这个API的例子: |
// 假设已经有了一个Unicode 串 wszSomeString...char szANSIString [MAX_PATH]; WideCharToMultiByte ( CP_ACP, // ANSI 代码页 WC_COMPOSITECHECK, // 检查重音字符 wszSomeString, // 原Unicode 串 -1, // -1 意思是串以0x00结尾 szANSIString, // 目的char字符串 sizeof(szANSIString), // 缓冲大小 NULL, // 肥缺省字符串 NULL ); // 忽略这个参数 调用这个函数后,szANSIString将包含Unicode串的ANSI版本。
|
wcstombs()
这个CRT函数wcstombs()是个简化版,但它终结了WideCharToMultiByte()的调用,所以最终结果是一样的。其原型如下: |
size_t wcstombs ( char* mbstr, const wchar_t* wcstr, size_t count );
|
以下是参数解释:
mbstr 接受结果ANSI串的字符(char)缓冲。 wcstr 要转换的Unicode串。 count mbstr参数所指的缓冲大小。 wcstombs()在它对WideCharToMultiByte()的调用中使用WC_COMPOSITECHECK | WC_SEPCHARS标志。用wcstombs()转换前面例子中的Unicode串,结果一样: wcstombs ( szANSIString, wszSomeString, sizeof(szANSIString) ); |
CString
MFC中的CString包含有构造函数和接受Unicode串的赋值操作,所以你可以用CString来实现转换。例如: // 假设有一个Unicode串wszSomeString... CString str1 ( wszSomeString ); // 用构造器转换 CString str2; str2 = wszSomeString; // 用赋值操作转换 ATL宏 ATL有一组很方便的宏用于串的转换。W2A()用于将Unicode串转换为ANSI串(记忆方法是“wide to ANSI”——宽字符到ANSI)。实际上使用OLE2A()更精确,“OLE”表示的意思是COM串或者OLE串。下面是使用这些宏的例子: #include <atlconv.h> // 还是假设有一个Unicode串wszSomeString... { char szANSIString [MAX_PATH]; USES_CONVERSION; // 声明这个宏要使用的局部变量 lstrcpy ( szANSIString, OLE2A(wszSomeString) ); } OLE2A()宏“返回”转换的串的指针,但转换的串被存储在某个临时栈变量中,所以要用lstrcpy()来获得自己的拷贝。其它的几个宏是W2T()(Unicode 到 TCHAR)以及W2CT()(Unicode到常量TCHAR串)。 有个宏是OLE2CA()(Unicode到常量char串),可以被用到上面的例子中,OLE2CA()实际上是个更正宏,因为lstrcpy()的第二个参数是一个常量char*,关于这个问题本文将在以后作详细讨论。 另一方面,如果你不想做以上复杂的串处理,尽管让它还保持为Unicode串,如果编写的是控制台应用程序,输出/显示Unicode串时应该用全程变量std::wcout,如: wcout << wszSomeString; 但是要记住,std::wcout只认Unicode,所以你要是“正常”串的话,还得用std::cout输出/显示。对于Unicode串文字量,要使用前缀L标示,如: wcout << L"The Oracle says..." << endl << wszOracleResponse; 如果保持串为Unicode,编程时有两个限制: —— 必须使用wcsXXX() Unicode串处理函数,如wcslen()。 —— 在Windows 9x环境中不能在Windows API中传递Unicode串。要想编写能在9x和NT上都能运行的应用,必须使用TCHAR类型,详情请参考MSDN。 用例子代码总结上述内容 下面用两个例子演示本文所讲的COM概念。代码中还包含了本文的例子工程。 使用单接口COM对象 第一个例子展示的是单接口COM对象。这可能是你碰到得最简单的例子。它使用外壳中的活动桌面组件对象类(CLSID_ActiveDesktop)来获得当前桌面墙纸的文件名。请确认系统中安装了活动桌面(Active Desktop)。 |
以下是编程步骤:初始化COM库。 (Initialize)创建一个与活动桌面交互的COM对象,并取得IActiveDesktop接口。 调用COM对象的GetWallpaper()方法。如果GetWallpaper()成功,则输出/显示墙纸文件名。释放接口(Release())。 收回COM库(Uninitialize)。WCHAR wszWallpaper [MAX_PATH];CString strPath;HRESULT hr; IActiveDesktop* pIAD; // 1. 初始化COM库(让Windows加载DLLs)。通常是在程序的InitInstance()中调用 // CoInitialize ( NULL )或其它启动代码。MFC程序使用AfxOleInit()。 CoInitialize ( NULL ); // 2. 使用外壳提供的活动桌面组件对象类创建COM对象。 // 第四个参数通知COM需要什么接口(这里是IActiveDesktop). hr = CoCreateInstance ( CLSID_ActiveDesktop, NULL, CLSCTX_INPROC_SERVER, IID_IActiveDesktop, (void**) &pIAD ); if ( SUCCEEDED(hr) ) { // 3. 如果COM对象被创建成功,则调用这个对象的GetWallpaper() 方法。 hr = pIAD->GetWallpaper ( wszWallpaper, MAX_PATH, 0 ); if ( SUCCEEDED(hr) ) { // 4. 如果 GetWallpaper() 成功,则输出它返回的文件名字。 // 注意这里使用wcout 来显示Unicode 串wszWallpaper. wcout 是 // Unicode 专用,功能与cout.相同。 wcout << L"Wallpaper path is:\n " << wszWallpaper << endl << endl; } else { cout << _T("GetWallpaper() failed.") << endl << endl; } // 5. 释放接口。 pIAD->Release(); } else { cout << _T("CoCreateInstance() failed.") << endl << endl; } // 6. 收回COM库。MFC 程序不用这一步,它自动完成。CoUninitialize();
|
在这个例子中,输出/显示Unicode 串 wszWallpaper用的是std::wcout。
使用多接口的COM对象 第二个例子展示了如何使用一个提供单接口的COM对象QueryInterface()函数。其中的代码用外壳的Shell Link组件对象类创建我们在第一个例子中获得的墙纸文件的快捷方式 |
以下是编程步骤:初始化COM 库。 创建一个用于建立快捷方式的COM 对象并取得IShellLink 接口。 调用IShellLink 接口的SetPath()方法调用对象的QueryInterface()函数并取得IPersistFile接口。 调用IPersistFile 接口的Save()方法。释放接口收回COM库 CString sWallpaper = wszWallpaper; // 将墙纸路径转换为ANSIIShellLink* pISL; IPersistFile* pIPF; // 1. 初始化COM库(让Windows 加载DLLs). 通常在InitInstance()中调用 // CoInitialize ( NULL )或其它启动代码。MFC 程序使用AfxOleInit() 。 CoInitialize ( NULL ); // 2. 使用外壳提供的Shell Link组件对象类创建COM对象。. // 第四个参数通知COM 需要什么接口(这里是IShellLink)。 hr = CoCreateInstance ( CLSID_ShellLink, NULL, CLSCTX_INPROC_SERVER, IID_IShellLink, (void**) &pISL ); if ( SUCCEEDED(hr) ) { // 3. 设置快捷方式目标(墙纸文件)的路径。 hr = pISL->SetPath ( sWallpaper ); if ( SUCCEEDED(hr) ) { // 4. 获取这个对象的第二个接口(IPersistFile)。 hr = pISL->QueryInterface ( IID_IPersistFile, (void**) &pIPF ); if ( SUCCEEDED(hr) ) { // 5. 调用Save() 方法保存某个文件得快捷方式。第一个参数是 // Unicode 串。 hr = pIPF->Save ( L"C:\\wallpaper.lnk", FALSE ); // 6a. 释放IPersistFile 接口。 pIPF->Release(); } } pISL->Release(); } // 输出错误信息部分这里省略。 // 7. 收回COM 库。MFC 程序不用这一步,它自动完成。 CoUninitialize();
|
处理HRESULT
这一部分准备用SUCCEEDED 和 FAILED宏进行一些简单的出错处理。主要是深入研究从COM方法返回的HRESULT,以便达到完全理解和熟练应用。 HRESULT是个32位符号整数,其非负值表示成功,负值表示失败。HRESULT有三个域:程度位(表示成功或失败),功能码和状态码。功能码表示HRESULT来自什么组件或程序。微软给不同的组件多赋予功能码,如:COM、任务调度程序等都有功能码。功能码是个16位的值,仅此而已,没有其它内在含义;它在数字和意义之间是随意关联的;类似GetLastError()返回的值。 如果你在winerror.h头文件中查找错误代码,会看到许多按照[功能]_[程度]_[描述]命名规范列出的HRESULT值,由组件返回的通用的HRESULT(类似E_OUTOFMEMORY)在名字中没有功能码。如, REGDB_E_READREGDB: 功能码 = REGDB, 指“注册表数据库(registry database)”;程度 = E 意思是错误(error);描述 = READREGDB 是对错误的描述(意思是不能读注册表数据库)。 S_OK: 没有功能码——通用(generic)HRESULT;程度=S;表示成功(success);OK 是状态描述表示一切都好(everything's OK)。 好在有一种比察看winerror.h文件更容易的方法来确定HRESULT的意思。使用VC提供的错误查找工具(Error Lookup)可以轻松查到为HRESULT内建功能码。例如,假设你在CoCreateInstance()之前忘了调用CoInitialize()。CoCreateInstance()返回的值是0x800401F0。你只要将这个值输入到错误查找工具按“Look Up”按钮,便可以看到错误信息描述“尚未调用CoInitialize”如下图所示: |
|
另外一种查找HRESULT描述的方法是在调试器中。假设有一个HRESULT变量是hres。在Watch窗口的左边框中输入“hres,hr”,表示想要看的值,“hr”便会通知VC显示HRESULT所描述的值。如下图所示:
|
|
|
通过以上的讨论,想必你对COM编程有了初步的认识,本文第二部分将探讨COM的内部机制。教你如何用C++编写自己的接口。
|
走马观花看COM服务器——描述COM服务器的基本要求。 服务器生命其管理——描述COM服务器如何控制加载时间。 实现接口,从IUnknown开始——展示如何用C++类编写一个接口实现并描述IUnknown之方法的目的。 深入CoCreateInstance()——探究CoCreateInstance()的调用机理。 COM服务器的注册——描述完成服务器注册所需要的注册表入口。 创建COM对象——类工厂——描述创建客户端要使用的COM对象的过程。 一个定制接口的例子——例子代码示范了上述概念。 一个使用服务器的客户端——举例说明一个简单的客户端应用程序,用它来测试COM服务器。 其它内容——有关源代码和调试的注释。 |
||||||||||
走马观花看COM服务器 | ||||||||||
本文我们将讨论最简单的一种COM服务器,进程内服务器(in-process)。“进程内”意思是服务器被加载到客户端程序的进程空间。进程内服务器都是DLLs,并且与客户端程序同在一台计算机上。 进程内服务器在被COM库使用之前必须满足两个条件或标准: 1、 必须正确在注册表的HKEY_CLASSES_ROOT\CLSID 键值下注册。 2、 必须输出DllGetClassObject()函数。 这是进程内服务器运行的最小需求。在注册表的HKEY_CLASSES_ROOT\CLSID 键值下必须创建一个键值,用服务器的GUID作为键名字,这个键值必须包含两个键值清单,一是服务器的位置,而是服务器的线程模型。 COM库对DllGetClassObject()函数进行调用是在CoCreateInstance() API中完成的。 还有三个函数通常也要输出: |
||||||||||
o DllCanUnloadNow():由COM库调用来检查是否服务器被从内存中卸载。 o DllRegisterServer():由类似RegSvr32的安装实用程序调用来注册服务器。 o DllUnregisterServer():由卸载实用程序调用来删除由DllRegisterServer()创建的注册表入口。 |
||||||||||
另外,只输出正确的函数是不够的——还必须遵循COM规范,这样COM库和客户端程序才能使用服务器。 | ||||||||||
服务器生命其管理 | ||||||||||
DLL服务器的一个与众不同的方面是控制它们被加载的时间。“标准的”DLLs被动的并且是在应用程序使用它们时被随机加载/或卸载。从技术上讲,DLL服务器也是被动的,因为不管怎样它们毕尽还是DLL,但COM库提供了一种机制,它允许某个服务器命令COM卸载它。这是通过输出函数DllCanUnloadNow()实现的。这个函数的原型如下: | ||||||||||
HRESULT DllCanUnloadNow(); |
||||||||||
当客户应用程序调用COM API CoFreeUnusedLibraries()时,通常出于其空闲处理期间,COM库遍历这个客户端应用已加载所有的DLL服务器并通过调用它的DllCanUnloadNow()函数查询每一个服务器。另一方面,如果某个服务器确定它不再需要驻留内存,它可以返回S_OK让COM将它卸载。 服务器通过简单的引用计数来确定它是否能被卸载。下面是DllCanUnloadNow()的实现: |
||||||||||
extern UINT g_uDllRefCount; // 服务器的引用计数 HRESULT DllCanUnloadNow() { return (g_uDllRefCount > 0) ? S_FALSE : S_OK; } |
||||||||||
如何处理引用计数将在下一节涉及到具体代码时讨论。 | ||||||||||
实现接口,从IUnknown开始 | ||||||||||
有必要回想一下IUnknown派生的每一个接口。因为IUnknown包含了两个COM对象的基本特性——引用计数和接口查询。当你编写组件对象类时(coclass),还要写一个满足自己需要的IUnknown实现。以实现IUnknown接口的组件对象类为例——下面这个例子可能是你编写的最简单的一个组件对象类。我们将在一个叫做CUnknownImpl的C++类中实现IUnknown。下面是这个类的声明: | ||||||||||
class CUnknownImpl : public IUnknown { public: // 构造函数和析构器 CUnknownImpl(); virtual ~CUnknownImpl(); // IUnknown 方法 ULONG AddRef(); ULONG Release)(); HRESULT QueryInterface( REFIID riid, void** ppv ); protected: UINT m_uRefCount; // 对象的引用计数 }; |
||||||||||
构造器和析构器 | ||||||||||
构造器和析构器管理服务器的引用计数: | ||||||||||
CUnknownImpl::CUnknownImpl() { m_uRefCount = 0; g_uDllRefCount++; } CUnknownImpl::~CUnknownImpl() { g_uDllRefCount--; } |
||||||||||
当创建新的COM对象时,构造器被调用,它增加服务器的引用计数以保持这个服务器驻留内存。同时它还将对象的引用计数初始化为零。当这个COM对象被摧毁时,它减少服务器的引用计数。 | ||||||||||
AddRef()和Release() 这两个方法控制COM对象的生命期。AddRef()很简单: ULONG CUnknownImpl::AddRef() { return ++m_uRefCount; } AddRef()只增加对象的引用计数并返回更新的计数。 Release()更简单: ULONG CUnknownImpl::Release() { ULONG uRet = --m_uRefCount; if ( 0 == m_uRefCount ) // 是否释放了最后的引用? delete this; return uRet; } |
||||||||||
除了减少对象的引用计数外,如果没有另外的明确引用,Release()将摧毁对象。Release()也返回更新的引用计数。注意Release()的实现假设COM对象在堆中创建。如果你在全局粘上创建某个对象,当对象试图删除自己时就会出问题。 现在应该明白了为什么在客户端应用程序中正确调用AddRef()和 Release()是如此重要!如果在这了做得不对,你使用的对象会被很快摧毁,这样的话在整个服务器中内存会很快溢出导致应用程序下次存取服务器代码时崩溃。 如果你编写多线程应用,可能会想到使用++&替代InterlockedIncrement()和InterlockedDecrement()的线程安全问题。++&——用于单线程服务器很保险,因为即使客户端应用是多线程的并从不同的线程中进行方法调用,COM库都会按顺序进行服务器的方法调用。也就是说,一旦一个方法调用开始,所有其它试图调用方法的线程都将阻塞,直到第一个方法返回。COM库本身确保服务器一次不会被一个以上的线程闯入。 QueryInterface() QueryInterface()简称QI(),由客户端程序调用这个函数从COM对象请求不同的接口。我们在例子代码中因为只实现一个接口,QI()会很容易使用。QI()有两个参数:一个是所请求的接口IID,一个是指针的缓冲大小,如果查询成功,QI()将接口指针地址存储在这个缓冲指针中。 |
||||||||||
HRESULT CUnknownImpl::QueryInterface ( REFIID riid, void** ppv ) { HRESULT hrRet = S_OK; // 标准QI()初始化 – 置 *ppv 为 NULL. *ppv = NULL; // 如果客户端请求提供的接口,给 *ppv.赋值 if ( IsEqualIID ( riid, IID_IUnknown )) { *ppv = (IUnknown*) this; } else { // 不提供客户端请求的接口 hrRet = E_NOINTERFACE; } // 如果返回一个接口指针。 调用AddRef()增加引用计数. if ( S_OK == hrRet ) { ((IUnknown*) *ppv)->AddRef(); } return hrRet; } 在QI()中做了三件不同的事情: 1、初始化传入的指针为NULL[*ppv = NULL;]。 2、检查riid,确定组件对象类(coclass)实现了客户端所请求接口. [if ( IsEqualIID ( riid, IID_IUnknown ))] 3、如果确实实现勒索请求的接口,则增加COM对象的引用计数。 [((IUnknown*) *ppv)->AddRef();] AddRef()调用很关键。 *ppv = (IUnknown*) this; |
||||||||||
要创建新的COM对象引用,就必须调用这个函数通知COM对象这个新引用成立。在AddRef()调用中的强制转换IUnknown*看起来好像多余,但是在QI()中初始化的*ppv有可能不是IUnknown*类型,所以最好是养成习惯对之进行强行转换。。 上面我们已经讨论了一些DLL服务器的内部细节,接下来让我们回头看一看当客户端调用CoCreateInstance()时是如何处理服务器的。 深入CoCreateInstance() 在本文的第一部分中,我们见过CoCreateInstance()API,其作用是当客户端请求对象时,用它来创建对象。从客户端的立场看,它是一个黑盒子。只要用正确的参数调用它即可得到一个COM对象。它并没有什么魔法,只是在一个定义良好的过程中加载COM服务器,创建请求的COM对象并返回所要的指针。就这些。 下面让我们来浏览一下这个过程。这里要涉及到几个不太熟悉的术语,但不用着急,后面会对它们作详细讨论。 |
||||||||||
1、客户端程序调用CoCreateInstance(),传递组件对象类的CLSID以及所要接口的IID。 2、COM库在HKEY_CLASSES_ROOT\CLSID.键值下查找服务器的CLSID键值,这个键值包含服务器的注册信息。 3、COM库读取服务器DLL的全路径并将DLL加载到客户端的进程空间。 4、COM库调用在服务器中DllGetClassObject()函数为所请求的组件对象类请求类工厂。 5、服务器创建一个类工厂并将它从DllGetClassObject()返回。 6、COM库在类工厂中调用CreateInstance()方法创建客户端程序请求的COM对象。 7、CreateInstance()返回一个接口指针到客户端程序。 |
||||||||||
COM服务器注册 COM服务器必须在Windows注册表中正确注册以后才能正常工作。如果你看一下注册表中的HKEY_CLASSES_ROOT\CLSID键,就会发现大把大把子键,它们就是在这个计算机上注册的COM服务器。当某个COM服务器注册后(通常是用DllRegisterServer()进行注册),就会以标准的注册表格式在CLSID键下创建一个键,它名字为服务器的GUID。下面是一个这样的例子: {067DF822-EAB6-11cf-B56E-00A0244D5087} 大括弧和连字符是必不可少的,字母大小写均可。 |
||||||||||
struct IClassFactory : public IUnknown { HRESULT CreateInstance( IUnknown* pUnkOuter, REFIID riid, void** ppvObject ); HRESULT LockServer( BOOL fLock ); }; |
||||||||||
其中,CreateInstance()是创建COM对象的方法。LockServer()在必要时让COM库增加或减少服务器的引用计数。 一个定制接口的例子 这个工程是一个能运行的DLL服务器例子,对象由类工厂创建,此DLL服务器在 CSimpleMsgBoxImpl组件对象类中实现了一个接口:ISimpleMsgBox。 接口定义 我们的新接口是ISimpleMsgBox。所有的接口多必须从IUnknown派生。这个接口只有一个方法:DoSimpleMsgBox()。注意它返回标准类型HRESULT。所有的方法都应该返回HRESULT类型,并且所有返回到调用者的其它数据都应该通过指针参数操作。 |
||||||||||
struct ISimpleMsgBox : public IUnknown { // IUnknown 方法 ULONG AddRef(); ULONG Release(); HRESULT QueryInterface( REFIID riid, void** ppv ); // ISimpleMsgBox方法 HRESULT DoSimpleMsgBox( HWND hwndParent, BSTR bsMessageText ); }; struct __declspec(uuid("{7D51904D-1645-4a8c-BDE0-0F4A44FC38C4}")) ISimpleMsgBox; |
||||||||||
有__declspec的一行将一个GUID赋值给ISimpleMsgBox,并且以后可以用__uuidof操作符来获取GUID。这两个东西都是微软的C++的扩展。 DoSimpleMsgBox()的第二个参数是BSTR类型。意思是二进制串——即定长序列位的COM表示。BSTRs主要用于Visual Basic 和 Windows Scripting Host之类的脚本客户端。 接下来这个接口由CSimpleMsgBoxImpl C++类来实现。其定义如下: |
||||||||||
class CSimpleMsgBoxImpl : public ISimpleMsgBox { public: CSimpleMsgBoxImpl(); virtual ~CSimpleMsgBoxImpl(); // IUnknown 方法 ULONG AddRef(); ULONG Release(); HRESULT QueryInterface( REFIID riid, void** ppv ); // ISimpleMsgBox 方法 HRESULT DoSimpleMsgBox( HWND hwndParent, BSTR bsMessageText ); protected: ULONG m_uRefCount; }; class __declspec(uuid("{7D51904E-1645-4a8c-BDE0-0F4A44FC38C4}")) CSimpleMsgBoxImpl; 当某一客户端想要创建一个SimpleMsgBox COM对象时,它应该用下面这样的代码: ISimpleMsgBox* pIMsgBox; HRESULT hr; // 组件对象类的CLSID hr = CoCreateInstance ( __uuidof(CSimpleMsgBoxImpl), NULL, // 非聚合 CLSCTX_INPROC_SERVER, // 进程内服务器 __uuidof(ISimpleMsgBox), // 所请求接口的IID (void**) &pIMsgBox ); // 返回的接口指针的地址 |
||||||||||
类工厂实现 我们的类工厂SimpleMsgBox是在一个叫做CSimpleMsgBoxClassFactory的C++类中实现的: |
||||||||||
class CSimpleMsgBoxClassFactory : public IClassFactory { public: CSimpleMsgBoxClassFactory(); virtual ~CSimpleMsgBoxClassFactory(); // IUnknown方法 ULONG AddRef(); ULONG Release(); HRESULT QueryInterface( REFIID riid, void** ppv ); // IClassFactory方法 HRESULT CreateInstance( IUnknown* pUnkOuter, REFIID riid, void** ppv ); HRESULT LockServer( BOOL fLock ); protected: ULONG m_uRefCount; }; 构造函数、析构函数和IUnknown方法都和前面例子中的一样,不同的只有IClassFactory的方法,LockServer(),看起来相当更简单: HRESULT CSimpleMsgBoxClassFactory::LockServer ( BOOL fLock ) { fLock ? g_uDllLockCount++ : g_uDllLockCount--; return S_OK; } |
||||||||||
CreateInstance()是重点。我们说过这个方法负责创建新的CSimpleMsgBoxImpl对象。让我们进一步探讨一下它的原型和参数: | ||||||||||
HRESULT CSimpleMsgBoxClassFactory::CreateInstance ( IUnknown* pUnkOuter, REFIID riid, void** ppv ); |
||||||||||
第一个参数pUnkOuter只用于聚合的新对象,指向“外部的”COM对象,也就是说,这个“外部”对象将包含此新对象。对象的聚合超出了本文的讨论范围,本文的例子对象也不支持聚合。 riid 和ppv 与在QueryInterface()中的用法一样——它们是客户端所请求的接口IID和存储接口指针的指针缓冲。 下面是CreateInstance()的实现。它从参数的有效性检查和参数的初始化开始。 |
||||||||||
HRESULT CSimpleMsgBoxClassFactory::CreateInstance ( IUnknown* pUnkOuter, REFIID riid, void** ppv ) { // 因为不支持聚合,所以这个参数pUnkOuter必须为NULL. if ( NULL != pUnkOuter ) return CLASS_E_NOAGGREGATION; //检查指针ppv是不是void*类型 if ( IsBadWritePtr ( ppv, sizeof(void*) )) return E_POINTER; *ppv = NULL; 检查完参数的有效性后,就可以创建一个新的对象了。 CSimpleMsgBoxImpl* pMsgbox; // 创建一个新的COM对象 pMsgbox = new CSimpleMsgBoxImpl; if ( NULL == pMsgbox ) return E_OUTOFMEMORY; 最后,用QI()来查询客户端所请求的新对象的接口。如果QI()失败,则这个对象不可用,必须删除它。 HRESULT hrRet; // 用QI查询客户端所请求的对象接口 hrRet = pMsgbox->QueryInterface ( riid, ppv ); // 如果QI失败,则删除这个COM对象,因为客户端不能使用它(客户端没有 //这个对象的任何接口) if ( FAILED(hrRet) ) delete pMsgbox; return hrRet; } |
||||||||||
深入DllGetClassObject() 现在让我们深入DllGetClassObject()内部。它的原型是: HRESULT DllGetClassObject ( REFCLSID rclsid, REFIID riid, void** ppv ); rclsid是客户端所请求的组件对象类的CLSID。这个函数必须返回指定组件对象类的类工厂。 这里的两个参数: riid 和 ppv类似QI()的参数。不过在这个函数中,riid指的是COM库所请求的类工厂接口的IID。通常就是IID_IClassFactory。 因为DllGetClassObject()也创建一个新的COM对象(类工厂),所以代码与IClassFactory::CreateInstance()十分相似。开始也是进行一些有效性检查以及初始化。 |
||||||||||
HRESULT DllGetClassObject ( REFCLSID rclsid, REFIID riid, void** ppv ) { // 检查客户端所要的CSimpleMsgBoxImpl类工厂 if ( !InlineIsEqualGUID ( rclsid, __uuidof(CSimpleMsgBoxImpl) )) return CLASS_E_CLASSNOTAVAILABLE; //检查指针ppv是不是void*类型 if ( IsBadWritePtr ( ppv, sizeof(void*) )) return E_POINTER; *ppv = NULL; |
||||||||||
第一个if语句检查rclsid参数。我们的服务器只有一个组件对象类,所以rclsid必须是CSimpleMsgBoxImpl类的CLSID。__uuidof操作符获取先前在__declspec(uuid())声明中指定的CsimpleMsgBoxImpl类的GUID。 | ||||||||||
下一步是创建一个类工厂对象。 CSimpleMsgBoxClassFactory* pFactory; // 构造一个新的类工厂对象 pFactory = new CSimpleMsgBoxClassFactory; if ( NULL == pFactory )return E_OUTOFMEMORY; |
||||||||||
这里的处理与CreateInstance()中所做的有所不同。在CreateInstance()中是调用了QI(),并且如果调用失败,则删除COM对象。 我们可以把自己假设成一个所创建的COM对象的客户端,调用AddRef()进行一次引用计数(COUNT = 1)。然后调用QI()。如果QI()调用成功,它将再一次用AddRef()进行引用计数(COUNT = 2)。如果QI()调用失败。引用计数将保持为原来的值(COUNT = 1)。 在QI()调用之后,类工厂对象就使用完了,因此要调用Release()来释放它。如果QI()调用失败,这个对象将自我删除(因为引用计数将为零),所以最终结果是一样的。 |
||||||||||
// 调用AddRef()增加一个类工厂引用计数,因为我们正在使用它 pFactory->AddRef(); HRESULT hrRet; // 调用QI()查询客户端所要的类工厂接口 hrRet = pFactory->QueryInterface ( riid, ppv ); // 使用完类工厂后调用Release()释放它 pFactory->Release(); return hrRet; } |
||||||||||
再谈QueryInterface() 前面讨论过QI()的实现,但还是有必要再看一看类工厂的QI(),因为它是一个很现实的例子,其中COM对象实现的不光是IUnknown。首先进行的是对ppv缓冲的有效性检查以及初始化。 |
||||||||||
HRESULT CSimpleMsgBoxClassFactory::QueryInterface( REFIID riid, void** ppv ) { HRESULT hrRet = S_OK; //检查指针ppv是不是void*类型 if ( IsBadWritePtr ( ppv, sizeof(void*) )) return E_POINTER; //标准的QI初始化,将赋值为NULL. *ppv = NULL; 接下来检查riid,看看它是不是类工厂实现的接口之一:IUnknown 或 IclassFactory。 // 如果客户端请求一个有效接口,则扶植给 *ppv. if ( InlineIsEqualGUID ( riid, IID_IUnknown )) { *ppv = (IUnknown*) this; } else if ( InlineIsEqualGUID ( riid, IID_IClassFactory )) { *ppv = (IClassFactory*) this; } else { hrRet = E_NOINTERFACE; } 最后,如果riid是有效接口,则调用接口的AddRef(),然后返回。 //如果返回有效接口指针,则调用AddRef() if ( S_OK == hrRet ) { ((IUnknown*) *ppv)->AddRef(); } return hrRet; } |
||||||||||
ISimpleMsgBox实现 最后的也是必不可少的一关是ISimpleMsgBox实现,我们的代码只实现ISimpleMsgBox的方法DoSimpleMsgBox()。首先用微软的扩展类_bstr_t将bsMessageText转换成TCHAR串。 |
||||||||||
HRESULT CSimpleMsgBoxImpl::DoSimpleMsgBox ( HWND hwndParent, BSTR bsMessageText ) { _bstr_t bsMsg = bsMessageText; LPCTSTR szMsg = (TCHAR*) bsMsg; // 如果需要的话,用_bstr_t将串转换为ANSI 做完转换的工作后,显示信息框,然后返回。 MessageBox ( hwndParent, szMsg, _T("Simple Message Box"), MB_OK ); return S_OK; } |
||||||||||
使用服务器的客户端 我们已经完成了一个超级棒的COM服务器,如何使用它呢? 我们的接口一个定制接口,也就是说它只能被C或C++客户端使用。(如果在组件对象类中同时实现IDispatch接口,那我们几乎就可以在任何客户端环境中——Visual Basic,Windows Scripting Host,Web页面,PerlScript等使用COM对象。有关这方面的内容我们留待另外的文章讨论)。本文提供了一个使用ISimpleMsgBox的例子程序。这个程序基于用Win32应用程序向导建立的Hello World例子。文件菜单包含两个测试服务器的命令: 如图所示: |
||||||||||
Test MsgBox COM Server菜单命令创建CSimpleMsgBoxImpl对象并调用DoSimpleMsgBox()。因为这 是个简单的方法,要写的代码不长。 我们先用CoCreateInstance()创建一个COM对象。 void DoMsgBoxTest(HWND hMainWnd) { ISimpleMsgBox* pIMsgBox; HRESULT hr; hr = CoCreateInstance ( __uuidof(CSimpleMsgBoxImpl), // 组件对象类的CLSID NULL, // 非聚合 CLSCTX_INPROC_SERVER, // 只使用进程内服务器 __uuidof(ISimpleMsgBox), // 所请求接口的IID (void**) &pIMsgBox ); // 容纳接口指针的缓冲 if ( FAILED(hr) ) return; 然后调用DoSimpleMsgBox()方法并释放接口。 pIMsgBox->DoSimpleMsgBox ( hMainWnd, _bstr_t("Hello COM!") ); pIMsgBox->Release(); } |
||||||||||
就这么简单。代码中从头到尾都有TRACE语句,这样在调试器中运行测试程序就可以看到服务器的每一个方法 是如何被调用的。 另外一个菜单命令是调用CoFreeUnusedLibraries()函数,从中你能看到服务器DllCanUnloadNow()函数的运行。 其它细节-COM宏 COM代码中有些宏隐藏了实现细节,并允许在C和C++客户端使用相同的声明。本文中没有使用宏,但在例子代 码中用到了这些宏,所以必须掌握它们的用法。下面是ISimpleMsgBox的声明 |
||||||||||
struct ISimpleMsgBox : public IUnknown { // IUnknown 方法 STDMETHOD_(ULONG, AddRef)() PURE; STDMETHOD_(ULONG, Release)() PURE; STDMETHOD(QueryInterface)(REFIID riid, void** ppv) PURE; // ISimpleMsgBox 方法 STDMETHOD(DoSimpleMsgBox)(HWND hwndParent, BSTR bsMessageText) PURE; }; STDMETHOD()包含virtual关键字,返回类型和调用规范。STDMETHOD_()也一样,除非你指定不 同的返回类型。PURE扩展了C++的“=0”,使此函数成为一个纯虚拟函数。 STDMETHOD()和STDMETHOD_()有对应的宏用于方法实现——STDMETHODIMP和STDMETHODIMP_()。 例如DoSimpleMsgBox()的实现: STDMETHODIMP CSimpleMsgBoxImpl::DoSimpleMsgBox ( HWND hwndParent, BSTR bsMessageText ) { ... } 最后,标准的输出函数用STDAPI宏声明,如: STDAPI DllRegisterServer() STDAPI包括返回类型和调用规范。要注意STDAPI不能和__declspec(dllexport)一起使用, 因为STDAPI的扩展。输出必须使用.DEF文件。 |
||||||||||
服务器注册以及反注册 前面讲过服务器实现了DllRegisterServer()和DllUnregisterServer()两个函数。它们的工作是创建和 删除关于COM服务器的注册表入口。其代码都是对注册表的处理,所以在此不必赘言,只是列出DllRegisterServer()创建的注册表入口: |
||||||||||
|
||||||||||
关于例子代码的注释 本文的例子代码在一个WORKSPACE(工作间)文件中(SimpleComSvr.dsw)同时包含了服务器的源代码和测试服 务器所用的客户端源代码。在VC的IDE环境中可以同时加载它们进行处理。在工作间的同级层次有两个工程都要 用到的头文件,但每个工程都有自己的子目录。 同级的公共头文件是: ISimpleMsgBox.h——定义ISimpleMsgBox的头文件。 SimpleMsgBoxComDef.h——包含__declspec(uuid())的声明。这些声明都在单独的文件中,因为客户 端需要CSimpleMsgBoxImpl的GUID,不是它的定义。将GUID移到单独的文件中,使客户端在存取GUID时不依赖 CSimpleMsgBoxImpl的内部结构。它是接口,ISimpleMsgBox,对客户端很重要。 正如前面所说的,必须用.DEF文件来从服务器输出四个标准的输出函数。下面是例子工程的.DEF文件: |
||||||||||
EXPORTS DllRegisterServer PRIVATE DllUnregisterServer PRIVATE DllGetClassObject PRIVATE DllCanUnloadNow PRIVATE |
||||||||||
每一行都包含函数名和PRIVATE关键字。这个关键字的意思是:此函数是输出函数,但不包含在输入库(import lib)中。也就是说客户端不能直接从代码中调用这个函数,即使是链接了输入库也不行。这个关键字时必须要用的,否则链接器会出错。 在服务器中设置断点链 如果你想在服务器代码中设置断点,有两种方法:第一种是将服务器工程(MsgBoxSvr)设置为活动工程,然后开始调试。MSVC将问你调试会话要运行的可执行程序。输入客户端测试程序的全路径,你必须事先建立好。第二种方法是将客户端工程(TestClient)设置为活动工程,配置工程的从属(dependencies)属性,以便服务器工程从属于客户端工程。这样如果你改变了服务器的代码,那么在编译客户端工程时会自动重新编译服务器工程代码。最后还要做的是当你开始调试客户端时必须告诉MSVC加载服务器符号(symbols)。 下面是设置工程属性的对话框:Project->Dependencies菜单 |
||||||||||
为了加载服务器符号,打开TestClient的工程设置(Project->Settings菜单),选择Debug标签,并在Category组合框中选择Additional DLLs。在列表框中单击New一个入口,然后输入服务器DLL的全路径名。如下图所示: | ||||||||||
这样设置以后,根据实际源代码的所在位置,DLL的路径将会做自动调整。 |
COM程序的简单实现(COM技术内幕笔记之一)
这是今天在读《COM技术内幕》这本书时模拟COM而写的一段代码,包括了基本的接口(IX,IY), 组件的实现(CA),以及对组件的调用。 这段代码知识点涵盖了此书的前四章,还没有实现的是,把组件,接口放到动态链接库去实现。这本书的第五章就讲到了动态链接库库对COM组件的封装。先在此把前面的代码总结,并保存下来。

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

上一篇文章里,在一个CPP文件中实现了组件IX,IY,及组件CA,以及在客户端对接口的查询,但其还不是一个COM,COM的许多特性还没有被展现出来.比如,用动态链接库实现,没有这个我就不能根据需要随意的加载和卸载组件,组件无法复用等功能。
以下这篇笔记将详细的介绍如何用动态链接库去实现COM组件。
首先,我们先完成我们所需的接口的创建工作,这样,COM组件就会根据其接口实现之。
定义IFACE.H,这个头文件要被DLL及客户端EXE共享。












































可以看到,我们定义了三个接口,分别为IX,IY,IZ.
下面我们实现组件。新建一个DLL项目,项目名为CMNPT,在VC创建过程中默认为空dll项目.
然后,添加头文件libport.h,和源文件libport.cpp.
在libport.h中,定义了该dll的输出函数:





























































































到时,一个DLL定义就完成了,下面就要实现客户端对组件的调用.
新建一项目,名为Client.在这个项目下建立Create.h与Create.cpp文件.分别如下:

可以看到CreateInstance是调用了LoadLibaray来调用组件的DLL,然后,获得CreateInstance函数的地址,调用后得到IUnknown的指针.
下面的步骤是在main函数中调用CallCreateInstance函数,获得IUnknown指针,查询接口,调用组件的实现...
















































通过以上步骤,一个用动态链接库实现的DLL就作出来了,但其还有许多瑕疵,比如需要知道组件的dll名称及dll的存放位置,需要显式的调用GetProcAddress函数以获得组件的CreateInstance函数地址。
有没有一种方式,不需要知道组件的dll名,也不用知道该dll在磁盘的什么地方,都可以调用到这个dll,然后加载,获得接口?这个方法在下一节中会详述。
COM中的HRESULT, CLISD,ProgID, DLL注册,COM库函数的知识(COM技术内幕笔记之三)
1.COM中的HRESULT:
COM函数中返回值一般是HRESULT类型,这是因为COM是一套二进制标准,而并不是针对某个语言的,所以,定义了一个所有语言都认可的HRESULT类型。
HRESULT占32位,可以分成三个部分,0~15为返回代码16~30为设备代码,31为重要程度.
常用的HRESULT的值有:S_OK, NOERROR,S_FALSE,E_UNEXPECTED,E_NOIMPLE,E_NOINTERFACE等.
关于它们的定义,可以见winerror.h头文件.
如果HRESULT返回出现异常了,我们可以打印出hr的值,如cout<<hr<<endl;然后根据这个16位进制的值在winerror.h中找到相应的宏定义.
一个函数在各种情况下返回的状态代码通常包含多个成功代码及多个失败代码,这就是我们为什么要用SUCCEEDED及FAILED宏的原因.一般不能直接将HRESULT值同某个成功代码(如S_OK)进行比较以决定函数是否成功.
2.COM中的GUID:
GUID(IID)是一个128比特(16进制)的一个结构.其名是全局唯一标识符.定义GUID是为了避免COM接口标识的重复定义.
可以用VC++ tools目录下自带的GUIDGEN生成IID结构.如:



GUID的比较:其实在objbase.h中已经实现了guid的比较,直接用==操作符就可以进行两个guid之间的比较.如果不喜欢用操作符,则可以使用IsEqualGUID,ISEqualIID,IsEqualCLSID函数进行比较.
除了用GUID来唯一标识接口外,还用GUID来唯一的标识组件.同接口一样,所有的组件都有一个不同的ID,两个组件可以实现相同的接口集,但每一个组件必须具有各不相同的CLSID.
由于GUID结构较大,所以一般不用值传递GUID参数,而用引用传递.这就是为什么QueryInterface接收一个常量引用参数的原因.如果不想输出const IID&,则可以用REFIID类型代替.
3.组件在注册表中的结构:
在注册表中保存了组件的详细信息,其中HKEY_CLASSES_ROOT\CLSID保存了每个注册组件的GUID值.在这个GUID值下面有一个子关键字:InprocServer32,保存了DLL的文件名称及保存位置.还有个子关键字ProgID,保存组件的CLSID指定的一个易记名称.在VB中,将用ProgID而不是CLSID来标识组件.
另外,ProgID不止保存在HKEY_CLASSES_ROOT\CLSID的子关键字中,也另存一份保存在HKEY_CLASSES_ROOT的子关键字中.为什么呢?因为ProgID的主要作用是获得相应的CLSID,在每一个CLSID项中查找某个ProgID是非常低效的,所以在HKEY_CLASSES_ROOT下面直接列出ProgID.这样,根据ProgID来查找其CLSID将非常方便.
注意,用ProgID标识组件不能保证ProgID是唯一的.名字冲突会是一个潜在的问题.但因其处理比较容易,所以经常用它.
用ProgID有如下约定:
<Program>.<Component>.<Version>
例如:Visio.Application.3 Office.Binder.95
4.ProgID和CLSID之间的转换 / CLSID和字符串的转换:
有两个函数,可以在两者之间转换:CLSIDFromProgID / ProgIDFromCLSID,如:
CLSID clsid;
CLSIDFromProgID(L"Helicopter.TailRotor",&clsid);
CLSID和字符串的转换在COM库函数中实现,具体的函数有:
StringFromCLSID / StringFromIID / StringFromGUID2 / CLSIDFromString / IIDFromString
5.Dll的注册.
如果想注册DLL(用RegSvr32 -s命令注册),必须在DLL中输出以下两个函数:
STDAPI DllRegisterServer();和 STDAPI DllUnregisterServer();
regsvr32.exe命令就是通过调用dll函数中的这两个函数来完成组件的注册的.
6.COM库函数
所以的COM组件和客户都需要完成一些相同的操作,为保证这些操作是按标准并且兼容的方法完成的,COM定义了一个函数库以实现所有的这些操作
此函数库是在OLE32.DLL中实现的.
COM库的初始化:在使用COM库的函数之前,进程必须先调用CoInitialize来初始化COM库函数.当进程不再需要使用COM库函数中,必须调用CoUninitialize.
函数原型定义如下:
HRESULT CoInitialize(void* reserved);
void CoUninitialize();
对每一个进程,COM库函数只需初始化一次.由于COM库是用于创建组件的,因此进程中组件无需初始化COM库.COM库初始化一般只是在EXE中进行,而在DLL中则无需进行.
7.在组件中如果分配内存,在客户中怎么释放?
在组件中分配一块内存,然后将其通过一个输出参数传递给客户是一种非常常见的方式,但带来一个问题是:谁来释放它?如何释放?COM库实现了一个方便的函数,如CoTaskMemAlloc和CoTaskMemFree.用来释放组件中分配的内存:
如:




COM组件的类厂(COM技术内幕笔记之四)
在上一篇中,介绍了怎么样用动态链接库去实现COM,但组件对我们来说仍是不透明的,我们需要知道实现组件DLL的位置,必须自己来加载组件的CreateInstance函数来获得组件的指针.在书中第一篇就曾经提到过:COM组件可以透明地在网络上(或本地)被重新分配位置,而不会影响本地客户程序.所以,由客户端来调用DLL并不是什么好主意.必须有一种更好的办法让组件的实现更透明,更灵活!
于是,就引入了类厂的概念.什么是类厂,类厂也是一个接口,它的职责是帮我们创造组件的对象.并返回给客户程序一个接口的指针.每个组件都必须有一个与之相关的类厂,这个类厂知道怎么样创建组件.当客户请求一个组件对象的实例时,实际上这个请求交给了类厂,由类厂创建组件实例,然后把实例指针交给客户程序。这么说有点难明白.先看一个伪实例.
1.实现二个接口IX,IY (上二节中有详细介绍)
2.实现一个组件CA,实现了IX,IY接口. (上二节中有详细介绍)
3.对于这个组件进行注册,把组件的信息加入到注册表中.
实现DllRegisterServer和DllUnregisterServer函数.函数具体功能就是把本组件的CLSID,ProgID,DLL的位置放入注册表中.这样程序就可以通过查询注册表来获得组件的位置.
4.创建本组件类厂的实例
class CFactory:public IClassFactory
{
virtual HRESULT __stdcall QueryInterface(const IID& iid,void** ppv);
virtual ULONG __stdcall AddRef();
virtual ULONG __stdcall Release();
virtual HRESULT __stdcall CreateInstance(IUnknown* pUnknownOuter,
const IID& iid,
void** ppv);
}
在类厂实例中,主要的功能就是CreateInstance了,这个函数就是创建组件的相应实例.看它的实现:
HRESULT __stdcall CFactory::CreateInstance(IUnknown* pUnknownOuter,const IID& iid,void** ppv)
{
//...
CA* pA = new CA;
if(pA == NULL)
return E_OUTOFMEMORY;
HRESULT hr = pA->QueryInterface(iid,ppv);
pA->Release();
return hr;
}
5.在这个组件的DLL中导出DllGetClassObject函数.这个函数的功能就是创建类厂的实例对象并查询接口.看其实现:
STDAPI DllGetClassObject(const CLSID& clsid,
const IID& iid,
void** ppv)
{
//....
CFactory* pFactory = new CFactory();
if(pFactory == NULL)
return E_OUTOFMEMORY;
HRESULT hr = pFactory->QueryInterface(iid,ppv);
pFactory->Release();
return hr;
}
组件的实现差不多就这么多,下面在客户端怎么调用组件呢?这就需要用到COM函数库了,由COM函数库去查找注册表,调用组件的类厂,创建组件实例,返回接口.如下所示:
IUnknown* pUnk = NULL;
IX* iX = NULL;
CoInitialize(NULL);
CoCreateInstance(CLSID_Component1,CLSCTX_INPROC_SERVER,IID_IUnknown,(void**)&pUnk);
pUnk->QueryInterface(IID_IX,(void**)&iX);
pUnk->Release();
iX->Fx();
iX->Release();
CoUninitialize();
至于客户是通过CoCreateInstance怎么获得组件的类厂,创建组件实例的.下面摘录的一篇文章很清晰的说明了这一切:
-------------------------------------------------------------------------------------
这部分我们将构造一个创建COM组件的最小框架结构,然后看一看其内部处理流程是怎样的
COM组件的运行机制,即COM是怎么跑起来的。
IUnknown *pUnk=NULL;
IObject *pObject=NULL;
CoInitialize(NULL);
CoCreateInstance(CLSID_Object, CLSCTX_INPROC_SERVER, NULL, IID_IUnknown, (void**)&pUnk);
pUnk->QueryInterface(IID_IOjbect, (void**)&pObject);
pUnk->Release();
pObject->Func();
pObject->Release();
CoUninitialize();
CoCreateInstance身上,让我们来看看它内部做了一些什么事情。以下是它内部实现的一个伪代码:
CoCreateInstance(....)
{
.......
IClassFactory *pClassFactory=NULL;
CoGetClassObject(CLSID_Object, CLSCTX_INPROC_SERVER, NULL, IID_IClassFactory, (void **)&pClassFactory);
pClassFactory->CreateInstance(NULL, IID_IUnknown, (void**)&pUnk);
pClassFactory->Release();
........
}
这段话的意思就是先得到类厂对象,再通过类厂创建组件从而得到IUnknown指针。
继续深入一步,看看CoGetClassObject的内部伪码:
CoGetClassObject(.....)
{
//通过查注册表CLSID_Object,得知组件DLL的位置、文件名
//装入DLL库
//使用函数GetProcAddress(...)得到DLL库中函数DllGetClassObject的函数指针。
//调用DllGetClassObject
}
DllGetClassObject是干什么的,它是用来获得类厂对象的。只有先得到类厂才能去创建组件.
下面是DllGetClassObject的伪码:
{
......
CFactory* pFactory= new CFactory; //类厂对象
pFactory->QueryInterface(IID_IClassFactory, (void**)&pClassFactory);
//查询IClassFactory指针
pFactory->Release();
......
}
CoGetClassObject的流程已经到此为止,现在返回CoCreateInstance,看看CreateInstance的伪码:
CFactory::CreateInstance(.....)
{
...........
CObject *pObject = new CObject; //组件对象
pObject->QueryInterface(IID_IUnknown, (void**)&pUnk);
pObject->Release();
...........
}
Component实现:(FacInterFace.dll)






















































组件的注册:











































































































































































































组件的实现:


















































































































































































































































































以上是组件的实现。下面是客户端的代码实现:













































再在最后详述一篇,客户端调用CoCreateInstance,导致调用CoGetClassObject,CoGetClassObject通过查找注册表,得知DLL位置,文件名,然后调用DLL中DllGetClassObject,
DllGetClassObject的功能是返回CFactory的实例.
返回后,回到CoCreateInstance,通过CFactory的指针,调用
pClassFactory->CreaetInstance()创建组件实例.
这样就返回了组件实例的指针.
CoCreateInstace --> CoGetClassObject --> DllGetClassObject --> Get CFactory*
<-------------------------------------------------------
--> CFactory->CreateInstance(); --> Get IX*
IX->Fx();
包容和聚合(COM技术内幕笔记五)
包容和聚合:
包容和聚合实际上是使一个组件使用另外一个组件的一种技术。在包容的情况下,外部组件将包含内部组件。在聚合的情况下,外部组件聚合内部组件。
在此设想一下,外部组件是我们的要实现的组件,而内部组件是其它要重用的组件。
包容是外部组件包含指向内部组件接口的指针.外部组件相对来说是内部组件的一个客户,它将使用内部组件的接口来实现它自己的接口.
聚合是包容的一个特例,当一个外部组件聚合了某个内部组件的一个接口时,它并没有像包容那样重新实现此接口并明确地将调用请求转发给内部组件。相反,外部组件将直接把内部件的接口指针返回给客户。
如何使用包容:
在前一节,建立了一个组件CA,其实现了IX,IY接口。在这一节,暂时把其看作是一内部组件。我们要使用其对IY接口的函数实现
新建一个DLL项目,新建一接口IX,新建一个组件的CLSID。另外,导入CA项目IFACE.h中的IY接口IID和CA组件的CLSID。如下所示:


















在组件CB实现的时候,添加一成员变量:
private:
IY* m_pIY;
对IY接口的Fy函数的实现,与组件CA不同:
Virtual void __stdcall CB::Fy()
{
m_pIY->Fy();
}
对组件CB新增一成员函数 HRESULT Init();


















至于CB的其它实现和CA相同,暂不累叙,如有不清楚的概念请看前一节。
在组件CB的CFactory::CreateInstance函数中加入对Init 函数的调用:

















在此,就实现了组件CB对组件CA的包容。CB没有自己去实现基类IY的Fy()函数,而是把这个任务交给了组件CA对于Fy()函数的实现。一切的一切都是通过组件CB中的Init函数。通过CoCreateInstance查询组件CA的IY接口。然后返回IY指针,赋给CB的私有成员m_pIY。
通过对于m_pIY的包容,实现了组件的复用。
至于组件的聚合,下一节再叙。