Basic concepts of automation: COM components and interfaces)

COM component and Interface)

Xu Shiwei (copyright statement)
2007-3-12

In the previous article, I predicted that I would start to introduce winx's support for automation. First, I want to explain the concepts related to automation.

There are three sections to describe:

• Com basics: COM components and interfaces)
• Variant and idispatch)
• Automation, OA, secondary development interfaces (Application Development interfaces, Apis), and typelib)

This is the first article.

COM components (Component) can be intuitively understood as a class, but this is not a rigorous definition. There are two reasons:

• Some languages (such as C) do not have classes, but they can implement COM components.
• COM component (Component) is usually a class, but it may also be implemented by multiple classes. But for component customers, it is a class or multiple classes for implementation, it does not know, do not care. For details about using multiple classes to implement COM components, you can refer to the "nested classes to implement COM interfaces" section in COM components (for example, if MFC prefers, ATL tends to use multiple inheritance) "," aggregation.

COM component is a concept based on binary object protocol. It can also be understood that this is a binary "class ". A com component exposes a group of interfaces instead of a group of methods ).

Interface is widely used. It generally refers to the specification (contract) of a class )". In the sense of COM, interfaces refer to binary protocols that are compatible with the current vtbl mechanism, in addition, the first three vtbl interfaces are compatible with the iunknown interface (from the inheritance point of view, it can be understood as the requirement to inherit from the iunknown interface, but it is only understood in this way ). For example, you can define the following interface:

Interface ifoo: iunknown
{
Virtual void _ stdcall fooa () = 0;
Virtual int _ stdcall foob (INT arg1, int arg2) = 0;
};

However, you can also choose not to write like this, but the pure C style:

Struct ifoovtbl
{
Hresult (_ stdcall * QueryInterface) (void * pthis, const guid * IID, void ** GMM );
Ulong (_ stdcall * addref) (void * pthis );
Ulong (_ stdcall * release) (void * pthis );
Void (_ stdcall * fooa) (void * pthis );
INT (_ stdcall * foob) (void * pthis, int arg1, int arg2 );
};

Struct ifoo
{
Struct ifoovtbl * vptr;
};

QueryInterface is the core component of COM (Component). With it, it makes the component possible to develop and upgrade. We know that the interface in COM has a guid (globally unique identifier) corresponding to it. Theoretically, once an interface is published, it should not be modified, so that old customers can upgrade to use the new COM component. To upgrade your components, you should:

 

Interface ifoo2: ifoo
{
Virtual hresult _ stdcall newfoo () = 0;
};

When you need the function in ifoo2, you need to use QueryInterface to switch to ifoo2:

Ifoo * pfoo;
...
Ifoo2 * pfoo2;
Hresult hR = pfoo-> queryinterafce (iid_ifoo2, (void **) & pfoo2 );
If (succeeded (HR ))
{
// Use pfoo2...
Pfoo2-> release ();
}

In iunknown, addref and release are used to manage the lifecycle of COM components. I have also talked about it in "C ++ memory management change". I will not explain it here.