Tricks of the Windows Game Programming Gurus:DirectX Fundamentals and the Dreaded COM

All ITKnowledge Source Code Search Tips Advanced Search |

| Tricks of the Windows Game Programming Gurus by Andre LaMothe Sams, Macmillan Computer Publishing ISBN: 0672313618 Pub Date: 09/27/99

Search this book:

Previous | Table of Contents | Next

### COM: Is It the Work of Microsoft… or Demons?

Computer programs today are easily reaching multimillion-line sizes, and large systems will soon reach to billions of lines of code. With programs this large, abstraction and hierarchy are of utmost importance. Otherwise, complete chaos would ensue.

The two most recent attempts at computer languages that foster more object-oriented programming techniques are, of course, C++ and Java. C++ is really an evolution (or maybe more a regurgitation) of C, with object-oriented hooks built into it. On the other hand, Java is based on C++ but is fully object-oriented and much cleaner. In addition, Java is more of a platform while C++ is simply a language.

Anyway, languages are great, but it’s how you use them that counts in the long run. Alas, even though C++ is chock full of cool OO (object-oriented) features, many people don’t use them or use them the wrong way. Thus, large-scale programs are still a bit of a problem. This is one of the difficulties that the COM model addresses.

COM was invented many years back as a simple white paper on a new software paradigm, which was similar to how computer chips or Lego blocks work. You simply plug them together and they work. Computer chips and Lego blocks know how to be computer chips and Lego blocks, so everything works out. To implement this kind of technology with software, you need a very generic interface that can take on the form of any type of function set you can imagine. This is what COM does.

One of the cool things about computer chips is that when you add more of them to a design, you don’t have to tell all the other chips that you’ve changed something. However, as you know, this is a little harder with software programs. You at least have to recompile to make an executable. Fixing this problem is another goal of COM. You should be able to add new features to a COM object without breaking the software that uses the old COM object. In addition, COM objects can be changed without recompiling the original program, which is very cool.

Since you can upgrade COM objects without recompiling your program, that means you can upgrade your software without patches and new versions. For example, say you have a program that uses three COM objects: one that implements graphics, one for sound, and one for networking (see Figure 5.3). Now imagine that you sell 100,000 copies of this program, but you don’t want to send out 100,000 upgrades! To update the graphics COM object, all you do is give the users the new COM object for graphics and the program will automatically use it. No recompiling, no linking, no nothing. Easy. Of course, all this technology is very complex at the low level, and writing your own COM objects is a bit challenging, but using them is easy.

Figure 5.3 An overview of COM.

The next question is, how are COM objects distributed or contained, given their plug-and-play nature? The answer is that there are no rules about this, but in most cases COM objects are DLLs, or Dynamic Link Libraries, that can be downloaded or supplied with the program that uses them. This way they can be easily upgraded and changed. The only problem with this is that the program that uses the COM object must know how to load it from a DLL. But we’ll get to that in the “Building a Quasi-COM Object” section later in this chapter.

#### What Exactly Is a COM Object?

A COM object is really a C++ class or a set of C++ classes that implement a number of interfaces. (Basically, an interface is a set of functions.) These interfaces are used to communicate with the COM object. Take a look at Figure 5.4. Here we see a single COM object that has three interfaces named `IGRAPHICS`, `ISOUND`, and `IINPUT`.

Figure 5.4 The interfaces of a COM object.

Each one of these interfaces has a number of functions that you can call (when you know how) to do work. So a single COM object can have one or more interfaces, and you may have one or more COM objects. Moreover, the COM specification states that all interfaces you create must be derived from a special base class interface called `IUnknown`. For you C programmers, all this means is that `IUnknown` is like a starting point to build the interface from.

Let’s take a look at the `IUnknown` class definition:

    struct IUnknown

    {

    // this function is used to retrieve other interfaces

    virtual HRESULT __stdcall QueryInterface(const IID &iid, (void **)ip) = 0;

    // this is used to increment interfaces reference count

    virtual ULONG __stdcall AddRef() = 0;

    // this is used to decrement interfaces reference count

    virtual ULONG __stdcall Release() = 0;

    };

> Note: Notice that all methods are pure and virtual. In addition, the methods use `__stdcall` in deference to the standard C/C++ calling convention. If you remember from Chapter 2, “The Windows Programming Model,” `__stdcall` pushes the parameters on the stack from right to left.

Even if you’re a C++ programmer, this class definition may look a bit bizarre if you’re rusty on virtual functions. Anyway, let’s dissect `IUnknown` and see what’s up. All interfaces derived from `IUnknown` must implement, at very minimum, each of the methods `QueryInterface()`, `AddRef()`, and `Release()`.

Previous | Table of Contents | Next

Copyright © Macmillan Computer Publishing, Inc.

Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.