Re: How about this replacement of WINE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

.






[Index of Archives]     [Gimp for Windows]     [Red Hat]     [Samba]     [Yosemite Camping]     [Graphics Cards]     [Wine Home]

  Powered by Linux