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.
