CN112363780A

CN112363780A - Method for realizing dynamic link of software

Info

Publication number: CN112363780A
Application number: CN202011364319.4A
Authority: CN
Inventors: 王志平
Original assignee: Individual
Current assignee: Individual
Priority date: 2020-11-29
Filing date: 2020-11-29
Publication date: 2021-02-12

Abstract

Artificial intelligence (hereinafter AI) is the main technical embodiment of ICT in the future, wherein the most critical factor "learning" is almost the complete embodiment of "intelligence" in AI. "learning" of AI is not based on "memory" learning, but rather on "method" learning. Therefore, the more powerful chip cannot be an AI, and only the software running on the chip can be an AI. When we are accustomed to defining software starting from the main function, we limit the software as the only space that can become the vast majority of the AI's when we consider that the dynamically linked library is "live" in the case that we must own the main function. The invention provides infinite play space for software to move towards AI, and the thinking space which can be expanded by the software is consistent with the thinking expansion space required by the AI which is recognized by people.

Description

Method for realizing dynamic link of software

Technical Field

The invention relates to the technical field of software design and computers, in particular to a method for realizing dynamic linking of software.

Background

In a practical sense, the computer technology has the meaning of solving the problem, and exactly the problem about mental labor which needs to be solved. Given that time is sufficient, energy is sufficient, and everyone is willing to provide mental work indefinitely, then nature does not require a computer. However, it is obviously not possible to dispense with a computer, and it is clear that there is no specific answer to how a computer will be developed in the future, or what is the ultimate goal of computer technology. It is certain that computer technology will naturally replace the human mind. In other words, the development of computer technology may never have a specific ultimate goal, but the development of computer technology will always move towards AI (acronym for Artificial Intelligence).

Computers are made up of two broad categories, namely "hardware" and "software". Then, whether "hardware" or "software" can represent the direction of computer development, perhaps, this problem has not yet given an exact generally accepted theorem. However, the idea here is that "hardware" techniques can theoretically move toward the ultimate end, while "software" techniques can theoretically move toward the other extreme, i.e., infinite divergence, or infinite expansion. This is not really difficult to prove, but is a matter of time. In an objective sense, the human brain is the "computer hardware" consisting of carbohydrates, whereas the "computer hardware" in our eyes consists of chips and other components. In fact, from an evolutionary objective point of view, the human organism has evolved towards something that is not more and more robust and safer. However, "software" running in our brain, human wisdom, has evolved incredibly in an extremely divergent space. Human organisms end up in the end (or degenerate) and human wisdom goes to a larger expansion space. Thus, a generally accepted theorem may not be needed at all, since computer technology goes to AI not "hardware", but "software".

However, under existing software background, "hardware" is often considered more to implement the functionality of AI. This is not without reason, one is that in the existing AI application scenario, at the edge of AI definition, the application of showy occupies almost all of the AI utility technology, in other words, the existing AI technology does not require the software itself to have the ability to "think"; secondly, any software (including a dynamic link library) has a role in an Application scenario, which is to have a unique API Interface (i.e. an input/output Interface), but a huge number of functional processing units are packaged inside the software, on the contrary, the hardware is not in the implementation process, and the Interface between the hardware actually has more forms of input and output according to different applications. In the first point, it is obvious that in the prior art, software actually performs only control operations in the actual AI application from the software framework. With respect to the second point, it is obvious that when the software implements the functions it needs to implement, it bundles an open and divergent requirement space into an API slot, and then further disperses it via the narrow slot step by step to the corresponding specific function implementation unit, which acts as a timing hourglass if it needs to be more vividly described.

The existing software background technology can be seen more carefully, and two major disadvantages still exist:

first, for example, the acrobat control is loaded in word of microsoft office software. Then firstly, the precondition is that acrobat application software needs to be installed, and secondly, a dynamic link library of acrobat needs to be loaded in the word and becomes one of the controls of the word. Therefore, acrobat necessitates a specialized dynamic link library for other programs to fulfill this application requirement like word. However, it is clear that such encapsulation into a dynamically linked library, all of its internal functionality is already implemented in acrobat's application software. Although there is no perceived inconvenience in the process of using the device, it is not uncommon to take up more disk space or more operations in the process of linking the functions we need. However, if these excessive resources are occupied and operated, the software is required to complete itself without manual intervention (i.e. the acrobat designer thinks that the world has no software, which is a word, at all), and the situation is feared to become very embarrassing. Therefore, when a certain software can realize the unlimited extension to the outside, all that can be relied on is to solve the following problems: "who my is", "what i need", "what i can do". If a specific target needs to be considered on the problem of expansion, the method means that the range of expansion can be limited forever (the software cannot be determined to achieve the target of 'thinking', or the software cannot become AI, the human brain has the ability of thinking because objectively, the human brain cannot be limited to what problems can or cannot be imagined, and the direction of imagination of the specific problem by the human brain cannot be limited);

secondly, under the existing software background technology conditions, there are two ways of software outward expansion: "interprocess communication" and "dynamically linked libraries". The 'interprocess communication' realizes the outward expansion of software and is closer to the possibility of 'infinite expansion' in logic view, but the 'interprocess communication' is low in efficiency for being executed in a processor, so that the requirement of outward expansion of the software cannot be met in all ranges of the software by adopting the 'interprocess communication'. In practical applications, the method of "inter-process communication" is often applied only when the processing scale is large and the consumption of "inter-process communication" is small compared to the processing time. Therefore, the method of software external expansion adopted by the absolutely majority of actual software applications running inside the processor is the dynamic link library. However, in the manner of "inter-process communication" or "dynamic link library", all the functional implementation units (functions or dynamic link functions) that may be used by the software function to be extended, but not used in real time, must be loaded inside the extended software function, i.e. the "process" or "dynamic link library" that is packaged into the software function. Therefore, a considerable number of function implementation units having the same function, such as a function like printf, or other general-purpose control, may be repeatedly loaded at a certain time inside the processor. However, in the actual operation of the software, the probability that these forced-loading function implementation units are used or used simultaneously is very small. Software can be expanded to an external infinite extent or an approximately infinite extent, and an absolute goal is whether hardware resources can be recycled or reasonably used. We can imagine that if the human brain simultaneously functions every nerve terminal cell in our skin, and every time it is loaded in the brain, there is a fear that our brain capacity is not enough to do this and there is a fear that we must install a suitable refrigeration device to our brain to ensure that our brain does not "get a fever" for a long time.

Obviously, the existing software background technology cannot enable software to truly move to the AI, because the existing software background technology cannot build a basic software framework, all software can actively and infinitely expand under the basic framework.

Disclosure of Invention

The definition of the program entry of the software of the present invention will have a default, like the program entry of main function in the prior art software background. However, this default program entry will not be the only program entry for a piece of software. Therefore, for the "software" under the technical condition of the present invention, when the operation is started with the default program entry, the "software" can be regarded as starting a certain software under the prior art. When the software starts to run with a non-default program entry, the software automatically becomes a dynamic link library dynamically linked by other software. Therefore, under the technical condition of the invention, the software does not need to specifically compile a dynamic link library for some other application software, and when the software is used by some functional unit of other application software, the software does not need to declare a so-called API for the functional unit in the compiling process. Secondly, all functional units in the software can be directly called by other software without going through any other functional units in the software (including the default entrance program of the software, so any functional unit inside the software can be considered to have own API). For the technology of the present invention, the "software" is only a package, that is, one or more dynamically linkable functions are packaged in a File, hereinafter, the packaged File is referred to as "Dynamic host Process File", which is abbreviated as DMPF, i.e., english abbreviation of Dynamic Main Process File, and the Function where the Default program entry in DMPF is located is referred to as "Default Dynamic host Function", which is abbreviated as DDMF, i.e., english abbreviation of Default Dynamic Main Function.

The functions encapsulated in the DMPF are all used in the form of Dynamic links (including DDMF), and all functions will be referred to as "embedded Dynamic functions" herein, abbreviated as NDFs, i.e., english acronym of Nested Dynamic Function (for DDMF, it can be considered a specific NDF in the DMPF, or default linked NDF). In the technical scheme of the invention, each DMPF can be regarded as a point. Inside a computer, even in a network, there can be many DMPF points, and all the DMPF points can directly form a link relation or indirectly form a link relation. Moreover, between two DMPF points directly forming a link relationship, the internal NDFs can be directly called with each other (i.e. the NDFs in different DMPFs can be directly linked without an API (application program interface) of the DDMF).

In the technical scheme of the invention, the link relation is formed without depending on an API (application programming interface) declared in the compiling process. Any DMPF need only compile all NDF source code directly into machine code during its design and compilation process, and does not need any preparation for linking or being linked. The key information about the ability to form link relationships with other DMPFs is stored in a text File called "Dynamic Library File", abbreviated DLF, english abbreviation of Dynamic Library File. The Path of DLF of a certain DMPF is called PDLF, namely the abbreviation of Path to DLF, and PDLF is a character string. PDLF would be part of the DMPF and placed in the file header of the DMPF, in characters between PDLF and DMPF binary machine code; "or other characters as delimiters. So, in the header of a DMPF, starting with the first byte after encountering the first delimiter, is the starting address of the DMPF and all other NDFs. And the offset address of all NDFs (including DDMF) in the DMPF in the MDPF takes the start address as the base address (DDMF offset address is 0). The DMPF may not insert a PDLF at the time of compilation, that is, the first byte of the DMPF is binary machine code, and the PDLF is inserted in the DMPF file header manually after completion of compilation or by a tool (the PDLF may also be inserted by default by the compiler when the DMPF is compiled). The DLF is also a text file, after the MDPF is compiled, the compiler automatically generates a default DLF, and the DLF file records necessary relevant information for each NDF. The Record Information corresponding to each NDF is called "DMPF Information Record Entry", which is abbreviated as DIRE, i.e., an abbreviation of DMPF Information Record Entry, and the DIRE contains the following necessary Information:

1. "Dynamic Link notation", abbreviated DLS, the abbreviation of Dynamic Link Symbol, DLS is the unique identifier of NDF in operation for finding the location of a specific NDF code. During the process of completing the DMPF compiling, the compiler allocates a default DLS which is not repeated with other NDFs for each NDF. DLS is a digital character string, and in the process of loading DLF into the memory, DLS can be converted into a specific binary numerical value;

2. "Dynamic Link Path", abbreviated PDL, is an abbreviation of Path to Dynamic Link, which is a Path to an external DMPF. The DMPF may have an NDF whose actual execution code is empty in its inside, and only "function and input/output description information" of the NDF is described in a source code of the NDF, which indicates that the NDF exists in another DMPF, and the PDL is a path pointing to the DMPF. If the NDF described by the current DIRE does exist in an external DMPF, the compiler makes the PDL a specific character (e.g., "-) to indicate that the NDF described by the current DIRE exists in an external DMPF. After the DMPF compilation is complete, the PDL may be modified manually or by dedicated software, or modified by itself during the DMPF run. If the NDF described by the current DIRE is present in the home DMPF, the compiler makes the PDL null (or other special character) to indicate that the NDF described by the current DIRE is present in the home DMPF;

3. "external DLF", abbreviated FDLF, an abbreviation for Foreign DLF. The FDLF file has the same structure and function as the DLF file except that the FDLF field does not exist in the FDLF file, but the FDLF describes information of the external DMPF. When the PDL of a DIRE is not empty (or other specific character), it indicates that the NDF described by the DIRE exists in the external DMPF. Then, the external DMPF also has its DLF for recording information of the external DMPF. After the compiler finishes compiling the DMPF, the value of the FDLF field is not specified but is left empty, and the FDLF field can be modified manually or by special software. It should be emphasized, however, that the FDLF field in the DIRE is only a file name and does not contain a directory path, i.e., the FDLF file must be the current directory where the DMPF is located. Because of the fact that the FDLF here is not a source DLF for the external DMPF, but a replica of the external DMPF source DLF, the DLS in the FDLF cannot be duplicated with the DLS in the current DLF. Therefore, when the DMPF finds that the FDLF is empty during the operation process and the PDL indicates an external DMPF, the DDMF will automatically find a specific external DMPF according to the PDL information during the process of loading the DLF, then find the source DLF of the external DMPF, complete the replication of the source DLF of the external DMPF, and complete the distribution of the DLS in the FDLF. When the DDMF loads the DLF in operation, the information of the FDLF is loaded at the same time (but the information of the DLF source of the external DMPF is not loaded,. the loading refers to loading the software resource into the memory or cache of the processor, and the unloading refers to releasing the memory or cache resource occupied by the software);

4. "function and input/output description Information" is abbreviated as NDFI, which is an abbreviation of NDF Information, and NDFI is a function implemented by the NDF described by the current DIRE and describing an input data structure and an output data structure of the NDF according to a certain rule or protocol. The function description information and the input/output data structure information of the NDF are embodied in the NDF source code, so that the NDFI can be synchronously completed when the compiler finishes compiling the DMPF. When the DDMF loads DLF (fully distributed flag) which is FDLF (fully distributed flag), the DLS is associated with a pointer called by NDF in software through the information of NDFI;

5. "Offset Address", abbreviated NDFO, an abbreviation for NDF Offset, which denotes the Offset address of NDF in DMPF as described by DIRE.

In summary, DDMF needs to load information in DLF and FDLF files at the beginning of startup and build its necessary data structures inside its software for saving the loaded information, but it does not mean that DDMF needs to load the procedures of NDF described by all DIREs. In the technical scheme of the invention, the software is loaded before the NDF needs to be used for a specific NDF loading time, and the loaded NDF is kept in the memory until the DDMF unloads the NDF from the memory (after unloading, the NDF still needs to be loaded again if the NDF is used again next time). Therefore, according to the technical scheme of the invention, when a certain DMPF is used, all NDFs contained in the DMPF are not required to be loaded into the memory at any time, only the NDFs required to be used are required to be loaded, and the loaded NDFs which are not used for a long time can be timely unloaded, so that the high-efficiency cyclic use of hardware resources is realized.

In conclusion, under the condition of good manual intervention, the scheme of the invention can quickly achieve dynamic link among different modules of the software without losing any efficiency.

In conclusion, the scheme of the invention can link the self-required function modules in a software-based automatic search mode without any manual intervention. Therefore, in the case where the software only depicts a framework and the DDMF is implemented with a related search function, and the above-mentioned each NDF does not have any actual execution content, the DDMF is activated, and the software can "make" a complete self-contained software without any manual intervention. Moreover, the software can completely use a search algorithm according to the character description of a higher-level language, the software completes function expansion by itself, and the expansion space is not limited, so that the machine code and the algorithm with a certain thinking mode can realize true AI together.

Drawings

FIG. 1 illustrates A, B, C three DMPFs with a ring link relationship, respectively, as shown in the DMPF_A、DMPF_B、DMPF_C. As shown in the figure, lines A1-A9, B1-B9, and C1-C9 with arrows respectively represent DMPF_A、DMPF_B、DMPF_CThe link relationship generated in actual operation as the host process entry (in the link relationship shown in fig. 1, DMPF_A、DMPF_B、DMPF_CAny of which may become an example software portal);

shown in FIG. 1, DLF_A、DLF_B、DLF_CAre respectively expressed as DMPF in the example_A、DMPF_B、DMPF_CA corresponding source DLF;

shown in FIG. 1, FDLF_A1Expressed as DMPF_AWhen the DDMF in the middle is used as a software inlet, the DMPF_ALinking to a DMPF_BThe resulting FDLF;

shown in FIG. 1, FDLF_A2Expressed as DMPF_AWhen the DDMF in the middle is used as a software inlet, the DMPF_ALinking to a DMPF_CThe resulting FDLF;

shown in FIG. 1, FDLF_B1Expressed as DMPF_BWhen the DDMF in the middle is used as a software inlet, the DMPF_BLinking to a DMPF_AThe resulting FDLF;

shown in FIG. 1, FDLF_B2Expressed as DMPF_BWhen the DDMF in the middle is used as a software inlet, the DMPF_BLinking to a DMPF_CThe resulting FDLF;

shown in FIG. 1, FDLF_C1Expressed as DMPF_CWhen the DDMF in the middle is used as a software inlet, the DMPF_CLinking to a DMPF_AThe resulting FDLF;

shown in FIG. 1, FDLF_C2Expressed as DMPF_CWhen the DDMF in the middle is used as a software inlet, the DMPF_CLinking to a DMPF_BThe resulting FDLF;

shown in FIG. 1 as DMPF_AFor example, the "program code" shown refers to a program containing a DMPF_ASoftware code (including DDMF) including all NDFs inside. The character shown "; "is a separator between the PDLF and the" program code "in this example, and the separator is not limited to be only the separator in the technical solution of the present invention; ", other characters are also possible in practical application;

shown in FIG. 1 as DLF_AFor example, a DIRE per line is shown, representing the description of information for a certain NDF (including the necessary fields of DLS, PDL, FDLF, NDFI, NDFO, described above). The character shown ": "is a separator between fields, and the technical solution of the present invention does not limit that the separator can only be": ", other characters are also possible in practical applications. The character shown "; "is an end-point for each row of DIREs, and the technical solution of the present invention does not limit the end-point to be only; ", other characters are also possible in practical applications. The character shown ": : "the fields indicating the sequential locations are empty;

as shown in FIG. 1, A1-A9, B1-B9, and C1-C9 have the same link logic, and DMPF is used hereinafter_AFor example, the link relationship shown in the figure is explained as follows:

a1: when DMPF_ABy a process (i.e. DMPF)_AParent process) as the object of the newly created child process (i.e., parent process link DMPF_AThen, with DMPF_ADDMF in (r) as a program entry for a child process), the parent process first accesses from the DMPF_AFile headerGet PDLF information, start DMPF_AAnd passes the PDLF information as input to the DDMF. As shown in A1, DDMF finds DLF from PDLF_AA file. DDMF on DLF_ALoading into memory and according to DLF_AOriginal DLS (i.e. recorded in DLF)_AAssigned DLS in (e)) building the most basic link relation data structure;

a2, A6: DDMF completion vs DLF_AAfter loading, the DIREs belonging to the external DMPF are queried in turn, such as DLF in FIG. 1_ADLS as shown₁And DLS₂The DIRE where it is located. Finding DMPF as shown in A2 and A6_BAnd DMPF_C；

A3, A7: DDMF against DMPF_BAnd DMPF_CPDLF information recorded in the header, as shown in A3 and A7, finds PDLs_BAnd PDL_C；

A4, A8: DDMF loads external DMPF related information (i.e., DMPF)_BAnd DMPF_CRelated information). If DLF is present_AMiddle FDLF_A1Or FDLF_A2If it is empty, then copy DLF_BOr DLF_CDIREs in the file, a DLS is assigned to each DIRE. As shown in A4 and A8, respectively, in DLF_ALocation directory creation FDLF_A1Or FDLF_A2Separately recording from DLF_BAnd DLF_CAnd obtaining the obtained DIRE information and FDLF_A1Or FDLF_A2File name of (2) to DLF_AThe corresponding position. In creating FDLF_A1Or FDLF_A2To create FDLF_A1For example, it obtains DLF_BInformation in (1), e.g. DLF_BDLS as shown₁The corresponding DIRE pointed to by DLF_ANDF of home in (1), so when DDMF finds a DIRE from an external DLF (e.g., from a DLF)_BDLS in (1)₁Corresponding DIRE) is a home NDF, DDMF ignores DIREs from outside DLFs and copies the home corresponding DIRE to a corresponding location in a corresponding FDLF (e.g., FDLF LF)_A1DLS shown in (A)₀The corresponding DIRE is a duplicate from DLF_AMiddle DLS₀The corresponding DIRE);

A5、a9: DDMF loads external DMPF related information (i.e., DMPF)_BAnd DMPF_CRelated information). If DLF is present_AMiddle FDLF_A1And FDLF_A2None are empty, DDMF loads FDLF directly, as shown by A5, A9_A1And FDLF_A2。

Detailed Description

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following description will be made with reference to the accompanying drawings. It is obvious that the drawings in the following description are only some examples of the invention, and that for a person skilled in the art, other drawings and embodiments can be obtained from them without inventive effort.

For the sake of simplicity, only the parts related to the present invention are schematically shown in the drawings, and they do not represent the actual structure or flow of the product. Moreover, to facilitate understanding of the drawing figures, some of the figures may have identical structures or features, only one of which is schematically depicted or only one of which is labeled. In this document, "one" means not only "only one" but also a case of "more than one".

Example 1

In an embodiment of the present invention, the implementation of compiling a software source code in the technical solution of the present invention includes the steps of:

1. preparing before compiling, and declaring the function, the input data format, the output data format, whether the external DMPF comes, whether PDL is specified and whether the external DMPF is used as a DDMF of a source code of each NDF;

2. the compiler compiles the source code to generate a DMPF, and makes the offset address of the DDMF in the "program code" 0 to generate an inherent DLF file (DLF shown in fig. 1) corresponding to the DMPF_A) And the DLF file name, i.e. PDLF, is placed in the DMPF file header in a character string encoding manner (which may be ASCII or other character string encoding), and in characters "; "or other characters as delimiters separate the PDLF from the" program code ".

Example 2

On the basis of embodiment 1, an embodiment of the present invention, in the technical solution of the present invention, implementing basic initialization of the first operation of DDMF in DMPF, includes the steps of:

1. one process (father process) prepares to start another process (child process), and links the DDMF in the DMPF as a program inlet, the father process reads the PDLF information in the DMPF file header, and starts the DDMF by taking the PDLF as the input of the DDMF;

2. the DDMF finds the DLF file according to the PDLF. The DDMF loads the DLF into a memory, and constructs a most basic 'link relation data structure' according to the original DLS (namely the distributed DLS recorded in the DLF);

example 3

An embodiment of the present invention, on the basis of embodiment 1 and embodiment 2, in the technical solution of the present invention, one of initialization scenarios for a DDMF in a DMPF to operate for the first time is implemented, where a precondition of the scenario is that an NDF of an external DMPF to which the DMPF belongs has been assigned a specific PDL, includes the steps of:

1. after the DDMF finishes loading the DLF, the DIREs belonging to the external DMPF are sequentially inquired, and the external DMPF corresponding to the PDL is respectively found;

2. DDMF loads external DMPF related information (FDLF information in DLF is empty at this time). And copying the DIREs in the DLF file corresponding to the external DMPF, and distributing DLS for each DIRE. And respectively creating FDLF in the directory where the DMPF is located, recording DIRE information obtained from the DLF corresponding to the external DMPF, and recording the file name of the FDLF to the corresponding position of the DLF. In the process of creating the FDLF, if the DIRE corresponding to the DLS pointed by the DLF corresponding to the external DMPF points to the NDF in the local DMPF, the DDMF ignores the DIRE from the DLF corresponding to the external DMPF, and copies the DIRE corresponding to the local DMPF to the corresponding position in the corresponding FDLF;

3. and loading all FDLF (fully distributed domain name) and perfecting a link relation data structure.

Example 4

An embodiment of the present invention, on the basis of embodiment 1 and embodiment 2, in the technical solution of the present invention, one of initialization scenarios for a DDMF in a DMPF to operate for the first time is implemented, where a precondition of the scenario is that an NDF of an external DMPF to which the DMPF belongs is not specified to a specific PDL, includes the steps of:

1. after the DDMF finishes loading DLF, the DIRE belonging to the external DMPF is inquired in sequence;

2. DDMF loads external DMPF-related information (PDL in DLF is here "-, or other specific character to indicate that NDF from external DMPF described by the current DIRE is not specified to a specific PDL). The DDMF detects that the PDL value indicates that the current DIRE has no specific PDL, and starts to search matched NDF under a local specified directory and a directory of a specified network address according to the NDFI information in the DIRE;

3. the DDMF searches the matched NDF and records the address information of the NDF in the PDL of the corresponding position;

4. and at the moment, the FDLF information in the DLF is still empty, the DIREs in the DLF file corresponding to the external DMPF are copied, and a DLS is distributed for each DIRE. And respectively creating FDLF in the directory where the DMPF is located, recording DIRE information obtained from the DLF corresponding to the external DMPF, and recording the file name of the FDLF to the corresponding position of the DLF. In the process of creating the FDLF, if the DIRE corresponding to the DLS shown by the DLF corresponding to the external DMPF points to the NDF in the home DMPF, the DDMF ignores the DIRE from the DLF corresponding to the external DMPF, and copies the DIRE corresponding to the home to the corresponding position in the corresponding FDLF.

Example 5

In an embodiment of the present invention, on the basis of embodiment 3 or embodiment 4, the NDF in operation is implemented in the technical solution of the present invention_nDynamically linking NDFs among external DMPFs_n+1The method comprises the following steps:

1、NDF_nobtaining NDF from the "Link relationship data Structure" after loading FDLF, according to DLS_n+1The DIRE information of (4);

2、NDF_nthe PDL in the obtained DIRE is judged to be non-empty, which represents NDF_n+1For the management of external DMPF, loading external DM according to PDL information and NDFO informationNDF in PF_n+1。

Claims

1. The method is realized by indicating the DLF file position of the 'link relation data structure' of the building software in the DMPF file header, and is characterized in that:

PDLF is inserted into the DMPF file header, and characters in the PDLF are coded in ASCII, but the PDLF is not limited to be coded only in ASCII;

and/or

Between PDLF and binary executable code with special characters "; ", but not limited to, the use of only characters"; "as a separator separates the PDLF from the binary executable code.

2. According to claim 1, the method for building a software 'link relation data structure' is realized, and is characterized in that:

constructing a DLF file format, constructing a data structure expressed by the format, and constructing an incidence relation among data units in the expressed data structure;

and/or

Establishing an FDLF file format, establishing a data format expressed by the format, and establishing an association relation among data units in an expressed data structure;

and/or

And constructing an association relation between the DLF file and the FDLF file.

3. According to claim 1 and claim 2, the realization DMPF completes the perfection of the software execution function autonomously by a non-manual intervention method under the condition of only software framework without actual software execution function content, and is characterized in that:

the content of the DLF file and the FDLF file can be modified by NDF in the DMPF;

and/or

The NDF searches for an external DMPF with the software execution function required by the DMPF through the information recorded by the NDFI, and brings the NDF resource information in the external DMPF into a 'link relation data structure' of the software.

4. According to claim 1 and claim 2, the real-time dynamic loading of the required software functional units by the software during operation is realized, characterized in that:

after loading a DLF file, loading an FDLF file and constructing a link relation data structure, the current NDF does not load a program of the target NDF before calling other target NDFs in the DMPF;

and/or

When the current NDF finds that other target NDFs in the DMPF need to be called, loading the target NDF;

and/or

After the target NDF loading is completed, the target NDF may be unloaded by the current NDF.