Description: Linux Unified Kernel 0.2.2-1 was released
On December 17 2008, the Linux Unified Kernel project released the version 0.2.2-1 of LUK.
The previous release (0.2.2) of the Linux Unified Kernel fixed a large amount of bugs in the implemented mechanisms, but there are still many key problems left, such as process running with ungrouped threads. Therefore, this version (0.2.2-1) has resolved some key problems.
What's new in this release: - Fixed bugs in process/thread management - Fixed bugs in virtual memory management - Fixed bugs in synchronization - Fixed bugs in Window management in Wine built-in dlls
Linux Unified Kernel (LUK) is a computer operating system kernel intended to be binary-compatible with application software and device drivers made for Microsoft Windows and Linux.
The LUK project aims to add all Windows kernel mechanisms into the Linux kernel, including process management, thread management, Object management, virtual memory management, synchronization, system calls (syscall), the application registry, WDM device driver framework, Windows DPC mechanism, etc., to form a new kernel. Thus, the new kernel allows both Linux and Windows applications and device drivers to work directly without virtualization or emulation.
But LUK is not simply an accumulation of the two kernels. In order to prevent LUK from becoming bloated, if a function has been completed in the ReactOS kernel, and it can also be achieved using the Linux kernel (ReactOS/Wine/NDISwrapper code as a reference if they have implemented the function), then LUK prefers to use the latter.
LUK has two sets of syscalls and their corresponding syscall tables: a Windows syscall set and a Linux syscall set. Windows applications call the syscall table via software interrupt "int 0x2e" to make a system call. Linux applications call syscall table via "int 0x80".
The LUK project does not develop the Windows and the Linux userland libraries. Those libraries are offered by the Wine (or Windows/ReactOS) project and the Linux project.
LUK is primarily written in the C programming language, and is licensed under the terms of the GNU General Public License. Although the project is in the alpha development stage as of 2008, many Windows programs already work well.
The version 0.2.2-1 of LUK source is available from the following locations:
Is it wise to fork the Linux Operating System (the monolith kernel is the operating system) so that you can run Windows drivers and Applications on it?
Why not help to develope the Wine or Mono?
LUK uses the codes of wine codes, but its technique is different from the one of wine. Just like KVM, it uses a lot of XEN's codes, but the technique of kvm is very different from XEN.
The relationship between the LUK and WINE:
* ReactOS
LUK uses ReactOS code as a reference to implement some basic mechanisms of the Microsoft Windows Operating System. That involves implementing the Windows device driver framework, NDIS, the system call interface, the process management and resource management, the device driver interface (Environment), etc.
* Wine
First, the LUK project benefits from Wine's progress in implementing the Win32 API. Most of Wine's DLLs can be used directly by LUK. Second, LUK use Wine code as a reference to implement some functions, such as Windows Registry functions for its Windows Registry table. Third, the LUK project develops the kernel modules to implement Windows functions for Process/Thread management, Object management, Virtual memory management, synchronization etc. But some functions have not been completed yet, so the LUK uses Wine to offer those functions. The route of unified kernel is:
The LUK project develops the linux kernel modules that offer windows kernel functions and patches WINE to use its module.
IF (the functions have implemented in LUK-module)
Use LUK functions
ELSE
Use wine functions (winesever have moved into kernel space)
ENDIF
* Kernel-win32
Kernel-Win32 is a project intended to move some stuff of Wineserver into Linux kernel to accelerate Wine. LUK project ported (and sometimes re-implementing) kernel-win32 into LUK to implement the Windows system call mechanism.
You will learn more about LUK on wiki:
http://en.wikipedia.org/wiki/Linux_Unified_Kernel
Putting the capabilities that make sense directly into the kernel will improve Linux support for compatible binaries, and it will speed up emulation (since at this point, it won't really BE emulation anymore...).
Ratings & Comments
3 Comments
Is it wise to fork the Linux Operating System (the monolith kernel is the operating system) so that you can run Windows drivers and Applications on it? Why not help to develope the Wine or Mono?
LUK uses the codes of wine codes, but its technique is different from the one of wine. Just like KVM, it uses a lot of XEN's codes, but the technique of kvm is very different from XEN. The relationship between the LUK and WINE: * ReactOS LUK uses ReactOS code as a reference to implement some basic mechanisms of the Microsoft Windows Operating System. That involves implementing the Windows device driver framework, NDIS, the system call interface, the process management and resource management, the device driver interface (Environment), etc. * Wine First, the LUK project benefits from Wine's progress in implementing the Win32 API. Most of Wine's DLLs can be used directly by LUK. Second, LUK use Wine code as a reference to implement some functions, such as Windows Registry functions for its Windows Registry table. Third, the LUK project develops the kernel modules to implement Windows functions for Process/Thread management, Object management, Virtual memory management, synchronization etc. But some functions have not been completed yet, so the LUK uses Wine to offer those functions. The route of unified kernel is: The LUK project develops the linux kernel modules that offer windows kernel functions and patches WINE to use its module. IF (the functions have implemented in LUK-module) Use LUK functions ELSE Use wine functions (winesever have moved into kernel space) ENDIF * Kernel-win32 Kernel-Win32 is a project intended to move some stuff of Wineserver into Linux kernel to accelerate Wine. LUK project ported (and sometimes re-implementing) kernel-win32 into LUK to implement the Windows system call mechanism. You will learn more about LUK on wiki: http://en.wikipedia.org/wiki/Linux_Unified_Kernel
Putting the capabilities that make sense directly into the kernel will improve Linux support for compatible binaries, and it will speed up emulation (since at this point, it won't really BE emulation anymore...).