>>>>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.
.