Compile the Linux code for the simulator

It takes a long time to simulate other computers on a computer, usually to use legacy applications, or an application written to run popular OS on a system with a more stable and faster response. As Linux becomes increasingly popular, developers need to examine their choices when planning to run binary programs on non-Linux systems. This article will study the functions of the simulator, and will detail the problems of hardware simulation and software simulation.

It has been a long history to simulate other computers on a computer. A common reason for simulating old computers is nostalgia, but it is undeniable that many simulators can run a variety of computer games very well. Another reason for simulating other computers is to use application software that only exists on a specific platform.

Typically, application simulation targets platforms that occupy a large market share. For example, the WINE project tries to provide a way to run the Windows binary program.

However, Linux has proved to be a stable and all-powerful operating system in recent years. As a result, its market share has also increased. The increase in market share has aroused interest in simulating Linux. This article reviews the current situation of Linux binary program simulation on other systems, and highlights that in order to make it easier for people to run their binary program in the simulation environment, some issues that developers should keep in mind.

Basic Simulators

The idea of the simulator is very simple. Computers are fully predictable. If you want to know exactly what a particular code computer will do, you can get the result by creating a model for this computer. Of course, this involves a lot of overhead, but if the computer to be simulated is much older than the computer being simulated, the simulation environment will be faster than the original machine.

There are some simulation layers, such as the Linux Simulation layer of NetBSD, which only provides simulation of software in an environment, obtains system calls from the Linux library, and processes the returned results, it looks like you are using the Linux kernel. Other simulation layers, such as VirtualPC, can simulate the entire computer, including the processor. The speed of the simulation processor will be slower, but it can bring better compatibility.

Release Version format Simulator

Although this article focuses on running the Linux binary program on other platforms, the compiled binary program release version also occupies a place. With the increasing popularity of Linux simulation environments, the format of Linux binary programs has become a feasible method for issuing simple programs (without source code. The Linux binary program can run on multiple systems. It is undeniable that sometimes it has to pay some cost-using the Linux binary program format as the general release version format will also face some challenges.

Generally, the simulation is insufficient for you to operate on shared objects built by a system in programs built for another system. If most of your products are released in the form of shared library objects, these products may not be loaded to other platforms.

Some people think that it is crazy to use the Linux binary program format to issue code to other platforms. Maybe this is crazy, but it is feasible. In recent years, my main Web browser has been running in a simulated environment (not to mention word processor, document converter, or even credit card processing software ).

Most of the software applications we are happy to use are commercially available, and a single binary program that can run on many platforms can greatly benefit commercial software vendors. If a variety of Linux simulation environments are available, the format of the Linux binary program is represented by the first real software release version.

Oh, source code porting has a lot to do with distribution. Generally, porting is easier.

Full Hardware Simulator

A full hardware simulator simulates a complete machine, not just a processor, but also all the rest of the machine. For example, a simulated computer may have its own keyboard controller and video card.

Full hardware simulation is often used in programs that use older machines. The arcade game simulator is a popular example that simulates hardware for a variety of vintage arcade game consoles.

In some respects, a full hardware simulator is the easiest way to simulate. A complete hardware simulator is required for a lot of work, but once you have such a simulator, everything can be solved. For example, VirtualPC Version 3 for Macintosh supports Linux.

Hardware simulation can solve problems that are difficult to solve in other ways. For example, I used to have a BIOS flash tool that was released only in the format of a self-decompressed image file for DOS. Worse, the machine that runs it must install the actual floppy disk on the traditional ISA floppy controller (my Windows desktop has a LS-120 drive ). Solve this problem through simulation! I run this program in the simulator to write data to a USB floppy drive that has been inserted into the Mac.

Hardware simulation also has its disadvantages. In order to make everything work, we need to make great efforts. If you need a network, you need to simulate the network chip well so that the operating system can run on the chip. In addition, it may be very costly to simulate commands that do not have them. Generally, a system like this can operate almost perfectly, but time-based functions may be unreliable.

The full hardware simulator has been used for a long time, and is most suitable for legacy systems and code that may be affected by simulation processing speed.

Even so, users who want to run the x86Linux binary program on a Macintosh or any other non-x-86 machine may have to rely entirely on some of the currently available x86 simulators to try running the program. On a system like this, most tool programs will run very well (although it may be slow ). The only concern is that to improve performance, users of such systems may install small or older Linux distributions. Those who use 32 MB memory to run the simulated machine cannot run the latest version of KDE.

Some hardware simulators

Some hardware simulators provide an intermediate solution: They simulate a computer, but this computer can only be of the same type as the computer where they actually reside. Because the execution speed is equivalent to that of the host machine, programs like this can reduce the simulation cost. Examples of such simulators include serenity virtual station and VMWare.

These systems are most useful when you have applications for multiple operating systems and need to run them simultaneously. Similar to a complete hardware simulation, such a system will run a complete Linux OS environment, as long as your program can be properly transplanted across Linux systems, then there is no problem. However, it is declared again that the portability of Linux to older versions will be very useful. People who use virtual machines may be willing to run an old Linux version with a small footprint on such a system.
Software Simulator

In the simulation world, software simulators are the most basic. A software simulator does not run your application on a virtual machine-It runs it in real time instead of through a virtual machine. Create an environment in which the code of the program can run normally. However, attempts to access the operating system of the program will be sent through a simulation layer, these programs can be used. Wine is an excellent example (though for Windows), although it is not a formal simulator.

Some software simulators are explicitly called by users, such as lxrun programs that can be used in SCO and Solaris systems. Some software simulators are built into UNIX Kernel support for loading binary images-if the program looks incorrect, it can be compared with a possible simulator table, to check whether they can run it.

Software simulators usually provide the best user experience. No special settings or large disk images are required. You only need to run the program (in most cases ). However, access to system calls, shared libraries, and file system structures can lead to many problems, so we will discuss them later.

System Call

System calling is the simplest and most difficult part of simulation. A system call has a clearly defined interface, and usually can conveniently detect and process the call mechanism-this is a simple part. The difficulty is that it may be difficult or impossible to implement system calls. Traditionally, the most difficult to handle in Linux Simulation is clone () system calling. This call provides a forced way to obtain a simple thread, that is, to create two processes that share many contents. The shared content can include memory, file descriptors, and signal processing-in other words, it can include any content and all content. Unfortunately, if your operating system does not have similar functions, there is no way to implement this system call.

Worse, since POSIX Threads are not yet complete or widely supported, clone () has emerged and is often used as an alternative to POSIX Threads, many programs use it in a variety of exciting, complex, and unexpected ways.

If you want people to run your binary program, try to prevent them from using system calls for specific operating systems; it is best to use standard POSIX system calls. This is a good habit of software development.

A kernel-based simulator can capture system calls to it. A user space simulator, such as lxrun, will wait for the application to try to call the system. Because the Linux system call function is different from the system call function on Solaris or SCOUNIX, a code segment error occurs. Then, the lxrun program corrected the error like a debugger and made the system call continue to run -- but, in fact, it has intercepted the system call, it also calls the underlying operating system and solves all problems. Smart!

File System Structure

File System problems are usually more subtle. It is extremely simple to access the file system. It's not easy to find the file you want.

If your program runs in a simulated environment, the file system to be accessed may be essentially different from the file system used during program development. For example, if your program uses the/proc file system (often used to obtain Kernel Status and information ), common Features in newer kernels may not exist in older systems.

The developers here have great advantages over those on the proprietary system, because different Linux releases arrange files in different ways, therefore, most programmers are very clear about how to avoid over-reliance on file system design. But -- sometimes -- the file name has to be embedded into the program.

One solution adopted by many simulators to solve this problem is to create an additional interpretation layer for file system calls. For example, in the Linux simulated environment code of NetBSD, first check the access to the file according to the file in/emul/linux before checking the files in the real root directory of the system. This allows the system to provide override system files when the Linux binary program does not use standard files.

In fact, this method is mainly used in libraries and other supporting files, but it also provides many system binaries. For example, if the Linux binary program tries to call uname to obtain the kernel version, but obtains the NetBSD version, this will be very confusing. Instead, it should get the expected Linux version number.

Shared Library

As mentioned above, the shared library is a good example of a binary program that can be simulated but cannot be found by the system binary program. Because the formats and ABI details of shared libraries may vary on different systems, you cannot arbitrarily assume that all systems can share a given library. The name may conflict. For example, both NetBSD and SUSE7.3 have a file named libncurses. so.5. It is important to use the correct one.

The shared library points out another note for developers. It is important to understand the library versions that are being used by different systems. Now, the NetBSD Linux Simulation Environment is using the SuSE 7.3 shared library. There are still code using the 9.1 shared library, but they receive warnings that they cannot perform kernel-level simulation stably.

Simulation Environment software packages are usually far behind the market. Even if you think most of the expected users should have a fairly new Linux release version, a large number of simulators are still barely keeping up with the times.

Shared libraries also raise another concern-not every system contains all shared libraries. A simulated environment package typically does not install all the latest shared libraries. What's more troublesome is that their users are unlikely to be able to easily install the missing software packages.

In these cases, it is a good way to minimize dependency on new features and non-core shared libraries. Simulator users may encounter these problems.

Do not mistakenly think that using static libraries can solve these problems. Static libraries may introduce their own new dependencies, and it is not easy to check them. If a system call cannot be transplanted is statically linked, it will be useless to avoid this system call by rewriting the algorithm. Dynamic Links allow you to build programs to run on a wider range of systems.
Programs that call other programs

There is a special situation that is more troublesome than any other situation, especially related to the installer. In many systems, the shell obtained by calling/bin/sh is not bash. This means that scripts that use Bash extensions may not run on other systems.

This is a complicated logic in the simulator. When executing a binary program, the operating system may know enough to check the Linux path of the relevant Linux binary program, and it may install a copy of bash there. However, when you run a script, the kernel does not regard it as a Linux binary program. It finds that the script is attached with an interpreter path. When you try to load the interpreter, it will no longer run in simulated mode.

The portable shell script technology has been applied here. This is one of the most common problems when a user runs a simulated application. The installer may not run because it is not a portable shell script.

Similar to standard development, but more standard

To make it easier for users who may want to run your program in a simulated environment, note the following when developing the software and note the following when developing any software:

Follow appropriate standards whenever possible.
Avoid "Special features ".
Do not push the envelope ).

Also, do not rely on something just released a month ago to build your code. This will narrow down your effective target market.