Linux is compatible with Win32 programs. "One framework and two interfaces"

Linux is compatible with Win32 programs. & quot; one framework and two interfaces & quot; -- Linux general technology-Linux programming and kernel information. For more information, see the following. The objective of developing a Linux-compatible kernel is to allow Windows applications to run directly on this kernel, more specifically running on the operating system with this kernel as the core. In addition, some device driver modules developed for Windows can also be loaded into this kernel. This is because the number and variety of device driver modules developed for Windows are far greater than that of Linux. On the other hand, more and more applications need to run with dedicated device driver modules, the driver module cannot run without this device. Only by achieving both goals can we say that the Linux kernel is compatible with the Windows kernel. So, in order to achieve these two goals, what modifications and extensions must be made to the Linux kernel? This article will analyze and answer this question.

First, a closed program, if neither the library program nor the system call is called, is unrelated to the operating system, as long as the CPU of the machine is consistent with the target CPU of the program during compilation. This is because, taking PC as an example, all the commands generated after the program compilation are x86 machine commands, and all these commands can run normally, all of its jump commands and subroutine calls mean that the target of the command will not go beyond the boundaries of this program. Second, even if you need to call the Library Program, as long as you do not directly or indirectly call the system, it is also irrelevant to the operating system, because the calling of the library program is equivalent to expanding the territory of the program and advancing its boundary. Therefore, as long as no direct or indirect system call is made, the running of an application has nothing to do with the operating system, so it can run on any operating system. However, in general, such a program cannot run as an independent application or process, because an independent process must at least be input/output, this is inseparable from system calls.

How does the application software call the system? As we all know, this is implemented through the trap command, which is an int command on the x86 processor. In fact, the Linux kernel uses "int 0x80" for system calling, while the Windows kernel uses "int 0x2e ". This first Prevents Windows applications from running on the Linux kernel. Imagine that Windows Application Software attempted to call the system through "int 0x2e", and the Linux kernel considered this an illegal Trap Command. It can be seen that the Linux kernel must first accept "int 0x2e" as one of the methods for system calling. We should really thank the designers of the two kernels. If they both chose 0x80 or 0x2e, it would be hard for us to do it now. Fortunately, they do not conflict with each other.

Because all system calls use the same trap command to enter the kernel, you need to use the "call number" parameter to distinguish the required specific operations and functions. Therefore, in addition to the commands used for system calls, we need to consider how many call numbers are used in total. What operations and functions are corresponding to each call number and what parameters are required for each call number, what is the result, how to return it, and what are the side effects. All these factors constitute a system call interface. Of course, the Windows system call interface is different from that of Linux. To enable Windows software to run directly on the Linux kernel, the Linux kernel must also provide a Windows system call interface, otherwise, the Windows software will be "grafted" to the Linux system as Wine does. Wine has done a good job on the "grafting" side, but we know the effect is still unsatisfactory.

Let's talk about the Windows system call interface. On the one hand, it is about its performance, it is the calling method, parameters, effects, returned results, and side effects of various system calls that Windows applications see outside the kernel. However, on the other hand, what is more important is what is behind this interface, that is, the implementation of these system calls. Our workload in this area is also here.

According to "unreceivented Windows 2000 Secrets", Win2k has a total of 248 common system calls (the results of reverse engineering are evidenced ). Some of the system calls are very simple, or they can be replaced by the corresponding Linux system calls, but others are very complicated. Obviously, it is not realistic to develop these system calls from scratch (although ReactOS does ), what we need to do is try to use the low-level functions in the Linux kernel to implement these Windows calls. In a sense, Wine is outside the kernel to graft Windows applications to Linux system calls, our compatible kernel is to graft Windows system calls to many Linux kernel functions in the kernel. Grafting in the kernel is better than grafting outside the kernel, on the one hand, because the kernel function has a smaller "granularity, the relationship between kernel functions and system calls is a bit like that between assembly languages and advanced languages. On the other hand, the kernel space is uniform and provides a global view. For example, the process control blocks (PCB) of all processes can be seen in the kernel, while processes are isolated from each other when the kernel reaches the user space. Therefore, all operations that require a global view should be implemented in the kernel.

In addition to these common system calls, Win2k also has 639 GUI system calls. So we moved X11 to the kernel. Before WinNT 4.0, Windows, like Linux, was operated and managed by the graphic service process of the user space, which is of course less efficient. From WinNT 4.0, we moved graphic operations and Windows Management to the kernel to become a installable module win32k. sys. This makes sense to improve the speed of graphic Operations, otherwise the operation of game software will not be so smooth (of course, later with DirectX, further improving the speed of image/graphic operations, ). Therefore, strictly speaking, the so-called Windows system call interface also includes these graphic operation calls. However, the "raw material" to implement these calls is no longer a Linux kernel function, but a related function in X11. Of course, there is no need to cook over six hundred calls at the beginning. In fact, even the implementation of 248 common system calls does not need to be completed in one step.

After the system call interface is completed, many system calls can be implemented, such as creating processes and obtaining system time, which can be fully implemented in the Linux kernel. However, once the input/output is involved and the device driver is involved, the problem may occur again. The problem is not that drivers from conventional devices, such as the keyboard, mouse, hard disk, and other commonly used devices, are available in the Linux kernel. You just need to graft the system over. The problem lies in some special devices, especially new devices. Manufacturers of these devices often only provide the device driver module, namely, the. sys file, for Windows. If such. sys modules cannot be loaded into the Linux kernel and run properly, the compatibility with Windows applications may not be complete.

It is not difficult to mount the. sys module into the Linux kernel, because the dynamic installation module of Linux is essentially different from that of Linux. The difficulty is to make it run normally in the Linux kernel. To achieve this goal, first, connect the mounted modules to relevant system calls, and hook down (possibly) with the interrupt response mechanism; the second is to provide a specific environment for the module operation. In fact, the. sys module can be loaded into the Windows Kernel and run properly because the Windows Kernel meets these two conditions. Obviously, the existing Linux kernel does not meet such conditions. It meets the Running Conditions of the Linux dynamic installation module, which is similar to the differences between the two System Call interfaces. Therefore, this has become an important part of kernel-compatible development, and also represents a considerable workload.

Let's take a look at how the Windows Kernel meets these two conditions and know what we have to do.

First, how to hook and connect the. sys module with related system calls and interrupt responses. In other words, how to include the. sys module into the device driver framework in the kernel, including the position where the specific module is placed in the framework, and how to interact with the modules or components adjacent to the upper and lower sides. In the Windows Kernel, this is mainly about the I/O subsystem. It is embodied in two aspects: on the one hand, after the module is installed, it must first register with the I/O subsystem, or the device driver registration level above, that is, indirect registration to the I/O subsystem. On the other hand, when the relevant system call occurs, it is through the I/O Sub-system into a layer-by-layer call and return for a specific device driver. Therefore, the I/O subsystem represents the main body of a device driving framework. However, the I/O subsystem is not the entire device drive framework, and the. sys module may be hooked up with the interrupt response. For example,. one part of the sys module may run as an interrupt service, the other part may run as an bh function (known as DPC in Windows), and the other part may be driven by the I/O subsystem. The. sys module of Windows is developed for the device driver framework of Windows. Since we want to load these. sys modules into the Linux kernel for running, we must build such a framework in the Linux kernel. Specifically, it is necessary to implement the Windows I/O subsystem, the interrupt response/service mechanism of Windows, and some auxiliary components in the Linux kernel.

The Windows Device Driver framework solves the problem of loading and using the. sys module. If every module is closed and independent and does not require environment support, that is enough. However, in fact, there is almost no such closed and independent device driver module, and almost every module needs to be supported by the inverted environment. For example, a device driver module may need to allocate a buffer during operation. However, the driver module does not have this capability because it does not have any memory resources that can be dynamically allocated. Therefore, we had to request the kernel for allocation, which is the environment dependency. Therefore, the operating system kernel requires a large number of kernel functions to be called by the dynamic installation module. The size of this function set, as well as the call conditions, parameters, functions, return values, and side effects of each specific function constitute the device driver support interface of the specific kernel. Obviously, different kernels have different device driver support interfaces, as if different kernels have different system call interfaces. To make the. sys module of Windows run normally in the Linux kernel, you must provide the Windows Driver support interface in the Linux kernel. Unlike the system call interface, the Windows Device Driver support interface is publicly defined (otherwise, a third party cannot develop a device driver module for it ), it is defined as DDK of Win2k or WinXP, that is, "device driver development kit ". The DDK of Win2k defines 2000 support functions, but hundreds or even fewer are commonly used. Of course, Microsoft only discloses the definition of this interface, not its implementation.

So how can we implement these supporting functions? The old method is to convert them into or graft them to the corresponding Linux Device Driver support function.

It is worth mentioning that Windows defines another framework for network device drivers, known as NDIS, and provides a dedicated NDIS Device Driver support interface, to make the driver module of the NDIS device only need (and should only) to call the support function on the NDIS interface. In this way, the drive of the network device is self-built and has a small framework. However, both the NDIS framework and the supporting interface are relatively small. It can only be regarded as a dependency and expansion of the driver framework and interface of Windows devices, in addition, many NDIS support functions are actually simple package installation of some Windows Device Driver functions, so we classify NDIS into the framework and interface of the Windows Device Driver.

To sum up, we develop a Linux compatible kernel, which implements this framework and two interfaces in the Linux kernel: windows Device Driver framework, Windows System Call interface, and Windows Device Driver support interface. This is the subject of Linux compatible kernel development. Of course, there are still a lot of fragmented and auxiliary development work to do, but the workload is relatively small.

However, "One framework and two interfaces" are the subject of development work. This is compatible with the kernel itself, not the entire operating system. To make Windows applications run normally, some DLL, dynamic connection library, and some supporting service processes must be supported outside the kernel. If you simply look at the problem from a technical perspective, you only need to have a compatible kernel, because we can copy the DLL and supporting service programs on Windows. However, this is not only a technical issue, but also a legal issue. We cannot infringe the copyright of Microsoft. Therefore, these DLL and supporting service procedures also need to be developed. Fortunately, Wine has done a lot of work for us in this regard, you only need to make some modifications to the four DLL, that is, the so-called "four major. Note: It is exactly these four major components that require you to marry a Windows system call to a Linux System Call: kernel32.dll, gdi32.dll, user32.dll, and ntdll. dll, now we have to make them look back to their original faces, and twist the distorted things back.

We should also see that Windows technologies and applications are also developing. These developments are more reflected in DLL and service processes, such as OLE, COM/DCOM ,. NET is mostly implemented through DLL and service processes. Although Wine has already done a lot of such DLL and service programs, development in this area may never be completed, but it is a long stream of water.