With the combination of Microsoft® RPC (Remote Procedure Call) and Microsoft OLE technology, Microsoft began to shift the C/C++ programming model from individual functions to a distributed object model that is based on interfaces. An interface is simply a group of logically related functions. Note that the interface consists only of functions (called methods). There are no facilities for directly accessing data within an interface, except through the methods.
The benefit of such a distributed object model is that it allows developers to create small, independent, self-managing software objects. This modular approach allows software functionality to be developed in small "building blocks" that are then fitted together. Your application no longer has to handle every possible data format or possible application feature, as long as it can be integrated with other objects that can handle the desired formats and features.
The notion of objects is very familiar to Microsoft® Visual Basic® developers. Many software industry analysts have noted that the most visible success of object-oriented programming to date is the widespread use of Visual Basic custom controls.
One of the benefits of the modular, interface-based approach to software development is that individual interfaces usually contain significantly fewer functions than libraries, with the promise of more efficient use of memory. Whenever you want to use one function in a library, the entire library must be loaded into memory. Splitting function libraries into smaller interfaces makes it more likely that you load only the functions that you actually need, or at least fewer that you don't.
By convention, interface names start with the letter I. The methods are given a specific ordering within the interface. Knowing the order of the methods is important for developers who must define their own vtables, or function dispatch tables. The C++ compiler creates vtables for you, but if you are writing in C, you must create your own.
The methods of an interface still physically reside in an .EXE or .DLL file, but Microsoft has defined new rules for how these files are registered on the system and how they are loaded and unloaded from memory. Microsoft refers to the new rules as the Component Object Model, or COM.
According to the rules, the first three methods in all interfaces are always QueryInterface, AddRef, and Release, in that order. These methods provide a pointer to the interface when someone asks for it, keep track of the number of programs that are being served by the interface, and control how the physical .DLL or .EXE file gets loaded and unloaded. Any other methods in the interface are defined by the person who creates the interface. The interface that consists of these three common methods, QueryInterface, AddRef, and Release, is called IUnknown. Developers can always obtain a pointer to an IUnknown object.
The Component Object Model, like RPC before it, makes a strong distinction between the definition of the interface and its implementation. The interface methods and the data items (called properties) that make up the parameters are defined in a very precise way, using a special language designed specifically for defining interfaces. These languages (such as MIDL, the Microsoft Interface Definition Language, and ODL, the Object Definition Language) do not allow you to use indefinite type names, such as void *, or types that change from computer to computer, such as int. The goal is to force you to specify the exact size of all data. This makes it possible for one person to define an interface, a second person to implement the interface, and a third person to write a program that calls the interface.
Developers who write C and C++ code that use these types of interfaces read the object's interface definition language (IDL) files. They know exactly what methods are present in the interface and what properties are required. They can call the interfaces directly.
For developers who are not writing in C and C++, or do not have access to the object's IDL files, Microsoft's Component Object Model defines another way to use software components. This is based on an interface named IDispatch.