Three important sources of Linux compatibility with the kernel

Article Title: three important sources of Linux-compatible kernels. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.

The Linux compatible kernel we want to develop and build is not without source, nor does it need to "re-invent the wheel" from scratch ". As Newton said, "standing on the shoulders of giants", we should also make full use of the achievements made by others, especially those made by open-source communities.
Apart from Linux, there are three main sources of kernel compatibility: Wine, NdisWrapper, and ReactOS. All three are open-source projects established in Sourceforge. The source code can be downloaded from www.sourceforge.net.
Next, we will give a brief introduction to the three sources.

Wine

According to the Wine project, Wine Is short for "Wine Is Not an Emulator. This reminds us of the GNU "Gnu is Not Unix ". Many people may laugh at this and think it is a text game or humorous. However, I think this is actually a deep idea behind it. GNU says it is not Unix, meaning that although it is basically Unix or very similar to Unix, you cannot ask for it according to various Unix standards, in some cases, it is a little different from the real Unix. This is a "first-in-words" statement. Why does Wine say it is not a simulator? This reflects that Wine designers are afraid that others may mistakenly think that Wine is a simulator. This is mainly because the word "Simulator" is easy to misunderstand and thinks it is a simulation of CPU machine commands, which is very inefficient. So this is actually an argument, saying that Wine is not efficient. Of course, the efficiency of Wine is indeed much higher than that of simulation in the general sense.

So what is Wine?

? For Windows applications, Wine provides simulation for the Windows operating environment, So Wine can also be understood as "WIN Emulator ". This is exactly the reason why Windows applications can run on Linux. However, this simulation is not a simulation of CPU commands, but a simulation of Win32 API function calls.

? For Linux and its kernel, Wine is an intermediate layer between the kernel and Windows application software. On the one hand, it provides various dynamic connection libraries (DLL) for Windows application software, so that the library function calls implemented by the application software through Win32 API can be implemented, on the one hand, the system calls made to the Windows kernel by application software and dynamic Connection Library are translated into Linux kernel system calls and passed on to the Linux kernel.

? For many dynamic connection libraries, services/daemon, and tool programs that are part of the Windows operating system, Wine is the transplantation of these software on Linux, and it is actually a copy. In the second part of the article "intellectual property rights for Linux compatible kernels", the author divides software on Windows into five categories, all of which belong to the fifth category, that is, software developed by Microsoft, it should belong to the operating system and the software bound with Windows.

Wine does not touch the Linux kernel at all. All operations are performed outside the kernel. Some operations should have been implemented in the kernel, but because they do not touch the kernel, they have to try to set compensation outside the kernel, that is, in the user space. However, using a Linux system call to call a Windows system outside the kernel is like using another advanced language (for example, using Cobol to implement Fortran ), it often leads to very clumsy implementations, and some cannot even be implemented at all. This is because every specific system call in Linux or Windows is like a statement in a high-level language. Although we can regard it as a black box, however, it is very difficult to make the two black boxes identical in terms of input parameters and conditions, calculation results and side effects. It is true that Linux system calls are rich, flexible, and expressive, a bit like C language, which provides a good foundation for implementing Windows system calls through Linux system calls. However, even so, there are still many difficulties. The following is an example.

In Windows, a Handle is returned in operations such as opening a file (translated as a "Handle", I think it is not very good, but I cannot think of a better word ), this is the subscript used for a pointer array. Every process has such an array, So Handle is not global in principle, but limited to specific processes. Maybe the reader will immediately think of the opening file number. The two seem to be exactly the same, so you can use the Linux opening file number to implement Windows Handle. However, Windows Handle is not only used for files, but for all kinds of "objects". This is not to mention, but it is a bigger problem. When creating a child process, the Windows Kernel allows you to selectively "inherit" Handle. Of course, the Linux kernel can also inherit the file number when creating a sub-process, which seems to be the same. But it is troublesome. In Windows, when a file is opened, the parameter specifies whether the opened file can be inherited. When creating a sub-process, the parameter specifies that, indicates whether to inherit the opened files (Handle) that can be inherited by prior regulations (see "Advanced Windows", p17 ). It should be said that this is a good idea. What about Linux? It is inherited from three open file numbers: 1, 2, and 3. It is not difficult for anyone who knows about the kernel to make some extensions in the Linux kernel to implement the Windows genetic mechanism. But what if we want to implement it outside the kernel? Readers may wish to use their brains. If you have a very concise method, you may wish to let me know and give me a chance to express my admiration and congratulations.

As for the device driver, since it does not touch the kernel, it is naturally impossible to solve the problem of the device driver. Of course, for peripherals (such as hard disks) with corresponding device drivers on Linux, you can "Redirect" the Windows application's operations on these peripherals to the corresponding Linux device. But the problem is that those devices that have driver modules (. sys files) on Windows and have no driver modules on Linux. What should they do?

[1] [2] [3] [4] Next page