To Wine core developers:
As a regular user of Wine for various windows programs like Microsoft Office, QQ, etc., I have some basic understanding of the structure of the Wine program.
So far, the developers of Wine are trying to rewrite every component in Windows, such as *.dll, *.exe in system32, syswow64, etc., the two major problems with this approach are 1) this process cost a lot of time because it is extremely tedious and heavy-work-load for doing this, simply because Windows is complex, there are just too many components for you to rewrite; 2) Windows components change with time from Windows updates, causing further complications; 3) many Windows components have unknown bugs/ambiguities, many Win32/64 programs rely on those bugs, thus, removing those bugs might cause certain programs, which assume the bug exist, to malfunction.
I am wondering whether it is possible for us to hook the Window API at at kernel level, that is ntoskrnl.exe, kernel32.dll, etc., so that for whatever dll and exe which Windows will load, just keep their original native version. I call this new framework WineX.
For WineX, starting the wineserver will be equivalent to booting Windows, after that, you can run all windows programs without explorer.exe . Running a Windows program will require loading a tree of various user-level dlls, all of them ultimately goes into the kernel-level dlls. So all we need to hook is how to remap the kernel screen buffer, redirecting/simulating/faking kernel-level memory operations and IO operations at Windows kernel level so that they don't conflict with the Linux kernel. Essentially, we simulate the entire Windows kernel using Linux user level (or kernel level in advance). In this way, we no longer need to rewrite those numerous windows user-level components because they will be exactly the same as in Windows. It will also become more convenient because windows kernel-level components seldom get updated during windows update. It will also eliminate many compatibility issues because everything will be exactly the same as if in windows.
The new task is also very challenging, in the way that developers need to have good understanding of the windows kernel: how does windows kernel handle file IO, memory, device driver, etc., and how Windows user-level API interact with kernel-level API. However, I believe most developers are only familiar with Windows user-level components such as MSVC runtime, .NET framework, Direct X dlls, etc.. I feel that if we just keeps the current way, it will take almost forever for Wine to be able to run (without bug) more complicated Windows programs like Visual Studio, newest version D3D games like X-Rebirth, etc.
