Okay, here is the translation following your instructions: COM principles and applications

Author: Pan Aizhong
Editor-in-Chief: Liu Tong / et al.
Publisher:
Publish Date: 2002-03-01
Features: This book not only introduces the basic principles of COM and its extended knowledge but also covers some aspects of MTS and COM+. The book is divided into three parts: Part I is COM Basics, Part II is COM Extensions, and Part III is COM Applications and Development, introducing the concept of component-based programming design and the multi-layer software architecture model. After learning the basic principles of COM, readers can combine the concepts advocated by MTS and COM+ to understand and use COM and COM+ at a higher level.
Excerpt:
nbsp; COM, which stands for Component Object Model, is an object model that publishes components as units of distribution. This model enables various software components to interact in a unified manner. COM provides both the specification for component interaction and the environment for implementing such interaction. Since the interaction specification of component objects is not dependent on any specific language, COM can also serve as a standard for collaborative development across different languages. Even if readers are not yet familiar with COM, they may be familiar with OLE (Object Linking and Embedding, object linking and embedding). OLE technology is based on the COM specification, and OLE fully leverages the advantages of the COM standard, making applications on the Windows operating system highly interactive. Without OLE support, the Windows operating system would be much less impressive. However, the COM specification is not limited to OLE technology. In fact, OLE is merely one application of COM. In recent years, with the rapid development of network technology, OLE has shown significant limitations in network interconnection, while COM has demonstrated strong adaptability. As a result, over the past two years, with the growth of the network, COM has also had the opportunity to shine. Following OLE, Microsoft introduced a series of technologies based on COM,ActiveX technology, which fully illustrates the application value of COM. This chapter will provide a general overview of COM, giving readers a basic understanding of it.
1.1 The Origin of COM
As a component-based software model, the development process of COM is quite interesting. Initially, Microsoft did not deliberately develop a component-based system. However, as the interaction between applications in desktop window systems deepened, COM emerged during the development of OLE. Further development has shown that the component standards defined by COM are far more extensive than those of OLE. Therefore, in the context of the evolution of component-based software, Microsoft took a shortcut. From the beginning, COM had excellent application prospects. However, in the past few years of software development, although COM has performed well as a model standard for component-based software, actual progress has not been smooth. I believe the reason may be that OLE technology is too complex, and OLE programs are too complex, making it difficult for ordinary people to understand the underlying mechanisms of OLE. Especially when learning COM through OLE is like putting the cart before the horse. We can also say that OLE obscured COM technology, and even the shortcomings of OLE overshadowed the strengths of COM. However, this situation has improved significantly. People have gradually realized that COM meets the current needs of the software industry, and using COM for software architecture is an ideal application solution. Moreover, after separating from OLE, COM itself has undergone significant development and is now widely used in various Microsoft software products.
1.1.1 The Development History of OLE
Literally, OLE represents the concept of compound documents (compound documents), and even the first version of OLE (OLE1) was limited to this. It should be noted that in OLE1, communication between component programs and client programs did not use the COM specification but rather a mechanism called Dynamic Data Exchange (DDE, Dynamic Data Exchange). DDE is based on the message mechanism of the Windows operating system, and its biggest drawback is low efficiency and poor stability, making it inconvenient to use. These defects of DDE also limited the development of OLE1. Therefore, in the second version of OLE (OLE2), Microsoft rewrote the underlying code, abandoned DDE, and adopted a new COM model. As a result, OLE2 became a software system structured with COM. Due to the adoption of COM, OLE2 was more efficient than OLE1, and its stability and flexibility were greatly improved. In subsequent developments of OLE, the use of COM as the underlying structure and COM interfaces (interfaces) as the standard for communication between programs made module customization and expansion of OLE very convenient. Here, I might as well mention the version upgrade method of software. Generally, when upgrading a version of an application system, new software modules are used to completely replace old program modules. Therefore, upgrading means a complete update, for example, OLE2 upgrading OLE1, not only replacing software modules but also changing the underlying technology. However, after OLE2, due to the adoption of a component-based software model, each underlying module can be upgraded individually, and new component modules can be added based on the original software modules without changing the existing ones. Therefore, after OLE2, OLE technology was no longer limited to "object linking and embedding" or composite documents but became a general term for program communication on the desktop system. As a result, while people were waiting for "OLE3" to appear, OLE was no longer the original OLE. Moreover, the OLE system on users' computers was quietly being updated.
1.1.2 The Emergence of Components
In the early days of computer software development, an application system was often a single application program. The more complex the application, the larger the program, and the greater the difficulty of system development. Moreover, once a version of the system was completed, the application would not change until the next version was released. For large programs, the cycle for updating versions is very long, and between two versions, if the operating system changes or the hardware platform changes, it is difficult for the application system to adapt to such changes. Therefore, such monolithic applications no longer meet the needs of computer software and hardware development. From a software model perspective, a natural idea is to divide a large application program into multiple modules, each maintaining a certain degree of functional independence. When working together, they complete tasks through interfaces between each other. We refer to each such module as a component. A well-designed application system is often divided into several components, which can be developed, compiled, and even debugged and tested individually. Once all components are developed, they are combined to form the complete application system. When the external software and hardware environment of the system changes or user requirements are modified, it is not necessary to modify all components but only the affected components, and then recombine them to obtain the new upgraded software. Figure 1.1 illustrates such an upgrade process.