CN117075960B

CN117075960B - Program reconstruction method, application cross-platform migration method, device and computing equipment

Info

Publication number: CN117075960B
Application number: CN202311344740.2A
Authority: CN
Inventors: 赵志鹏
Original assignee: Uniontech Software Technology Co Ltd
Current assignee: Uniontech Software Technology Co Ltd
Priority date: 2023-10-17
Filing date: 2023-10-17
Publication date: 2024-01-23
Anticipated expiration: 2043-10-17
Also published as: CN117075960A

Abstract

The invention discloses a program reconstruction method, an application cross-platform migration device and computing equipment, relates to the technical field of application migration, and aims to solve the problem of low migration efficiency of the existing cross-platform application migration technology. The program reconstruction method comprises the following steps: adding a file header for a first file corresponding to a program to be reconstructed to obtain an intermediate file; performing file alignment on the intermediate file to obtain a second file so that the second file meets the file alignment requirement of a second executable program format; and determining all first relocation table entries in the current second file, and changing an absolute address relocation instruction corresponding to each first relocation table entry into a relative address relocation instruction so as to convert relocation of the second file from absolute address-based relocation to relative address-based relocation. The method and the device can improve the migration efficiency of the application across platforms by adding the file header, aligning the file and enabling the repositioning to realize address independence.

Description

Program reconstruction method, application cross-platform migration method, device and computing equipment

Technical Field

The invention relates to the technical field of application migration, in particular to a program reconstruction method, an application cross-platform migration device and computing equipment.

Background

With the rapid development of desktop systems and related technologies, more and more users running office software and entertainment software across platforms are further pushing the development of desktop systems towards more stable and simple technologies.

The disadvantage of the application of ecological absences is further highlighted when the current operation system is developed rapidly, and the cross-platform compatible application is a feasible transition scheme. At present, migration work of operating system related software is basically undertaken by third party companies and operating system manufacturers, and application developers are in a separated state. This is because, on the one hand, the application developer does not know the technology, nor is the application manufacturer high in his will to adapt to it; on the other hand, the operating system manufacturer often treats the application as a black box in the migration process because of no application source code, so that the migration efficiency is very low. Thus, there is a need to improve the migration efficiency of cross-platform migration applications.

Disclosure of Invention

To this end, the present invention provides a program reconfiguration method, an application cross-platform migration method, an apparatus, and a computing device in an effort to solve or at least alleviate at least one of the above-identified problems.

According to an aspect of the present invention, there is provided a program reconstruction method including: adding a file header to a first file corresponding to a program to be reconstructed so as to obtain an intermediate file, wherein the first file has a first executable program format matched with an original operating system, and the file header has a second executable program format matched with a target operating system; carrying out file alignment on the intermediate file to obtain a second file so as to enable the second file to meet the file alignment requirement of the second executable program format; and determining all first relocation table entries in the current second file, and changing an absolute address relocation instruction corresponding to each first relocation table entry into a relative address relocation instruction so as to convert relocation of the second file from absolute address-based relocation to relative address-based relocation.

Optionally, in the program reconstruction method according to the present invention, the first file is a PE file, and the header includes an ELF header.

Optionally, in the program reconstruction method according to the present invention, changing the absolute address relocation instruction corresponding to each first relocation entry to a relative address relocation instruction so that relocation of the second file is converted from absolute address-based relocation to relative address-based relocation includes: for each first relocation table entry, inserting a relative address relocation instruction at a corresponding position of the first relocation table entry; acquiring the offset between the position of the next instruction to be executed and the target position of the first repositioning table item when the current program runs; and modifying the address of the relocation position corresponding to the first relocation table entry into relative offset addressing by utilizing the relative address relocation instruction and the offset.

Optionally, in the program reconstruction method according to the present invention, the inserting a relative address relocation instruction at a location corresponding to the first relocation entry includes: determining a target instruction corresponding to the first repositioning table item to position a function where the target instruction is located; generating a relative address relocation instruction according to the related information of the function, so as to create a second relocation table entry matched with the second executable program format based on the relative address relocation instruction.

Optionally, in the program reconstruction method according to the present invention, the relevant information of the function includes one or more of the following information: the number of instructions of the function; code space of the function; register usage information of the function; access information of the function.

Optionally, in the program reconstructing method according to the present invention, part or all of the relative address relocation instruction is written into a predetermined section when creating a second relocation entry matching the second executable program format.

Optionally, the program reconstruction method according to the present invention further includes: and correcting the offset of the relative address repositioning instruction in the current second file based on the relative addressing instruction contained in the first file.

According to another aspect of the present invention, there is also provided an application cross-platform migration method, including: reconstructing the dependent library of the application to be migrated through the program reconstruction method to obtain a target library suitable for running in a target operating system; and converting the application to be migrated into a target application suitable for running in a target operating system through a compatibility layer, wherein the target application is suitable for directly calling the target library.

According to another aspect of the present invention, there is also provided a program reconstructing apparatus including: the adding unit is suitable for adding a file header to a first file corresponding to a program to be reconstructed so as to obtain an intermediate file, wherein the first file is provided with a first executable program format matched with an original operating system, and the file header is provided with a second executable program format matched with a target operating system; the file alignment unit is suitable for carrying out file alignment on the intermediate file to obtain a second file so as to enable the second file to meet the file alignment requirement of the second executable program format; and the repositioning unit is suitable for determining all first repositioning table items in the current second file, and changing the absolute address repositioning instruction corresponding to each first repositioning table item into a relative address repositioning instruction so as to change the repositioning of the second file from the repositioning based on the absolute address to the repositioning based on the relative address.

According to another aspect of the present invention, there is also provided an application cross-platform migration apparatus, including a reconstruction module and a conversion module: the reconstruction module is suitable for reconstructing the dependency library of the application to be migrated through the program reconstruction method to obtain a target library suitable for running in a target operating system; the conversion module is suitable for converting the application to be migrated into a target application suitable for running in a target operating system through a compatibility layer, and the target application is suitable for directly calling the target library.

According to another aspect of the present invention, there is also provided a computing device including: at least one processor and a memory storing program instructions; when the program instructions are read and executed by a processor, the computing device is caused to perform the program reconstruction method or the application cross-platform migration method as described above.

According to yet another aspect of the present invention, there is also provided a readable storage medium storing program instructions that, when read and executed by a computing device, cause the computing device to perform the program reconstruction method or the application cross-platform migration method as above.

According to the program reconstruction method, the application cross-platform migration device and the computing equipment, at least one of the following beneficial effects can be achieved: by reconstructing the program to be reconstructed corresponding to the application needing to run across the operating system, namely adding a file header, aligning the file and enabling the relocation to realize address independence, the migration efficiency of the application to be migrated across the platform can be improved without consuming a great amount of time and energy; maintenance cost caused by upgrading is reduced; the common development libraries for different applications can be shared, so that the volume of the container is fully reduced; the method solves the problem that the file mapping benefit cannot be enjoyed due to different file alignment modes of different operating systems, so that the memory is increased rapidly during running; by converting the absolute address relocation of the file into the relative address relocation, the problem that file mapping cannot be shared due to relocation can be further solved, and memory occupation can be reduced.

Drawings

To the accomplishment of the foregoing and related ends, certain illustrative aspects are described herein in connection with the following description and the annexed drawings, which set forth the various ways in which the principles disclosed herein may be practiced, and all aspects and equivalents thereof are intended to fall within the scope of the claimed subject matter. The above, as well as additional objects, features, and advantages of the present disclosure will become more apparent from the following detailed description when read in conjunction with the accompanying drawings. Like reference numerals generally refer to like parts or elements throughout the present disclosure.

FIG. 1 illustrates an application topology after migration according to the prior art;

FIG. 2 shows a schematic diagram of a computing device 200 according to one embodiment of the invention;

FIG. 3 shows a topology diagram after processing with a program reconstruction method according to an embodiment of the present invention;

FIG. 4 illustrates a flow chart of a program reconstruction method 400 according to one embodiment of the invention;

FIG. 5 is a schematic diagram illustrating the manner in which a header is added to a PE file in one embodiment;

FIG. 6 illustrates a flow chart of an exemplary process of a file alignment process;

FIG. 7 illustrates a flow chart of an exemplary process of absolute address relocation;

FIG. 8 shows an exemplary flowchart of a sub-process of step 430 in FIG. 4;

FIG. 9 illustrates a flow chart of an exemplary process of relative address relocation;

FIG. 10 shows an exemplary flowchart of a sub-process of step 810 in FIG. 8;

FIG. 11 illustrates a flow diagram of an application cross-platform migration method 1100 according to one embodiment of the invention;

fig. 12 shows a schematic configuration diagram of a program reconstruction apparatus 1200 according to an embodiment of the present invention;

fig. 13 shows a schematic structural diagram of an application cross-platform migration device 1300 according to one embodiment of the present invention.

Detailed Description

Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

As described above, currently, there are more and more users having a requirement to run applications across platforms, for example, users want to run Windows applications or macOS applications on Linux platforms, run Windows applications or Linux applications on macOS platforms, and so on.

For example, to run Windows applications on Linux, without separating Wine (Wine Is Not an Emulator) technology, wine represents a compatible layer for Windows applications to run on Posix (Portable Operating System Interface of UNIX, portable operating system interface) systems. However, since the application developer does not know the Wine technology, the application vendor does not have high adaptation will for Wine, and in addition, the operating system vendor processes the Windows application as a black box in the migration process because of no Windows application source code, so that the migration efficiency is very low.

Moreover, due to this separate state of migration and development, migrated applications often fail to function properly due to untimely or lack of maintenance, which further breaks the experience of these operating systems.

In the prior art, for example, for the distribution of Windows application under Linux, mainly based on the existing condition of Wine, the problem in the running of the application is intensively processed on the premise of not modifying the binary of the Windows application program as much as possible, and when the running state of the application is basically good, the packaging and secondary distribution are performed. The technology comprises the following main processes: downloading a Windows application installation package from an application developer network; initializing a Windows application running container on Linux by Wine, and installing the Windows application in the container; the developer responsible for migration solves the running problem of Windows application under Linux; and (3) testing, packaging and distributing the Wine container with the Windows application and the Wine for repairing Bug (error, fault, defect, vulnerability and the like). Fig. 1 shows an application topology diagram after migration, where application 1 to application N represent N applications of an original Windows operating system (or referred to as a Windows platform), after the N applications are migrated to the Linux platform by using the above prior art, a plurality of compatible layer containers (Wine containers) and a compatible layer resource management end (Wine resource management end) are corresponding, and the lowest part of the topology diagram is a compatible layer client dynamic link library (Wine client Libs, wine client dynamic link library). A Wine container is the execution environment that Wine provides for Windows applications. A WineServer is a component provided by Wine for resource management and allocation, and an application program sends a resource request to the WineServer as a client (wineclent) at runtime. Libs are DLL libraries (i.e., dynamically linked libraries) that Windows applications rely on.

In the process, developers of Windows applications are not involved in the whole process, migration developers patch Wine according to the Bug requirement, and because of no source code, many solutions are only deduced by phenomena and cannot be effectively verified, so that the solutions are possibly not universal, the maintenance cost is high, and the migration efficiency is low. In addition, different Windows applications use independent Wine containers, and as the number of applications installed by users increases, the Wine containers bring about small storage pressure, so that different containers cannot be shared for public Windows development libraries.

Meanwhile, with the upgrade of Windows application, the originally packed container and Wine need to be repackaged and tested, further increasing the maintenance cost. Furthermore, the prior art solutions, which are not optimized for the differences between PE (Portable Executable, executable program format of Windows system) files and ELF (Executable and Linkable Format, executable program format of Unix/Linux system, etc.) files, result in a much higher packet volume and runtime memory footprint distributed on Linux than Windows, which would further severely impact performance for non-X86 processor platforms.

In the following, some terms mentioned in the embodiments of the present invention are introduced.

ELFs are a common binary file format used to represent executable files, shared libraries, and object files.

Relocation (relocation) is an important step in the assembly of target files into executable files by compilers and linkers, and its purpose is to solve the problem of cross-module or cross-file symbolic references, ensuring that the program can execute correctly. The ELF file Position-index Code (PIC, address Independent) can be implemented relatively easily by a Global Offset Table (GOT) and a process link table (Procedure Linkage Table, PLT), i.e., indexing functions or data by means of relative address addressing.

A Global Offset Table (GOT) is a table containing the offsets of the addresses of all global variables and functions. At program loading, the operating system allocates space for the GOT and fills the correct address. In PIC code, global variables and function references will be replaced with references to corresponding entries in the GOT.

The procedure link table (Procedure Linkage Table, PLT) is a table containing calls to functions and code for resolving the addresses of the functions. The purpose of the PLT is to initialize the first time a function is called, and then transfer control to the actual address of the function.

Therefore, aiming at the problem of low application efficiency of cross-platform migration, the invention provides a program reconstruction method and an application cross-platform migration method, which can reconstruct a program to be reconstructed (namely a corresponding dependency library) corresponding to an application needing to run across an operating system, and provide a feasible high-efficiency migration scheme to eliminate the gap between application development and application migration.

FIG. 2 shows a schematic diagram of a computing device 200 according to one embodiment of the invention. It should be noted that, the computing device 200 shown in fig. 2 is only an example, and in practice, the computing device used to implement the program reconstruction method or the application cross-platform migration method of the present invention may be any type of device, and the hardware configuration of the computing device may be the same as that of the computing device 200 shown in fig. 2 or may be different from that of the computing device 200 shown in fig. 2. In practice, a computing device implementing the program reconstruction method or the application cross-platform migration method of the present invention may add or delete hardware components of the computing device 200 shown in fig. 2, and the present invention is not limited to the specific hardware configuration of the computing device.

As shown in fig. 2, computing device 200 typically includes memory 210 and one or more processors 220.

Depending on the desired configuration, the processor 220 may be any type of processing including, but not limited to: microprocessor (μp), microcontroller (μc), digital information processor (DSP), or any combination thereof.

Depending on the desired configuration, memory 210 may be any type of memory, including, but not limited to: volatile memory (such as RAM), non-volatile memory (such as ROM, flash memory, etc.), or any combination thereof. The memory 210 stores at least a target operating system 211 and program instructions 212 for executing a program reconfiguration method or an application cross-platform migration method.

Computing device 200 may be implemented as a server, such as a file server, database server, application server, WEB server, etc., as well as a personal computer including desktop and notebook computer configurations. Of course, computing device 200 may also be implemented as part of a small-sized portable (or mobile) electronic device. In an embodiment according to the invention, the computing device 200 is configured to perform a program reconfiguration method or an application cross-platform migration method according to the invention.

The program reconstruction method according to the embodiment of the invention comprises the following steps: adding a file header for a first file corresponding to a program to be reconstructed to obtain an intermediate file; the first file has a first executable program format matched with the original operating system, and the file header has a second executable program format matched with the target operating system; carrying out file alignment on the intermediate file to obtain a second file so as to enable the second file to meet the file alignment requirement of the second executable program format; and determining all first relocation table entries in the current second file, and changing an absolute address relocation instruction corresponding to each first relocation table entry into a relative address relocation instruction so as to convert relocation of the second file from absolute address-based relocation to relative address-based relocation.

It should be understood that in this embodiment and other embodiments of the present invention, an application scenario in which a Windows application is migrated to a Linux platform is mainly described as an example, but embodiments of the present invention are not limited thereto, and may be other cross-platform application migration scenarios, such as migration of a Linux application to a Windows platform or a macOS platform, migration of a macOS application to a Linux platform or a Windows platform, or the like.

For example, in an application scenario of migrating a Windows application to a Linux platform, a PE library which can be shared can be provided for a PE application through PE file reconstruction, so as to reduce the space and complexity occupied by application distribution. Fig. 3 shows a topology diagram of an example of a Windows program reconstructed by the program reconstruction method of the present invention under the above-mentioned scenario. In fig. 3, in contrast to fig. 1, there is a PE and ELF hybrid shared dynamic link library (PE ELF Mix Shared Libs) between the Wine container and the Wine resource management end to enable reconstruction of PE files.

An exemplary process of the program reconstruction method 400 according to one embodiment of the present invention is described below in conjunction with fig. 4. The above-described program reconstruction method 400 is performed in a computing device (e.g., the aforementioned computing device 200). As shown in fig. 4, the program reconstruction method 400 begins at step 410.

In step 410, a header is added to the first file corresponding to the program to be reconstructed to obtain an intermediate file.

The first file has a first executable program format matched with the original operating system, and the file header has a second executable program format matched with the target operating system.

The original operating system is, for example, a Windows operating system, and the target operating system is, for example, a Linux operating system.

As an example, the first file is, for example, a PE file, and the header includes, for example, an ELF header.

Fig. 5 shows an example after adding the first file to the file header. As shown in fig. 5, the file Header added by the PE file (as an example of the first file) may include an ELF Header (an ELF file Header, as shown by H1), dynamic Section Header (a dynamic section Header, as shown by H2), and TextSection Header (a code section Header, as shown by H3). Furthermore, a relocation entry (relay), i.e., a data area (.data), is also added to the first file. For example, the above H1, H2, and H3 may be packaged using a Wrapper to obtain an ELF Wrapper (as an example of a header), which is added to the PE file to obtain a PE-ELF hybrid file as shown in the right diagram of FIG. 5. The PE-ELF hybrid file is a PE file (as an example of an intermediate file) to which the ELF information is added, and has both PE file properties and partial properties of the ELF file.

Thus, the PE-ELF mixed file can be identified by the loader ld.so on Linux and can be treated normally like native Linux application.

As an example, an initialization function for the transition process may be added to the intermediate file. Because the codes in the PE file cannot be executed by Linux in-situ, the codes in the PE file can be taken over by a PE Loader (PE loading tool) of Wine through the added initialization function, and then the loading of the PE file is completed.

As an example, the added file header may be used to identify dependencies of the original first file to avoid duplicate copies and reloads of the same first file. For example, by adding ELF information (e.g., ELF file header, dynamic section header, code section header, and relocation table entry) as shown in FIG. 5, dependencies of the PE file can be clearly identified, avoiding duplicate copies and reloads of the same PE file.

Next, in step 420, the intermediate file is aligned, and the aligned intermediate file is used as a second file. Therefore, the obtained second file can meet the file alignment requirement of the second executable program format through the file alignment.

For example, the loading mode of the Wine to the PE file is similar to the loading mode of the ld.so to the ELF file under Linux, and the code segments in the PE file are loaded into the memory in a read-only mode by using a file mapping mode, so that the condition that the memory is read by using a file reading mode because of no alignment is avoided. However, if there is no page level, the mapping of the file will fail, and the file is read in by file reading, resulting in a memory surge.

In the prior art, the aligned PE files are usually 512 bytes, and the aligned ELF files are usually 4K bytes, and if the aligned PE files are aligned in a 512-byte manner, the non-4K alignment causes a large amount of memory to be occupied during file reading.

FIG. 6 illustrates one exemplary process of the file alignment process of step 420. It should be noted that, in the example shown in fig. 6, the PE file format is used as an example of the first executable program format, and the ELF file format is used as an example of the second executable program format, but the first executable program format and the second executable program format are not limited thereto, and the first executable program format and the second executable program format may be different for different original operating systems and target operating systems, and are not described herein again.

PE file alignment is 512 bytes, whereas ELF file alignment is typically 4K bytes, and to alleviate the problem of large memory usage due to non-4K alignment, it is necessary to realign PE sections that are not otherwise aligned.

As shown in fig. 6, the read PE file is first loaded in step 610. The loading mode of Wine to PE is similar to the loading mode of ld.so to ELF under Linux, and the code segments in PE are loaded into the memory by using a file mapping mode.

Then, in step 620, the loaded and read PE file is parsed. By the above analysis, a plurality of analyzed segments can be obtained.

Then, in step 630, the parsed multiple sections are used to align the PE files (e.g., page-level).

Next, in step 640, a determination is made as to whether the current page alignment is all completed: if yes, go to step 650 to write the aligned file; otherwise, return to step 630 and re-file alignment is performed again until all are completed. In this way, a 4K aligned PE file (as an example of a second file) is obtained.

That is, in step 630, the unaligned portion (i.e., unaligned PE section) present in the parsed section is page aligned (e.g., 4k aligned) until the re-ending process is complete, and written to disk storage to obtain a 4k aligned PE file.

If there is no page level, the file mapping will fail, which in turn will read in the file using a file read, resulting in a memory surge. By adding the PE file with the page alignment generated by filling, the problem of memory occupation caused by the misalignment of the files in the prior art can be solved under the condition that the size of a single PE file is only slightly increased.

In this way, through the file alignment process of step 420, the PE segments that were not aligned are realigned, thereby greatly reducing the memory occupation.

Next, in step 430, all the first relocation entries in the current second file are determined, and the absolute address relocation instruction corresponding to each first relocation entry is changed to a relative address relocation instruction, so that relocation of the second file is converted from relocation based on absolute address to relocation based on relative address.

For example, the relocation table may be determined by parsing the original first file to determine a relocation table entry therein as the first relocation table entry in the current second file.

When multiple PE files are loaded, relocation is required due to load address conflict. Repositioning is the process of converting the logical address space of a program into the actual physical address space in a memory, and is the basis for realizing the simultaneous operation of multiple programs in the memory. Relocation includes dynamic relocation and static relocation.

The relocation of the PE file is an absolute address offset, and the absolute address relocation mode is shown in FIG. 7. Wherein the Relocation table entry (Relocation) is used to record the instruction location where Relocation is required, the type of Relocation (knowing how to perform Relocation), and other auxiliary information required for Relocation. In the existing case, as shown in fig. 7, due to Copy-on-Write (COW), the relocated PE file cannot use the advantage of file mapping, resulting in additional memory occupation.

Copy-on-write is an operating system technique that is commonly used to share resources (e.g., memory or files) among multiple processes while ensuring that each process does not affect other processes when modifying the shared resources. Copy-on-write of files in Linux is commonly used to handle the following two cases: process replication and memory mapping.

For process replication, when one process (as a parent process) creates another process (as a child process) through a fork function, the child process typically shares the same memory map, including file maps, as the parent process. If any of the parent-child processes attempts to modify the shared file map, a copy-on-write mechanism is triggered to ensure that only the modified portion of the data will be copied without affecting the other processes.

For memory mapping, copy-on-write also applies when multiple processes map the same file to their virtual memory address space through mmap () system calls. If a process attempts to modify the data in the mapped file, only the modified page will be copied to the new physical memory page, while other processes can still share the original data.

In Linux, when multiple processes share the same resource (e.g., file map or memory map), the kernel points the page table entries of the processes to the same physical page. If one of the processes attempts to write to the shared resource, the kernel detects this write operation and triggers a copy-on-write mechanism. The kernel creates a new physical page for the process that triggered the write operation and copies the modified data onto the new page. Then, updating the page table entry of the process to point to the new physical page; the other processes still point to the original shared page and therefore they are unaffected. The advantage of copy-on-write is that it can reduce unnecessary memory overhead, since an actual copy of data only occurs when a process attempts to write. This allows multiple processes to efficiently share resources while maintaining data isolation. However, the prior art cannot take advantage of this because of the absolute address relocation of the PE file, which requires modification of a large number of mapped pages of the file.

Compared with PE files, the relocation of shareable ELF files is generally address-independent, so that the copy-on-write problem caused by absolute address relocation can be avoided. ELFs can share characteristics that are the ELF files themselves. The repositioning of the PE file is converted into relative address repositioning, so that the PE file is independent of the address, and therefore, even a plurality of processes can share the same PE file, and the memory occupation is further reduced. After the address independence is realized, the file is mapped to a virtual address space in a linux operating system in a file mapping mode, and the copy-on-write of the same file by a plurality of processes is ensured by the operating system (kernel) itself.

In one example, the process of changing the absolute address relocation instruction corresponding to each first relocation entry to a relative address relocation instruction may include steps 810 to 830 as shown in fig. 8.

In step 810, for each first relocation entry, a relative address relocation instruction is inserted at the location corresponding to the first relocation entry. Next, step 820 is performed.

In step 820, an offset between the current PC (Program Counter, the location of the next instruction to be executed when the Program is running) and the target location of the first relocation entry is obtained. Then, step 830 is performed.

In step 830, the address at the relocation corresponding to the first relocation table entry is modified to be addressed by the relative offset, using the relative address relocation instruction and the offset obtained in step 820.

Thus, in the embodiment of the present invention, by inserting an instruction at the PE relocation table entry (i.e. the first relocation table entry described above), the offset between the current PC (Program Counter, the location of the next instruction to be executed when the Program is running) and the relocation target is obtained, and then the address at the relocation is modified to be the PC relative offset address, so that the conversion from absolute address relocation to relative address relocation is completed. The relative PC address offset relocation scheme is shown in fig. 9 as an example of the relative address relocation described above. By analyzing the PE file, the instruction type of the repositioning place can be obtained, the instruction is converted into an instruction which needs to be inserted relative to PC addressing, after one-time traversal (all repositioning table items are traversed), the space which the original PE file needs to expand can be determined, and then after corresponding spatial stretching treatment is carried out on the PE file, the relative offset of each repositioning table item and a repositioning target can be determined. Thus, inserting instructions addressed to the PC before and after repositioning the entry completes the translation process.

Step 810 may be implemented, for example, by steps 1010-1020 shown in fig. 10.

As shown in fig. 10, in step 1010, for each first relocation table entry, a target instruction corresponding to the first relocation table entry is determined to locate a function in which the target instruction is located. Then, step 1020 is performed.

In step 1020, a relative address relocation instruction is generated according to the relevant information of the function to create a second relocation entry matching the second executable program format based on the relative address relocation instruction.

Wherein the relevant information of the function may include, for example, but not limited to, one or more of the following information: the number of instructions of the function; code space of the function; register usage information of the function; access information of the function; etc.

Further, the relative address relocation instruction may include, for example, but is not limited to, one or more of the following instructions: a jump instruction; a branch instruction; a memory access instruction; etc.

As an example, when creating a second relocation entry matching the second executable program format, part or all of the relative address relocation instruction is written to the predetermined section.

For example, the targets of the jump instruction, the transfer instruction, and the access instruction may be written to a predetermined section.

As an example, the program reconstruction method 400 may further include the steps of: the offset of the relative address relocation instruction in the current second file is corrected based on the relative addressing (e.g. relative PC addressing) instruction contained in the first file itself. Thus, if the first file (e.g., PE file) also has some instructions that are relatively addressed, the offset of the relatively addressed instructions can be corrected by traversing all relocation entries in the current second file again.

In one example, the PE file (corresponding to the original first file) may be parsed first to obtain relocation entries therein (corresponding to the first relocation entries), each of the relocation entries may be traversed, and each of the relocation entries may be processed as follows: finding a corresponding target (namely, an instruction position needing to be relocated) according to the relocation table entry, and then locating a function where the instruction is located; analyzing the function, determining the instruction number, code space, register use information and access information of the function, collecting the information, determining that the instruction at the relocation place is changed into one or more instructions required by relative address addressing, creating a relocation table entry corresponding to the ELF for the instruction, for example, writing the targets of a jump instruction, a transfer instruction and the access instruction into a data area (such as a data section), and only the data in the data section is required to be modified in a targeted manner during the subsequent file loading, wherein the code section is not required to be modified any more. Thus, after the above traversal is completed, a new code segment size is obtained, corresponding to the ELF relocation entry. Alternatively, the offset to the addressing instruction may be corrected by traversing again.

In the embodiment of the invention, in order to solve the problems existing in the prior art, for example, a mode of reconstructing a PE file structure is adopted to provide a new redistribution technical scheme for Windows application on a Linux platform. By reconstructing the PE file, a Windows application developer can directly generate a version which accords with the Linux operation, and the reconstructed PE has the PE file attribute and part of the ELF file attribute, so that the distribution mode similar to that of the Linux native application can be realized. Therefore, the maintenance cost caused by upgrading is solved, meanwhile, a Windows application developer can directly debug under Linux in a symbol providing mode, and the Windows application developer cooperates with an application migration developer to locate the real problem. The common development libraries for different applications can be shared, so that the volume of the Wine container is reduced sufficiently. In addition, through PE file reconstruction, the problem that the memory of the PE file is increased during operation due to inconsistent alignment mode and ELF file and the benefit of not enjoying mapping to the file can be solved. By changing the absolute address relocation of the PE file into the relative address relocation similar to ELF, the problem that file mapping cannot be shared due to relocation can be further solved, memory occupation is reduced, and the problem that the memory occupation of Windows applied to a non-X86 Linux platform is too high is greatly improved.

An example of a piece of algorithm code of the program reconstruction method according to the embodiment of the present invention is as follows:

REBUILD_PIC_PE(file)

new_size < -CACULATE_INSERT_SIZE () +old_size// calculating the file SIZE of a new file on an original file basis

New_file < -create empty file with new _size// create new file

R < -all relocation entries// R represents all relocation entries

begin </the base of file// mapping files to base addresses of memory

foreach relocation in R// traverse all relocation entries

code < -begin to relocation.addr// locate to relocation target address

New_file < -write code to// writing code instruction of original file into new file

New_file < -insert PC relative addressing code// inserting relative PC addressing code in new file

Begin < -relocation.addr// update relocation target address

Calculating the amount of disk space required to build a location independent PE file

CACULATE_INSERT_SIZE

size < -0// size is initialized to 0

R < -all relocation entries// R represents all relocation entries

foreach relocation in R// traverse all relocation entries

type < -the type of instruction relocation belongs to// type represents relocation type

size+=get_INST_related_address (type)// calculate the length of the newly added code

GET_INST_RELATIVE_ADDRESS(type)

case TYPE 1:1/TYPE 1 relocation TYPE instruction size calculation, just as an example

REG < -GET_SPARE_REG ()// GET current code segment free register

if reg is not NULL then

return (5+6)// one call+one add// length of one call instruction and add instruction

else

// need spill one reg

return (5+6) + (1+1)// extra one pop and one push// length of one call instruction and add instruction and one push and pop instruction

case TYPE 2-// other relocation TYPE newly added instruction size calculation

According to an embodiment of the present invention, the above-mentioned program reconstruction method may be performed in an original operating system, for example, or may be performed in a target operating system. For example, the program reconstruction method is executed in the original operating system, so that an application developer of the original operating system can conveniently and directly generate a version which accords with the running of the target operating system. Or, the above program reconstruction method is executed in the target operating system, so that the application migration developer of the target operating system can complete the above reconstruction work, and the conversion can be quickly and efficiently completed through a section of reconstruction program, so as to finally realize the migration.

The embodiment of the present invention further provides an application cross-platform migration method 1100, where the application cross-platform migration method 1100 may utilize the program reconstruction method 400 described above in connection with fig. 4 to complete cross-platform migration of an application. As shown in FIG. 11, the application cross-platform migration method 1100 includes steps 1110 and 1120.

In the application cross-platform migration method 1100, an application on an original operating system (i.e., an application to be migrated) is migrated to a target operating system for use, so that in step 1110, a dependency library of the application to be migrated may be reconstructed by the program reconstruction method 400 to obtain a target library suitable for running in the target operating system. The dependency library of the application to be migrated may be obtained by parsing the application file, and the process of obtaining the dependency library by parsing the application file may be implemented by using an existing parsing technology, which is not described herein.

According to the embodiment of the invention, for example, a version which accords with Linux (as an example of a target operating system) running can be directly generated for a Windows (as an example of an original operating system) application developer by reconstructing a PE file (as an example of a first file) corresponding to a dependency library of an application to be migrated, and the reconstructed PE file has the PE file attribute and part of the ELF file attribute, so that the distribution mode similar to that of a Linux native application can be realized.

Then, in step 1120, the application to be migrated is converted into a target application adapted to run in the target operating system through the compatibility layer, the target application being adapted to directly call the target library.

For example, when a Windows application needs to be migrated to Linux for use, the Windows application to be migrated first completes the reconstruction of its dependent library through step 1110. After the reconstruction is completed, based on the reconstructed target library, conversion is realized through Wine, namely, windows application is converted into Linux application suitable for running on a Linux platform, so that cross-platform migration of the application is completed.

According to the application cross-platform migration method 1100 provided by the embodiment of the invention, convenient application cross-platform migration can be realized, and the migrated application can directly use the libraries without packing a large number of files (such as PE libraries) through a wire by carrying out reconstruction conversion (such as conversion into a shared ELF library) on the dependent libraries (such as PE files) of the application to be migrated.

In this way, migration work may be directly handled by the application developer without third party or operating system vendor, and is no longer in a state where migration work is separated from the application developer. Alternatively, migration work may be performed by the application migration developer, which facilitates mitigating work and costs for the application developer.

In summary, it can be known that, by reconstructing the program to be reconstructed (i.e. the corresponding dependency library) corresponding to the application to be executed across the operating system, that is, adding the file header, aligning the file and making the relocation implementation address irrelevant, the technology of the embodiment of the invention is convenient for the application of the original operating system to smoothly and efficiently complete migration in the target operating system without consuming a great amount of time and effort, and overcomes the problem of low migration efficiency in the prior art when the application is migrated across the platform.

In the embodiment of the invention, the shared loading technology of Windows PE on Linux can be realized by a method of mixing PE and ELF formats. By PE reconfiguration, a PE address independent relocation scheme can be implemented.

In the embodiment of the invention, the problem that DLLs cannot be shared in each Windows application program is solved by adding ELF file attributes to the PE files, and the shared DLLs can be generated by common DLLs of different application programs, similar to an ELF shared library, so that the problem of occupied storage and the problem of occupied memory in running are solved.

In the embodiment of the invention, the absolute address relocation of PE is converted into the relative PC address offset relocation through PE file reconstruction, so that the problem of memory surge caused by copy-on-write caused by relocation is solved. By means of PE file reconstruction, the problem that application release of an application developer depends on an operating system manufacturer is solved, and the operating system manufacturer only needs to pay attention to the problem related to Wine, so that workload introduced by upgrading and packaging is greatly saved.

In addition, in the embodiment of the invention, the rights risk caused by the distribution of other manufacturers can be avoided as much as possible by the application developer.

Embodiments of the present invention also provide a program reconstructing apparatus 1200, as shown in fig. 12, which is capable of performing the respective step processes of the program reconstructing method 400 as described above. Next, the above-described program reconstructing apparatus 1200 is described with reference to fig. 12.

As shown in fig. 12, the program reconstructing apparatus 1200 includes an adding unit 1210, a file aligning unit 1220, and a repositioning unit 1230.

The adding unit 1210 is adapted to add a header to a first file corresponding to the program to be reconstructed, so as to obtain an intermediate file, where the first file has a first executable program format matched with the original operating system, and the header has a second executable program format matched with the target operating system.

The file alignment unit 1220 is adapted to perform file alignment on the intermediate file to obtain a second file, so that the second file meets the file alignment requirement of the second executable program format.

The relocation unit 1230 is adapted to determine all first relocation entries in the current second file, change the absolute address relocation instruction corresponding to each first relocation entry to a relative address relocation instruction, so that the relocation of the second file is converted from an absolute address based relocation to a relative address based relocation.

As an example, the relocation unit 1230 may be adapted to: determining a target instruction corresponding to each first relocation table item to locate a function in which the target instruction is located; a relative address relocation instruction is generated according to the relevant information of the function to create a second relocation table entry matching the second executable program format based on the relative address relocation instruction.

As an example, the relevant information of the function may include one or more of the following information: the number of instructions of the function; code space of the function; register usage information of the function; access information of the function; etc.

As an example, the relative address relocation instruction may include one or more of the following instructions: a jump instruction; a branch instruction; a memory access instruction; etc.

As an example, when creating a second relocation entry matching the second executable program format, part or all of the relative address relocation instruction may be written to the predetermined section.

As an example, the relocation unit 1230 is further adapted to: based on the relative addressing instruction contained in the first file itself, the offset of the relative address relocation instruction in the current second file is modified.

Embodiments of the present invention also provide an application cross-platform migration apparatus 1300, as shown in fig. 13, capable of performing the processing of the steps of the application cross-platform migration method 1100 as described above. Next, the above-described application cross-platform migration apparatus 1300 is described with reference to fig. 13.

As shown in fig. 13, the application cross-platform migration apparatus 1300 includes a reconstruction module 1310 and a conversion module 1320.

The reconstruction module 1310 is adapted to reconstruct the dependency library of the application to be migrated through the program reconstruction method as described above, so as to obtain a target library suitable for running in the target operating system.

The conversion module 1320 is adapted to convert an application to be migrated through the compatibility layer into a target application adapted to run in a target operating system, the target application being adapted to directly invoke the target library.

At present, two file systems (as an example application scene) are needed for migrating Windows applications to Linux in the prior art, so that migration, packaging, release, update and management are very inconvenient, and the program reconstruction method and the application cross-platform migration method according to the embodiment of the invention newly construct an executable file format based on Wine by fusing the advantages of the two file systems, and are more suitable for redistribution of Windows applications on a Linux platform. In addition, the technology provided by the embodiment of the invention also reduces the migration and release difficulty, can save the size of an application package space, narrows the distance between the original Windows application and a migration developer, and saves the migration release time of the Windows application on a Linux platform.

In addition, in the embodiment of the invention, under the condition of constructing the ELF-PE mixed binary file format, the absolute address relocation of the PE is converted into the relative address relocation similar to ELF through the PC relative offset address, so that the complete file mapping of the PE file is realized, and the modification of memory pages is reduced. In addition, by adding dependency information to the system, library dependency management is automatically completed, loading and repositioning of the hybrid binary system are completed through the system ld.so, dependency on Wine is further reduced, overhead in operation is saved, and program performance is improved.

The various techniques described herein may be implemented in connection with hardware or software or, alternatively, with a combination of both. Thus, the methods and apparatus of the present invention, or certain aspects or portions of the methods and apparatus of the present invention, may take the form of program code (i.e., instructions) embodied in tangible media, such as removable hard drives, U-drives, floppy diskettes, CD-ROMs, or any other machine-readable storage medium, wherein, when the program is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention.

In the case of program code execution on programmable computers, the computing device will generally include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. Wherein the memory is configured to store program code; the processor is configured to execute the program reconstruction method or the application cross-platform migration method of the present invention according to instructions in said program code stored in the memory.

By way of example, and not limitation, readable media comprise readable storage media and communication media. The readable storage medium stores information such as computer readable instructions, data structures, program modules, or other data. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. Combinations of any of the above are also included within the scope of readable media.

In the description provided herein, algorithms and displays are not inherently related to any particular computer, virtual system, or other apparatus. Various general-purpose systems may also be used with examples of the invention. The required structure for a construction of such a system is apparent from the description above. In addition, the present invention is not directed to any particular programming language. It should be appreciated that the teachings of the present invention as described herein may be implemented in a variety of programming languages and that the foregoing descriptions of specific languages are provided for disclosure of preferred embodiments of the present invention.

In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.

Similarly, it should be appreciated that in the foregoing description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. Those skilled in the art will appreciate that the modules or units or components of the devices in the examples disclosed herein may be arranged in a device as described in this embodiment, or alternatively may be located in one or more devices different from the devices in this example. The modules in the foregoing examples may be combined into one module or may be further divided into a plurality of sub-modules.

Those skilled in the art will appreciate that the modules in the apparatus of the embodiments may be adaptively changed and disposed in one or more apparatuses different from the embodiments. The modules or units or components of the embodiments may be combined into one module or unit or component and, furthermore, they may be divided into a plurality of sub-modules or sub-units or sub-components. Any combination of all features disclosed in this specification, and all processes or units of any method or apparatus so disclosed, may be employed, except that at least some of such features and/or processes or units are mutually exclusive. Each feature disclosed in this specification may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise.

Furthermore, those skilled in the art will appreciate that while some embodiments described herein include some features but not others included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the invention and form different embodiments. Furthermore, some of the embodiments are described herein as methods or combinations of method elements that may be implemented by a processor of a computer system or by other means of performing the functions. Thus, a processor with the necessary instructions for implementing the described method or method element forms a means for implementing the method or method element. Further, the elements described herein for apparatus embodiments are examples of the following apparatus: the apparatus is for carrying out the functions performed by the elements for carrying out the objects of the invention.

As used herein, unless otherwise specified the use of the ordinal terms "first," "second," "third," etc., to describe a general object merely denote different instances of like objects, and are not intended to imply that the objects so described must have a given order, either temporally, spatially, in ranking, or in any other manner.

While the invention has been described with respect to a limited number of embodiments, those skilled in the art, having benefit of the above description, will appreciate that other embodiments are contemplated within the scope of the invention as described herein. Furthermore, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter.

Claims

1. A program reconstruction method, comprising:

adding a file header to a first file corresponding to a program to be reconstructed so as to obtain an intermediate file, wherein the first file has a first executable program format matched with an original operating system, and the file header has a second executable program format matched with a target operating system;

carrying out file alignment on the intermediate file to obtain a second file so as to enable the second file to meet the file alignment requirement of the second executable program format;

determining all first relocation table entries in the current second file, and changing an absolute address relocation instruction corresponding to each first relocation table entry into a relative address relocation instruction so as to enable relocation of the second file to be converted from relocation based on absolute addresses to relocation based on relative addresses;

The changing the absolute address relocation instruction corresponding to each first relocation table entry into a relative address relocation instruction comprises: for each first relocation table entry, inserting a relative address relocation instruction at a corresponding position of the first relocation table entry; acquiring the offset between the position of the next instruction to be executed and the target position of the first repositioning table item when the current program runs; modifying the address of the relocation position corresponding to the first relocation table entry into relative offset addressing by utilizing the relative address relocation instruction and the offset;

the inserting the relative address relocation instruction at the corresponding position of the first relocation table entry comprises: determining a target instruction corresponding to the first repositioning table item to position a function where the target instruction is located; generating a relative address relocation instruction according to the related information of the function, so as to create a second relocation table entry matched with the second executable program format based on the relative address relocation instruction.

2. The program reconstruction method as claimed in claim 1, wherein the first file is a PE file, and the header includes an ELF header.

3. The program reconstruction method according to claim 1, wherein the related information of the function includes one or more of the following information:

The number of instructions of the function; code space of the function; register usage information of the function; access information of the function.

4. The program reconstruction method according to claim 1, wherein part or all of the relative address relocation instruction is written to a predetermined section when creating a second relocation entry matching the second executable program format.

5. The program reconstruction method according to any one of claims 1 to 4, further comprising:

and correcting the offset of the relative address repositioning instruction in the current second file based on the relative addressing instruction contained in the first file.

6. The application cross-platform migration method is characterized by comprising the following steps of:

reconstructing a dependent library of an application to be migrated through the program reconstruction method according to any one of claims 1 to 5 to obtain a target library suitable for running in a target operating system;

and converting the application to be migrated into a target application suitable for running in a target operating system through a compatibility layer, wherein the target application is suitable for directly calling the target library.

7. A program reconstruction apparatus, comprising:

the adding unit is suitable for adding a file header to a first file corresponding to a program to be reconstructed so as to obtain an intermediate file, wherein the first file is provided with a first executable program format matched with an original operating system, and the file header is provided with a second executable program format matched with a target operating system;

The file alignment unit is suitable for carrying out file alignment on the intermediate file to obtain a second file so as to enable the second file to meet the file alignment requirement of the second executable program format;

a repositioning unit adapted to determine all first repositioning table items in the current second file, and change an absolute address repositioning instruction corresponding to each first repositioning table item into a relative address repositioning instruction, so that repositioning of the second file is converted from absolute address-based repositioning to relative address-based repositioning;

the relocation unit is adapted to change the absolute address relocation instruction corresponding to each first relocation entry to a relative address relocation instruction by performing the following: for each first relocation table entry, inserting a relative address relocation instruction at a corresponding position of the first relocation table entry; acquiring the offset between the position of the next instruction to be executed and the target position of the first repositioning table item when the current program runs; modifying the address of the relocation position corresponding to the first relocation table entry into relative offset addressing by utilizing the relative address relocation instruction and the offset;

the relocation unit is adapted to insert a relative address relocation instruction at the correspondence of the first relocation entry by performing the following: determining a target instruction corresponding to the first repositioning table item to position a function where the target instruction is located; generating a relative address relocation instruction according to the related information of the function, so as to create a second relocation table entry matched with the second executable program format based on the relative address relocation instruction.

8. The application cross-platform migration device is characterized by comprising a reconstruction module and a conversion module:

the reconstruction module is suitable for reconstructing the dependency library of the application to be migrated through the program reconstruction method according to any one of claims 1 to 5 to obtain a target library suitable for running in a target operating system;

the conversion module is suitable for converting the application to be migrated into a target application suitable for running in a target operating system through a compatibility layer, and the target application is suitable for directly calling the target library.

9. A computing device, comprising:

at least one processor and a memory storing program instructions;

the program instructions, when read and executed by the processor, cause the computing device to perform the program reconstruction method of any one of claims 1-5 or the application cross-platform migration method of claim 6.

10. A readable storage medium storing program instructions which, when read and executed by a computing device, cause the computing device to perform the program reconstruction method of any one of claims 1-5 or the application cross-platform migration method of claim 6.