Study Notes on com principles and applications -- Implementation of COM

I. In-process components and out-of-process Components

As mentioned above, COM components support both in-process components and out-of-process components. The advantage of in-process components is fast and convenient. However, if any component crashes, the main process will crash. Components outside the process are slow but stable. If a component crashes somewhere, at most there is no result and the main process will not crash (for example, if the browser plug-in crashes, the browser will not crash ). When using COM components, users cannot actually feel the difference between the components in the process and those outside the process. You can use the same method when creating a COM Object. This will be detailed later in this article. The communication mode between a client program and an in-process component and an out-of-process component is actually quite different. However, the implementation of the COM library ensures the process transparency feature of the client program to create a COM object. The following describes how to use in-process components and out-of-process components:

1. Method of In-process components:

The customer program and component program are in the same process. Because they are in the same process, the customer program and component program share resources. The customer program can directly call the member function of the interface pointer. In-process component programs have also become in-process service programs. As the execution efficiency of In-process components is very high, in-process components are also widely used. In-process components mainly exist in the form of dynamic link library (DLL) (in fact, I am not very clear about other methods ~). When the client runs the program, the client maps the DLL file image required by the program to the address space of the calling process (For details, refer to the dynamic link library section in Windows core programming (version 5 ). Therefore, dll exists independently. Client program a can use this DLL, and client program B can also use this DLL. However, before calling a function in the DLL, the client program needs to know some information about the DLL so that the client program can normally call the function in the DLL. This information is also the function export information. There are many ways to generate the exported information. You can use define XXX extern "C" _ declspec (dllexport) to generate the information. For details about this method, see Windows core programming (fifth edition) ), but the COM component generally does not use this method. Another method is to write the def file and clearly specify the function to be exported (for this method, refer to msdn and some introductions on the Internet, as also described in Windows core programming (version 4, this method is also very simple ). In general, the use of in-process components is mainly implemented by using DLL loading.

2. external components:

In this way, the client program and component program are not in the same process. The component program runs a process separately, so that it cannot share resources with the client program. On Windows platforms, exe programs are generally used to implement external components. Because the customer program and component program are in different processes, there will certainly be a problem of Cross-process function calling and data transmission. Now we need to use the process communication method. I don't know about Process Communication, but there are many process communication methods in windows. Here I only know about the inter-process communication of COM components. Com uses the local process call (LPC) and remote process Call (RPC) methods for inter-process communication. LPC is used for inter-process communication between local machines, while RPC is used for inter-process communication between remote computers. If a program needs to call the system services of other processes, although it feels that it calls a system function, it actually uses inter-process communication. System processes are always in progress, so inter-process communication is required to call system services. The client program calls the system's DLL module, which is generally called the stub DLL. Then the stub DLL communicates with the system process to call the system service. Com's out-of-process components are also called in a similar way. Only a proxy DLL is called, while the COM component program uses the stub DLL. Then the agent DLL and the stub DLL are used to implement inter-process communication. The process is shown in:

2. Management of COM objects

The COM component must be used by other customer programs. To use these COM components, you must have the information of these COM components before calling the com library functions to use these COM components. In Windows, the COM component information is stored in the registry. The information mainly includes the guid and the file storage directory. In general, the creation of components is done by the COM library, but a lot of the work of the COM library is dependent on the registry. There are six subkeys under the Registry root node: hkey_classes_root, hkey_currnet_user, HKEY_LOCAL_MACHINE, HKEY_USERS, hkey_current_config, and hkey_dyn_data. Com information is generally stored in the CLSID subkey of hkey_classes_root. Let's take a look. There are many numeric keys under the CLSID subkey, which is actually the legendary guid. If the component is an out-of-process component, the sub-keys will save information about the proxy DLL and the stub DLL. This sub-key is called proxystubclsid or proxystubclsid32. If a component is an in-process component, a sub-key is called inprocserver32. In addition to being identified by clsid, component objects can also be named using strings. Such name information is called progid, which is also saved by a subkey. If you want your components to be used by other programs, you must add component information in the registry. I will not talk about this here. When should I write an article specifically to write the Registry Information and modify the COM component.

3. Who will create COM Object -- class factory

After talking about this, I didn't talk about how the COM object was actually created. The customer program creates a COM object by calling the com library function, and the com library creates a COM object by calling the class factory interface function. The code of the class factory is defined as follows:

1 IClassFactory : public IUnknown2 {3     public:4         virtual HRESULT STDMETHODCALLTYPE CreateInstance( IUnknown *pUnkOuter,  const IID &iid,  void **ppv) = 0;5         6         virtual HRESULT STDMETHODCALLTYPE LockServer( BOOL fLock) = 0;7 };

 

The class factory itself is actually a COM object, so the class factory will also inherit from iunknown. There is an interface function createinstance in the class factory. This createinstance is the function used by the COM library to create COM objects. Each class factory only targets specific COM objects, so createinstance knows exactly what COM objects you need to create. Punknownouter is used to aggregate object classes. Generally, you can enter null. The second parameter IID is the initial interface IID that the client program should obtain after the object is created. The last parameter of the command output is the interface pointer. Another interface function lockserver is used to control the lifecycle of COM components. If a client program wants to continue using the class factory to create a COM object after the COM object is created, it should call the lockserver function to pin the lock of the component, so as not to release it. This mainly prevents the user from saving the interface pointer of the class factory, and the interface pointer is released after it is created, if you use this interface pointer to create a COM object, the memory access error will occur. Therefore, You need to lock the component and release it when it is no longer in use.

4. Who will build a factory?

The COM object is set up by the class factory, but who will set up the class factory. Obviously, the category factory cannot be established by the class factory of the class factory, and the class factory is directly established by the COM library. The prototype of the interface functions of all class factories is the same, so the com library can call all class factory interface functions. Therefore, the com library can directly call the interface functions of the class factory. In this way, the client program can call the functions provided by the COM library to indirectly call the interface functions of the class factory to create a COM object.

The specific creation of COM objects will be followed by the blog.

Study Notes on com principles and applications -- Implementation of COM