[0032] Such as figure 1 As shown, the present invention provides a plug-in management method, which includes the following steps:
[0033] A. Abstract the operation interface of the plug-in and encapsulate it into an upper-layer calling interface;
[0034] B. When loading the called plug-in, store the plug-in handle obtained and mark it in the memory to establish the corresponding relationship between the plug-in handle and plug-in management information; the plug-in management information here at least includes: plug-in name, plug-in handle, plug-in called count, And the resident memory attribute bit.
[0035] C. Perform loading, unloading, or search operations on the called plug-in through the upper-layer calling interface and the corresponding relationship between the plug-in handle in the memory and the plug-in management information.
[0036] In order to facilitate the storage of the corresponding relationship between the plug-in handle and the plug-in management information, the present invention establishes a plug-in storage structure in the memory for storing the corresponding relationship between the plug-in handle and the plug-in management information; the plug-in storage structure is a single The form of the linked list is stored in the memory. Each plug-in storage structure correspondingly stores the management information of a called plug-in. Multiple plug-in storage structures sequentially form the single-linked list. The specific structure can be found in Figure 5.
[0037] It can be seen from the above methods that the present invention provides unified management of plug-ins, which includes the following aspects: 1. Unified interface: plug-in loading, plug-in symbol search, plug-in unloading, resident plug-in and other plug-in operation interfaces are abstracted, Form a unified upper call interface. 2. Unified storage: The handle returned after opening the plug-in is the mark of the plug-in in the memory. It is stored in a unified new structure with the plug-in name string, number of calls and other necessary management information. 3. Through a unified interface and unified storage, the implementation details of different operating systems are shielded upward to complete the cross-platform use of plug-ins.
[0038] Based on the above several advantages, the present invention can be extended to different operating systems. In the plug-in management, the plug-in application interfaces of different operating systems are also uniformly packaged into plug-in loading, symbol search, and plug-in uninstall interfaces. This separates the differences in the implementation of different operating systems from the unified management of plug-ins. To extend the new operating system, plug-in management only needs to use the system interface to complete the encapsulation of plug-in loading, symbol search, and plug-in unloading interfaces to realize the extension of plug-in management.
[0039] The plug-in uses a character string to call the symbol resources in the plug-in, and the method of the present invention can be widely applied to operating systems that support dynamic loading. Some operating systems may not support the use of static shared libraries. Considering that the static library itself does not have a corresponding calling relationship between strings and symbol resources, in order to adapt the method of the present invention to the use of static libraries, such as figure 2 As shown, the following step is added before the above step A: establishing a static plug-in resource configuration file for storing the correspondence information between the symbol call address and the symbol call string in the called plugin library. The static plug-in resource configuration file is used here to complete the storage of the relationship between strings and symbol resources. In addition, the plug-in loading, symbol search, and plug-in unloading interfaces are implemented and encapsulated in the same way as dynamic loading, realizing static loading of plug-ins.
[0040] Based on the above method, the present invention also provides a plug-in management system, such as image 3 As shown, it includes: an external interface module, which is used to abstract the operation interface of the plug-in, and encapsulate it into an upper-layer calling interface for communicating with upper-layer application software; an internal interface module, which is used to load the called plug-in, will get The plug-in handle is stored and marked in the memory, and the corresponding relationship between the plug-in handle and the plug-in management information is established; the internal interface module is called by the encapsulation function of the external interface module.
[0041] The principle is: such as image 3 As shown, according to the above plug-in management method, the entire plug-in management is divided into two layers:
[0042] The first layer is the external interface module facing the upper application, abstracting the similarities of the various platform operations of the plug-in management. Abstract plug-in loading, symbol search, plug-in unloading, and resident plug-in interfaces for plug-in use, implement the common management operations of plug-in management in these interfaces, and use a unified structure to store handle, plug-in name, number of calls, and resident Memory attribute bits and other information, realize unified management and unified storage.
[0043]The other layer is that the internal interface module is implemented by the operating system, which encapsulates the differences between the various platforms managed by the plug-in, and uses the application program interfaces of different systems to implement the same plug-in loading, symbol search, and plug-in unloading functions for external interface calls. In this way, if you need to extend the plug-in management in the new system, you only need to encapsulate the system application program interface into a unified form. The static loading system, like other dynamic loading systems, is also encapsulated in this layer, except that the functions of plug-in loading and symbol positioning are realized by combining the static plug-in information configuration file and the search function. Based on this description, it can be seen that the aforementioned internal interface modules include:
[0044] A plug-in storage structure established in the memory for storing the corresponding relationship between the plug-in handle and the plug-in management information; the plug-in storage structure is stored in the memory in the form of a singly linked list, and each plug-in storage structure corresponds to storage For the management information of a called plug-in, multiple plug-in storage structures sequentially form the singly linked list. For the specific structure, please refer to Figure 5.
[0045] And the static plug-in resource configuration file established in the memory is used to store the correspondence information between the symbol calling address and the symbol calling string in the called plug-in library. The static plug-in resource configuration file here is mainly used in operating systems that support static shared libraries.
[0046] The following will be attached Figure 4 with 5 , Describe in detail how to use the method and system of the present invention to perform plug-in management from the following aspects, that is, load, unload, or search for the called plug-in.
[0047] First, the loading operation of the application plug-in on the operating system platform is as follows:
[0048] The first step is to create a plug-in storage structure for storing the management information of the called plug-in. This structure is used as a carrier of common information of different operating systems to store some management information of the called plug-in, such as the name of the plug-in, and the plug-in handle. Plug-in is called count, and resident memory attribute bit, etc.;
[0049] The second step is to complete the work of loading the called plug-in and initialize the plug-in storage structure by calling the upper calling interface, that is, obtain the plug-in handle of the called plug-in, store it in the plug-in storage structure, and use the called plug-in as a subsequent operation Of the logo. Such as Figure 5 As shown, when the program calls multiple plug-ins, the plug-in structure is stored in the memory in the form of a singly linked list, and the plug-in storage structure storing the newly opened plug-in information is added to the head of the singly linked list. Each plug-in storage structure correspondingly stores the management information of a called plug-in, and multiple plug-in storage structures sequentially form the single-linked list. The specific plug-in loading process is completed by calling different system interfaces of the operating system.
[0050] Such as Figure 4 with 5 As shown, the plug-in storage structure mentioned in the first step above contains the following plug-in management information:
[0051] (1) Plug-in name (Name), used to search for plug-ins;
[0052] (2) The plug-in handle (handle), as the identification of the loaded plug-in to be operated;
[0053] (3) The plug-in called count (Ref_count) is used to record the number of running programs that call the plug-in. When there is no program to call the plug-in, the plug-in can be really uninstalled;
[0054] (4) The resident memory attribute bit (Is_resident) is used to indicate the resident attribute of the plug-in in the memory. According to this, it can be judged whether the plug-in needs to be unloaded or loaded. Set the plug-in called count and the resident memory attribute bit according to the actual situation, and the plug-in can be unloaded or loaded from the memory when it really needs to be unloaded or loaded. For example, if the resident memory attribute bit is "1", it means that the plug-in needs to be resident in the memory. When the resident memory attribute bit is set to "0", it means that the plug-in does not need to be resident in the memory and can be uninstalled when not in use.
[0055] The above four are basically necessary items. In addition, on the basis of the above four, it may also include: plug-in deconstruction function entry (Unload), which is used to instruct the operating system to uninstall the plug-in. In the initial programming, the destructuring function is preset, and its entry address is recorded in the corresponding position of the plug-in storage structure. If there is no preset deconstructing function, the plug-in is directly uninstalled in a default manner. It can be seen that the present invention shields the upper-layer program from the difference of the underlying operating system realized by the plug-in, and uses the plug-in storage deconstruction body to provide the upper-layer program with a unified use interface of the plug-in. In this way, when the program is transplanted across platforms in the future, there is no need to change the code of plug-in calling and management, so that it has portability. At the same time, the present invention provides a management interface for the loading and unloading positioning symbols of the plug-in, as well as the resident and return plug-in name of the plug-in, and provides additional functional interfaces and more complete security protection on the basis of the realization of the system. It is convenient for users to use and maintain the plug-in.
[0056] After loading the plug-in, the next application needs to obtain the symbols in the plug-in. To locate the symbols in the plug-in, you need to directly process the link information of the symbols. Such as figure 1 As shown, for an operating system that supports dynamic loading, the symbol location application program interface provided by different operating systems can be called through the encapsulation function to directly perform symbol location.
[0057] For systems that do not support dynamic loading and use static shared libraries to implement plug-in functions, because of static shared libraries, the linking operation has been completed before the program is linked, which means that the symbol information has been loaded into the executable file after the application linking is completed. , But to achieve the unification of plug-in calls, the correspondence between character strings and symbol resource addresses is required. The dynamic plug-in library contains this correspondence information, while the static library itself does not contain this information. Here you need to store this information in the form of a static plug-in information configuration file. Corresponding to each static library, the configuration file stores the plug-in name, the total number of symbols, and the symbols. The address and symbol name string correspondence table consists of three parts. Therefore, the static library symbol location function is called through the encapsulation function, the symbol location configuration information provided in advance by the static shared library provider is searched through this function, and the plug-in management is implemented by symbol location. The symbol location configuration information file mentioned here records the correspondence information between the internal symbol call address of the called plug-in library and the symbol call string, which can be set in advance. The above-mentioned symbol positioning configuration information file, packaging function, and symbol positioning application program interface, together with the plug-in handle stored in the plug-in storage structure, complete the complete operation of symbol positioning. Therefore, the above-mentioned symbol positioning configuration information file, packaging function, and The symbol location application program interface is associated with the plug-in handle stored in the plug-in storage structure to ensure that other related information can be found based on certain information. In order to complete the above-mentioned plug-in symbol location configuration information, it is necessary to encapsulate the search function when creating a static plug-in information configuration file to realize the search of the plug-in and the search and location of the symbol resources in the plug-in. It can be seen that the present invention completes the same functions as the system plug-in application program interface in the dynamic operating system, and also realizes the extension of plug-in management in the static clip in the system.
[0058] When the plug-in call is completed, the application will release the called plug-in. Since the plug-in is a shared library, it must be ensured that no other program is calling it before it can perform the real unloading action from the memory. Therefore, firstly, according to the resident memory attribute bit in the plug-in storage structure and the plug-in called count, it is judged whether the called plug-in needs to be uninstalled. According to the specific situation, if the plug-in called count shows that the plug-in is not currently called by any program, and the resident memory attribute bit shows that the plug-in does not need to be resident in the memory, the plug-in can be unloaded from the memory. When the called plug-in needs to be uninstalled, the plug-in storage structure is searched, the plug-in handle of the called plug-in is obtained, and the called plug-in is uninstalled according to the plug-in deconstruction function entry or the default mode. The dynamic plug-in uninstalls the plug-in by destructuring function or the default method, and the static plug-in cannot be uninstalled, and it is kept in the memory. After the called plug-in is uninstalled, the plug-in storage structure corresponding to the called plug-in is released from the singly linked list, and the life cycle of the plug-in in the memory is completed.
[0059] It can be seen from the above description that the present invention establishes a plug-in storage structure in the memory to store necessary information such as the handle of the loaded plug-in, and facilitates management such as adding, deleting, searching, etc. in a linked list; internally encapsulating the application program interface of the operating system, It is convenient to realize the scalability of the new system; the configuration information of the static shared library is searched and stored in the plug-in storage structure, which shields the difference between dynamic and static shared libraries, and ensures the portability of the upper-level program and the plug-in management mechanism Sex.
[0060] Compared with the prior art, the present invention defines a method for unified management and use of plug-ins, which ensures that users and upper-layer programs that call plug-ins no longer need to know how the lower-layer plug-ins are implemented, whether it is static or dynamic, and which is specific. This kind of dynamic, just use a unified interface to manage and use the plug-in. In addition, extract the commonalities between various plug-in implementations for unified storage and management, separate the differences related to the operating system, perform targeted processing, and use configuration files to perform operations on the operating system. Adaptation, for the new plug-in implementation of different platforms that will be added later, only the latter part needs to be changed. This completely realizes the portability and scalability of the software system, and realizes the unified use and management of cross-platform plug-ins.
[0061] The above examples of the specific steps are relatively specific and should not be considered as a limitation on the scope of patent protection of the present invention. The scope of patent protection of the present invention shall be subject to the appended claims.
