Component Object

Model
Presented by
I Unknown
Highlights
 Problemsin C++ Software distribution
 COM goals

 Mechanism
 Interfaces
 IUnknown
 CoClass
 Component
Software Distribution

Implement class in C++:

ClassX • Create .h file
attributes • Create .cpp file

methods

use class in multiple applications

Application A ClassX.obj
Application B ClassX.obj
Disadvantages:
• Duplication of binary code
(on disk and memory)
• Update of class X requires rebuild
(even if interface does not change)

Application C ClassX.obj
Dynamic Linking
Application A ClassX.obj
Application B ClassX.obj
Application C ClassX.obj
DLL is binary code that is
linked to the application at
run-time.
To use a DLL you will have
to add an import library to
your project.

Application A import library Problems were:

• Duplication of code
• Update requires recompilation
Application B ClassX.dll
Problems solved:
Application C • Duplication of code
Encapsulation

ClassX ClassX
private: a private: a,b

methods methods

Problem:
Application A
Version 2.0 C++ supports syntactic
SizeOf(ClassX) = 8 encapsulation via its private and
protected keywords but has no
Application B ClassX.dll
Version 1.0 notion of binary encapsulation.
Version 2.0
SizeOf(ClassX) = 4 SizeOf(ClassX) = 8
Application C Update of Class X still requires
Version 1.0
SizeOf(ClassX) = 4 recompilation
Separating Interface from Implementation

The binary layout of the interface does not change as

data members are added to or removed from
ClassX implementation class.
The interface class will become the only entry point into
private: a the DLL and it’s binary signature will never change.
void f(int b);

Solved problems:
• update of class X requires recompilation

DLL
IClassX ClassX
private: m_pThis private: a

void f(int b); void f(int b);

 Abstract Bases as Binary
Interfaces
The interface class will become the only entry point into the DLL and it’s binary
signature will never change.

Problem:
The binary signature is compiler dependent !

IClassX ClassX
private: m_pThis private: a

void f(int b); void f(int b);

Compiler X

Compiler Y
Abstract Bases as Binary
Interfaces

IClassX Problem:
• Binary interface can be compiler dependent
virtual void f(int b) = 0
virtual int g(int c) = 0
Solution:
The binary firewall imposed by the interface class can
not use compiler-variant language features.
ClassX
• No data members (attributes)

void f(int b) • Interface members are pure virtual functions

int g(int c)

Assumption:
All compilers on a given platform produce equivalent machine
code for the virtual function call mechanism !!!
Object Extensibility
The techniques presented so far allow clients:
• Select and load binary components dynamically. This means their
implementation can evolve over time without recompilation of the
client.

However:
• The interface of an object cannot evolve over time, because of the
compilation against the signature of the interface class.

Despite the immutability of interfaces, it is often necessary to

expose additional functionality !
 Object Extensibility

Problem:
Interfaces must be immutable and cannot change once published.

Solution:
Allow an implementation class to expose more than one interface.

The client should be able to determine at runtime whether

requested functionality is indeed supported by the object currently
in use. (dynamic_cast)
 Resource Management

The use of dynamic_casts usually results in duplication of pointers

and in complex code it is hard to keep track of these pointers.

Problem:
It’s hard to keep track off the number of references to an object
(needed to manage the lifetime).

Solution:
We allow object to manage its own lifetime !
What have we done?

Simple C++ class Reusable binary component

• Deploy in binary format

• Separate interfaces from implementations
• Use c++ compiler independent interfaces
• Introduce techniques for dynamically selecting implementations
• Use construct for dynamically discovering whether object
implements desired interface.

We ha ve ( almo st) desc ribed the C ompo nent

Obj ec t M odel !
 COM Goals
 Encapsulation (separate implementation from interface)
 Versioning
 Language independence
 Object Creation / Lifetime Control
 Standard error code (HRESULT)
 Location transparency
 Solve object discovery problem
Objects and Interfaces
Interfaces
◆ An interface is a named table of function pointers
(methods)
◆ An interface is not a class
◆ An interface is not a COM component
◆ COM clients only interact with pointers to interfaces
◆ COM components can implement multiple interfaces
◆ Every interface is uniquely identified by a GUID.
◆ Interfaces are immutable
 Binary Format of an Interface
Object
QueryInterface( ) {…}
Client
Pointer to Method 1
AddRef( ) {…}
Pointer to Method 2
Release( ) {…}
Pointer to Method 3
LookUpWord( ) {…}
Pointer to Method 4

Pointer to Method 5 AddToDictionary( ) {…}

Pointer to Method 6 RemoveFromDictionary( ) {…}

vtable
IUnknown contd.
 IUnknown
 Root interface
 Methods
 QueryInterface (IID)
 Get the interface pointer if it is supported by component
 Addref ()
 Increase count
 Release ()
 Decrease count and delete when count gets 0
Versioning using QueryIntface
Old Interface

LookUpWord( )
AddToDictionary( )
RemoveFromDictionary( )

Client1 COM Object

TextTools

Client2
GetSynonym( )

New Interface
COM Server Implementation
 CLSID and IID generation
 Viusalstudio\common7\tools\guidgen.exe
 Registration of CLSID
 HKEY_CLASSES_ROOT\CLSID directory
 RegSvr32.exe
 Calls DllRegisterServer() function of DLL:
 Interface implementation
 Add(), Sub()
 CoClass imlementaion
 Addref()
 Release()
 QueryInterface()
 Add(), Sub()
 Class Factory Implementation
 O/S calling function implementation and DEF file editing
 DllUnRegisterServer()
 DllRegisterServer()
 DLLGetClassObject()
CoClass
(Component Object Class)
 Consists
 interfaces
 its implementation
 CLSID
 COM Object
 Class Factory
 CoClass
 Generats CoClasses in a DLL
 Interface: IClassFactory
 Methods: CreateInstance, LockServer