COM Programming  «Prev  Next»
Lesson 2 Prerequisites
Objective Make sure you have the background and equipment required for this course.

Microsoft COM Reuse Mechanisms

Software and Hardware Prerequisites

Advanced COM (COM Fundamentals II) builds on the information presented in COM Fundamentals I (Basic Com), including:
  1. Core COM concepts, including COM servers, COM objects, and interfaces
  2. Basic COM programming technology, including interface pointers, IUnknown interface navigation, IUnknown reference counting, IClassFactory, interface definition language (IDL), Microsoft IDL (MIDL) compiler, and the Active Template Library (ATL)
  3. Understanding and using type libraries as part of the COM development process
  4. Familiarity with developing source code for basic in-process COM objects/servers and COM clients using the ATL

COM Fundamentals II is intended for professional C++ developers interested in building software components using Microsoft's Common Object Model, COM. Much of the information in this course builds on C++ concepts. To get the most from this course, you should have a solid understanding of the following C++ concepts:
  1. Classes and Structures
  2. Constructors
  3. Inheritance and multiple inheritance
  4. Virtual functions
  5. Pure virtual functions

You do not have to be an expert in these areas, but you should have an idea of what they mean.
You should have experience developing COM objects in in-process servers using ATL. You need to know how ATL supports COM objects via multiple inheritance and how to use Visual C++ 5.0 or 6.0 to create ATL-based COM objects in in-process servers. Additionally, you need to understand how COM objects, servers, and clients interact.

(API) Application Programming Interface

The Component Object Model (COM) is an application programming interface (API) that allows for creation of so called objects. These objects are software constructs to be useful for the service they provide for a client. The client may be another piece of software, a conventional application program or possibly another object. Objects are packaged in components. Here component means the (more physical) representation of software a data file on some storage medium.
If you boil it down to a level of software using software, what is special about CO (except being originated by Microsoft) ? There are already successful concepts like libraries, class libraries, dynamic link libraries and the like. To make these software pieces work together you need ‘interfaces’ which are basically contracts about how to give and how to take. Either side has to comply to these contracts. But writing computer programs comes with a bunch of different languages on different hardware and software platforms. To link to a library is very dependent on language and platform. It is about compatibility of data types and calling conventions. That is why libraries are reused mostly inside the world defined by a computer language or a platform boundary. But software still is only bits and bytes. Here contracts (interfaces) specified on a binary level, that sounds like a cute way to go. COM is just a binary specification. It does not tell you how to build components. It tells you how to connect to a COM object. That makes it language independent - and platform independent too (at least in theory). There should be some software vendors offering COM on Unix.