From what I see on their descriptions (site is in Chinese!), this is NOT a
replacement of WINE. They place certain system services in the kernel and
have compile kernel-module (.ko) to service them. The kernel patches are very
small so this is not "bloat" as someone has stated. My main question is how
such patches effect OTHER common patches, especially real-time pre-emption.
If this be safe, I have no objection to trying it.
The "unified kernel" project patches WINE to use its kernel module, otherwise,
UTILIZES WINE for its API layer. Since WINE is changed quite often,
continually patching and (re-) compiling is a lot of effort and maybe not
really worth it.
I could only see this thing growing if the main WINE trunk incorporated its
patches. The code would/should look more like:
if (unified-kernel-module modprobed in)
use-patched version
else
use-original version.
The patches should do this (maybe they actually do!) rather than simply
replace WINE code.
Then, those wishing to try kernel services could readily compile and use them
and those wishing to stay with vintage WINE could do so as well.
How about this replacement of WINE
>>>>From what I see on their descriptions (site is in Chinese!), this is NOT a replacement of WINE. They place certain system services in the kernel and have compile kernel-module (.ko) to service them.
---- here is their plan:
So, wine still could not solved the problem well. Out of such a concern, I suggested the idea and route of "Linux Compatible Kernel". Its objective is: extend Linux kernel and make it support both Linux's own application and device driver, and also Windows' application and device driver, becoming a "compatible kernel". To implement such a kernel, one need to add several parts on to Linux kernel:
- A framework that matches the properties and requirements of Windows device driver, i.e. Windows device driver framework, so that multiple Windows device driver modules may be loaded into kernel, while retaining their relationship and running conditions as in Windows.
- A set of export function defined by Windows kernel export function interface (see Windows DDK). To device driver program, these functions are like library functions provided by kernel.
- Windows native API. Microsoft did not open their native API, but "Windows NT/2000 Native API Reference" and other materials have unveiled this secret. Implement Windows system API in Linux kernel, are like implementing another high level language in assembly. This is because, inside the kernel, usable "brick" are not macro Linux API anymore but many micro Linux kernel functions.
>>>>The kernel patches are very small so this is not "bloat" as someone has stated.
---- yes, kernel patches are very small. it is only 175KB.
>>>>The "unified kernel" project patches WINE to use its kernel module, otherwise, UTILIZES WINE for its API layer. Since WINE is changed quite often, continually patching and (re-) compiling is a lot of effort and maybe not really worth it. I could only see this thing growing if the main WINE trunk incorporated its patches. The code would/should look more like:
if (unified-kernel-module modprobed in)
use-patched version
else
use-original version.
The patches should do this (maybe they actually do!) rather than simply
replace WINE code.
--- right. The patches actually do this:
"Starting point is Linux + Wine. Along with the development, 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-able version , more approximation of Windows can be released version. "
>>>>Then, those wishing to try kernel services could readily compile and use them and those wishing to stay with vintage WINE could do so as well.
---- the new version will be released in next month.
.
---- here is their plan:
So, wine still could not solved the problem well. Out of such a concern, I suggested the idea and route of "Linux Compatible Kernel". Its objective is: extend Linux kernel and make it support both Linux's own application and device driver, and also Windows' application and device driver, becoming a "compatible kernel". To implement such a kernel, one need to add several parts on to Linux kernel:
- A framework that matches the properties and requirements of Windows device driver, i.e. Windows device driver framework, so that multiple Windows device driver modules may be loaded into kernel, while retaining their relationship and running conditions as in Windows.
- A set of export function defined by Windows kernel export function interface (see Windows DDK). To device driver program, these functions are like library functions provided by kernel.
- Windows native API. Microsoft did not open their native API, but "Windows NT/2000 Native API Reference" and other materials have unveiled this secret. Implement Windows system API in Linux kernel, are like implementing another high level language in assembly. This is because, inside the kernel, usable "brick" are not macro Linux API anymore but many micro Linux kernel functions.
>>>>The kernel patches are very small so this is not "bloat" as someone has stated.
---- yes, kernel patches are very small. it is only 175KB.
>>>>The "unified kernel" project patches WINE to use its kernel module, otherwise, UTILIZES WINE for its API layer. Since WINE is changed quite often, continually patching and (re-) compiling is a lot of effort and maybe not really worth it. I could only see this thing growing if the main WINE trunk incorporated its patches. The code would/should look more like:
if (unified-kernel-module modprobed in)
use-patched version
else
use-original version.
The patches should do this (maybe they actually do!) rather than simply
replace WINE code.
--- right. The patches actually do this:
"Starting point is Linux + Wine. Along with the development, 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-able version , more approximation of Windows can be released version. "
>>>>Then, those wishing to try kernel services could readily compile and use them and those wishing to stay with vintage WINE could do so as well.
---- the new version will be released in next month.
.
Magiclinux is the first distribution that unifiedkernel embedded in. the last version of Magiclinux is 2.1-rc3 and the version of
unifiedkernel is 0.2.2-rc .
you can get it here:
http://apt.magiclinux.org/iso/MagicLinu ... .uni-1.iso
md5sum:
2f099f02d7b7b982ffc161a9f363d7c3 MagicLinux-2.1.rc3.uni-1.iso
----------------
unified kernel and reactos are the replacements of ms windows. but their technology are very different. reactos start from zero and the authores write all of the codes to implement the windows environment, that are very hard works. and unified kernel start from linux, it use linux stuff and use ReactOS codes as reference to build windows environment. unified kernel have implemented the Process/Thread management,Object management,Virtual memory management,hronization etc. but some functiones have not achieved yet. so unified use wine to offer those functiones. the route of unified kernel is:
( Linux + Wine ) =>… =>… => ( Linux' + Wine' )
The "unified kernel" project develop the linux kernel modules that offer windows kernel functiones and patches WINE to use its module.
if (the functiones have implemented in unified-kernel-module)
use unified-kernel functiones
else
use wine functiones (winesever have moved into kernel space)
endif
in the end, wine only offer the dll files. but the kernel32.dll、gdi32.dll、user32.dll and ntdll.dll are different from wine's. if you have mswindows copyright, you can replace all of the dll files with the dll files of mswindows, include kernel32.dll、gdi32.dll、user32.dll and ntdll.dll.
unifiedkernel is 0.2.2-rc .
you can get it here:
http://apt.magiclinux.org/iso/MagicLinu ... .uni-1.iso
md5sum:
2f099f02d7b7b982ffc161a9f363d7c3 MagicLinux-2.1.rc3.uni-1.iso
----------------
unified kernel and reactos are the replacements of ms windows. but their technology are very different. reactos start from zero and the authores write all of the codes to implement the windows environment, that are very hard works. and unified kernel start from linux, it use linux stuff and use ReactOS codes as reference to build windows environment. unified kernel have implemented the Process/Thread management,Object management,Virtual memory management,hronization etc. but some functiones have not achieved yet. so unified use wine to offer those functiones. the route of unified kernel is:
( Linux + Wine ) =>… =>… => ( Linux' + Wine' )
The "unified kernel" project develop the linux kernel modules that offer windows kernel functiones and patches WINE to use its module.
if (the functiones have implemented in unified-kernel-module)
use unified-kernel functiones
else
use wine functiones (winesever have moved into kernel space)
endif
in the end, wine only offer the dll files. but the kernel32.dll、gdi32.dll、user32.dll and ntdll.dll are different from wine's. if you have mswindows copyright, you can replace all of the dll files with the dll files of mswindows, include kernel32.dll、gdi32.dll、user32.dll and ntdll.dll.
