COM Techniques by Panther Software

October 7, 1998

This article is divided into three parts:

Introduction
Part 1: A Free-Threaded DCOM Server
Part 2: Creating Plug-ins
Part 3: The Client Application

Introduction

It is now late 1998 -- and if you haven't heard of Component Object Model (COM) and Distributed COM (DCOM) by this time, you are either very lucky because you have been surfing in Bali for the past four years or you need to get out from under a rock. If you haven't done any programming in COM, you may want to consider some of the entry-level books, such as Inside COM by Dale Rogerson (Microsoft Press) or Understanding ActiveX and OLE by David Chappell (Microsoft Press). Additionally, some very good books on the details of COM and DCOM include Professional DCOM Programming by Richard Grimes (Wrox Press) and Essential COM by Don Box (Addison Wesley). If you have done some COM programming and want to learn plug-in and shared data techniques, this article may be the perfect guide for marshaling through fast coral reef breaks.

The COM model allows developers to build real, stand-alone components. Users (clients) of COM components (servers) can utilize pre-built functionality in server objects without intimate knowledge of the server. COM is extremely elegant, because instead of trying to link in a component's functionality at design time or provide a path to the component in your source code, COM uses the CLSID to determine the binary's location -- whether that means local or remote.

Interfaces are represented by GUIDs. Interface IDs, which are known as IIDs but are really GUIDs, are used to determine the available methods. Accordingly, if you want to use the same Interface to represent methods in your component, it must have the exact same signature as the original interface. This is the concept of immutability.

As long as the mapping mechanism knows where to find the server component and the client knows the methods of the interface, the application is ready to run. The next time you type in your code

   CoCreateInstance(CLSID,…,IID,…);

don't think about COM, but rather consider that you are asking a mapping utility (the Registry) to locate a binary (DLL or EXE) identified by CLSID, and to load it into memory with LoadLibrary or CreateProcess to determine whether the binary supports a prescribed set of methods.

In general, when you want to use a component, you call CoCreateInstance to:

Load the binary identified in the mapping utility
See if it supports the unique signature identified by IID
And if so, call the methods as you would on any other object

If you grasp this concept, you are on your way to understanding what COM is really about!

Because any component can create a signature identified by an IID, the COM model allows clients to interchange components either by changing the CLSID's binary entry locations in the registry (possible but not recommended) or by allowing client applications to select from a variety of binaries supporting the same interface at run time in order to choose desired functionality (highly recommended).

In fact, it is the often-overlooked concept of "interchangeability because of interface immutability" that we will emphasize in this article. Immutability is so important that it is this writer's opinion that if one is convicted of modifying interfaces once they have been published to others, the guilty individual should have their COM programming privileges suspended for six months and do all their programming in Chateau Bow Wow (the Dog House). (Consistent with the U.S. penal system, after three strikes, the programmer's computer is taken away for good.)

Why is the concept of immutable interfaces so important? If we do a good job as developers and popularize interfaces, then we cannot only utilize each other's components but also interchange them as better widgets are developed - a concept that was popularized in the 1700s during the Industrial Revolution. (Hey, give us programmers some time; we will catch up with ideas that occurred over 200 years ago.)

One of today's most popular immutable interfaces is the ADORecordset championed by Microsoft. Ask any Windows database developer if he can work with data given to him in the form of an ADORecordset, and the answer is almost always yes. While we are not going to work with ADORecordsets in this article -- perhaps our next one -- we are going to emphasize the concept of immutability and attempt to popularize the use of immutable interfaces through custom component categories in the registry.

What We Will Build

Because this article is partially an update to our 1997 article titled ActiveX Magic, which demonstrated DCOM and Connection Points, we will again create a free-threaded DCOM server. However, rather than supporting a Connection Point -- which is preferably used for scripting clients -- we will instead create a straight call back interface. Additionally, in the DCOM server, we will demonstrate one of our favorite techniques for sharing data between different COM instances without using singletons. That is correct. You have heard singletons badmouthed long enough, but no one has showed you how to share data between COM instances without singletons, so this article will demonstrate this important concept in Part 1.

In Part 2 of the article, we will build a couple of plug-in COM objects that support the same interface through C++ class inheritance in Active Template Library (ATL). Using C++ inheritance, we will demonstrate how to use base class methods in derived COM objects. This technique allows you to create interfaces without having to implement every method of the interface. It's one of the many added bonuses of combining a language that supports inheritance such as C++ with the COM's concept of immutability. This section will also demonstrate custom registration using the .rgs files that are automatically created through the ATL wizards. With a few simple lines, you can create custom registration entries for your components without messy registry files or Win32 API calls.

Lastly, we will tie it all together with a Microsoft Foundation Classes (MFC) dialog application. The dialog application will use the DCOM server, implement the call back component for the DCOM server, and allow the user to dynamically change plug-ins to process the data. If that isn't enough to get you to paddle in from perfect waves in Bali and get back on the COM programming wave, then send me a plane ticket. Alas, with deadlines to meet, I guess we should hold off on those surf dreams continue with the task at hand -- becoming better COM programmers.

What You Are Going to Need

To build the samples, you are going to need Visual C++ 6.0. While you can utilize Windows 95, Windows 98, or Windows NT® as your development platform, we highly recommend developing on Windows NT 4.0 Workstation for any serious DCOM work. Using Windows NT, you can examine processes and shut things down with a little bit more stability and ease than in Windows 95 or Windows 98. Besides, if you haven't realized it yet, it is time to get with the program: Windows NT® is the way to go.