Wine 3.0 Still Expected Around EOY With D3D11; Wayland & D3D12 On Roadmap

[oiaohm]

What's really funny is when people like you insist they know what they're saying is right, when the real fact is they are wrong. Wine -does- emulate windows behavior, it must because they -cannot- rely on the behavior of native linux libraries. They have no option but to emulate the windows libraries behavior using native libraries that they cannot rely on!

Please try to understand what -emulate- means. Here it is in all of its glory.

https://www.merriam-webster.com/dictionary/emulate

It clearly says "to strive to equal" In this case equal compatibility. They aren't emulating at a low level, they are doing it at the highest level conceivably possible just like retarded morons. If they had bothered to impliment windows API's natively and then simply wrapped them, like their namesake implies, then it -could- rely on the behavior of the natively implemented windows libraries. Then it wouldn't emulate anything, it would truly be a wrapper environment.

https://en.wikipedia.org/wiki/Emulator

https://en.wikipedia.org/wiki/Compatibility_layer

In fact there is a clear difference between Emulator and Compatibility layer. Behaviour is the right word to lead you to the problem. How many test in the wine test suite check timing being how long X feature takes to run under windows the answer is absolutely zero. Wine does not emulate the performance shape of Windows.

So its not true to say that wine does emulate windows behaviour because if a function is faster or slower in wine that is fine because Wine is a compatibility layer if wine was a emulator that would be a bug. That performance difference only comes a bug if it effects a program under wine so far wine has never had a windows program complain that it doing a feature too fast. Yes some things under wine are many times faster than windows. Now in an emulator you have to attempt to match the timings. Compatibility layers are allowed to-do almost everything emulator does but does not have to do everything big thing is not having to care how fast or how slow stuff is unless it effects a program using the compatibility layer adversely.

Reality here is implementing Windows API naively on Linux then wrapping around them is insanely not that workable. Winelib attempts that. Wine has a pe.elf format that contains windows PE information and is in a Linux ELF binary. Windows API uses different memory structures to generic Linux and worse Windows applications at times expect to be able to jump straight to particular addresses and read particular address they never got allocations for. All this stuff make people jump to the wrong idea that wine is a emulator completely missing the timing side that must be done to be a emulator.

So duby229 as normal you are another person claiming wine is a emulator who has his terms wrong. Did not read what an emulator has to-do correctly and failed to understand where the difference is between compatibility layer and emulator.

Wine is not emulator/emulation that is wine first name is a directive to developers to remember wine only has to obey the rules of being a compatibility layer.

Basically you have two ways run non-native stuff emulate or compatibility this becomes Emulator and compatibility layer. It is very important to understand the difference particularly in hardware development where timings could be critical because the compatibility version may have wrong timings by a large margin. Using a compatibility layer when you need a emulator can cause you big trouble because is compatibility not emulation.

[oiaohm]

Which is gonna give windows huge unfair advantage! It'll be able to reliably run linux apps, and because of wine, linux still won't be able to reliably run windows apps. That situation sucks ass and is no way a good thing at all!

WSL under windows has most of the same problems wine does. Yes you can run some graphical applications under WSL but you start running into the memory difference nightmares. Both are compatibility layers and it unlikely that both will ever run everything because both sides be it windows or linux is a moving target.

[bobwya]

So any word on Gallium Nine and D3D to Vulkan?

Gallium Nine was not even mentioned. It a project developed outside of the Wine ecosystem after all.

A D3D12 to Linux native Vulkan library is being actively worked on... Look out for the talk by Henri online (at some point). A future Wine d3d12.dll will hook into this translation layer library.

[dragon321]

What's really funny is when people like you insist they know what they're saying is right, when the real fact is they are wrong. Wine -does- emulate windows behavior, it must because they -cannot- rely on the behavior of native linux libraries. They have no option but to emulate the windows libraries behavior using native libraries that they cannot rely on!

Please try to understand what -emulate- means. Here it is in all of its glory.

https://www.merriam-webster.com/dictionary/emulate

It clearly says "to strive to equal" In this case equal compatibility. They aren't emulating at a low level, they are doing it at the highest level conceivably possible just like retarded morons. If they had bothered to impliment windows API's natively and then simply wrapped them, like their namesake implies, then it -could- rely on the behavior of the natively implemented windows libraries. Then it wouldn't emulate anything, it would truly be a wrapper environment.

"What's really funny is when people like you insist they know what they're saying is right, when the real fact is they are wrong" This is description to You, not me. Wine doesn't emulating Windows. Wine translating Windows calls to native POSIX and X11/OpenGL calls. This isn't emulation.

And You should read this:
https://wiki.winehq.org/FAQ#Is_Wine_...e_disagreement

And You really thing moving Wine to kernel mode would improve compatibility? Not, it won't. And with this Wine will lose main advantage - portability. The reason of Wine poor comatibility is lack of documentation and Windows source code, not Wine userland nature. Moving Wine to kernel mode won't improve this - this won't make documentation and source code magically will appear. And making Linux/BSD working like Windows in kernel mode You will get another Windows - thats what ReactOS trying to do. Check ReactOS compatibility - it implements Windows API in kernel. Today ReactOS compatibility is worse than Wine. This is proof about nonsense of Your talking. Wine target is running usermode Windows binaries - so kernel mode implementation is useless, because usermode translation will give same effect. Read this FAQ and stop calling Wine emulator, because it isn't emulator. And stop calling developers 'morons', because they know more than You.

[oiaohm]

https://wiki.winehq.org/Wine_User%27s_Guide#What_is_Wine.2C_and_how_can_it_help_me.3F

Dragon321 there is newer document. I was the first author of the Wine FAQ entry. Its not as clear as it could have been and when I wrote that I did not 100 percent understand the finer differences between emulator and compatibility layer. There are in fact differences and once you learn them its without question what wine is as it fails to meet all the requirements to be an emulator and it does meet all the requirements to be called a compatibility layer.

Reactos uses quite a few of the wine projects parts but there are many parts of wine that Reactos cannot use. because the implementation is so far different it not funny. Some reactos developers who are attempting to implement as per Windows design same some area of wine look totally insane they work on Linux, OS X, BSD but the code is nothing acceptable to a Windows kernel.

https://en.wikipedia.org/wiki/Longene

Moving wine to kernel mode has been tried. Longene had more support than Reactos but the more Longene made kernel space closer to windows the worse the performance came. You really don't want to be emulating stuff in kernel space you want minimal in kernel as you can.

Something people like duby229 forget is that if a idea sound simple its likely someone else has already tried it first. Emulating the lowest levels has been tried. There is a nightmare.

http://widefox.pbworks.com/w/page/8042318/Process

This is getting a little old. But it still true. It faster to start a process under Linux than it is under windows api. This is not the only thing Linux kernel and OS X kernel is faster at doing with their native APIs than Windows so the sooner you can get to platform native API the better.

So it makes no sense to copy Windows internals for wine unless some application in fact needs it because all you are doing is adding slower paths than what Linux or OS X or BSD has.

[Zan Lynx]

If they had bothered to impliment windows API's natively and then simply wrapped them, like their namesake implies, then it -could- rely on the behavior of the natively implemented windows libraries. Then it wouldn't emulate anything, it would truly be a wrapper environment.

Not even Windows relies on the Windows kernel APIs. Absolutely everything goes through their DLLs. Microsoft doesn't guarantee a stable kernel ABI. Programs are guaranteed a stable DLL ABI and that's it.

So creating Linux equivalents of the NT kernel system calls would be a huge failure.

And that's not even counting the fact that copying the Windows DLLs into a Linux system would be a copyright violation. Sure you could use them if you already owned a copy of Windows. What would be the point of Wine then, if you already had to own Windows to use it?

[duby229]

https://wiki.winehq.org/Wine_User%27..._it_help_me.3F

Dragon321 there is newer document. I was the first author of the Wine FAQ entry. Its not as clear as it could have been and when I wrote that I did not 100 percent understand the finer differences between emulator and compatibility layer. There are in fact differences and once you learn them its without question what wine is as it fails to meet all the requirements to be an emulator and it does meet all the requirements to be called a compatibility layer.

Reactos uses quite a few of the wine projects parts but there are many parts of wine that Reactos cannot use. because the implementation is so far different it not funny. Some reactos developers who are attempting to implement as per Windows design same some area of wine look totally insane they work on Linux, OS X, BSD but the code is nothing acceptable to a Windows kernel.

https://en.wikipedia.org/wiki/Longene

Moving wine to kernel mode has been tried. Longene had more support than Reactos but the more Longene made kernel space closer to windows the worse the performance came. You really don't want to be emulating stuff in kernel space you want minimal in kernel as you can.

Something people like duby229 forget is that if a idea sound simple its likely someone else has already tried it first. Emulating the lowest levels has been tried. There is a nightmare.

http://widefox.pbworks.com/w/page/8042318/Process

This is getting a little old. But it still true. It faster to start a process under Linux than it is under windows api. This is not the only thing Linux kernel and OS X kernel is faster at doing with their native APIs than Windows so the sooner you can get to platform native API the better.

So it makes no sense to copy Windows internals for wine unless some application in fact needs it because all you are doing is adding slower paths than what Linux or OS X or BSD has.

Wow, the leaps of logic you just made are astounding at the most fundamental levels. Just wow!So as a programmer you must have some idea what runtime behavior means right? It certainly is much more than just latency and timing. Passing data between one API's format and another API's format at the highest possible level while duplicating the runtime behavior of the first is not trivial. It's damn sure is not just a passthrough.

You might want to look at the specific definition of emulate. It's much less specific than you claim it to mean.

[duby229]

Not even Windows relies on the Windows kernel APIs. Absolutely everything goes through their DLLs. Microsoft doesn't guarantee a stable kernel ABI. Programs are guaranteed a stable DLL ABI and that's it.

So creating Linux equivalents of the NT kernel system calls would be a huge failure.

And that's not even counting the fact that copying the Windows DLLs into a Linux system would be a copyright violation. Sure you could use them if you already owned a copy of Windows. What would be the point of Wine then, if you already had to own Windows to use it?

I never said anything like that at all. you should re-read what I wrote.

[duby229]

https://en.wikipedia.org/wiki/Emulator

https://en.wikipedia.org/wiki/Compatibility_layer

In fact there is a clear difference between Emulator and Compatibility layer. Behaviour is the right word to lead you to the problem. How many test in the wine test suite check timing being how long X feature takes to run under windows the answer is absolutely zero. Wine does not emulate the performance shape of Windows.

So its not true to say that wine does emulate windows behaviour because if a function is faster or slower in wine that is fine because Wine is a compatibility layer if wine was a emulator that would be a bug. That performance difference only comes a bug if it effects a program under wine so far wine has never had a windows program complain that it doing a feature too fast. Yes some things under wine are many times faster than windows. Now in an emulator you have to attempt to match the timings. Compatibility layers are allowed to-do almost everything emulator does but does not have to do everything big thing is not having to care how fast or how slow stuff is unless it effects a program using the compatibility layer adversely.

Reality here is implementing Windows API naively on Linux then wrapping around them is insanely not that workable. Winelib attempts that. Wine has a pe.elf format that contains windows PE information and is in a Linux ELF binary. Windows API uses different memory structures to generic Linux and worse Windows applications at times expect to be able to jump straight to particular addresses and read particular address they never got allocations for. All this stuff make people jump to the wrong idea that wine is a emulator completely missing the timing side that must be done to be a emulator.

So duby229 as normal you are another person claiming wine is a emulator who has his terms wrong. Did not read what an emulator has to-do correctly and failed to understand where the difference is between compatibility layer and emulator.

Wine is not emulator/emulation that is wine first name is a directive to developers to remember wine only has to obey the rules of being a compatibility layer.

Basically you have two ways run non-native stuff emulate or compatibility this becomes Emulator and compatibility layer. It is very important to understand the difference particularly in hardware development where timings could be critical because the compatibility version may have wrong timings by a large margin. Using a compatibility layer when you need a emulator can cause you big trouble because is compatibility not emulation.

You just described in exquisite detail, "Square peg, meet Round hole.".

[Khrundel]

Hmm... https://bugs.winehq.org/show_bug.cgi?id=42284
Does this mean new wine on wayland will work in virtual desktop only?