The purpose of this article is to provide programming guidance to programmers who have just contacted COM, and to help them understand the basic concepts of COM. The content includes a brief introduction to COM specifications, important COM terminology, and how to reuse existing COM components. This article does not include how to write your own COM objects and interfaces.
COM, the Component Object model, is the first three-letter abbreviation of the Component object, which is seen everywhere in today's Windows world. The huge new technology that emerges at any time is based on COM. Various documents are also flooded with terminology such as COM objects, interfaces, servers, and so on. Therefore, for a programmer, not only to master the method of using COM, but also thoroughly familiar with all of COM.
This article describes the internal operating mechanism of COM from the inside out to teach you how to use a third-party-provided COM object (for example, the Windows Shell Component shell). After reading this article, you can learn how to use the built-in components in the Windows operating system and the COM objects provided by third parties.
This article assumes that you are proficient in C + + language. MFC and ATL are used in the example code, and if you are unfamiliar with MFC and ATL, this article will explain the code in a complete and thorough light.
This article includes the following sections:
What the hell is com--? --com The key point of the standard, it is designed to solve what problems?
The definition of basic elements--com terms and the meaning of these terms.
Use and work with COM objects-how to create, use, and destroy COM objects.
Basic interface--describes the basic interface of IUnknown and its methods.
Mastering string processing-how to handle strings in COM code.
Apply COM Technology-example code to illustrate all the concepts discussed in this article.
Handle Hresult--hresult type descriptions, how to monitor errors and success codes.
What the hell is com--?
Simply put, COM is a way to share binary code across applications and languages. Unlike C + +, it advocates source code reuse. ATL is a good example. Source-level reuse is good, but only for C + +. It also brings the possibility of name collisions, not to mention the continual copying and reuse of code that leads to engineering bloat and bloat.
Windows uses DLLs to share code at the binary level. This is also the key to the operation of Windows programs-reuse Kernel32.dll, user32.dll and so on. But DLLs are written for C interfaces and can only be used by C or the language that understands the C call specification. The programming language is responsible for implementing shared code, not the DLLs itself. In this way, the use of DLLs is limited.
MFC introduces another MFC extended DLLs binary sharing mechanism. However, its use is still limited-it can only be used in MFC programs.
COM solves these problems by defining binary standards, where COM explicitly states that binary modules (DLLs and exes) must be compiled to match the specified structure. This standard also sets out exactly how COM objects are organized in memory. The binary standard for COM definitions must also be independent of any programming language (such as named adornments in C + +). Once these conditions are met, it is easy to access these modules from any programming language. The compiler is responsible for the resulting binary code compatible with the standard. This makes it easier for later people to use these binary codes.
In memory, this standard form of COM objects is occasionally used in C + + virtual functions, so that's why many COM code uses C + +. But remember, the language used to write the module is irrelevant because the resulting binaries are available for all languages.
In addition, COM is not Win32 specific. Theoretically, it can be ported to UNIX or other operating systems. But I never seem to have heard of COM outside of Windows.
Definition of basic elements
Let's look up from the bottom. An interface is nothing more than a set of functions. These functions are called methods. Interface names begin with uppercase I, such as ishelllink in C + +, and interfaces are designed as an abstract base class, with only pure virtual functions.
An interface can inherit from other interfaces, and the principle of inheritance here is like a single inheritance in C + +. Interfaces are not allowed for multiple inheritance.
CoClass (the Component object class--component object classes) is contained in a DLL or EXE and contains the code for one or more interfaces. Component Object Classes (COCLASSS) implement these interfaces. A COM object is represented in memory as an instance of a Component object Class (COCLASSS). Note that COM "classes" and C + + "classes" are not the same, although the COM class is often implemented as a C + + class.
A COM server is a binary (DLL or EXE) that contains one or more coclass.
Registration (registration) is a process of creating a registry portal that tells the Windows operating system where the COM server is placed. Canceling registration (unregistration) is the opposite-removing these registration entries from the registry.
The GUID (homophonic is "fluid", meaning that the global unique identifier--globally unique identifier) is a 128-digit number. It is a way of labeling independent of the COM programming language. Each interface and coclass has a GUID. Because each GUID is globally unique, it avoids name collisions (as long as you create them with the COM API). Sometimes you run into another term uuid (meaning the global unique identifier--universally unique identifier). The use of UUIDs and GUIDs is the same in practice.