Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd
Upload
6 views

The Microsoft Component Object Model

The Microsoft Component Object Model (COM) is a platform-independent system for creating binary software components that interact through defined interfaces, which are contracts of related function prototypes. Each COM interface is strongly typed and immutable, identified by a unique GUID, allowing different object classes to implement the same interface interchangeably. COM uses reference counting for managing object lifetimes and organizes objects into apartments to control thread access.

Uploaded by

liuxk1988
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
6 views

The Microsoft Component Object Model

The Microsoft Component Object Model (COM) is a platform-independent system for creating binary software components that interact through defined interfaces, which are contracts of related function prototypes. Each COM interface is strongly typed and immutable, identified by a unique GUID, allowing different object classes to implement the same interface interchangeably. COM uses reference counting for managing object lifetimes and organizes objects into apartments to control thread access.

Uploaded by

liuxk1988
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

The Microsoft Component Object Model (COM) is a platform-

independent, distributed, object-oriented system for creating binary


software components that can interact.

The only language requirement for COM is that code is generated in


a language that can create structures of pointers and, either
explicitly or implicitly, call functions through pointers.

A COM object is one in which access to an object's data is achieved


exclusively through one or more sets of related functions. These
function sets are called interfaces, and the functions of an interface
are called methods. Further, COM requires that the only way to gain
access to the methods of an interface is through a pointer to the
interface.

An interface is actually a contract that consists of a group of related


function prototypes whose usage is defined but whose
implementation is not . These function prototypes are equivalent to
pure virtual base classes in C++ programming.

 A COM interface is not the same as a C++ class. The pure


virtual definition carries no implementation. If you are a
C++ programmer, you can define your implementation of
an interface as a class, but this falls under the heading of
implementation details, which COM does not specify. An
instance of an object that implements an interface must
be created for the interface actually to exist.
Furthermore, different object classes may implement an
interface differently yet be used interchangeably in
binary form, as long as the behavior conforms to the
interface definition.
 A COM interface is not an object. It is simply a related
group of functions and is the binary standard through
which clients and objects communicate. As long as it can
provide pointers to interface methods, the object can be
implemented in any language with any internal state
representation.
 COM interfaces are strongly typed. Every interface has its
own interface identifier (a GUID), which eliminates the
possibility of duplication that could occur with any other
naming scheme.
 COM interfaces are immutable. You cannot define a new
version of an old interface and give it the same identifier.
Adding or removing methods of an interface or changing
semantics creates a new interface, not a new version of
an old interface. Therefore, a new interface cannot
conflict with an old interface. However, objects can
support multiple interfaces simultaneously and can
expose interfaces that are successive revisions of an
interface, with different identifiers. Thus, each interface is
a separate contract, and systemwide objects need not be
concerned about whether the version of the interface
they are calling is

https://www.cnblogs.com/coderht/p/7436860.html

An instance of an interface implementation is actually a pointer to


an array of pointers to methods - that is, a function table that refers
to an implementation of all of the methods specified in the interface

With appropriate compiler support (which is inherent in C and C++),


a client can call an interface method through its name, not its
position in the array.

https://docs.microsoft.com/en-us/windows/win32/com/the-com-library

https://docs.microsoft.com/en-us/windows/win32/com/rules-for-managing-
reference-counts

Using a reference count to manage an object's lifetime allows


multiple clients to obtain and release access to a single object
without having to coordinate with one another in managing the
object's lifetime.

From a COM client's perspective, reference counting is always done


for each interface. Clients should never assume that an object uses
the same counter for all interfaces.
From a COM client's perspective, reference counting is always done
for each interface. Clients should never assume that an object uses
the same counter for all interfaces.

The default case is that AddRef must be called for every new copy
of an interface pointer and Release must be called for every
destruction of an interface pointer, except where the following rules
permit otherwise:。

In general, the simplest way to view the COM threading architecture


is to think of all the COM objects in the process as divided into
groups called apartments. A COM object lives in exactly one
apartment, in the sense that its methods can legally be directly
called only by a thread that belongs to that apartment. Any other
thread that wants to call the object must go through a proxy.

You might also like