Understand COM components

COM, a component object model, describes how to create components and how to use components to create applications.

1. advantages of using components:

One advantage of component architecture is that applications can evolve over time. In addition, you can also use components to upgrade existing applications more conveniently and flexibly, such as application customization, Component Libraries, and distributed components.

The advantages of using components directly come from the ability to dynamically insert or unload them from applications. To implement this function, all components must meet two conditions:

First, the component must be dynamically linked;

Second, they must hide (or encapsulate) their internal implementation details. Dynamic Links are a crucial requirement for components, while message hiding is a necessary condition for dynamic links.

COM components consist of executable code published in the form of Win 32 dynamic connection library (DLL) or executable file (EXE. Components compiled according to the COM specification can meet all requirements on the component architecture. COM components can provide services to applications, operating systems, and other components. Custom COM components can be connected to other components at runtime to form an application; COM components can be dynamically inserted or detached from applications.

2. How to register com components?

You can register components in either of the following ways:
One is to use regsvr32.exe:
For example, run regsvr32.exe c: \ test. dll to register test. dll in the C: root directory.
The other is to register in MTS (Microsoft Transaction Server. MTS is recommended because it has the following advantages:

1) dynamically uninstall and balance to improve the upgrade of components and component-based applications.
2) including the ability to publish and submit events and queue components, making it easier to work with multiple components.

3. What is the relationship between com components and the registry?

One of the important properties of COM is location transparency. In the past, when calling the output function of a common dynamic link library, you must place the dynamic link library in the same-level directory of the application (or the directory that the system can find, such as the Windows directory, the existing search path in the environment, and so on), or the dynamic library location information hard coding into the program, in fact, all show that the location of the common dynamic library is not transparent.

It is easier for a client program to call a COM object because the caller does not need to consider the location of the COM component, no matter which directory it is in or whether it is on the current workstation, the system provides a mechanism to ensure the location of COM objects. This is location independence.

In fact, the implementation mechanism of COM location independence is not profound. It mainly depends on the registry, which is why COM components must be registered before use. After receiving a request from the client program, the COM library will go to the Registry to retrieve the registration entry of the COM Object and locate the COM object.

To successfully locate a COM object by the COM database, you must write at least the information shown in 1 and 2 in the registry.

Observe the registration information and you can find that there is a connection between them. Now a registration item {18034D20-B0C3-4135-9DCF-C2E12A58D330} is added to the HKEY _ CLASSES_ROOT \ key of the Registry. This GUID is CLSID, representing the COM class.

Figure 1 ProgID registration of a component

 

Figure 2 register the CLSID information of a component

Under this registration project, there is a string value named InProcServer32, which indicates that the carrier containing this COM class should be a dynamic link library. The data of this string value is "xxx. dll", indicating the physical location of the component. This information plays a decisive role in searching and locating the component in the COM library.

There is also a string value named ProgID, whose content is MyCOM. SimpleMath.1. The emergence of ProgID is mainly to give a long CLSID a "humanized" name, usually in the customer program using ProgID instead of CLSID.

In addition, you can also use ProgID to identify the COM object in the registry. The information displayed in Figure 2 is the registration information of the ProgID component, the data named CLSID string value is the CLSID value of the COM Object. Therefore, you can locate the specified component based on ProgID or CLSID.

Of course, the COM component cannot write registration information to the Registry by nature. For an in-process server, two output functions named DllRegisterServer and DllUnregisterServer must be implemented, to write and uninstall registration information.

HRESULT DllRegisterServer (void)

{

// Main implementation method:

// Call the Windows API function to obtain the physical location of the module,

// Call the Windows API to create a registry function. Figure 5-4 and 5-5 shows the registered project.

... (Code omitted)

}

HRESULT DllUnregisterServer (void)

{

// Main Implementation Method

// Call the Windows API to operate the registry function and delete the written information in the registry.

(Code omitted)

}