The Component Object Model (COM)
When Microsoft designed OLE, it had object-oriented programming in mind. COM objects are much like instantiated C++ classes or an ADA package. In fact, COM was designed with C++ programmers in mind. It supports encapsulation, polymorphism, and reusability. However, COM was also designed to be compatible at the binary level and thus differs from a C++ object.As a programmer, you are aware that compiled programming languages such as C, C++, Pascal, and ADA are machine-dependent. As a binary object, a COM object concerns itself with how it interfaces with other objects. When not used in the environment of its creator, an interface is exposed that can be seen in the non-native environment. It can be seen because it is a binary object and therefore not machine-dependent. This does not require the host environment or an interacting object to know anything about the COM object. When the object is created in the womb of its mother application, COM does not concern itself with how that object interacts within it. This interaction is between the mother application and the child object.
When the object interacts with the rest of the world, however, COM is concerned about how to interface with that object. It’s important to note that COM is not a programming language; it is a binary standard that enables software components to interact with each other as objects. COM is not specific to any particular programming language. COM can work with any language that can support the binary layout of a COM object. It is a programming model to facilitate the programmability of this standard.
The Evolution of Component Technology
You will begin your journey to understanding COM and DCOM by looking at the evolution of component technology. Although object-oriented technology has had an evolution all its own, a spinoff of object-oriented technology, termed component technology, has had its own evolution. The component technology evolution has a majority of its roots in the Microsoft Windows family of operating systems. Although there were other contributors to the component revolution with quasi-component–based development, using libraries of functions in FORTRAN, and Smalltalk classes, Microsoft has defined component-based technology as we see it today. This began with the custom control.
Custom Controls
The term control, or custom control, has been around since Windows 3.0, when it was first defined. A custom control is nothing more than a dynamic link library (DLL) that exports a defined set of functions. Unlike a DLL, a custom control can manipulate properties and handle the firing of events in response to user or programmatic input.
In the early days of Microsoft Windows, the Visual Basic (VB) development environment caught on in the development community, and component technology took off. VB programmers found that custom controls were necessary because they needed better ways to express the user interface of their applications. Many times, there was simply no way to perform a complex operation in Visual Basic. Unfortunately, or fortunately, depending on your perspective, these C language DLLs had no way of allowing Visual Basic to query the control for information on the properties and methods supported by the control. This made custom controls difficult to use in the Visual Basic development environment.
Visual Basic Extensions
In 1991, Microsoft unveiled the VBX. VBX stands for Visual Basic Extension. The idea was that these little reusable software components could be embedded in their container application. To everyone’s surprise, VBXs took off like wildfire. Companies cropped up all over the place, developing these little reusable software components. VBXs were able to provide a wide range of functionality, from a simple text label to a complex multimedia or communications control. They were written in C and C++ and provided a wide variety of capabilities that otherwise could not have been possible in a Visual Basic application. VBXs were extremely popular.
Because VBXs became popular, demand for them grew within the developer market. Soon developers wanted them for 32-bit applications and even on non-Intel platforms such as the DEC Alpha, RISC, Power PC, and the MIPS. Developers wanted to extend VBXs by using Visual Basic for Applications to connect VBXs with applications such as Access, PowerPoint, Excel, Project, and Word.
Unfortunately, VBXs are severely restricted. They were built on a 16-bit architecture that is not designed as an open interface. They were primarily designed to accommodate the Visual Basic environment. This made VBXs almost impossible to port to a 32-bit environment. Seeing the value and popularity of VBXs, Microsoft wanted to capitalize on this market. Microsoft was looking for an object-oriented architecture that was extensible and that supported a data-driven approach, as opposed to an application-driven approach. The result was OLE 1.0.
OLE 1.0
In 1991, Microsoft introduced a new specification called OLE 1.0. The acronym stood for object linking and embedding. OLE 1.0 was basically a method of handling compound documents. A compound document is a way of storing data in multiple formats—such as text, graphics, video, and sound—in a single document. At the time, object-oriented was the new programming buzzword, and the OLE 1.0 specification was a move toward a more object-oriented paradigm. Furthermore, OLE 1.0 was an effort to move toward a more document-centric approach, instead of an application-centric approach.
Unfortunately, OLE 1.0 was coldly received by software developers. Very few independent software vendors (ISVs) and corporations raced to embrace OLE 1.0 and to OLE-enable their applications. This reluctance to deploy OLE 1.0 in applications was mainly due to OLE 1.0 being very complex and having a steep learning curve. OLE 1.0 had to be coded using a very complex C application programming interface (API), which embodied programming concepts germane to OLE. These new concepts were foreign to most developers.
OLE 2.0
Undaunted by the limited success of OLE 1.0, Microsoft continued to strive to improve OLE. In 1993, Microsoft released the OLE 2.0 specification, which encompassed more than just compound documents. It sported an entire architecture of object-based services that could be extended, customized, and enhanced. The foundation of this services architecture was the Component Object Model. The services available through this architecture are
- • COM
- • Clipboard
- • Drag and drop
- • Embedding
- • In-place activation
- • Linking
- • Monikers (persistent naming)
- • OLE Automation
- • OLE controls
- • OLE documents
- • Structured storage
- • Uniform data transfer (UDT)
From a programmatic view, OLE 2.0 is a series of services built on top of each other, as shown in Figure 1.1. These services form an architecture of interdependent building blocks built on the COM foundation.
The release of OLE 2.0 had such an effect on standard ways of computing that it received two prestigious industry awards: a Technical Excellence award from PC Magazine and the MVP award for software innovation from PC/Computing. Adding to the OLE 2.0 success was a new and improved programming interface. Developers could now move to OLE-enabled applications much more easily. The OLE 2.0 services incorporate many principles embodied in object-oriented programming: encapsulation, polymorphism, and an object-based architecture. Further adding to the success of OLE 2.0 was the release in February 1993 of Visual C++ 1.0 with the Microsoft Foundation Class (MFC) Library version 2.0. MFC had wrapped the OLE API in a C++ class library, thus making it much easier for programmers to use the OLE services architecture.
Today, OLE is no longer the acronym for object linking and embedding. That term is obsolete. Now Microsoft refers to it as simply OLE, pronounced o-lay. Notice that no version number is attached to OLE anymore. Because OLE is an extensible architecture, it can be enhanced and extended without changing its basic foundation. A testimonial to this capability is OLE controls. OLE controls were not part of the original release of OLE. OLE controls were not added to the available OLE services until almost a year after the original release. In fact, objects created with OLE 1.0 still work and interact with modern OLE applications. However, their functionality is limited to the original 1.0 specification, so no need for versions exists. From here on, this chapter refers to OLE unless specifically outlining a feature of OLE 1.0 or 2.0.
