CN109460280B - Method and terminal for running program - Google Patents
Method and terminal for running program Download PDFInfo
- Publication number
- CN109460280B CN109460280B CN201710796999.9A CN201710796999A CN109460280B CN 109460280 B CN109460280 B CN 109460280B CN 201710796999 A CN201710796999 A CN 201710796999A CN 109460280 B CN109460280 B CN 109460280B
- Authority
- CN
- China
- Prior art keywords
- windows
- simulator
- windows api
- instruction
- api simulator
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 44
- 238000004088 simulation Methods 0.000 claims description 33
- 238000004590 computer program Methods 0.000 claims 2
- 239000000758 substrate Substances 0.000 claims 1
- 238000005516 engineering process Methods 0.000 abstract description 9
- 239000008186 active pharmaceutical agent Substances 0.000 description 142
- 230000006870 function Effects 0.000 description 14
- 238000013519 translation Methods 0.000 description 13
- 238000010586 diagram Methods 0.000 description 10
- 238000012545 processing Methods 0.000 description 7
- 230000008569 process Effects 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 4
- 238000004891 communication Methods 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 230000002159 abnormal effect Effects 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 230000006872 improvement Effects 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000005008 domestic process Methods 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
- G06F9/45516—Runtime code conversion or optimisation
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention provides a method and a terminal for running a program, wherein the method comprises the following steps: when the host needs to execute the Windows program, the Windows API simulator client in the virtual machine only calls the Windows program, converts the Windows instruction into the instruction of the current host architecture, and uses the Windows API simulator server outside the virtual machine to execute the program. By adopting the scheme, the problem of poor stability of running Windows programs in a non-X86 architecture host machine environment in the related technology is solved, the stability of running the programs is improved on the basis of ensuring that the Windows programs are run in the non-X86 host machine, the performance requirement of a virtual machine is reduced, and the power consumption of the host machine is saved.
Description
Technical Field
The present invention relates to the field of communications, and in particular, to a method and a terminal for running a program.
Background
In the related art, long-term Wintel alliance formed by Intel (CPU of X86 architecture) and Windows occupies the market of PC and server for a long time, a good ecological environment is established, and other CPU of non-X86 architecture is limited in development, even part of architecture is almost disappeared.
With the rapid development of mobile interconnection related software and hardware technology, the rapid development of a CPU (Central processing Unit) of an advanced reduced instruction set machine (Advanced RISC Machine, abbreviated as ARM) architecture takes the leading role in the mobile field, and gradually establishes own ecology.
On the other hand, under the large background of information security at the national level and rapid promotion of the domestic process, domestic CPUs (typically the flyaway of the longson and ARM architectures with the MIPS architecture (simplified instruction set, microprocessor without interlocked piped stages architecture)) have also been rapidly developed, and the Linux system with an open source is operated, and the X86 architecture is replaced in a specific domestic field and gradually extended to other fields.
However, since the CPU of the non-X86 architecture is developed late, the ecology is relatively poor compared with that of X86, and since the Wintel alliance flourishes for a long time, a great number of users have made serious dependencies on the CPU, and most of application programs in the Windows operating system are binary programs which have been compiled, and for various reasons (such as no source code and platform compatibility problems), the application programs have no corresponding Linux version. There is an urgent need to directly run binary applications on Windows in non-X86 environments.
However, in reality, since the API interfaces of Windows and other operating systems are different, an application program developed for Windows cannot run on other OS; on the other hand, because the instruction sets of the X86 architecture CPU and other architecture CPUs are not compatible, the compiled binary program in the X86 architecture CPU environment cannot run in other CPU architecture environments. Both of these reasons result in the inability of binary applications in the X86 architecture CPU environment to run in non-X86 and non-Windows environments for Windows.
It can be said that the compatibility problem of the Windows binary application program is one of the biggest and the most difficult obstacles in the popularization process of the hardware and the operating system with the non-X86 architecture.
In view of the above problems, the solutions in the related art include the following:
1. and (5) a virtual machine. That is, a complete virtual machine of X86 architecture is run in a non-X86 host environment, a Windows operating system is run in the virtual machine, and a Windows binary representation of X86 is run on top of the Windows system in the virtual machine. The scheme is the most main scheme aiming at the problem of cross-CPU architecture and cross-operating system application compatibility in the related technology, wherein virtual machines have various implementation modes, such as commercial Vware, open-source KVM and the like, and the related technology is mature at present. However, this solution has the following major problems:
1) The hardware support (especially CPU) is needed, the support of the X86 architecture is relatively perfect at present, the support of the non-X86 architecture (such as Loongson) is not ideal, and under the condition of poor hardware support, the instruction simulation is completely performed by depending on software, so that the efficiency is very low.
2) The system (including CPU, peripheral equipment, BIOS, etc.) needs to be simulated completely, the quantity of virtual machines is large, more system resources need to be consumed, and the performance is poor.
2. Instruction simulator + Window API simulator. Namely, a Window API simulator is used for solving the problem of API compatibility between Windows and non-Windows systems, and an instruction simulator is used for solving the problem of X86 and non-X86 architecture instruction set compatibility. The Window API simulator is a compatible layer capable of running Windows applications on various portable operating system interfaces, and has a corresponding open source technology at present, which translates Windows API calls into POSIX calls, which translate API levels rather than CPU instructions; instruction simulators perform instruction translation across CPU architectures, such as translating X86 instructions into corresponding ARM or MIPS instructions, typical of existing instruction simulators such as Qemu, bochs, and the like. The main difference between this scheme and scheme 1 is that: the scheme does not simulate the whole system, only performs instruction translation aiming at the user mode part of the application program, transfers to the host kernel for execution when the execution is performed to the system call, and returns to the user mode for continuous execution after the execution is completed; therefore, the scheme is lighter, consumes fewer resources and has better performance compared with a virtual machine simulated by pure software. However, the biggest problem faced by this solution is still performance problem, because instruction simulation can be performed only by software, and the volume of the Window API simulator itself is also relatively large (the basic Windows API and the running environment need to be provided), instruction simulation needs to be performed on the Window API simulator and the application program, and the efficiency is relatively low. Typically implemented using a hardware instruction simulator and a Window API simulator.
Aiming at the performance problems, the implementation is improved in the related technology, and the main improvement ideas are as follows: the whole Window API simulator is operated outside the simulator, and only the Windows library on which the application program depends is simulated by using the Window API simulator compiled locally, so that the workload of software instruction translation can be reduced, and the operating efficiency of the application program is improved. The realization thinking is as follows: when the instruction simulation is executed, whether the called interface is a Windows compatible interface is judged by a certain means (for example, by judging CALL and JMP instructions, or inserting an abnormal instruction into each function entry of a compatible library, or inserting an abnormal instruction into an abnormal processing function), if so, the execution is directly transferred to a corresponding position in a corresponding library (provided in a Window API simulator) of local compiling, and similar skip is carried out after the execution is finished, and the original flow is returned to execute. Similar improvements do in principle improve the performance of the solution, but they have the main problem: the implementation is complex, the simulators and Window API simulators are required to be deeply modified, modification and optimization are performed on the processing flow of the instruction level, and quite complex logic processing such as parameter processing, address translation jump, various anomalies and the like are required to be considered, so that problems are easy to occur, stability is easy, and the real available standard is difficult to be reached.
Aiming at the problem of poor stability of a Windows program running in a non-X86 architecture host environment in the related art, no effective solution exists at present.
Disclosure of Invention
The embodiment of the invention provides a method and a terminal for running a program, which at least solve the problem of poor stability of running a Windows program in a non-X86 architecture host environment in the related art.
According to one embodiment of the present invention, there is provided a method of operating a program, including: a non-X86 architecture host runs Windows applications using a view operating system application programming interface Windows API simulator; wherein, the Windows API simulator comprises: and the Windows API simulator client is positioned in the virtual machine, and the Windows API simulator server is positioned outside the virtual machine, wherein the virtual machine is used for simulating the instructions of the Windows application program.
Optionally, the non-X86 architecture host runs a Windows application using a view operating system application programming interface Windows API simulator, comprising: the Windows API simulator client executes the Windows application program and sends a call request of the Windows application program for calling an API interface of a Windows system to the Windows API simulator server; the Windows API simulator server side realizes the call request at a local interface of the host to obtain an implementation result, wherein the local interface is indicated to the Windows API simulator server side by the Windows API simulator client side; and the Windows API simulator client receives the implementation result and continues to execute the Windows application program.
Optionally, the virtual machine is a hardware instruction simulator, and the sending the call request to the Windows API simulator server includes: simulating the call request as an instruction of an architecture to which the host belongs by using the hardware instruction simulator; and sending the instruction to the Windows API simulator server.
Optionally, before the host of the non-X86 architecture runs the Windows application using the Windows API simulator, the method includes: the host detects the format of a program to be executed; and designating a simulator for the program to be executed according to the format, wherein the Windows application program is run by using the Windows API simulator under the condition that the format is determined to be the Windows application program.
Optionally, when the host is an advanced reduced instruction set machine ARM architecture, the virtual machine is configured to implement emulation of an X86 architecture instruction to an ARM instruction.
The virtual machine is configured to implement emulation of X86 architecture instructions to MIPS instructions when the host is a reduced instruction set MIPS architecture.
According to another embodiment of the present invention, there is provided a terminal, a host installed with a non-X86 architecture, including: the view operating system application programming interface Windows API simulator is used for running Windows application programs; wherein, the Windows API simulator comprises: and the Windows API simulator client is positioned in the virtual machine, and the Windows API simulator server is positioned outside the virtual machine, wherein the virtual machine is used for simulating the instructions of the Windows application program.
Optionally, the Windows API simulator client is configured to execute the Windows application program, and send a call request of the Windows application program for calling an API of the Windows system to the Windows API simulator server; the Windows API simulator server is used for realizing the call request to obtain an implementation result at a local interface of the host, wherein the local interface is indicated to the Windows API simulator server by the Windows API simulator client; and the Windows API simulator client is also used for receiving the implementation result and continuously executing the Windows application program.
Optionally, when the virtual machine is a hardware instruction simulator, the hardware instruction simulator is configured to simulate the call request as an instruction to which the host belongs; and the Windows API simulator client sends the simulated instruction to the Windows API simulator server.
According to another embodiment of the present invention, there is also provided a storage medium including a stored program, wherein the program, when run, performs the method described in any one of the above alternative embodiments.
According to another embodiment of the present invention, there is also provided a processor for running a program, wherein the program when run performs the method as described in any of the above alternative embodiments.
According to the invention, the host machine of the non-X86 architecture comprises a Windows API simulator client side positioned in the virtual machine and a Windows API simulator server side positioned outside the virtual machine, when the host machine needs to execute the Windows program, the Windows API simulator client side in the virtual machine is used for calling the Windows program, and the Windows API simulator client side outside the virtual machine is combined with the Windows API simulator server side, so that the host machine and the virtual machine use the interface resources of the current host machine to run the Windows program, namely the Windows API simulator client side in the virtual machine is used for calling the Windows program only and converting the Windows instruction into the instruction of the current host machine architecture, and the Windows API simulator server side outside the virtual machine is used for executing the program. By adopting the scheme, the problem of poor stability of running Windows programs in a non-X86 architecture host machine environment in the related technology is solved, the stability of running the programs is improved on the basis of ensuring that the Windows programs are run in the non-X86 host machine, the performance requirement of a virtual machine is reduced, and the power consumption of the host machine is saved.
Drawings
The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate embodiments of the invention and together with the description serve to explain the invention and do not constitute a limitation on the invention. In the drawings:
FIG. 1 is a flow chart of a method of running a program according to an embodiment of the invention;
FIG. 2 is a block diagram of an operating device according to the present preferred embodiment;
FIG. 3 is a schematic flow chart of a first implementation according to a preferred embodiment;
fig. 4 is a schematic flow chart of a second implementation according to the preferred embodiment;
FIG. 5 is a schematic flow chart of a third implementation according to the preferred embodiment;
FIG. 6 is a workflow diagram of a hardware instruction simulator in accordance with the preferred embodiments;
FIG. 7 is a workflow diagram of a Windows API simulator in accordance with the preferred embodiments;
FIG. 8 is a workflow diagram of a native operating system in accordance with the preferred embodiments;
fig. 9 is a block diagram of a hardware structure of a mobile terminal for a method of running a program according to an embodiment of the present invention.
Detailed Description
Example 1
In this embodiment, a method for running a running program on a terminal is provided, fig. 1 is a flowchart of a method for running a program according to an embodiment of the present invention, and as shown in fig. 1, the flowchart includes the following steps:
step S102, a host machine of a non-X86 architecture uses a Windows API simulator of a view operating system application program programming interface to run a Windows application program;
step S104, wherein the Windows API simulator includes: and the Windows API simulator client is positioned in the virtual machine, and the Windows API simulator server is positioned outside the virtual machine, wherein the virtual machine is used for simulating the instructions of the Windows application program.
According to the invention, the host machine of the non-X86 architecture comprises a Windows API simulator client side positioned in the virtual machine and a Windows API simulator server side positioned outside the virtual machine, when the host machine needs to execute the Windows program, the Windows API simulator client side in the virtual machine is used for calling the Windows program, and the Windows API simulator client side outside the virtual machine is combined with the Windows API simulator server side, so that the host machine and the virtual machine use the interface resources of the current host machine to run the Windows program, namely the Windows API simulator client side in the virtual machine is used for calling the Windows program only and converting the Windows instruction into the instruction of the current host machine architecture, and the Windows API simulator server side outside the virtual machine is used for executing the program. By adopting the scheme, the problem of poor stability of running Windows programs in a non-X86 architecture host machine environment in the related technology is solved, the stability of running the programs is improved on the basis of ensuring that the Windows programs are run in the non-X86 host machine, the performance requirement of a virtual machine is reduced, and the power consumption of the host machine is saved.
Optionally, the non-X86 architecture host runs a Windows application using a view operating system application programming interface Windows API simulator, comprising: the Windows API simulator client executes the Windows application program and sends a call request of the Windows application program for calling an API interface of a Windows system to the Windows API simulator server; the Windows API simulator server side realizes the call request at a local interface of the host to obtain an implementation result, wherein the local interface is indicated to the Windows API simulator server side by the Windows API simulator client side; the Windows API simulator client receives the implementation result and continues to execute the Windows application program.
Optionally, the virtual machine is a hardware instruction simulator, and the sending the call request to the Windows API simulator server includes: simulating the call request as an instruction of the architecture to which the host belongs by using the hardware instruction simulator; and sending the instruction to the Windows API simulator server.
Optionally, before the host of the non-X86 architecture runs the Windows application using the Windows API simulator, the method includes: the host detects the format of a program to be executed; and designating a simulator for the program to be executed according to the format, wherein the Windows application program is run by using the Windows API simulator under the condition that the format is determined to be the Windows application program.
Optionally, when the host is an advanced reduced instruction set machine ARM architecture, the virtual machine is configured to implement emulation of an X86 architecture instruction to an ARM instruction; the virtual machine is used to implement emulation of X86 architecture instructions into MIPS instructions when the host is a reduced instruction set MIPS architecture. It should be appreciated that the present invention is not limited to ARM and MIPS architectures, and may include other non-X86 architectures.
The following detailed description is of preferred embodiments of the invention.
The technical problems to be solved by the preferred embodiment are as follows: the implementation schemes aiming at the problem of application compatibility of cross-CPU architecture and cross-operating system in the related art have the defects of different degrees, and cannot meet the practical requirements.
To solve the above problems, the present preferred embodiment provides a method of running Windows binary program in a non-X86 environment. The method utilizes a hardware instruction simulator to approach the problem of instruction compatibility across CPUs; the method comprises the steps that a Windows API simulator (comprising a Windows API simulation client and a local Windows API simulation server) is utilized to solve the problem of API compatibility of a cross-operating system; meanwhile, the main Windows API simulation work is placed outside the hardware instruction simulator through the local Windows API simulation server, and only the user mode part instructions of the Windows binary program (and related libraries thereof) and the Windows API simulation client are simulated by the hardware instruction simulator, so that the simulation efficiency can be greatly improved.
Fig. 2 is a schematic block diagram of an operating device according to the preferred embodiment, and as shown in fig. 2, a method for operating a Windows binary program in a non-X86 environment according to the preferred embodiment includes the following modules: hardware instruction simulator, windows API simulator (including Windows API simulation client and local Windows API simulation server), windows binary application program, and local operating system. The following are respectively described:
1. a hardware instruction simulator. Translation (or simulation) of hardware instructions is performed, and translation from X86 architecture instructions to non-X86 architecture instructions is mainly realized as follows:
1) When the physical host is ARM architecture, the hardware instruction simulator has the function of translating the X86 architecture instruction into the ARM instruction.
1) When the physical host is a MIPS architecture, the hardware instruction emulator possesses the translation of X86 architecture instructions to MIPS instructions.
The method uses a tool chain provided by a physical host to compile and run on a local operating system; and does not simulate a complete system, but rather only dynamically translates (or simulates) part of the instructions for a particular application user state.
2. The Windows API simulator comprises a Windows API simulation client and a local Windows API simulation server:
1) The Windows API simulation client, compiled using an X86 toolchain, runs within the hardware instruction simulator, and requires instruction simulation. The main functions include:
A. and analyzing and loading the executable files in Windows PE format and the dynamic link library.
B. An API interface consistent with a Windows system is provided for Windows binary application programs to directly call.
C. And packaging the Windows API called by the Windows binary application program into a request, and sending the Windows API simulation request to a local Windows API simulation server.
D. And receiving the simulation result of the server and returning the simulation result to the Windows binary application program.
2) The local Windows API simulation server uses the local tool chain compiling provided by the physical host to run outside the hardware instruction simulator without instruction translation. The main functions include:
A. and receiving a request sent by the Windows API simulation client.
B. And calling a local interface provided by an operating system running in the physical host to realize corresponding functions.
C. And sending the execution result back to the Windows API simulation client.
3. The local operating system, i.e., the operating system running on the physical host. The main uses include:
A. and providing an interface for upper-layer applications (comprising a Windows API server and a hardware instruction simulator) to realize functions required to be provided by corresponding Windows APIs.
B. An environment is provided for the hardware instruction simulator to run.
C. A configuration is provided that specifies, for the format of the executable program, the hardware instruction emulator that it uses in execution.
D. The format of the running executable is identified, and when the executable is executed, the simulation is performed using the corresponding simulator according to the configuration.
4. The Windows binary application program, i.e. the binary application program originally running in the X86 architecture Windows system, is compiled using the X86 toolchain, and needs to perform instruction simulation, and the physical instruction simulator performs instruction translation (or simulation).
The method for running Windows binary program in non-X86 environment according to the preferred embodiment typically comprises the following steps:
step one, a Windows binary application program compiled by using an X86 toolchain is run in a host environment of a non-X86 architecture by using a Windows API simulator.
And step two, the local operating system uses a corresponding hardware instruction simulator to simulate the execution of each instruction according to the configuration. Each instruction is simulated (or translated) by the hardware instruction simulator when executed, and the simulated (or translated) instruction is actually executed. This simulation (or translation) process is throughout.
And thirdly, starting the Windows API simulator client, and analyzing, linking and loading the corresponding executable file and the dependent dynamic library thereof.
And step four, the Windows API simulator client starts a local Windows API simulator server.
And step five, the Windows API simulator client jumps to the entrance of the application program to start execution.
And step six, determining that the application program calls an API interface provided by the Windows system.
And step seven, the Windows API simulator client encapsulates the call request and sends the call request to the local Windows API simulator server.
And step eight, the local Windows API simulator server receives the request, calls an interface provided by the local operating system to realize corresponding functions, and sends an execution result back to the client.
And step nine, the Windows API simulator client feeds back the execution result to the Windows binary application program.
And step ten, the application program continues to execute.
The following are specific embodiments of the preferred embodiment
In order to make the technical problems, technical solutions and advantages to be solved by the preferred embodiments more apparent, the following detailed description will be given with reference to the accompanying drawings and specific embodiments.
Fig. 3 is a schematic flow chart of the first implementation manner according to the preferred embodiment, as shown in fig. 3, specifically including the following steps:
step 31, running a Windows binary application compiled using the X86 toolchain in the host environment of the Loongson CPU (installed Linux operating system) using a Windows API simulator.
In step 301, a local operating system (e.g., linux system) uses a corresponding hardware instruction simulator to simulate the execution of each instruction according to the configuration. Each instruction is emulated (or translated) by a hardware instruction emulator as it is executed.
In step 302, the CPU then executes the emulated (or translated) instruction. This simulation (or translation) process is throughout.
In step 35, the application program calls the API interface provided by the Windows system.
Step 38, the Windows API simulator client feeds back the execution result to the Windows binary application program.
The application continues to execute, step 39.
Fig. 4 is a schematic flow chart of a second embodiment according to a preferred embodiment, specifically including the following steps:
in step 41, in the host environment of the Feiteng CPU (installed Linux system), a Windows binary application compiled using an X86 toolchain is run using a Windows API simulator.
In step 401, the local operating system (Linux system) uses a corresponding hardware instruction simulator to simulate the execution of each instruction according to the configuration. Each instruction is emulated (or translated) by a hardware instruction emulator as it is executed.
And step 43, starting the local Windows API simulator server.
In step 45, the application program calls an API interface provided by the Windows system.
In step 46, the Windows API simulator client encapsulates the call request and sends it to the local Windows API simulator server.
And step 48, the Windows API simulator client feeds back the execution result to the Windows binary application program.
The application continues to execute, step 49.
Fig. 5 is a schematic flow chart of a third embodiment according to a preferred embodiment, specifically including the following steps:
in step 51, in the terminal (such as mobile phone, set top box, etc.) environment of ARM CPU (installing android operating system), windows CE binary application program is run by using Windows API simulator.
In step 501, the local operating system (android system) uses a corresponding hardware instruction simulator to simulate the execution of each instruction according to the configuration. Each instruction is emulated (or translated) by a hardware instruction emulator as it is executed.
In step 55, the application program calls the API interface provided by the Windows system.
In step 56, the Windows API simulator client encapsulates the call request and sends it to the local Windows API simulator server.
In step 58, the Windows API simulator client feeds back the execution result to the Windows binary application.
The application continues to execute, step 59.
FIG. 6 is a workflow diagram of a hardware instruction simulator, as shown in FIG. 6, including the steps of:
at step 61, the hardware instruction emulator executes the specified X86 instruction.
At step 62, a lookup is made in the cache as to whether there is a corresponding instruction (or a plurality of instructions in succession) to translate (or emulate) the result (the translated instruction may be executed by a non-86 architecture).
If not, the corresponding instruction (or sequential instructions) is translated (or emulated) and the result is cached, step 64.
The host CPU hardware executes the translated (or emulated) native CPU instructions, step 65.
FIG. 7 is a workflow diagram of a Windows API simulator according to the preferred embodiment, as shown in FIG. 7, including the steps of:
in step 71, the application program calls an API interface provided by the Windows system.
And step 72, the Windows API simulator client encapsulates the call request and sends the call request to the local Windows API simulator server.
In step 74, the Windows API simulator client feeds back the execution result to the Windows binary application.
The application continues to execute, step 75.
FIG. 8 is a workflow diagram of a native operating system, as shown in FIG. 7, including the steps of:
in step 81, the user specifies the simulator used in executing the program to be executed (not in X86 format or X86 format) through the configuration interface provided by the local operating system. It should be added that when the program to be executed is in a non-X86 format, the program is normally operated in the current non-X86 host, and the program does not need to be operated through the hardware instruction simulator.
In step 83, the local operating system identifies the format of the running executable program, and when executing the executable program, the corresponding simulator is used to execute the executable program according to the configuration.
The beneficial effects of the above method of the preferred embodiment are as follows:
1. the method can realize that the Windows binary application compiled in the X86 architecture can run in the environment of the non-X86 architecture without any modification, can solve the problem of compatibility of the Windows binary application to a certain extent, and is beneficial to establishing and enriching the software ecology of the hardware of the non-X86 architecture.
2. As the Windows API simulation server is operated locally, the burden of the hardware instruction simulator can be greatly reduced, thereby solving the performance problem existing in the existing partial scheme.
3. Because the client/server model is used for realizing, the communication between the client and the server is based on the standard system interface, and related functions can be realized only by using the standard system interface, so that the complexity of realization is low, the stability can be ensured, and the method is better than the related technology.
From the description of the above embodiments, it will be clear to a person skilled in the art that the method according to the above embodiments may be implemented by means of software plus the necessary general hardware platform, but of course also by means of hardware, but in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present invention may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium (e.g. ROM/RAM, magnetic disk, optical disk) comprising instructions for causing a terminal device (which may be a mobile phone, a computer, a server, or a network device, etc.) to perform the method according to the embodiments of the present invention.
Example two
The method embodiment provided in the first embodiment of the present application may be executed in a mobile terminal, a computer terminal or a similar computing device. Taking the mobile terminal as an example, fig. 9 is a block diagram of a hardware structure of the mobile terminal according to a method for running a program according to an embodiment of the present invention. As shown in fig. 9, the mobile terminal 90 may include one or more (only one is shown in the figure) processors 902 (the processors 902 may include, but are not limited to, a microprocessor MCU or a processing device such as a programmable logic device FPGA), a memory 904 for storing data, and a transmission device 906 for communication functions. It will be appreciated by those skilled in the art that the configuration shown in fig. 9 is merely illustrative and is not intended to limit the configuration of the electronic device. For example, the mobile terminal 90 may also include more or fewer components than shown in fig. 9, or have a different configuration than shown in fig. 9.
The memory 904 may be used to store software programs and modules of application software, such as program instructions/modules corresponding to the methods of operating the programs in the embodiments of the present invention, and the processor 902 executes the software programs and modules stored in the memory 904 to perform various functional applications and data processing, i.e., implement the methods described above. The memory 904 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 904 may further include memory located remotely from the processor 902, which may be connected to the mobile terminal 90 via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.
The transmission means 906 is used for receiving or transmitting data via a network. The specific examples of the network described above may include a wireless network provided by a communication provider of the mobile terminal 90. In one example, the transmission means 906 comprises a network adapter (Network Interface Controller, NIC) that can be connected to other network devices via a base station to communicate with the internet. In one example, the transmission device 906 may be a Radio Frequency (RF) module for communicating with the internet wirelessly.
According to another embodiment of the present invention, there is provided a terminal, a host installed with a non-X86 architecture, including: the view operating system application programming interface Windows API simulator is used for running Windows application programs; wherein, this Windows API simulator includes: and the Windows API simulator client is positioned in the virtual machine, and the Windows API simulator server is positioned outside the virtual machine, wherein the virtual machine is used for simulating the instructions of the Windows application program.
Optionally, the Windows API simulator client is configured to execute the Windows application program, and send a call request of the Windows application program for calling an API of the Windows system to the Windows API simulator server; the Windows API simulator server is used for realizing the call request at the local interface of the host to obtain the realization result, wherein the local interface is indicated to the Windows API simulator server by the Windows API simulator client; the Windows API simulator client is also used for receiving the realization result and continuously executing the Windows application program.
Optionally, when the virtual machine is a hardware instruction simulator, the hardware instruction simulator is configured to simulate the call request as an instruction to which the host belongs; the Windows API simulator client sends the simulated instruction to the Windows API simulator server.
Example III
According to another embodiment of the present invention, there is also provided a processor for running a program, wherein the program when run performs the method as described in any of the above alternative embodiments.
Example IV
According to another embodiment of the present invention, there is also provided a storage medium including a stored program, wherein the program, when run, performs the method described in any one of the above alternative embodiments.
It will be appreciated by those skilled in the art that the modules or steps of the invention described above may be implemented in a general purpose computing device, they may be concentrated on a single computing device, or distributed across a network of computing devices, they may alternatively be implemented in program code executable by computing devices, so that they may be stored in a memory device for execution by computing devices, and in some cases, the steps shown or described may be performed in a different order than that shown or described, or they may be separately fabricated into individual integrated circuit modules, or multiple modules or steps within them may be fabricated into a single integrated circuit module for implementation. Thus, the present invention is not limited to any specific combination of hardware and software.
The above description is only of the preferred embodiments of the present invention and is not intended to limit the present invention, but various modifications and variations can be made to the present invention by those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims (8)
1. A method of operating a program, comprising:
a non-X86 architecture host runs Windows applications using a view operating system application programming interface Windows API simulator;
wherein, the Windows API simulator comprises: the Windows API simulator client is positioned in the virtual machine, and the Windows API simulator server is positioned outside the virtual machine, wherein the virtual machine is used for simulating the instructions of the Windows application program to the non-X86 architecture instructions;
wherein, the host machine of the non-X86 architecture uses the Windows API simulator of the view operating system application program programming interface to run Windows application programs, comprising:
the Windows API simulator client executes the Windows application program and sends a call request of the Windows application program for calling an API interface of a Windows system to the Windows API simulator server;
the Windows API simulator server side realizes the call request at a local interface of the host to obtain an implementation result, wherein the local interface is indicated to the Windows API simulator server side by the Windows API simulator client side;
and the Windows API simulator client receives the implementation result and continues to execute the Windows application program.
2. The method of claim 1, wherein the virtual machine is a hardware instruction simulator, and sending the call request to the Windows API simulator server comprises:
simulating the call request as an instruction of an architecture to which the host belongs by using the hardware instruction simulator;
and sending the simulated instruction to the Windows API simulator server.
3. The method of claim 1, wherein before a non-X86 architecture host runs a Windows application using a Windows API simulator, the method comprises:
the host detects the format of a program to be executed;
and designating a simulator for the program to be executed according to the format, wherein the Windows application program is run by using the Windows API simulator under the condition that the format is determined to be the Windows application program.
4. The method of claim 1, wherein the step of determining the position of the substrate comprises,
when the host is an advanced simplified instruction set machine ARM architecture, the virtual machine is used for realizing simulation from an X86 architecture instruction to an ARM instruction;
the virtual machine is configured to implement emulation of X86 architecture instructions to MIPS instructions when the host is a reduced instruction set MIPS architecture.
5. A terminal, a host installed with a non-X86 architecture, comprising:
the view operating system application programming interface Windows API simulator is used for running Windows application programs;
wherein, the Windows API simulator comprises: the Windows API simulator client is positioned in the virtual machine, and the Windows API simulator server is positioned outside the virtual machine, wherein the virtual machine is used for simulating the instructions of the Windows application program;
the Windows API simulator client is used for executing the Windows application program and sending a call request of the Windows application program for calling an API interface of a Windows system to the Windows API simulator server;
the Windows API simulator server is used for realizing the call request to obtain an implementation result at a local interface of the host, wherein the local interface is indicated to the Windows API simulator server by the Windows API simulator client;
and the Windows API simulator client is also used for receiving the implementation result and continuously executing the Windows application program.
6. The terminal of claim 5, wherein when the virtual machine is a hardware instruction emulator, the hardware instruction emulator is configured to emulate the call request as an instruction to which the host belongs;
and the Windows API simulator client sends the simulated instruction to the Windows API simulator server.
7. A computer readable storage medium, characterized in that the computer readable storage medium comprises a stored program, wherein the program when run performs the method of any of the preceding claims 1 to 4.
8. An electronic device comprising a memory and a processor, characterized in that the memory has stored therein a computer program, the processor being arranged to execute the method according to any of the preceding claims 1-4 by means of the computer program.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710796999.9A CN109460280B (en) | 2017-09-06 | 2017-09-06 | Method and terminal for running program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710796999.9A CN109460280B (en) | 2017-09-06 | 2017-09-06 | Method and terminal for running program |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109460280A CN109460280A (en) | 2019-03-12 |
| CN109460280B true CN109460280B (en) | 2023-06-30 |
Family
ID=65606044
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710796999.9A Active CN109460280B (en) | 2017-09-06 | 2017-09-06 | Method and terminal for running program |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109460280B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113098730B (en) * | 2020-01-08 | 2022-08-05 | 中国移动通信有限公司研究院 | Server testing method and equipment |
| CN113032108B (en) * | 2021-05-26 | 2021-08-20 | 武汉深之度科技有限公司 | Application program running method, computing device and storage medium |
| CN114115938A (en) * | 2021-11-03 | 2022-03-01 | 麒麟软件有限公司 | Linux cross-architecture file running method based on QEMU |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1731347A (en) * | 2004-08-06 | 2006-02-08 | 梁肇新 | Linux-based Windows software compatible layer architecture |
| CN102141929A (en) * | 2010-10-21 | 2011-08-03 | 华为技术有限公司 | Application program running method, simulator, host machine and system |
| CN102402453A (en) * | 2012-01-04 | 2012-04-04 | 北京航空航天大学 | System virtual machine facing MIPS platform |
| CN103259874A (en) * | 2013-06-05 | 2013-08-21 | 百度在线网络技术（北京）有限公司 | Method and system for cross-system operating of application and cloud server |
| CN103516593A (en) * | 2013-09-18 | 2014-01-15 | 无锡欣业信息科技有限公司 | Method and system for achieving region fast pushing information based on wechat platform |
| CN106445630A (en) * | 2016-08-10 | 2017-02-22 | 北京奇虎科技有限公司 | Android simulator and method for realizing Android simulator |
-
2017
- 2017-09-06 CN CN201710796999.9A patent/CN109460280B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1731347A (en) * | 2004-08-06 | 2006-02-08 | 梁肇新 | Linux-based Windows software compatible layer architecture |
| CN102141929A (en) * | 2010-10-21 | 2011-08-03 | 华为技术有限公司 | Application program running method, simulator, host machine and system |
| CN102402453A (en) * | 2012-01-04 | 2012-04-04 | 北京航空航天大学 | System virtual machine facing MIPS platform |
| CN103259874A (en) * | 2013-06-05 | 2013-08-21 | 百度在线网络技术（北京）有限公司 | Method and system for cross-system operating of application and cloud server |
| CN103516593A (en) * | 2013-09-18 | 2014-01-15 | 无锡欣业信息科技有限公司 | Method and system for achieving region fast pushing information based on wechat platform |
| CN106445630A (en) * | 2016-08-10 | 2017-02-22 | 北京奇虎科技有限公司 | Android simulator and method for realizing Android simulator |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109460280A (en) | 2019-03-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110618876B (en) | Linux and Android coexistence and interaction method based on Feiteng platform and shared kernel | |
| US11720344B2 (en) | Code hot-update method and device, storage medium, processor, and terminal | |
| US20180074843A1 (en) | System, method, and computer program product for linking devices for coordinated operation | |
| CN107967139B (en) | Hot updating method and device for game | |
| CN105100191A (en) | Method, device and system for realizing Java application installation via cloud compilation | |
| Wu et al. | Android unikernel: Gearing mobile code offloading towards edge computing | |
| CN103345406A (en) | System and method for achieving cloud virtual mobile terminal of intelligent mobile terminal | |
| Doyu et al. | A tinymlaas ecosystem for machine learning in iot: Overview and research challenges | |
| CN113157362B (en) | Android multi-window display method applied to Linux | |
| CN109460280B (en) | Method and terminal for running program | |
| CN103443763A (en) | ISA bridging including support for call to overidding virtual functions | |
| CN101800910B (en) | Simulation system, PC side simulator and mobile phone side agent client | |
| Yousafzai et al. | Computational offloading mechanism for native and android runtime based mobile applications | |
| CN111123737A (en) | Digital hardware virtual simulation system | |
| CN117369993A (en) | Method for compatibly running different service systems in Linux environment and credit creation server | |
| Wu et al. | Porting mobile web application engine to the android platform | |
| CN113657069B (en) | SOC simulation verification method and device, verification server and storage medium | |
| CN114816672A (en) | Virtual machine creation method and device, electronic equipment and storage medium | |
| JP2007505395A (en) | Continuation-delivery methods and equipment in virtual machines. | |
| CN113641577A (en) | Debugging method and device for terminal product application program | |
| CN112306539A (en) | Method, system, terminal and medium for developing application layer of single chip microcomputer | |
| CN117193942A (en) | Lightweight virtual machine creation method and device, electronic equipment and storage medium | |
| CN102364435B (en) | Method for realizing application program interface (API) of WinCE | |
| CN109426571B (en) | Method, system, storage medium, processor and apparatus for function call and data access | |
| CN113467861B (en) | File calling method and device, storage medium and electronic equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20240529 Address after: No. 99, West Section of Hupan Road, Xinglong Street, Tianfu New Area, China (Sichuan) Free Trade Experimental Zone, Chengdu City, Sichuan Province, 610213, with OL-10-20230003 attached Patentee after: ZTE Communications (Chengdu) Co.,Ltd. Country or region after: China Address before: 518057 No. 55 South Science and technology road, Shenzhen, Guangdong, Nanshan District Patentee before: ZTE Corp. Country or region before: China |