Beginning ATL 3 COM Programming
by Wrox Press.

The Holy Grail of computing is to put applications together quickly and cheaply from reusable, maintainable code — preferably, code written by someone else. For many years now, experience and research have shown that object-oriented languages have a marked effect on the ability of software developers to write this kind of code. The ability to abstract concepts from a problem, and to turn them into classes and objects in a way that is fundamentally supported by the programming language, is a powerful draw for software engineers. The benefits of object-oriented techniques are there for all to see.

On its own, however, an object-oriented programming language is not sufficient for widespread reuse. As soon as we go beyond the idea of having a single developer or group of developers, the real world comes crashing in. The first problem we see is that developers throughout the world are programming in different languages.

As much as some well-known Californian companies would like us to simplify things by standardizing around a single programming language, it's never going to happen. The reasons for the diversity of languages in the world today are complex, beyond one company's control, and in many cases well founded. Some languages are better suited than others to a particular problem domain; some programmers have a natural preference for a particular language because it more closely reflects the way they think; some languages relate well to particular hardware. New languages and tools replace old ones because they're based on new ideas or take advantage of processor power that wasn't previously available. The popularity of a language responds to fashion and hype, and even to the quantity of good books teaching the subject. We live, and will continue to live, in a world of many tongues.

Now, a multitude of languages has its benefits, but the problem it presents to us is that it fragments the marketplace for reusable components. A Java class is of little use to a C++ developer, and a chunk of Visual Basic code won't help a COBOL programmer. If I write a system in C++ today, will that effort be superceded five years from now by the arrival of a new programming language, as yet undreamed? It was issues like these that drove the authors of the Component Object Model (COM) to their solution, which is to use language-neutral, binary components. Subject to a few considerations, this methodology allows developers to write components in whatever language they choose. It's the compiled code that matters, not the source code.

Of course, COM is neither the first nor the only way of reusing compiled code. C-style DLLs, for example, have been used extensively in Windows programming for a very long time, and their advantages are manifold:

• They allow parts of an application to be swapped out or upgraded without the need for recompilation.
• Code can be loaded on a just-in-time basis, so that it doesn't take up any memory if it's never needed.
• Code can be shared between processes, which can be more memory-efficient than linking it statically (that is, compiling it into the application).

Given this list of important features, it will come as no surprise that COM components can themselves be packaged as DLLs. However, if it were as simple as that, you'd be looking at a very thin book indeed. Happily for us, C-style DLLs also have a number of disadvantages that COM must address:

• Although they are callable from most languages, relatively few languages let you create them.
• They expose only simple functions — they are not object-oriented.
• Traditionally, DLLs have been loaded by filename, which means that if the location or the name of a DLL changes, the application will not be able to load it.
• It is difficult to provide different versions of a DLL on the same system, because doing so can cause conflicts between different vendors' products.

As you read on, you'll discover how COM overcomes all of these problems, and provides a number of other facilities we've yet to mention. We should begin, though, by getting a firmer grasp of exactly what COM is.

A One Sentence Description Of COM
COM is a complicated topic, but we can write a simple one-sentence description that outlines its most important features:

Let's look more closely at that overlong sentence and its implications to get a fuller picture of the kinds of facilities offered by COM.

• COM is a specification The COM specification describes the standards that you need to follow in order to create interoperable COM components. This standard describes what COM components should look like and how they should behave.
• COM is a set of services The specification is backed up by a set of services or APIs. These services are provided by the COM library, which is part of the operating system on Win32 platforms, and available as a separate package for other operating systems.
• COM allows modular programming COM components can be packaged as DLLs or EXEs — COM provides the communication mechanism to allow components in different modules to talk to each other.
• COM is object-oriented
COM components are true objects in the usual sense: they have identity, state and behavior. In certain circumstances, COM components can be treated polymorphically.
• COM enables easy customization and upgrades to your applications COM components link with each other dynamically, and COM defines standard ways of locating components and identifying their functionality, so individual components are swappable without having to recompile the entire application.
• COM enables distributed applications COM provides a communication mechanism that enables components to interact across a network. More importantly, COM provides location transparency to applications (if desired) that enables them to be written without regard to the location of their components. The components can be moved without requiring any changes to the application.
• COM components can be written in many programming languages COM is a binary standard. Any language that can cope with the binary standard can create or use COM components. The number of languages and tools that support COM is sizable, with C, C++, Java, JScript, Visual Basic, VBScript, Delphi, PowerBuilder, and MicroFocus Cobol forming just part of the list.

COM is not about any particular type of application. It's not about controls (that's ActiveX); it's not about compound documents (that's OLE); it's not about data access (that's OLE DB and ADO); and it's not about games and graphics (that's DirectX). But COM is the object model that underlies all these technologies. An understanding of COM is vital to programming any of these technologies successfully.