Basic concepts of automation: APIs and plug-ins (addin)

Secondary development interface (API) and plug-in (addin)

Xu Shiwei (copyright statement)
2007-4-20

In the previous article, we have explained:

• Basic concepts of automation: COM components and interfaces)
• Basic concepts of automation: variant and dispatch)

At the same time, we may often hear the following words:

• Automation (COM automation)
• OA (office automation)
• Secondary Development Interface (application development interface, application programming interface, API)
• Plugin (addin, addon)

And so on. This article attempts to explain these concepts.

Automation, as its name implies, refers to "Enabling machines to automatically complete specific tasks without human intervention ". To achieve this goal, the core idea of automation technology is that applications need to integrate their core functionsDom ModelTo allow others to use thisDom ModelTo use the functions of the application. This is what we usually call the Application Programming Interface-Application Programming Interface (API for short. To distinguish it from programming interfaces such as Windows APIs, we introduce a proprietary term called"Secondary Development Interface". "Secondary DevelopmentIt is intended to "redevelop on the basis of existing applications ". If you want to treat the operating system as a larger application, there is no major difference between the secondary development interface and Windows API (although we know that Windows API is not provided in the form of COM components ).

Understanding automation, OA (office automation, office automation) is a good explanation, it is nothing more than the application of office software. OA refers to the automation of office (including document circulation) systems.

When an application provides APIs, we can use these APIs in two ways. The first method is to use an application as a server to provide external services through APIS. In this case, the application is just a service program of the exe com server. As long as we understand what the LPC or RPC call between processes is, everything is very easy. The second method is to implement an application plug-in (addin ). This method is more interesting. First of all, this is a kind of in-process call, which is very efficient. Secondly, this is a two-way communication. The application perceives the existence of the plug-in through the plug-in mechanism provided by the application and loads the plug-in. The plug-in obtains the activity right, use the API of the application to complete specific functions. Finally, and most importantly, the integration of plug-ins and applications actually expands the capabilities of applications and makes the applications more powerful.

The Startup Process of the plugin (addins) is as follows:

1. Start the application. Obtain the list of plug-ins through the registry (or stored anywhere else. Plug-ins are generally provided in the form of COM components. Therefore, you only need to have a list of plug-ins CLSID or progid. In addition, the functions of plug-ins can vary widely, but they need to implement a unified interface, such as _ idtextensibility2 or something similar. This interface is used in the second step below.
2. Traverse the plug-in list and create and initialize Each plug-in. The key is initialization. Of course, the application does not know what the plug-in wants to do. It just gets _ idtextensibility2 (or similar interfaces) and calls the initialization function (such as onconnection ).
3. The plug-in obtains the initialization opportunity. Note that during initialization, the applicationDom ModelIs passed in. In _ idtextensibility2, the root interface is defined as the idispatch type, that is, idispatch * application. But it can actually be more common, such as iunknown * application. With this application pointer, the plug-in can do whatever it wants and call any API it wants to call.

From the extension (addins), you can talk about a lot of content. However, this is not the intention of this article. Therefore, we can only wait for the opportunity to continue this topic. However, I can't help but start with the topic: Because the plug-in (addin) mechanism makes the application structure more flexible, more and more software architectures, the pursuit of a super lightweight kernel (that is, the application we call it the kernel, because it is the core of everything in the Organization), and more functions through the plug-in (addin). A lightweight kernel means that an extra key point needs to be addressed: the plug-in (addin) not only extends the functions of the application, but also extends the APIs of the application, these APIs are seamlessly integrated with the APIs of the original kernel, so that the entire system can roll larger and larger like a snowball.