Description: The Linux Unified Kernel Project -- Linux Unified Kernel 0.2.1
Copyright: ========== (c) 2006 Insigma Co., Ltd
This is an opensource project; you can redistribute and/or modify the programs under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
The Project: ============ Linux Unified Kernel is a project (linux.insigma.com.cn) in the Insigma Research Institute, which is a subdivision of Insigma Co., Ltd (www.insigma.com.cn).
The Package: ============ o This package implements the basic mechanisms of Microsoft Windows includeing process/thread mamangement, object management, virtual memory managment and synchronization. With the support of Linux Unified Kernel 0.2.1, most of general Win32 applications (see APPLIST) can run directly on Linux.
To Build and Run: ================= To build Linux Unified Kernel, there are 3 steps to go: o Build Linux kernel o Build Linux Unified Kernel module o Build Wine
To run a Win32 application, you can just input the executable file in shell or double-click the shortcut.
To get more details of building and running, please read INSTALL.
To Do in Future: ================ o File System Integration. o Bug Fix for Pthread TLS. o Windows Application Testbed. o The Windows Registry mechanism. o Various system call functions on the Windows syscall interface. o The WDM device driver framework. o The Windows DPC mechanism. o Exported kernel functions defined by Windows DDK. o Others.
Why === The previous release (0.2.0) of the Linux Unified Kernel implemented Windows Process/Thread creating, so that some simple Win32 programs might work on Linux. Howerver, many other Windows mechanisms like multi-threading were not implemented, and most of general Win32 applications can't run with this release's support.
What's new in this release ========================== Process/Thread management. Object management. Virtual memory management. Synchronization. Built-in EXE loading function. Patches for both updated Linux kernel and Wine. Many bug fixes in process/thread creating.
How it can be used ================== After installing the Linux Unified Kernel 0.2.1, you can run the programs directly listed in APPLIST.
Implemented =========== This version of Linux Unified Kernel provides several Windows mechanism implementations, including process/thread management, object management, virtual memory management, synchronization, etc. Also, the relevant system calls are implemented to replace the services running in the user space.
Process/thread management which is one of the most important components in Linux Unified Kernel is implemented based on the previous release. In this version, some other strategies such as multi-threading are introduced, so that the process/thread management can take the place of the corresponding operations in Wine.
Object management and virtual memory management are the new features. Object management which has no counterpart on Linux builds an infrastructure for all the Win32 objects, and virtual memory management combines Win32 system calls to their core operations in Linux kernel.
Synchronization in this version is improved from the previous release, and the strategies enable the implemented objects to be synchronized when processes or threads are running.
For compatibility consideration, this version also provides some operations to work with Wine. For example, the module loading built-in EXEs is offered to run the "exe.so" programs in Wine, like explorer.exe.so, regedit.exe.so, etc. You also can run the tools which Wine provides to configure or to do other work.
Not fully implemented ===================== Linux Unified Kernel 0.2.1 provides the mechanism to run built-in EXEs, but this support is not perfect for some application installations. As a result, you need run the script switch.sh before installing a Win32 application (please see INSTALL for details).
This release of Linux Unified Kernel provides some operations like token -opening which are in the range of security mechanism. These operations will not work exactly as they do on Windows, but they are needed by the current Linux Unified Kernel in other mechanisms. Those components will be fixed in future.
About this list =============== This version of Linux Unified Kernel implements some most important mechanisms, and fixes many bugs in the last version. Now many general Win32 programs can run on Linux system. Here is the list of some important applications that we have tested.
The applications on the list may not work well as on Windows system. You can report the bugs to linux@insigma.com.cn.
Application name ================ Microsoft Office 2000 ( Word, Excel, PowerPoint) Securecrt 5.0 Dream Weaver 8 WinRar Acrobat Reader 5
Quick start =========== To get the support of Linux Unified Kernel, there are 3 basic steps to go: 1. Build Linux kernel 2. Build Linux Unified Kernel module 3. Build Wine
To run Win32 applications on Linux Unified Kernel, just do it like running a Linux program.
For more details, please read the rest of the file.
The current version (0.2.1) of Linux Unified Kernel provides 2 patches for both Linux kernel and Wine, so the versions should be specified.
Basic requirements: Make sure you have installed the X11 development include files (called xlib6g-dev in Debian and XFree86-devel in Red Hat).
Build tool requirements: Make sure you have at least gcc 3.2 available which Linux kernel 2.6.23 requires.
Building Linux kernel ===================== To build Linux Unified Kernel, the first thing is to patch the Linux kernel 2.6.23. First, cd to the top-level directory of the kernel-source code (linux-2.6.23), then run the following command:
patch -p1 < path/patchfile
where "path" is the path of the patch file and "patchfile" is its file name (In this package, it is unifiedkernel-0.2.1-k2.6.23.diff in the directory "kernel").
After patching kernel, configure it like:
make menuconfig
The general configuration file is provided in the patch (you can also configure it yourself), you can just save and exit to run the next commands:
make make modules_install make install
Then reboot your system to build the Linux Unified Kernel module.
Building Linux Unified Kernel module ==================================== To build the module, cd to the "module" directory and run the command:
make
Then install the module to get the Linux Unified Kernel support:
insmod unifiedkernel.ko
Building Wine ============= To use the Win32 programs, you need to build the user space environment. The script install.sh will help you do this building work automatically:
./install.sh -w wine_path -f patch_file -p prefix
where "wine_path" is the path of the Wine-source code(0.9.40), "patch_file" is the patch file name of Wine(unifiedkernel-0.2.1-w0.9.40.diff), and "prefix" is the directory of storing the built-in programs whose default is "/usr/local"
Running programs ================ After the 3 steps of building, you can run none-installed Win32 programs that APPLIST lists.
For example:
./calc.exe (running Win32 Program calculator in the current directory) /usr/notepad.exe (running Win32 Program Notepad in an absolute directory)
or double-click the icon created either by the install program or by yourself.
As this release of Linux Unified Kernel doesn't support build-in EXE perfectly, so you need to install the Win32 applications like Microsoft Office 2000 that need installation in the Wine environment.
Everytime you want to install a Win32 program, please follow the 3 steps:
./switch.sh -p prefix -w wine_path -d wine (chang to the Wine running environment)
wine setupfile (install application)
./switch.sh -p prefix -w wine_path -d unifiedkernel (chang to the Unified Kernel running environment)
where "setupfile" is the file name of the installation file like "setup.exe", and the options "prefix" and "wine_path" represent the same meanings as they are in the script install.sh.
After that, you can run a Win32 program with the Linux Unified support.
* Note: everytime you want to install a Win32 application, please use the 3-step installation, and after that, it will keeps you running Win32 programs in Linux Unified Kernel environment.
Linux Unified Kernel is not yet completed, so several programs may crash or not work exactly as on Microsoft Windows. You can report these bugs to linux@insigma.com.cn.
UNINSTALL ======== If you don't want to use Linux Unified Kernel any more, you can uninstall it. 1. Uninstall module:
rmmod unifiedkernel.ko
cd to the directory "module" and run command:
make clean
2. Unpatch Linux kernel 2.6.23 and Wine 0.9.40: cd to the top-level directory of the kernel-source code or Wine, then run the command:
patch -R -p1 < path/patchfile
where "path" is the path of the patch file and "patchfile" is its file name.
The main problem is not whether kde-apps is or is not the place. It is of language and I do not mean C.
I think I see what our Chinese friends are trying to accomplish but the Bable-fish translations are really not readable.
If I knew that the kernel patches were compatible with the RT preempt, I might try that (one can always keep multiple kernels around in Linux). Patching wine is a bigger and more continuous bother and I doubt many will try that. This thing wants to replace wine with kernel level operability so either "in" or "out".
As I said, get multimedia device compatibility at native speeds and this will be prize. Of course, now one must moderate the native-linux accesses and the Linux Unified Kernel accesses which may now be hitting the same hardware.
A few questions?
1. What does this do more than what wine does now?
2. Safe to apply patch to -rt (Ingo's) patched kernel (rt preemptable)?
3. Wine, I suppose, will now use the kernel module. I do not understand patching EITHER wine or the kernel. (I think building wine from source takes longer than compiling the kernel.) It might do to have this incorporated into the wine project and if it be possible to leave the linux kernel alone and simply compile the module against the kernel source or headers, this might be better for most users.
Correction: One must patch BOTH.
This is a big job and wine is updated very often. So I do not know if I will start with this.
A working WDM would be very very tempting but might be a better idea might be a bridge to jack the wine-asio works (this works very well!).
.
Below the text of automatic translation from google.com:
"A framework, the two interfaces"
Maode parade
We develop Linux-compatible core objective is to enable Windows applications directly in the kernel can run on more precisely in order to the core as the core operating systems. At the same time, but also allow for the development of Windows and some of the equipment drive module can also run into the kernel. This is because for Windows device drivers are developed in terms of quantity and variety are far more than Linux on the other hand is because there are more and more applications need special equipment to drive module supporting operation, missing This device driver modules running up. Only at the same time to achieve the two goals can be said that Linux kernel compatible with the Windows kernel. So, in order to achieve these two objectives, we must make some of the Linux kernel revision and expansion of what? This paper is an analysis of this, and answer this question.
First, the closed section of the procedure, if not call the process, nor for system calls, with the operating system is irrelevant, as long as the CPU of the machine with this procedure compile-time goal can be consistent with the CPU. This is because the PC-for example, this procedure generated by the compiler all the instructions are all x86 machine instructions, and all these directives can all normal operation of all of its instructions and subroutine calls Jump instructions are not the target this process beyond the borders. Secondly, even if the procedures need to call, as long as no direct or indirect system calls, also has nothing to do with the operating system, called the procedure because of the effect on the expansion of this procedure equivalent to the site to promote its borders. Therefore, as long as no direct or indirect system call, the application will follow the operation of the operating system irrelevant, thus can be run on any operating system. Generally, however, such a procedure is not as a separate application, the independent operation of the process, at least since the independence process has to input / output, which can not be separated from the system call.
So how application software system calls? As we all know, this is achieved through the trap instructions, is in the x86 processor instructions int. In fact, the use of the Linux kernel, "int 0x80" Achieving system calls, and use of the Windows kernel, "int 0x2e." First of all, this makes Windows applications can run on the Linux kernel. Just think, an attempt to Windows applications through "int 0x2e" system call, and the Linux kernel that this is illegal trap instructions. So, first of all, the Linux kernel must accept the "int 0x2e" as a means of system calls. We really thank the two of the core designers, if they originally chose the 0 x80, or choose to have a 0 x2e, which we are now harder to resolve. Fortunately, this conflict is not among them.
Since all system calls through a trap with instructions to enter kernel parameters on the need to adopt the "call" to distinguish between the specific requirements of the operation and function. So, what instructions in the system call, we must also consider the use of the total number of calls, each call, what response operation and functions, what needs some parameters, what the outcome, how to return to, what are the side effects, etc. . All of these factors together, constitute a system call interface. Of course, Windows and the Linux system call interface different. To bring Windows software to run directly on the Linux kernel, it must allow the Linux kernel also provides a Windows system call interface, it just seemed as the Wine Windows software "grafting" of the Linux system call. "Grafted", the Wine has done a very good job, but we know that effect or not ideal.
Our system call interface for Windows, of course, say that the performance of Windows applications is the core of the outside see specific system calls call methodologies, parameters, effects, the results of the return, as well as side effects. But on the other hand, more importantly, this interface is behind things, the realization of these system calls, we have in this area but this is also the main workload.
According to the "Undocumented Windows 2000 Secrets", a total of 248 conventional Win2k system calls (with the results of reverse engineering card). Some of these system calls is very simple, or almost directly corresponding alternative Linux system calls, and some are very complex. Obviously, we developed these systems from scratch call is not realistic (although ReactOS is doing), we should do is to make full use of the Linux kernel function in the low to achieve these Windows system calls. In a sense, Wine is outside the core Windows applications will be grafted on to the Linux system call, and we will have the compatibility of the core kernel inside Windows system calls will be grafted to the Linux kernel function on the many. Grafting is the core inside than outside the core grafting better, the kernel function on the one hand because of the "size" small core functions and system calls a bit like the relationship between language and high-level language compilation between relations. On the other hand because of the kernel space is unified, and can provide the overall vision. For example, the core process can be seen in all the process control block (PCB), and a kernel to user space, the process of separation between each other. Therefore, all require the operation of the overall vision, it should achieve in the core.
In addition to these conventional system calls, Win2k are 639 graphical interface (GUI) system call. This is tantamount to X11 moved to the core inside. In the past WinNT 4.0, Windows, like Linux, the graphical user space services on the process to achieve graphics and window operation, and management, as of course efficiency is relatively low. WinNT 4.0 from the beginning, so graphics operation and management moved to the Windows kernel inside, a module can be installed win32k.sys. This increased the speed of graphics operations meaningful, otherwise the game software can not be so smooth operation (of course, but there has been a DirectX, and further enhance the image / graphics operation speed, it is after). Therefore, strictly speaking, the so-called Windows system call interface graphics operations also include these calls. But achieving these calls "raw materials" is no longer a function of the Linux kernel, but the correlation function of X11. Of course, things are prioritized, and there is absolutely no need in the very beginning that more than 600 calls have a pot. In fact, even the 248 call the realization of conventional systems, nor is it necessary to step in place.
After this system call interface, customs, many system calls can be achieved, such as creating process, take time, etc. These systems, the Linux kernel inside integrity can be achieved. However, once involved input / output, device drivers involved, and there may be a problem. The problem lies not in the conventional device driver, such as the keyboard, mouse, hard disk, such as equipment used in the Linux kernel driver was alone, as long as the system call grafted on to the past. The problem is that some special equipment, in particular the new equipment. These equipment manufacturers often provide only for Windows device driver modules, namely. Sys files. If we can not turn the case. Sys modules into the Linux kernel and give them normal operation, the compatibility of Windows applications will not be complete.
Will be. Sys modules into the Linux kernel it is not difficult, because Linux installation module with the dynamic nature of the no different. It is difficult in the Linux kernel in normal operation. To achieve this goal, the first module to load up with the relevant system call interface down (likely) interrupt response mechanism engaged with the second module is to provide a specific operating environment. In fact,. Sys module reason can be put into normal operation of the Windows kernel and it is precisely because the Windows kernel to meet these two conditions. Obviously, the existing Linux kernel does not have such a condition that it meet the dynamic installation module is a Linux operating conditions, this system call interface with the two different is the same. Therefore, this has become compatible with the development of a core component of the important, but also represents a considerable workload.
Look at how the Windows kernel to meet these two conditions, we know what to do the.
The first is how to make. Sys module with the relevant system calls and interrupt response engaged, and I connected. In other words, what will be. Sys module into the core of the device driver framework, including specific modules on the framework of what position, and below and adjacent to the module or how interactive components. In the Windows kernel, which is the main I / O subsystem matter, the specific mainly reflected in two aspects: one is loaded after the first module to the I / O subsystem registration, or a device driver upward Registration, which is indirectly to the I / O subsystem registration. On the other hand, when the system calls when it is through I / O subsystem into for the specific device driver layer call and return. Therefore, I / O subsystem represents a device driver framework of the main. However, the I / O subsystem is not the device driver framework, and all. Sys module with the interrupt response might be engaged. For example, a. Sys module is a part of the interrupt service routine operation, and the other may have been in part as a bh function (in Windows called DPC) operation, and also is part of the I / O subsystem drivers. The Windows. Sys modules are targeted at the Windows device driver development of the framework, since we want these. Sys modules into the Linux kernel running on the Linux kernel must be constructed from such a framework. Specifically, it is necessary to achieve the Linux kernel in Windows I / O subsystem, the Windows interrupt response / service mechanism, as well as a number of complementary ingredients.
Windows device driver framework to address the right. Sys module load and use. If each module are closed, independent, and did not require the support of the environment, that would suffice. However, the fact is almost non-existent this closure, an independent device driver modules, the operation of almost every module needs the support of the inverted environment. For example, a device driver modules may be necessary in the operation of the distribution of the buffer zone. However, device driver module is not available and the ability, because it does not have any memory can be dynamically allocated resources. Therefore, the request had to be allocated core, which is dependent on the environment. To this end, the operating system kernel to "leads to (export)," a large number of core functions for dynamic module installed call. Set the size of this function, as well as each of the specific function to be called the conditions and parameters, role, and the return value, side effects, constitutes a specific kernel device driver support interface. Obviously, different cores have different device driver interface support, as if there are different different kernel system calls interface. Let the Windows. Sys module in the normal operation of the Linux kernel, it must be provided in the Linux kernel device driver support for Windows interface. System call interface with the different Windows device driver support interface definition is open to the public (otherwise it will be impossible for third parties to develop device driver modules), and defined in the DDK Win2k or WinXP, "Device Driver Development Kit." Win2k defined in the DDK 2000 to a support function, but is also commonly used by several hundred, or even less. Of course, Microsoft is only open this interface definition, but not its realization.
So, how to achieve these support function? Or the old methods, turns them into, or grafting to the appropriate Linux device driver support function forward.
It is worth mentioning that, Windows drivers for network equipment other definition of a framework, known as NDIS, and provides a specialized NDIS device driver interface support, NDIS device driver modules need only (and should only) call NDIS interface support functions. In this way, network equipment drive on their own systems, with a major in the framework of the small framework. However, regardless of the framework is still supporting NDIS interface are relatively small, only a Windows device driver framework and the client interface and expansion, and many NDIS support function in some Windows device driver is a simple function of packaging, so we will Windows NDIS device driver into the framework and interface.
In summary, we have developed compatible with Linux kernel, is mainly in the Linux kernel to achieve this in a framework and the two interfaces: Windows device driver framework, Windows system call interface, as well as support Windows device driver interface. This is compatible with Linux kernel development of the main. Of course, there are many piecemeal, supporting the development work to be done, but relatively small compared to the workload.
However, "a framework, the two interface" is the mainstay of development work, which is compatible with the core itself, rather than in terms of the whole operating system. Let Windows applications normal operations, the core also need some outside DLL, or dynamic link library support, as well as a number of supporting the process of support services. If only from a technical point of view, as long as it is compatible with the kernel on the line, because we are able to Windows DLL on the procedures and services from copy. But this is not only a technical problem, but a legal problem, we can not go to Microsoft's copyright infringement. Therefore, these DLL and services also need to develop procedures, Wine Fortunately, we have done a lot for this area of work, which is the need for the four DLL, the so-called "four parts" for some changes. Information Windows system calls to the detachment of the Linux system call is these four pieces: kernel32.dll, gdi32.dll, user32.dll, and ntdll.dll, but now it also true that they return to the distorted distort things back again.
Also see, the Windows technology and applications are developing their own, these developments more DLL and services reflected in the process, such as OLE, COM / DCOM,. NET, most of these technologies and services through DLL process to achieve. Although Wine has been done many such DLL and service procedures, but that the development may never be finished, but it is Xishuichangliu affairs.
.
Below the text of automatic translation from google.com:
Compatible with the Linux kernel development strategies and routes
Maode parade
The author since the introduction of Linux kernel compatible with the concept of the future, I heard a lot of repercussions. While supporters of Bufajiren, promote open-source software such as Chairman of the Alliance of landing the first group, Ni Guangnan academicians, and the OSDL is Mr. Hirano are supported. Needless to say, however, take exception to the views of this, there are many. Interestingly, these views are often dissociate into two extremes. An extreme, compatible with Linux kernel to achieve the target has been achieved, so simply do not have superfluous. That has been achieved and in the user space is because we have a Wine, and NdisWrapper it has been resolved to Windows device drivers into the Linux kernel problems. The other extreme, it is that much more difficult compatible kernel, it is unlikely to succeed, it is only a "dream." Clearly, in talking about the development of the road map that should be answered before the first of these two views. Fortunately, they constitute just answered each other.
First of all, as the author said in an article several others, Wine is only logical, functional basically solved the Linux kernel used to simulate / simulation of the Windows kernel, but the performance is not satisfactory, and said basically resolved actually very reluctantly. As NdisWrapper, it answered some network equipment (NIC) drivers, and not the sense of the device driver. Moreover NdisWrapper device driver can only be in the upper echelons of the Linux Socket, and not many documents and the operation of system calls engaged. In fact, one step back, and even if NdisWrapper respectively Wine really solve the Windows device driver and application software in the Linux kernel running on the cross-platform, and also need someone to integrate these two. Many companies are only some open-source software collection (rather than integration) Longlai have resulted in releases, not on a so-called "high-tech companies?" Therefore, if Windows applications and device drivers can run on Linux efficiently, thereby truly accepted by the overwhelming majority of users, the development should be compatible with the kernel that it is necessary, but not that easy.
As for too much difficulty, then Wine and NdisWrapper precisely the existence and development of compatible core technical feasibility of providing a reference. Indeed, in some respects Wine far from ideal, but it is precisely because the kernel and to avoid the consequences, and many in the user space is difficult to solve a problem that the core can be a much better inside. Or to the contrary, Wine in the user space can be basically solved the problems, the core inside the better resolved. Of course, the core of the design and programming of the user space than in difficulty (complexity) to be significantly higher, but "difficult" is a relative concept, difficult in the end-Who can say to what extent simply can not be done ? Say this is not the moon, not Goldbach's Conjecture. On the other hand, Wine provided by the many high-level DLL for the actual use of compatible kernel provided the conditions, or can be said to be resolved to worry about. If, after all, do not involve core Wine, also Bujuweiping, then NdisWrapper can do for us in the construction of the core device driver framework and provide the reference interface support, in essence, is also a possibility that.
Much of the difficulty that there is a concern that the Windows code is not open to the public, possession of the black box, several books alone will be how much information, how we can develop compatible with the Windows kernel? Of course, such worries have some justification, but ReactOS and, in this regard to provide us with a reference. ReactOS is starting from scratch to develop, Wine only outside the core issue of even able to a certain extent, to meet the design goal, and we stand on their shoulders, as raw materials are the Linux kernel, at least much better conditions than they .
Of course, the Wine, and NdisWrapper ReactOS as a reference means that we need to thoroughly understand, or at least basically understand their code. To that end I will continue to write in the article on this Web site launched from a parabolic quoted Yu role.
In short, the development of compatible kernel is not readily available, nor is it Nanxushangjingtian, can not be accomplished overnight, it is not foreseeable future. That the phrase is still an old saying: contempt difficult strategic and tactical importance difficulties.
After a follow-up, gradually moving towards the
We have developed compatible core can not be taken at one go, but should adopt a gradual approach strategy. A system call interface as an example, we can shelve the first GUI for those that win32k.sys the expansion of system calls, even for conventional system call 248 batches can be achieved. In fact, we even do not have the necessary pursuit of a complete realization. Project, there is a so-called 20/80 principle, that is 20% of the workload can often achieve 80% of the function, while the remaining 20% are often functional needs 80% of the workload can be achieved. If we can support the compatibility of core 80% of the Windows applications, and the remaining 20% have no further consideration be slowly. Furthermore, Windows itself is also developing today or "complete" the realization of tomorrow may not be complete at all. Therefore, we can take a certain distance behind in the follow-up strategy. As long as Windows exists, is still developing, this follow-up will never end. After a follow-up of this, gradually moving towards the strategic decision of our development will be a gradual spiral in the development process. That is to say: the relationship between the different components, the development of the spiral; from the same internal components, is the gradual development.
Well, this evolutionary spiral development process is the starting point for what? Starting point is Linux + Wine. Along with the development of, the Linux kernel becoming compatible core, the Linux + Let us said, and Wine is gradually evolving into a system call interface on Windows customization and optimization of the Wine, we tactfully called Wine '. Therefore, the entire development process is:
(Linux + Wine) =>… =>… => (Linux + + Wine ')
Starting point for Linux + Wine obviously can run, in the process of development every step to achieve a limited objective, the results of each step should be a run, more approximation of Windows can be released version.
On the Linux kernel in principle to amend the dynamic module in the form of installation, as far as possible not to change the original Linux kernel code and, where necessary, of course, can also play a patch.
Compatible with the main kernel is a development framework, the two interfaces. If the core of their ranking position from top to bottom, that is: system call interface, device driver framework, as well as support device driver interface. Below were to be discussed.
System call interface development
System call interface realize there is a "threshold", that is, core entry / exit mechanism, the system calls the space switching mechanisms, which is crossed this threshold there will be no system call interface. However, the realization of this mechanism is not complicated, because we have to realize is the nature of the Linux kernel system calls, thus this is actually a Linux system call switching mechanism of space, only different:
(1) the original Linux system calls through directives "int 0x80" into the kernel now need to add Windows system calls through instruction "int 0x2e" into the kernel.
(2) that there is a Linux system calls Jump table, this is a Linux system calls, for the next target function pointer array; now need to add a Windows system calls Jump Table, namely, the Windows system calls, for the next target function pointer array; later added to a GUI for the expansion of system calls Jump table.
Clearly, the realization of this threshold is not difficult.
With (system calls) kernel entry / exit mechanism, we can consider the system call interface itself, the kernel system calls that the combination of function. For Win2k, it is the "Windows NT/2000 Native API Reference" in reference referred to more than 200 functions. In the realization of these functions constitutes a Windows file system, I / O subsystem, process management subsystem, memory management subsystem, and so on.
On the workload here, but can be (and should be) to be realized in batches.
(1) 248 system calls, the number of Linux with a.
(2) system space entry / exit Linux can reuse the corresponding code.
(3) process / thread management. Integration of the two systems need to process / thread management mechanism.
(4) inter-process communication (including LPC). Basically, Linux can be grafted to the corresponding mechanism.
(5) storage management. The need to expand the Linux memory management interface.
(6) file system. Basically, can be grafted to the Linux file system.
(7) device driver. WDM device drivers connected to the framework.
Not only in batches, with a system that may need to call several minutes to complete. Some systems can be called a lot of options, some of which may actually rarely used options. Calling for such a system, we will be able to achieve its basic functions first, and then gradually improve.
How to achieve these system calls core function?
(1) Some system calls can be grafted to the appropriate Linux system call.
(2) system call can be some part of the Linux system call reuse corresponding code.
(3) Some system calls in Linux counterparts did not need to use the Linux kernel function in the lower be realized.
(4) Wine can learn from the code, to a certain extent, part of the Wine code into the kernel and be optimized.
Obviously, this system call interface, the file system should be grafted to the Linux file system and I / O subsystems are we are to achieve the Windows device driver framework, process management subsystem should be grafted to Linux process management, memory management subsystem should be grafted to Linux memory management, and so on.
Wine in the bottom of the four pieces, kernel32.dll, user32.dll, gdi32.dll and ntdll.dll, the original all the system calls all leading Linux system call. With the progress of development, each achieving a Windows system calls, it should be the level at Wine in the original system called "redirect" to the call of the Windows operating system. To this end, the DLL can be loaded / connect mechanism to be expanded in order to achieve the "virtual connection", that is, redirection function. For example, you can load / DLL linking lower when the need for the introduction of the DLL from the lower each have a function to check a map files to see whether they need to redirect this function to another DLL files in another function names. In this way, every Windows system calls for a future, as long as the modifications to the mapping files, and provide another group on the bottom of the DLL. Development in the end, the original Wine on the bottom for the new DLL (the same name) replaced by the DLL. At this time, it will become Wine Wine '.
As noted above, these systems function can be called in batches to achieve, foremost among which is the need to achieve the file system and device driver to the system call, in order to build on this basis Windows device driver framework.
Apart from the conventional system calls, there is a dedicated graphics interface (GUI) system call interface expansion, it is because Microsoft to the original space in the realization of the GUI user support (similar to X11) moved to the core, and to become a dynamic win32k.sys module installed. This expanded system call interface with the conventional interface with a combined entry / exit mechanism, the system calls only, all more than 1000. To this end, an additional need for a core function Jump table. As for the specific function of the realization of system calls, it is essentially the X11 core services in the transplant process, which we can be shelved for the time being, left to return to the future and realized.
Device Driver Development Framework
Basic device driver framework corresponds to Win2k kernel I / O management, as well as power management, such as plug-and-play mechanism, but also involves some object management, system configuration, and security management functions. One of the most important is the level of WDM device drivers mechanism can be achieved. The framework document with the above operating system calls (open (), close (), read () and write (), ioctl (), etc.) convergence, intermediate-based "IO request packet" IRP (IO Request Packet) Device Driver mechanism Below is the integration of the Linux kernel interrupt response / service mechanisms, including "soft interrupt" bh function is the enforcement mechanism. Mainly include:
(1) the dynamic device drivers loaded and connectivity.
(2) the generation and transmission of IRP, as well as the start-up device driver, synchronization, and end.
(3) the device driver interrupt service registration grafting to Linux interrupt mechanism, device driver will be the concern of the Windows kernel running mapped to the Linux kernel running on.
(4) the device driver DPC request to Linux bh graft function mechanism.
The basic framework for the realization of device drivers is basically a "yes" and "no", a form once this framework, which left a lot of the work is not. Therefore, the device driver framework for the realization of "threshold" is relatively high, the technical difficulty relatively larger. However, we have ReactOS code and NdisWrapper part of the code to be used as reference.
In addition, the network equipment (NIC), or NDIS device driver both its uniqueness, should be regarded as part of Windows device drivers, device driver framework should include the realization of the realization of NDIS. This is in the past but it does not Bigongfu, NdisWrapper code basically can be used directly.
Framework for the development of device drivers and system call interface development is not necessarily the sequence. System call interface in the operating system calls document has not yet been achieved, may wish to use the Linux system calls for special equipment or as / proc node drive, as the bridge has not yet made good before a temporary bridge-like. The basic framework in place after the device drivers, if only from a technical point of view, all. Sys files (Windows device driver module) can be loaded on the Linux kernel running. However, some. Sys module is its operating system from Microsoft bundled together with the issue, Microsoft has these. Sys files copyright, Linux users can not directly taken over with. This category. Sys module are basically the standards for some of the basic, common external equipment, generally can be divided into several categories (class), such as disk, USB, graphics, networking equipment and so on. They both call interface part of the public, and each has its own unique. Generally, Linux has actually have corresponding functions, but they need to Linux kernel (including device driver modules) in these functions and data structures and concrete. Sys call interface between building bridges. This part of the work in the form and system call interface and / or device driver interface realize there are similarities, but also like the system call interface can be realized as Wine + Linux from the beginning, for example, with core Wine and NTFS in the HPFS Linux is actually the realization of the paper disk drive adapter to the Windows disk file access. But there might be some Microsoft. Sys module can not be found in the Linux kernel counterparts, it needs the imitation. But this work is not necessary at the outset, but could be postponed to achieve a basic framework for device drivers, and partly to achieve a return after two interface from the gradual development.
Device Driver Interface Development Support
According to the Microsoft WinXP DDK, kernel device driver called for the function (as well as global variables) about 1,000 (more than Win2000). In this 1000 around the core function, some of the "IO manager" IoManager and "Object Manager" ObManager, which are device driver framework, while the rest belong to device driver interface.
(1) Some of resources call / mapping can be used (redirect) to the Linux kernel in the corresponding fixtures.
(2) some resources call / can be used for grafting (adapter) to the Linux kernel in the corresponding fixtures.
(3) Some of resources call / quote plus the need to achieve.
Support device driver interface there is also the realization of a minimum threshold. For example, a function of the buffer zone and the distribution of equivalent spinlock () function is necessary. We are fortunate that ReactOS and NdisWrapper has provided us with a set of basic support function, but ReactOS code is not built on the basis of the Linux kernel, and therefore require some adaptation and optimization work. In this basic set on the basis of a group to achieve more than each function compatible with the coverage of the core increased some.
From the functional point of view, the majority of device driver interface function (and the data structure) in the Linux kernel have counterparts in, for example, the allocation for the buffer zone as well as a function of spinlock () is, we need to do is to hand out the necessary The support function and data structure corresponding to the implementation of the Linux kernel function and data structure, there is a course, some adaptation work. Some also function in the Linux kernel is not close counterparts, it's important to the Linux kernel material to the various structures.
From the development of the timing, should support the development of the interface device driver framework in place in the future, or at least the two synchronous development. This is because, from the device driver framework, the existence of interface support will lose its significance, but also lost the test means.
Other development
In addition to a framework, the two interfaces, there are some ancillary development to be done, such as:
(1) Wine changes
(2) certain. Sys module imitation
(3) interaction with the registry
(4) in the Unicode strings and the use of the file name
(5) from the Windows style file path name to the Linux path of the mapping
(6) from the Windows style of the device name to the Linux path of the mapping
Also can cite many. These work together should not be underestimated, but from an overall perspective, from the difficulty and technical content, is not the main.
Development of the road map
Integrated all of the above, our road map will be developed largely as shown:
The first is the preparatory stage. At this stage I will continue to write in a number of articles, on the similarities and differences between Windows and Linux and make some introductory comparison, the Wine, NdisWrapper, ReactOS code for some introductory and analysis, to arouse the surfers participation and discussion, and more Welcome to our website on the subject of the research results and opinion. In this way, after a period of time, the people involved in R & D needs to be done should be able to glance at the chest. At the same time, the development of the team, whether full-time or amateur, there is a need for the formation and organization of the process, we also need the website for a period of time to gradually improve. Moreover, we have to develop a set of coding standards and code management practices (including the submission of the code, evaluation, recruitment, archiving, management, incentives and other aspects of the scheme), for specific prepare for the preparation of the code. Obviously such a preparation phase is necessary, it is estimated that this stage will continue until the first quarter of next year, and we hope that in principle to the Spring Festival for the sector.
After beginning the development of specific, the first thing to do is to bring about the system call interface entry / exit mechanism. This has been said before. Next is the device driver framework. The former is indivisible, or there is no problem. The latter slightly better, we can first Gaoge minimum basic framework, then slowly replenish. If the preparation phase, as the first phase of the whole project, then this is the second stage.
With these, the following will be the third phase of gradual development, so concrete plans in the system calls and device driver support function on the development of a cycle in vivo. As mentioned above, where each one cycle to realize the goal of a limited group, the results of each one should be a run, more approximation of Windows can be released version. This stage may never be finished, will continue to cycle, and the result is more and more approaching Windows. On the other hand, our core is compatible with Linux kernel, and Linux is also developing. Thus, while compatible with Linux kernel will be "things" to development, while more and more accurate, more extensive Windows-compatible application software.
Our development goal is to be completed within one year to enter the third stage and completed at least the first round cycle, namely, the basic realization of some of the most important system calls and device driver support function, some visible results. This year we will be able to have a prototype can be issued. In turn, this prototype is a further proved the feasibility of the entire project could be further developed and enhanced the public's confidence in the project. As for the more specific arrangements will need to be prepared to stage further refinement.
>>>(1)what is The Linux Unified Kernel short description what it does??
Win32 applications and ms windows drivers can run on Linux(kernel patched by Unified Kernel).
>>>(2)dose this project have a english webpage url
only Chinese webpage.
google.com' English webpage: http://translate.google.com/translate?u=http%3A%2F%2Flinux.insigma.com.cn%2Fjszl.asp%3Fdocid%3D122805676&langpair=zh%7Cen&hl=en&ie=UTF-8
>>>(3)how is this relevant to reactos
"Windows device driver framework for the realization of including I / O subsystem that the realization of the code of ReactOS are extremely important, and even some of the code can be used directly."
"NDIS for the realization of ReactOS can be NDISWrapper and the corresponding code for a comparison between, on the one hand choose the better one, on the other hand complement each other, learn from each other."
" the system call interface, ReactOS the corresponding code to be used as reference."
"The process management and resource management, reference and comparison ReactOS Wine and services related to the process of code in the Linux kernel then be achieved."
"The device driver interface (Environment), in accordance with the definition of DDK inspected by the realization of ReactOS (if it has been achieved), then look for the Linux kernel or its equivalents of approximate.Comparing then be referenced to determine how to achieve specific."
In general, if a feature is in the ReactOS achieve, and can be used in the Linux kernel to achieve certain resources, then we tend to use Linux resources. This is because the general Linux resources have been subjected to more tests.On the other hand, after all, is a compatible core Linux kernel, rather than the accumulation of two core together. Like the case of Wine, and the author will be another of the paper, essays and analysis of the relevant code ReacOS. "
http://www.reactos.org/forum/viewtopic.php?t=5240&postdays=0&postorder=asc&start=15
I hope the developers of Reactos help the UnifiedKernel to implemente the WDM device driver framework.
----------------------------------------
1.
reactos kernel + WINE's .dlls = Reactos OS => windows environment
UnifiedKernel + WINE's .dlls = UnifiedKernelOS => windows environment + linux
Note: Reactos and UnifiedKernelOS are operating systems . but WINE is a application.
---------------------------------------
2.
reactos kernel start from zero
UnifiedKernel start from linux+wine (using ReactOS code as reference)
----
"Starting point is Linux + Wine. Along with the development of, the Linux kernel becoming compatible core, the Linux + Let us said, and Wine is gradually evolving into a system call interface on Windows customization and optimization of the Wine, we tactfully called Wine '. Therefore, the entire development process is:
(Linux + Wine) =>… =>… => (Linux + + Wine ')
Starting point for Linux + Wine obviously can run, in the process of development every step to achieve a limited objective, the results of each step should be a run, more approximation of Windows can be released version. "
--------------------------------------------
3.
the Linux UnifiedKernel is a GPL project. Reactos can help the Linux UnifiedKernel.
but why you have not promoted this job to wine developers? wine-devel mailing list is a much more appropriate place to let peoples know about this project.
Ratings & Comments
10 Comments
The main problem is not whether kde-apps is or is not the place. It is of language and I do not mean C. I think I see what our Chinese friends are trying to accomplish but the Bable-fish translations are really not readable. If I knew that the kernel patches were compatible with the RT preempt, I might try that (one can always keep multiple kernels around in Linux). Patching wine is a bigger and more continuous bother and I doubt many will try that. This thing wants to replace wine with kernel level operability so either "in" or "out". As I said, get multimedia device compatibility at native speeds and this will be prize. Of course, now one must moderate the native-linux accesses and the Linux Unified Kernel accesses which may now be hitting the same hardware.
- who need this? - what actually Linux Unified Kernel can that Wine can not? - why on kde-apps.org?
A few questions? 1. What does this do more than what wine does now? 2. Safe to apply patch to -rt (Ingo's) patched kernel (rt preemptable)? 3. Wine, I suppose, will now use the kernel module. I do not understand patching EITHER wine or the kernel. (I think building wine from source takes longer than compiling the kernel.) It might do to have this incorporated into the wine project and if it be possible to leave the linux kernel alone and simply compile the module against the kernel source or headers, this might be better for most users.
Correction: One must patch BOTH. This is a big job and wine is updated very often. So I do not know if I will start with this. A working WDM would be very very tempting but might be a better idea might be a bridge to jack the wine-asio works (this works very well!).
. Below the text of automatic translation from google.com: "A framework, the two interfaces" Maode parade We develop Linux-compatible core objective is to enable Windows applications directly in the kernel can run on more precisely in order to the core as the core operating systems. At the same time, but also allow for the development of Windows and some of the equipment drive module can also run into the kernel. This is because for Windows device drivers are developed in terms of quantity and variety are far more than Linux on the other hand is because there are more and more applications need special equipment to drive module supporting operation, missing This device driver modules running up. Only at the same time to achieve the two goals can be said that Linux kernel compatible with the Windows kernel. So, in order to achieve these two objectives, we must make some of the Linux kernel revision and expansion of what? This paper is an analysis of this, and answer this question. First, the closed section of the procedure, if not call the process, nor for system calls, with the operating system is irrelevant, as long as the CPU of the machine with this procedure compile-time goal can be consistent with the CPU. This is because the PC-for example, this procedure generated by the compiler all the instructions are all x86 machine instructions, and all these directives can all normal operation of all of its instructions and subroutine calls Jump instructions are not the target this process beyond the borders. Secondly, even if the procedures need to call, as long as no direct or indirect system calls, also has nothing to do with the operating system, called the procedure because of the effect on the expansion of this procedure equivalent to the site to promote its borders. Therefore, as long as no direct or indirect system call, the application will follow the operation of the operating system irrelevant, thus can be run on any operating system. Generally, however, such a procedure is not as a separate application, the independent operation of the process, at least since the independence process has to input / output, which can not be separated from the system call. So how application software system calls? As we all know, this is achieved through the trap instructions, is in the x86 processor instructions int. In fact, the use of the Linux kernel, "int 0x80" Achieving system calls, and use of the Windows kernel, "int 0x2e." First of all, this makes Windows applications can run on the Linux kernel. Just think, an attempt to Windows applications through "int 0x2e" system call, and the Linux kernel that this is illegal trap instructions. So, first of all, the Linux kernel must accept the "int 0x2e" as a means of system calls. We really thank the two of the core designers, if they originally chose the 0 x80, or choose to have a 0 x2e, which we are now harder to resolve. Fortunately, this conflict is not among them. Since all system calls through a trap with instructions to enter kernel parameters on the need to adopt the "call" to distinguish between the specific requirements of the operation and function. So, what instructions in the system call, we must also consider the use of the total number of calls, each call, what response operation and functions, what needs some parameters, what the outcome, how to return to, what are the side effects, etc. . All of these factors together, constitute a system call interface. Of course, Windows and the Linux system call interface different. To bring Windows software to run directly on the Linux kernel, it must allow the Linux kernel also provides a Windows system call interface, it just seemed as the Wine Windows software "grafting" of the Linux system call. "Grafted", the Wine has done a very good job, but we know that effect or not ideal. Our system call interface for Windows, of course, say that the performance of Windows applications is the core of the outside see specific system calls call methodologies, parameters, effects, the results of the return, as well as side effects. But on the other hand, more importantly, this interface is behind things, the realization of these system calls, we have in this area but this is also the main workload. According to the "Undocumented Windows 2000 Secrets", a total of 248 conventional Win2k system calls (with the results of reverse engineering card). Some of these system calls is very simple, or almost directly corresponding alternative Linux system calls, and some are very complex. Obviously, we developed these systems from scratch call is not realistic (although ReactOS is doing), we should do is to make full use of the Linux kernel function in the low to achieve these Windows system calls. In a sense, Wine is outside the core Windows applications will be grafted on to the Linux system call, and we will have the compatibility of the core kernel inside Windows system calls will be grafted to the Linux kernel function on the many. Grafting is the core inside than outside the core grafting better, the kernel function on the one hand because of the "size" small core functions and system calls a bit like the relationship between language and high-level language compilation between relations. On the other hand because of the kernel space is unified, and can provide the overall vision. For example, the core process can be seen in all the process control block (PCB), and a kernel to user space, the process of separation between each other. Therefore, all require the operation of the overall vision, it should achieve in the core. In addition to these conventional system calls, Win2k are 639 graphical interface (GUI) system call. This is tantamount to X11 moved to the core inside. In the past WinNT 4.0, Windows, like Linux, the graphical user space services on the process to achieve graphics and window operation, and management, as of course efficiency is relatively low. WinNT 4.0 from the beginning, so graphics operation and management moved to the Windows kernel inside, a module can be installed win32k.sys. This increased the speed of graphics operations meaningful, otherwise the game software can not be so smooth operation (of course, but there has been a DirectX, and further enhance the image / graphics operation speed, it is after). Therefore, strictly speaking, the so-called Windows system call interface graphics operations also include these calls. But achieving these calls "raw materials" is no longer a function of the Linux kernel, but the correlation function of X11. Of course, things are prioritized, and there is absolutely no need in the very beginning that more than 600 calls have a pot. In fact, even the 248 call the realization of conventional systems, nor is it necessary to step in place. After this system call interface, customs, many system calls can be achieved, such as creating process, take time, etc. These systems, the Linux kernel inside integrity can be achieved. However, once involved input / output, device drivers involved, and there may be a problem. The problem lies not in the conventional device driver, such as the keyboard, mouse, hard disk, such as equipment used in the Linux kernel driver was alone, as long as the system call grafted on to the past. The problem is that some special equipment, in particular the new equipment. These equipment manufacturers often provide only for Windows device driver modules, namely. Sys files. If we can not turn the case. Sys modules into the Linux kernel and give them normal operation, the compatibility of Windows applications will not be complete. Will be. Sys modules into the Linux kernel it is not difficult, because Linux installation module with the dynamic nature of the no different. It is difficult in the Linux kernel in normal operation. To achieve this goal, the first module to load up with the relevant system call interface down (likely) interrupt response mechanism engaged with the second module is to provide a specific operating environment. In fact,. Sys module reason can be put into normal operation of the Windows kernel and it is precisely because the Windows kernel to meet these two conditions. Obviously, the existing Linux kernel does not have such a condition that it meet the dynamic installation module is a Linux operating conditions, this system call interface with the two different is the same. Therefore, this has become compatible with the development of a core component of the important, but also represents a considerable workload. Look at how the Windows kernel to meet these two conditions, we know what to do the. The first is how to make. Sys module with the relevant system calls and interrupt response engaged, and I connected. In other words, what will be. Sys module into the core of the device driver framework, including specific modules on the framework of what position, and below and adjacent to the module or how interactive components. In the Windows kernel, which is the main I / O subsystem matter, the specific mainly reflected in two aspects: one is loaded after the first module to the I / O subsystem registration, or a device driver upward Registration, which is indirectly to the I / O subsystem registration. On the other hand, when the system calls when it is through I / O subsystem into for the specific device driver layer call and return. Therefore, I / O subsystem represents a device driver framework of the main. However, the I / O subsystem is not the device driver framework, and all. Sys module with the interrupt response might be engaged. For example, a. Sys module is a part of the interrupt service routine operation, and the other may have been in part as a bh function (in Windows called DPC) operation, and also is part of the I / O subsystem drivers. The Windows. Sys modules are targeted at the Windows device driver development of the framework, since we want these. Sys modules into the Linux kernel running on the Linux kernel must be constructed from such a framework. Specifically, it is necessary to achieve the Linux kernel in Windows I / O subsystem, the Windows interrupt response / service mechanism, as well as a number of complementary ingredients. Windows device driver framework to address the right. Sys module load and use. If each module are closed, independent, and did not require the support of the environment, that would suffice. However, the fact is almost non-existent this closure, an independent device driver modules, the operation of almost every module needs the support of the inverted environment. For example, a device driver modules may be necessary in the operation of the distribution of the buffer zone. However, device driver module is not available and the ability, because it does not have any memory can be dynamically allocated resources. Therefore, the request had to be allocated core, which is dependent on the environment. To this end, the operating system kernel to "leads to (export)," a large number of core functions for dynamic module installed call. Set the size of this function, as well as each of the specific function to be called the conditions and parameters, role, and the return value, side effects, constitutes a specific kernel device driver support interface. Obviously, different cores have different device driver interface support, as if there are different different kernel system calls interface. Let the Windows. Sys module in the normal operation of the Linux kernel, it must be provided in the Linux kernel device driver support for Windows interface. System call interface with the different Windows device driver support interface definition is open to the public (otherwise it will be impossible for third parties to develop device driver modules), and defined in the DDK Win2k or WinXP, "Device Driver Development Kit." Win2k defined in the DDK 2000 to a support function, but is also commonly used by several hundred, or even less. Of course, Microsoft is only open this interface definition, but not its realization. So, how to achieve these support function? Or the old methods, turns them into, or grafting to the appropriate Linux device driver support function forward. It is worth mentioning that, Windows drivers for network equipment other definition of a framework, known as NDIS, and provides a specialized NDIS device driver interface support, NDIS device driver modules need only (and should only) call NDIS interface support functions. In this way, network equipment drive on their own systems, with a major in the framework of the small framework. However, regardless of the framework is still supporting NDIS interface are relatively small, only a Windows device driver framework and the client interface and expansion, and many NDIS support function in some Windows device driver is a simple function of packaging, so we will Windows NDIS device driver into the framework and interface. In summary, we have developed compatible with Linux kernel, is mainly in the Linux kernel to achieve this in a framework and the two interfaces: Windows device driver framework, Windows system call interface, as well as support Windows device driver interface. This is compatible with Linux kernel development of the main. Of course, there are many piecemeal, supporting the development work to be done, but relatively small compared to the workload. However, "a framework, the two interface" is the mainstay of development work, which is compatible with the core itself, rather than in terms of the whole operating system. Let Windows applications normal operations, the core also need some outside DLL, or dynamic link library support, as well as a number of supporting the process of support services. If only from a technical point of view, as long as it is compatible with the kernel on the line, because we are able to Windows DLL on the procedures and services from copy. But this is not only a technical problem, but a legal problem, we can not go to Microsoft's copyright infringement. Therefore, these DLL and services also need to develop procedures, Wine Fortunately, we have done a lot for this area of work, which is the need for the four DLL, the so-called "four parts" for some changes. Information Windows system calls to the detachment of the Linux system call is these four pieces: kernel32.dll, gdi32.dll, user32.dll, and ntdll.dll, but now it also true that they return to the distorted distort things back again. Also see, the Windows technology and applications are developing their own, these developments more DLL and services reflected in the process, such as OLE, COM / DCOM,. NET, most of these technologies and services through DLL process to achieve. Although Wine has been done many such DLL and service procedures, but that the development may never be finished, but it is Xishuichangliu affairs.
. Below the text of automatic translation from google.com: Compatible with the Linux kernel development strategies and routes Maode parade The author since the introduction of Linux kernel compatible with the concept of the future, I heard a lot of repercussions. While supporters of Bufajiren, promote open-source software such as Chairman of the Alliance of landing the first group, Ni Guangnan academicians, and the OSDL is Mr. Hirano are supported. Needless to say, however, take exception to the views of this, there are many. Interestingly, these views are often dissociate into two extremes. An extreme, compatible with Linux kernel to achieve the target has been achieved, so simply do not have superfluous. That has been achieved and in the user space is because we have a Wine, and NdisWrapper it has been resolved to Windows device drivers into the Linux kernel problems. The other extreme, it is that much more difficult compatible kernel, it is unlikely to succeed, it is only a "dream." Clearly, in talking about the development of the road map that should be answered before the first of these two views. Fortunately, they constitute just answered each other. First of all, as the author said in an article several others, Wine is only logical, functional basically solved the Linux kernel used to simulate / simulation of the Windows kernel, but the performance is not satisfactory, and said basically resolved actually very reluctantly. As NdisWrapper, it answered some network equipment (NIC) drivers, and not the sense of the device driver. Moreover NdisWrapper device driver can only be in the upper echelons of the Linux Socket, and not many documents and the operation of system calls engaged. In fact, one step back, and even if NdisWrapper respectively Wine really solve the Windows device driver and application software in the Linux kernel running on the cross-platform, and also need someone to integrate these two. Many companies are only some open-source software collection (rather than integration) Longlai have resulted in releases, not on a so-called "high-tech companies?" Therefore, if Windows applications and device drivers can run on Linux efficiently, thereby truly accepted by the overwhelming majority of users, the development should be compatible with the kernel that it is necessary, but not that easy. As for too much difficulty, then Wine and NdisWrapper precisely the existence and development of compatible core technical feasibility of providing a reference. Indeed, in some respects Wine far from ideal, but it is precisely because the kernel and to avoid the consequences, and many in the user space is difficult to solve a problem that the core can be a much better inside. Or to the contrary, Wine in the user space can be basically solved the problems, the core inside the better resolved. Of course, the core of the design and programming of the user space than in difficulty (complexity) to be significantly higher, but "difficult" is a relative concept, difficult in the end-Who can say to what extent simply can not be done ? Say this is not the moon, not Goldbach's Conjecture. On the other hand, Wine provided by the many high-level DLL for the actual use of compatible kernel provided the conditions, or can be said to be resolved to worry about. If, after all, do not involve core Wine, also Bujuweiping, then NdisWrapper can do for us in the construction of the core device driver framework and provide the reference interface support, in essence, is also a possibility that. Much of the difficulty that there is a concern that the Windows code is not open to the public, possession of the black box, several books alone will be how much information, how we can develop compatible with the Windows kernel? Of course, such worries have some justification, but ReactOS and, in this regard to provide us with a reference. ReactOS is starting from scratch to develop, Wine only outside the core issue of even able to a certain extent, to meet the design goal, and we stand on their shoulders, as raw materials are the Linux kernel, at least much better conditions than they . Of course, the Wine, and NdisWrapper ReactOS as a reference means that we need to thoroughly understand, or at least basically understand their code. To that end I will continue to write in the article on this Web site launched from a parabolic quoted Yu role. In short, the development of compatible kernel is not readily available, nor is it Nanxushangjingtian, can not be accomplished overnight, it is not foreseeable future. That the phrase is still an old saying: contempt difficult strategic and tactical importance difficulties. After a follow-up, gradually moving towards the We have developed compatible core can not be taken at one go, but should adopt a gradual approach strategy. A system call interface as an example, we can shelve the first GUI for those that win32k.sys the expansion of system calls, even for conventional system call 248 batches can be achieved. In fact, we even do not have the necessary pursuit of a complete realization. Project, there is a so-called 20/80 principle, that is 20% of the workload can often achieve 80% of the function, while the remaining 20% are often functional needs 80% of the workload can be achieved. If we can support the compatibility of core 80% of the Windows applications, and the remaining 20% have no further consideration be slowly. Furthermore, Windows itself is also developing today or "complete" the realization of tomorrow may not be complete at all. Therefore, we can take a certain distance behind in the follow-up strategy. As long as Windows exists, is still developing, this follow-up will never end. After a follow-up of this, gradually moving towards the strategic decision of our development will be a gradual spiral in the development process. That is to say: the relationship between the different components, the development of the spiral; from the same internal components, is the gradual development. Well, this evolutionary spiral development process is the starting point for what? Starting point is Linux + Wine. Along with the development of, the Linux kernel becoming compatible core, the Linux + Let us said, and Wine is gradually evolving into a system call interface on Windows customization and optimization of the Wine, we tactfully called Wine '. Therefore, the entire development process is: (Linux + Wine) =>… =>… => (Linux + + Wine ') Starting point for Linux + Wine obviously can run, in the process of development every step to achieve a limited objective, the results of each step should be a run, more approximation of Windows can be released version. On the Linux kernel in principle to amend the dynamic module in the form of installation, as far as possible not to change the original Linux kernel code and, where necessary, of course, can also play a patch. Compatible with the main kernel is a development framework, the two interfaces. If the core of their ranking position from top to bottom, that is: system call interface, device driver framework, as well as support device driver interface. Below were to be discussed. System call interface development System call interface realize there is a "threshold", that is, core entry / exit mechanism, the system calls the space switching mechanisms, which is crossed this threshold there will be no system call interface. However, the realization of this mechanism is not complicated, because we have to realize is the nature of the Linux kernel system calls, thus this is actually a Linux system call switching mechanism of space, only different: (1) the original Linux system calls through directives "int 0x80" into the kernel now need to add Windows system calls through instruction "int 0x2e" into the kernel. (2) that there is a Linux system calls Jump table, this is a Linux system calls, for the next target function pointer array; now need to add a Windows system calls Jump Table, namely, the Windows system calls, for the next target function pointer array; later added to a GUI for the expansion of system calls Jump table. Clearly, the realization of this threshold is not difficult. With (system calls) kernel entry / exit mechanism, we can consider the system call interface itself, the kernel system calls that the combination of function. For Win2k, it is the "Windows NT/2000 Native API Reference" in reference referred to more than 200 functions. In the realization of these functions constitutes a Windows file system, I / O subsystem, process management subsystem, memory management subsystem, and so on. On the workload here, but can be (and should be) to be realized in batches. (1) 248 system calls, the number of Linux with a. (2) system space entry / exit Linux can reuse the corresponding code. (3) process / thread management. Integration of the two systems need to process / thread management mechanism. (4) inter-process communication (including LPC). Basically, Linux can be grafted to the corresponding mechanism. (5) storage management. The need to expand the Linux memory management interface. (6) file system. Basically, can be grafted to the Linux file system. (7) device driver. WDM device drivers connected to the framework. Not only in batches, with a system that may need to call several minutes to complete. Some systems can be called a lot of options, some of which may actually rarely used options. Calling for such a system, we will be able to achieve its basic functions first, and then gradually improve. How to achieve these system calls core function? (1) Some system calls can be grafted to the appropriate Linux system call. (2) system call can be some part of the Linux system call reuse corresponding code. (3) Some system calls in Linux counterparts did not need to use the Linux kernel function in the lower be realized. (4) Wine can learn from the code, to a certain extent, part of the Wine code into the kernel and be optimized. Obviously, this system call interface, the file system should be grafted to the Linux file system and I / O subsystems are we are to achieve the Windows device driver framework, process management subsystem should be grafted to Linux process management, memory management subsystem should be grafted to Linux memory management, and so on. Wine in the bottom of the four pieces, kernel32.dll, user32.dll, gdi32.dll and ntdll.dll, the original all the system calls all leading Linux system call. With the progress of development, each achieving a Windows system calls, it should be the level at Wine in the original system called "redirect" to the call of the Windows operating system. To this end, the DLL can be loaded / connect mechanism to be expanded in order to achieve the "virtual connection", that is, redirection function. For example, you can load / DLL linking lower when the need for the introduction of the DLL from the lower each have a function to check a map files to see whether they need to redirect this function to another DLL files in another function names. In this way, every Windows system calls for a future, as long as the modifications to the mapping files, and provide another group on the bottom of the DLL. Development in the end, the original Wine on the bottom for the new DLL (the same name) replaced by the DLL. At this time, it will become Wine Wine '. As noted above, these systems function can be called in batches to achieve, foremost among which is the need to achieve the file system and device driver to the system call, in order to build on this basis Windows device driver framework. Apart from the conventional system calls, there is a dedicated graphics interface (GUI) system call interface expansion, it is because Microsoft to the original space in the realization of the GUI user support (similar to X11) moved to the core, and to become a dynamic win32k.sys module installed. This expanded system call interface with the conventional interface with a combined entry / exit mechanism, the system calls only, all more than 1000. To this end, an additional need for a core function Jump table. As for the specific function of the realization of system calls, it is essentially the X11 core services in the transplant process, which we can be shelved for the time being, left to return to the future and realized. Device Driver Development Framework Basic device driver framework corresponds to Win2k kernel I / O management, as well as power management, such as plug-and-play mechanism, but also involves some object management, system configuration, and security management functions. One of the most important is the level of WDM device drivers mechanism can be achieved. The framework document with the above operating system calls (open (), close (), read () and write (), ioctl (), etc.) convergence, intermediate-based "IO request packet" IRP (IO Request Packet) Device Driver mechanism Below is the integration of the Linux kernel interrupt response / service mechanisms, including "soft interrupt" bh function is the enforcement mechanism. Mainly include: (1) the dynamic device drivers loaded and connectivity. (2) the generation and transmission of IRP, as well as the start-up device driver, synchronization, and end. (3) the device driver interrupt service registration grafting to Linux interrupt mechanism, device driver will be the concern of the Windows kernel running mapped to the Linux kernel running on. (4) the device driver DPC request to Linux bh graft function mechanism. The basic framework for the realization of device drivers is basically a "yes" and "no", a form once this framework, which left a lot of the work is not. Therefore, the device driver framework for the realization of "threshold" is relatively high, the technical difficulty relatively larger. However, we have ReactOS code and NdisWrapper part of the code to be used as reference. In addition, the network equipment (NIC), or NDIS device driver both its uniqueness, should be regarded as part of Windows device drivers, device driver framework should include the realization of the realization of NDIS. This is in the past but it does not Bigongfu, NdisWrapper code basically can be used directly. Framework for the development of device drivers and system call interface development is not necessarily the sequence. System call interface in the operating system calls document has not yet been achieved, may wish to use the Linux system calls for special equipment or as / proc node drive, as the bridge has not yet made good before a temporary bridge-like. The basic framework in place after the device drivers, if only from a technical point of view, all. Sys files (Windows device driver module) can be loaded on the Linux kernel running. However, some. Sys module is its operating system from Microsoft bundled together with the issue, Microsoft has these. Sys files copyright, Linux users can not directly taken over with. This category. Sys module are basically the standards for some of the basic, common external equipment, generally can be divided into several categories (class), such as disk, USB, graphics, networking equipment and so on. They both call interface part of the public, and each has its own unique. Generally, Linux has actually have corresponding functions, but they need to Linux kernel (including device driver modules) in these functions and data structures and concrete. Sys call interface between building bridges. This part of the work in the form and system call interface and / or device driver interface realize there are similarities, but also like the system call interface can be realized as Wine + Linux from the beginning, for example, with core Wine and NTFS in the HPFS Linux is actually the realization of the paper disk drive adapter to the Windows disk file access. But there might be some Microsoft. Sys module can not be found in the Linux kernel counterparts, it needs the imitation. But this work is not necessary at the outset, but could be postponed to achieve a basic framework for device drivers, and partly to achieve a return after two interface from the gradual development. Device Driver Interface Development Support According to the Microsoft WinXP DDK, kernel device driver called for the function (as well as global variables) about 1,000 (more than Win2000). In this 1000 around the core function, some of the "IO manager" IoManager and "Object Manager" ObManager, which are device driver framework, while the rest belong to device driver interface. (1) Some of resources call / mapping can be used (redirect) to the Linux kernel in the corresponding fixtures. (2) some resources call / can be used for grafting (adapter) to the Linux kernel in the corresponding fixtures. (3) Some of resources call / quote plus the need to achieve. Support device driver interface there is also the realization of a minimum threshold. For example, a function of the buffer zone and the distribution of equivalent spinlock () function is necessary. We are fortunate that ReactOS and NdisWrapper has provided us with a set of basic support function, but ReactOS code is not built on the basis of the Linux kernel, and therefore require some adaptation and optimization work. In this basic set on the basis of a group to achieve more than each function compatible with the coverage of the core increased some. From the functional point of view, the majority of device driver interface function (and the data structure) in the Linux kernel have counterparts in, for example, the allocation for the buffer zone as well as a function of spinlock () is, we need to do is to hand out the necessary The support function and data structure corresponding to the implementation of the Linux kernel function and data structure, there is a course, some adaptation work. Some also function in the Linux kernel is not close counterparts, it's important to the Linux kernel material to the various structures. From the development of the timing, should support the development of the interface device driver framework in place in the future, or at least the two synchronous development. This is because, from the device driver framework, the existence of interface support will lose its significance, but also lost the test means. Other development In addition to a framework, the two interfaces, there are some ancillary development to be done, such as: (1) Wine changes (2) certain. Sys module imitation (3) interaction with the registry (4) in the Unicode strings and the use of the file name (5) from the Windows style file path name to the Linux path of the mapping (6) from the Windows style of the device name to the Linux path of the mapping Also can cite many. These work together should not be underestimated, but from an overall perspective, from the difficulty and technical content, is not the main. Development of the road map Integrated all of the above, our road map will be developed largely as shown: The first is the preparatory stage. At this stage I will continue to write in a number of articles, on the similarities and differences between Windows and Linux and make some introductory comparison, the Wine, NdisWrapper, ReactOS code for some introductory and analysis, to arouse the surfers participation and discussion, and more Welcome to our website on the subject of the research results and opinion. In this way, after a period of time, the people involved in R & D needs to be done should be able to glance at the chest. At the same time, the development of the team, whether full-time or amateur, there is a need for the formation and organization of the process, we also need the website for a period of time to gradually improve. Moreover, we have to develop a set of coding standards and code management practices (including the submission of the code, evaluation, recruitment, archiving, management, incentives and other aspects of the scheme), for specific prepare for the preparation of the code. Obviously such a preparation phase is necessary, it is estimated that this stage will continue until the first quarter of next year, and we hope that in principle to the Spring Festival for the sector. After beginning the development of specific, the first thing to do is to bring about the system call interface entry / exit mechanism. This has been said before. Next is the device driver framework. The former is indivisible, or there is no problem. The latter slightly better, we can first Gaoge minimum basic framework, then slowly replenish. If the preparation phase, as the first phase of the whole project, then this is the second stage. With these, the following will be the third phase of gradual development, so concrete plans in the system calls and device driver support function on the development of a cycle in vivo. As mentioned above, where each one cycle to realize the goal of a limited group, the results of each one should be a run, more approximation of Windows can be released version. This stage may never be finished, will continue to cycle, and the result is more and more approaching Windows. On the other hand, our core is compatible with Linux kernel, and Linux is also developing. Thus, while compatible with Linux kernel will be "things" to development, while more and more accurate, more extensive Windows-compatible application software. Our development goal is to be completed within one year to enter the third stage and completed at least the first round cycle, namely, the basic realization of some of the most important system calls and device driver support function, some visible results. This year we will be able to have a prototype can be issued. In turn, this prototype is a further proved the feasibility of the entire project could be further developed and enhanced the public's confidence in the project. As for the more specific arrangements will need to be prepared to stage further refinement.
more: http://translate.google.com/translate?u=http%3A%2F%2Flinux.insigma.com.cn%2Fjszl.asp%3Fdocid%3D122805676&langpair=zh%7Cen&hl=en&ie=UTF-8
>>>(1)what is The Linux Unified Kernel short description what it does?? Win32 applications and ms windows drivers can run on Linux(kernel patched by Unified Kernel). >>>(2)dose this project have a english webpage url only Chinese webpage. google.com' English webpage: http://translate.google.com/translate?u=http%3A%2F%2Flinux.insigma.com.cn%2Fjszl.asp%3Fdocid%3D122805676&langpair=zh%7Cen&hl=en&ie=UTF-8 >>>(3)how is this relevant to reactos "Windows device driver framework for the realization of including I / O subsystem that the realization of the code of ReactOS are extremely important, and even some of the code can be used directly." "NDIS for the realization of ReactOS can be NDISWrapper and the corresponding code for a comparison between, on the one hand choose the better one, on the other hand complement each other, learn from each other." " the system call interface, ReactOS the corresponding code to be used as reference." "The process management and resource management, reference and comparison ReactOS Wine and services related to the process of code in the Linux kernel then be achieved." "The device driver interface (Environment), in accordance with the definition of DDK inspected by the realization of ReactOS (if it has been achieved), then look for the Linux kernel or its equivalents of approximate.Comparing then be referenced to determine how to achieve specific." In general, if a feature is in the ReactOS achieve, and can be used in the Linux kernel to achieve certain resources, then we tend to use Linux resources. This is because the general Linux resources have been subjected to more tests.On the other hand, after all, is a compatible core Linux kernel, rather than the accumulation of two core together. Like the case of Wine, and the author will be another of the paper, essays and analysis of the relevant code ReacOS. "
http://www.reactos.org/forum/viewtopic.php?t=5240&postdays=0&postorder=asc&start=15 I hope the developers of Reactos help the UnifiedKernel to implemente the WDM device driver framework. ---------------------------------------- 1. reactos kernel + WINE's .dlls = Reactos OS => windows environment UnifiedKernel + WINE's .dlls = UnifiedKernelOS => windows environment + linux Note: Reactos and UnifiedKernelOS are operating systems . but WINE is a application. --------------------------------------- 2. reactos kernel start from zero UnifiedKernel start from linux+wine (using ReactOS code as reference) ---- "Starting point is Linux + Wine. Along with the development of, the Linux kernel becoming compatible core, the Linux + Let us said, and Wine is gradually evolving into a system call interface on Windows customization and optimization of the Wine, we tactfully called Wine '. Therefore, the entire development process is: (Linux + Wine) =>… =>… => (Linux + + Wine ') Starting point for Linux + Wine obviously can run, in the process of development every step to achieve a limited objective, the results of each step should be a run, more approximation of Windows can be released version. " -------------------------------------------- 3. the Linux UnifiedKernel is a GPL project. Reactos can help the Linux UnifiedKernel.
but why you have not promoted this job to wine developers? wine-devel mailing list is a much more appropriate place to let peoples know about this project.