Introduction to COM - What It Is and How to Use It.

 

Purpose of this Article

I have written this tutorial for programmers who are just starting out in COM and need some help in understanding the basics. The article briefly covers the COM specification, and then explains some COM terminology and describes how to reuse existing COM components. This article does not cover writing your own COM objects or interfaces.

Updates:

July 22, 2000: Added a couple of more paragraphs about using Release() and unloading DLLs. Also added the section on HRESULTs.

Introduction

COM (Component Object Model) is the popular TLA (three-letter acronym) that seems to be everywhere in the Windows world these days. There are tons of new technologies coming out all the time, all based on COM. The documentation throws around lots of terms like COM object, interface, server, and so on, but it all assumes you're familiar with how COM works and how to use it.

This article introduces COM from the beginning, describes the underlying mechanisms involved, and shows how to use COM objects provided by others (specifically, the Windows shell). By the end of the article, you will be able to use the COM objects built-in to Windows and provided by third parties.

This article assumes you are proficient in C++. I use a little bit of MFC and ATL in the sample code, but I will explain the code thoroughly, so you should be able to follow along if you are not familiar with MFC or ATL. The sections in this article are:

COM - What Exactly Is It? - A quick introduction to the COM standard, and the problems it was created to solve. You don't need to know this to use COM, but I'd still recommend reading it to get an understanding of why things are done the way they are in COM.

Definitions of the Basic Elements - COM terminology and descriptions of what those terms represent.

Working with COM Objects - An overview of how to create, use, and destroy COM objects.

The Base Interface - IUnknown - A description of the methods in the base interface, IUnknown.

Pay Close Attention - String Handling - How to handle strings in COM code.

Bringing it All Together - Sample Code - Two sets of sample code that illustrate all the concepts discussed in the article.

Handling HRESULTs - A description of the HRESULT type and how to test for error and success codes.

References - Books you should expense if your employer will let you. :)

COM - What exactly is it?

COM is, simply put, a method for sharing binary code across different applications and languages. This is unlike the C++ approach, which promotes reuse of source code. ATL is a perfect example of this. While source-level reuse works fine, it only works for C++. It also introduces the possibility of name collisions, not to mention bloat from having multiple copies of the code in your projects.

Windows lets you share code at the binary level using DLLs. After all, that's how Windows apps function - reusing kernel32.dll, user32.dll, etc. But since the DLLs are written to a C interface, they can only be used by C or languages that understand the C calling convention. This puts the burden of sharing on the programming language implementer, instead of on the DLL itself.

MFC introduced another binary sharing mechanism with MFC extension DLLs. But these are even more restrictive - you can only use them from an MFC app.

COM solves all these problems by defining a binary standard, meaning that COM specifies that the binary modules (the DLLs and EXEs) must be compiled to match a specific structure. The standard also specifies exactly how COM objects must be organized in memory. The binaries must also not depend on any feature of any programming language (such as name decoration in C++). Once that's done, the modules can be accessed easily from any programming language. A binary standard puts the burden of compatibility on the compiler that produces the binaries, which makes it much easier for the folks who come along later and need to use those binaries.

The structure of COM objects in memory just happens to use the same structure that is used by C++ virtual functions, so that's why a lot of COM code uses C++. But remember, the language that the module is written in is irrelevant, because the resulting binary is usable by all languages.

Incidentally, COM is not Win32-specific. It could, in theory, be ported to Unix or any other OS. However, I have never seem COM mentioned outside of the Windows world.

Definitions of the Basic Elements

Let's go from the bottom up. An interface is simply a group of functions. Those functions are called methods. Interface names start with I, for exampleIShellLink. In C++, an interface is written as an abstract base class that has only pure virtual functions.

Interfaces may inherit from other interfaces. Inheritance works just like single inheritance in C++. Multiple inheritance is not allowed with interfaces.

A coclass (short for component object class) is contained in a DLL or EXE, and contains the code behind one or more interfaces. The coclass is said toimplement those interfaces. A COM object is an instance of a coclass in memory. Note that a COM "class" is not the same as a C++ "class", although it is often the case that the implementation of a COM class is a C++ class.

A COM server is a binary (DLL or EXE) that contains on or more coclasses.

Registration is the process of creating registry entries that tell Windows where a COM server is located. Unregistration is the opposite - removing those registry entries.

A GUID (rhymes with "fluid", stands for globally unique identifier) is a 128-bit number. GUIDs are COM's language-independent way of identifying things. Each interface and coclass has a GUID. Since GUIDs are unique throughout the world, name collisions are avoided (as long as you use the COM API to create them). You will also see the term UUID (which stands for universally unique identifier) at times. UUIDs and GUIDs are, for all practical purposes, the same.

A class ID, or CLSID, is a GUID that names a coclass. An interface ID, or IID, is a GUID that names an interface.

There are two reasons GUIDs are used so extensively in COM:

1. GUIDs are just numbers under the hood, and any programming language can handle them.
2. Every GUID created, by anyone on any machine, is unique when created properly. Therefore, COM developers can create GUIDs on their own with no chance of two developers choosing the same GUID. This eliminates the need for a central authority to issue GUIDs.

An HRESULT is an integral type used by COM to return error and success codes. It is not a "handle" to anything, despite the H prefix. I'll have more to say about HRESULTs and how to test them later on.

Finally, the COM library is the part of the OS that you interact with when doing COM-related stuff. Often, the COM library is referred to as just "COM," but I will not do that here, to avoid confusion.

Working with COM Objects

Every language has its own way of dealing with objects. For example, in C++ you create them on the stack, or use new to dynamically allocate them. Since COM must be language-neutral, the COM library provides its own object-management routines. A comparison of COM and C++ object management is listed below:

Creating a new object

• In C++, use operator new or create an object on the stack.
• In COM, call an API in the COM library.

Deleting objects

• In C++, use operator delete or let a stack object go out of scope.
• In COM, all objects keep their own reference counts. The caller must tell the object when the caller is done using the object. COM objects free themselves from memory when the reference count reaches 0.

Now, in between those two stages of creating and destroying the object, you actually have to use it. When you create a COM object, you tell the COM library what interface you need. If the object is created successfully, the COM library returns a pointer to the requested interface. You can then call methods through that pointer, just as if it were a pointer to a regular C++ object.

Creating a COM object

To create a COM object and get an interface from the object, you call the COM library API CoCreateInstance(). The prototype forCoCreateInstance() is:

HRESULT CoCreateInstance (
    REFCLSID  rclsid,
    LPUNKNOWN pUnkOuter,
    DWORD     dwClsContext,
    REFIID    riid,
    LPVOID*   ppv );

The parameters are:

rclsid

The CLSID of the coclass. For example, you can pass  CLSID_ShellLink to create a COM object used to create shortcuts.

pUnkOuter

This is only used when aggregating COM objects, which is a way of taking an existing coclass and adding new methods to it. For our purposes, we can just pass NULL to indicate we're not using aggregation.

dwClsContext

Indicates what kind of COM servers we want to use. For this article, we will always be using the simplest kind of server, an in-process DLL, so we'll pass  CLSCTX_INPROC_SERVER. One caveat: you should not use  CLSCTX_ALL (which is the default in ATL) because it will fail on Windows 95 systems that do not have DCOM installed.

riid

The IID of the interface you want returned. For example, you can pass  IID_IShellLink to get a pointer to an  IShellLink interface.

ppv

Address of an interface pointer. The COM library returns the requested interface through this parameter.

When you call CoCreateInstance(), it handles looking up the CLSID in the registry, reading the location of the server, loading the server into memory, and creating an instance of the coclass you requested.

Here's a sample call, which instantiates a CLSID_ShellLink object and requests an IShellLink interface pointer to that COM object.

HRESULT     hr;
IShellLink* pISL;

hr = CoCreateInstance ( CLSID_ShellLink,         // CLSID of coclass

                        NULL,                    // not used - aggregation

                        CLSCTX_INPROC_SERVER,    // type of server

                        IID_IShellLink,          // IID of interface

                        (void**) &pISL );        // Pointer to our interface pointer


    if ( SUCCEEDED ( hr ) )
        {
        // Call methods using pISL here.

        }
    else
        {
        // Couldn't create the COM object.  hr holds the error code.

        }

First we declare an HRESULT to hold the return from CoCreateInstance() and an IShellLink pointer. We call CoCreateInstance() to create a new COM object. The SUCCEEDED macro returns TRUE if hr holds a code indicating success, or FALSE if hr indicates failure. There is a corresponding macro FAILED that tests for a failure code.

Deleting a COM object

As stated before, you don't free COM objects, you just tell them that you're done using them. The IUnknown interface, which every COM object implements, has a method Release(). You call this method to tell the COM object that you no longer need it. Once you call Release(), you must not use the interface pointer any more, since the COM object may disappear from memory at any time.

If your app uses a lot of different COM objects, it's vitally important to call Release() whenever you're done using an interface. If you don't release interfaces, the COM objects (and the DLLs that contain the code) will remain in memory, and will needlessly add to your app's working set. If your app will be running for a long time, you should call the CoFreeUnusedLibraries() API during your idle processing. This API unloads any COM servers that have no outstanding references, so this also reduces your app's memory usage.

Continuing the above example, here's how you would use Release():

    // Create COM object as above.  Then...


    if ( SUCCEEDED ( hr ) )
        {
        // Call methods using pISL here.


        // Tell the COM object that we're done with it.

        pISL->Release();
        }

The IUnknown interface is explained fully in the next section.

The Base Interface - IUnknown

Every COM interface is derived from IUnknown. The name is a bit misleading, in that it's not an unknown interface. The name signifies that if you have an IUnknown pointer to a COM object, you don't know what the underlying object is, since every COM object implements IUnknown.

IUnknown has three methods:

1. AddRef() - Tells the COM object to increment its reference count. You would use this method if you made a copy of an interface pointer, and both the original and the copy would still be used. We won't need to use AddRef() for our purposes in this article.
2. Release() - Tells the COM object to decrement its reference count. See the previous example for a code snippet demonstrating Release().
3. QueryInterface() - Requests an interface pointer from a COM object. You use this when a coclass implements more than one interface.

We've already seen Release() in action, but what about QueryInterface()? When you create a COM object with CoCreateInstance(), you get an interface pointer back. If the COM object implements more than one interface (not counting IUnknown), you use QueryInterface() to get any additional interface pointers that you need. The prototype of QueryInterface() is:

HRESULT IUnknown::QueryInterface (
    REFIID iid,
    void** ppv );

The parameters are:

iid

The IID of the interface you're requesting.

ppv

Address of an interface pointer.  QueryInterface() returns the interface through this parameter if it is successful.

Let's continue our shell link example. The coclass for making shell links implements IShellLink and IPersistFile. If you already have anIShellLink pointer, pISL, you can request an IPersistFile interface from the COM object with code like this:

HRESULT hr;
IPersistFile* pIPF;

    hr = pISL->QueryInterface ( IID_IPersistFile, (void**) &pIPF );

You then test hr with the SUCCEEDED macro to determine if QueryInterface() worked. If it succeeded, you can then use the new interface pointer, pIPF, just like any other interface. You must also call pIPF->Release() to tell the COM object that you're done using the interface.

Pay Close Attention - String Handling

I need to make a detour for a few moments, and discuss how to handle strings in COM code. If you are familiar with how Unicode and ANSI strings work, and know how to convert between the two, then you can skip this section. Otherwise, read on.

Whenever a COM method returns a string, that string will be in Unicode. (Well, all methods that are written to the COM spec, that is!) Unicode is a character encoding scheme, like ASCII, only all characters are 2 bytes long. If you want to get the string into a more manageable state, you should convert it to a TCHAR string.

TCHAR and the _t functions (for example, _tcscpy()) are designed to let you handle Unicode and ANSI strings with the same source code. In most cases, you'll be writing code that uses ANSI strings and the ANSI Windows APIs, so for the rest of this article, I will refer to chars instead of TCHARs, just for simplicity. You should definitely read up on the TCHAR types, though, to be aware of them in case you ever come across them in code written by others.

When you get a Unicode string back from a COM method, you can convert it to a char string in one of several ways:

1. Call the WideCharToMultiByte() API.
2. Call the CRT function wcstombs().
3. Use the CString constructor or assignment operator (MFC only).
4. Use an ATL string conversion macro.

WideCharToMultiByte()

You can convert a Unicode string to an ANSI string with the WideCharToMultiByte() API. This API's prototype is:

int WideCharToMultiByte (
    UINT    CodePage,
    DWORD   dwFlags,
    LPCWSTR lpWideCharStr,
    int     cchWideChar,
    LPSTR   lpMultiByteStr,
    int     cbMultiByte,
    LPCSTR  lpDefaultChar,
    LPBOOL  lpUsedDefaultChar );

The parameters are:

CodePage

The code page to convert the Unicode characters into. You can pass  CP_ACP to use the current ANSI code page. Code pages are sets of 256 characters. Characters 0-127 are always identical to the ASCII encoding. Characters 128-255 differ, and can contain graphics or letters with diacritics. Each language or region has its own code page, so it's important to use the right code page to get proper display of accented characters.

dwFlags

dwFlags determine how Windows deals with "composite" Unicode characters, which are a letter followed by a diacritic. An example of a composite character is  è. If this character is in the code page specified in  CodePage, then nothing special happens. However, if it is  not in the code page, Windows has to convert it to something else.
Passing  WC_COMPOSITECHECK makes the API check for non-mapping composite characters. Passing  WC_SEPCHARS makes Windows break the character into two, the letter followed by the diacritic, for example  e`. Passing  WC_DISCARDNS makes Windows discard the diacritics. Passing WC_DEFAULTCHAR makes Windows replace the composite characters with a "default" character, specified in the  lpDefaultChar parameter. The default behavior is  WC_SEPCHARS.

lpWideCharStr

The Unicode string to convert.

cchWideChar

The length of  lpWideCharStr in Unicode characters. You will usually pass -1, which indicates that the string is zero-terminated.

lpMultiByteStr

A  char buffer that will hold the converted string.

cbMultiByte

The size of  lpMultiByteStr, in bytes.

lpDefaultChar

Optional - a one-character ANSI string that contains the "default" character to be inserted when  dwFlags contains  WC_COMPOSITECHECK | WC_DEFAULTCHAR and a Unicode character cannot be mapped to an equivalent ANSI character. You can pass NULL to have the API use a system default character (which as of this writing is a question mark).

lpUsedDefaultChar

Optional - a pointer to a  BOOL that will be set to indicate if the default char was ever inserted into the ANSI string. You can pass NULL if you don't care about this information.

Whew, a lot of boring details! Like always, the docs make it seem much more complicated than it really is. Here's an example showing how to use the API:

// Assuming we already have a Unicode string wszSomeString...

char szANSIString [MAX_PATH];

    WideCharToMultiByte ( CP_ACP,                // ANSI code page

                          WC_COMPOSITECHECK,     // Check for accented characters

                          wszSomeString,         // Source Unicode string

                          -1,                    // -1 means string is zero-terminated

                          szANSIString,          // Destination char string

                          sizeof(szANSIString),  // Size of buffer

                          NULL,                  // No default character

                          NULL );                // Don't care about this flag

After this call, szANSIString will contain the ANSI version of the Unicode string.

wcstombs()

The CRT function wcstombs() is a bit simpler, but it just ends up calling WideCharToMultiByte(), so in the end the results are the same. The prototype for wcstombs() is:

size_t wcstombs (
    char*          mbstr,
    const wchar_t* wcstr,
    size_t         count );

The parameters are:

mbstr

A  char buffer to hold the resulting ANSI string.

wcstr

The Unicode string to convert.

count

The size of the  mbstr buffer, in bytes.

wcstombs() uses the WC_COMPOSITECHECK | WC_SEPCHARS flags in its call to WideCharToMultiByte(). To reuse the earlier example, you can convert a Unicode string with code like this:

    wcstombs ( szANSIString, wszSomeString, sizeof(szANSIString) );

CString

The MFC CString class contains constructors and assignment operators that accept Unicode strings, so you can let CString do the conversion work for you. For example:

// Assuming we already have wszSomeString...


CString str1 ( wszSomeString );    // Convert with a constructor.

CString str2;

    str2 = wszSomeString;          // Convert with an assignment operator.

ATL macros

ATL has a handy set of macros for converting strings. To convert a Unicode string to ANSI, use the W2A() macro (a mnemonic for "wide to ANSI"). Actually, to be more accurate, you should use OLE2A(), where the "OLE" indicates the string came from a COM or OLE source. Anyway, here's an example of how to use these macros.

#include <atlconv.h>


// Again assuming we have wszSomeString...


{
char szANSIString [MAX_PATH];
USES_CONVERSION;  // Declare local variable used by the macros.


    lstrcpy ( szANSIString, OLE2A(wszSomeString) );
}

The OLE2A() macro "returns" a pointer to the converted string, but the converted string is stored in a temporary stack variable, so we need to make our own copy of it with lstrcpy(). Other macros you should look into are W2T() (Unicode to TCHAR), and W2CT() (Unicode string to const TCHARstring).

There is an OLE2CA() macro (Unicode string to a const char string) which we could've used in the code snippet above. OLE2CA() is actually the correct macro for that situation, since the second parameter to lstrcpy() is a const char*, but I didn't want to throw too much at you at once.

Sticking with Unicode

On the other hand, you can just keep the string in Unicode if you won't be doing anything complicated with the string. If you're writing a console app, you can print Unicode strings with the std::wcout global variable, for example:

    wcout << wszSomeString;

But keep in mind that wcout expects all strings to be in Unicode, so if you have any "normal" strings, you'll still need to output them with std::cout. If you have string literals, prefix them with L to make them Unicode, for example:

    wcout << L"The Oracle says..." << endl << wszOracleResponse;

If you keep a string in Unicode, there are a couple of restrictions:

• You must use the wcsXXX() string functions, such as wcslen(), on Unicode strings.
• With very few exceptions, you cannot pass a Unicode string to a Windows API on Windows 9x. To write code that will run on 9x and NT unchanged, you'll need to use the TCHAR types, as described in MSDN.

Bringing it All Together - Sample Code

Following are two examples that illustrate the COM concepts covered in the article. The code is also contained in the article's sample project.

Using a COM object with a single interface

The first example shows how to use a COM object that exposes a single interface. This is the simplest case you'll ever encounter. The code uses the Active Desktop coclass contained in the shell to retrieve the filename of the current wallpaper. You will need to have the Active Desktop installed for this code to work.

The steps involved are:

1. Initialize the COM library.
2. Create a COM object used to interact with the Active Desktop, and get an IActiveDesktop interface.
3. Call the GetWallpaper() method of the COM object.
4. If GetWallpaper() succeeds, print the filename of the wallpaper.
5. Release the interface.
6. Uninitialize the COM library.

 

WCHAR   wszWallpaper [MAX_PATH];
CString strPath;
HRESULT hr;
IActiveDesktop* pIAD;

    // 1. Initialize the COM library (make Windows load the DLLs). Normally you would

    // call this in your InitInstance() or other startup code.  In MFC apps, use

    //  AfxOleInit() instead.

    CoInitialize ( NULL );

    // 2. Create a COM object, using the Active Desktop coclass provided by the shell.

    // The 4th parameter tells COM what interface we want (IActiveDesktop).

    hr = CoCreateInstance ( CLSID_ActiveDesktop,
                            NULL,
                            CLSCTX_INPROC_SERVER,
                            IID_IActiveDesktop,
                            (void**) &pIAD );

    if ( SUCCEEDED(hr) )
        {
        // 3. If the COM object was created, call its GetWallpaper() method.

        hr = pIAD->GetWallpaper ( wszWallpaper, MAX_PATH, 0 );

        if ( SUCCEEDED(hr) )
            {
            // 4. If GetWallpaper() succeeded, print the filename it returned.

            // Note that I'm using wcout to display the Unicode string wszWallpaper.

            // wcout is the Unicode equivalent of cout.

            wcout << L"Wallpaper path is:/n    " << wszWallpaper << endl << endl;
            }
        else
            {
            cout << _T("GetWallpaper() failed.") << endl << endl;
            }

        // 5. Release the interface.

        pIAD->Release();
        }
    else
        {
        cout << _T("CoCreateInstance() failed.") << endl << endl;
        }

    // 6. Uninit the COM library.  In MFC apps, this is not necessary since MFC does

    // it for us.

    CoUninitialize();

In this sample, I used std::wcout to display the Unicode string wszWallpaper.

Using a COM object with a multiple interfaces

The second example shows how to use QueryInterface() with a COM object that exposes a single interface. The code uses the Shell Link coclass contained in the shell to create a shortcut to the wallpaper file that we retrieved in the last example.

The steps involved are:

1. Initialize the COM library.
2. Create a COM object used to create shortcuts, and get an IShellLink interface.
3. Call the SetPath() method of the IShellLink interface.
4. Call QueryInterface() on the COM object and get an IPersistFile interface.
5. Call the Save() method of the IPersistFile interface.
6. Release the interfaces.
7. Uninitialize the COM library.

CString       sWallpaper = wszWallpaper;  // Convert the wallpaper path to ANSI

IShellLink*   pISL;
IPersistFile* pIPF;

    // 1. Initialize the COM library (make Windows load the DLLs). Normally you would

    // call this in your InitInstance() or other startup code.  In MFC apps, use

    // AfxOleInit() instead.

    CoInitialize ( NULL );

    2. Create a COM object, using the Shell Link coclass provided by the shell.
    // The 4th parameter tells COM what interface we want (IShellLink).

    hr = CoCreateInstance ( CLSID_ShellLink,
                            NULL,
                            CLSCTX_INPROC_SERVER,
                            IID_IShellLink,
                            (void**) &pISL );

    if ( SUCCEEDED(hr) )
        {
        // 3. Set the path of the shortcut's target (the wallpaper file).

        hr = pISL->SetPath ( sWallpaper );

        if ( SUCCEEDED(hr) )
            {
            // 4. Get a second interface (IPersistFile) from the COM object.

            hr = pISL->QueryInterface ( IID_IPersistFile, (void**) &pIPF );

            if ( SUCCEEDED(hr) )
                {
                // 5. Call the Save() method to save the shortcut to a file.  The

                // first parameter is a Unicode string.

                hr = pIPF->Save ( L"C://wallpaper.lnk", FALSE );

                // 6a. Release the IPersistFile interface.

                pIPF->Release();
                }
            }

        // 6b. Release the IShellLink interface.

        pISL->Release();
        }

    // Printing of error messages omitted here.


    // 7. Uninit the COM library.  In MFC apps, this is not necessary since MFC

    // does it for us.

    CoUninitialize();

Handling HRESULTs

I've already shown some simple error handling, using the SUCCEEDED and FAILED macros. Now I'll give some more details on what to do with theHRESULTs returned from COM methods.

An HRESULT is a 32-bit signed integer, with nonnegative values indicating success, and negative values indicating failure. An HRESULT has three fields: the severity bit (to indicate success or failure), the facility code, and the status code. The "facility" indicates what component or program theHRESULT is coming from. Microsoft assigns facility codes to the various components, for example COM has one, the Task Scheduler has one, and so on. The "code" is a 16-bit field that has no intrinsic meaning; the codes are just an arbitrary association between a number and a meaning, just like the values returned by GetLastError().

If you look up error codes in the winerror.h file, you'll see a lot of HRESULTs listed, with the naming convention [facility]_[severity]_[description]. Generic HRESULTs that can be returned by any component (like E_OUTOFMEMORY) have no facility in their name. Examples:

• REGDB_E_READREGDB: Facility = REGDB, for "registry database"; E = error; READREGDB is a description of the error (couldn't read the database).
• S_OK: Facility = generic; S = success; OK is a description of the status (everything's OK).

Fortunately, there are easier ways to determine the meaning of an HRESULT than looking through winerror.h. HRESULTs for built-in facilities can be looked up with the Error Lookup tool. For example, say you forgot to call CoInitialize() before CoCreateInstance(). CoCreateInstance()will return a value of 0x800401F0. You can enter that value into Error Lookup and you'll see the description: "CoInitialize has not been called."

You can also look up HRESULT descriptions in the debugger. If you have an HRESULT variable called hres, you can view the description in the Watch window by entering "hres,hr" as the value to watch. The ",hr" tells VC to display the value as an HRESULT description.

References

Essential COM by Don Box, ISBN 0-201-63446-5. Everything you'd ever want to know about the COM spec and IDL (interface definition language). The first two chapters go into great detail about the COM spec and the problems it was designed to solve.

MFC Internals by George Shepherd and Scot Wingo, ISBN 0-201-40721-3. Contains an in-depth look at MFC's COM support.

Beginning ATL 3 COM Programming by Richard Grimes, et al, ISBN 1-861001-20-7. This book goes into depth about about writing your own COM components using ATL.

 

 

 

　　本文的目的是为刚刚接触COM的程序员提供编程指南，并帮助他们理解COM的基本概念。内容包括COM规范简介，重要的COM术语以及如何重用现有的COM组件。本文不包括如何编写自己的COM对象和接口。
　　COM即组件对象模型，是Component Object Model 取前三个字母的缩写，这三个字母在当今Windows的世界中随处可见。随时涌现出来的大把大把的新技术都以COM为基础。各种文档中也充斥着诸如COM对象、接口、服务器之类的术语。因此，对于一个程序员来说，不仅要掌握使用COM的方法，而且还要彻底熟悉COM的所有一切。
　　本文由浅入深描述COM的内在运行机制，教你如何使用第三方提供的COM对象（以Windows 外壳组件Shell为例）。读完本文后，你就能掌握如何使用Windows操作系统中内建的组件和第三方提供的COM对象。
　　本文假设你精通C++语言。在例子代码中使用了一点MFC和ATL，如果你不熟悉MFC和ATL也没关系，本文会对这些代码进行完全透彻的解释。本文包括以下几个部分：

• 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版本。 调用这个函数后，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;  // 将墙纸路径转换为ANSI
IShellLink*   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();
            }
        }

        // 6. 释放IShellLink 接口。
        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++编写自己的接口。