[Wine] Re: How about this replacement of WINE.

[bussuser]

jeffz wrote:
> unified kernel is probably considered off-topic here and you should also read this:
> 
> http://wiki.winehq.org/FAQ#head-8b4fbbe473bd0d51d936bcf298f5b7f0e8d25f2e


unified kernel is considered off-topic here? I don't think so. i consider that unified kernel is another WINE. it uses a lot of codes of WINE and  provide more  functions.

  
bellow text is form the unifiedkernel webpage

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

Once we have such a compatible core, from the principle that as long as the Windows DLL (dynamic link library) and the process of software services to move in your computer, you can directly run all of Windows applications software. But of course, we can not do so, because it involved Microsoft's intellectual property rights (of course,we can use the DLL provided by third parties ). So, after a compatible core, Wine is still needed, only then does not need the Windows system calls Translation / converted into a Linux system calls, which will be an optimized Wine. Such a Wine, which is actually a Windows "system DLL" (as well as the service process and some tools) of the open source version.

In this way, compatible core's  Windows system call-interface, coupled with the optimized Wine, this combination of the two in the user space,create an operating environment for the Windows application software. And the device driver interface( definited by core DDK Export Function interface) and the device driver framework, create another operating environment for the Windows device drivers.

Thus, Windows applications to "see" is a Windows environment, whether in space of user or space of systems are the same.because this environment is built by the "assembly language"(it is built wiht the micro "kernel function brick", not macro Linux API ) , the performance of the windows applications should be similar that provided by Windows itself. This means that future Windows software in general can be run on compatible core, and run-time performance and the effect can be similar to run on Windows. So, the users switch to Linux operating system is very realistic things. "