The 2010s Were Very Successful For Wine Thanks To CodeWeavers + Valve's Steam Play

[duby229]

Nowadays, a better way to start a flamewar on Phoronix is to state your feelings about Outreachy, and treat those feelings like fact.

Go ahead and be prejudiced. This don't have nothing to do with how you feel about outreachy. This was about an asinine comment saying Wine was successful because of Codeweavers... Fact is Wine regresses stupidly bad every single release -because- of Codeweavers....

[Weasel]

I think -ALL- open source devs deserve to get paid for their work, so in that sense, thank you Codeweavers.... But no thanks at all to their completely asinine development philosophy. Wine -IS- an emulator and Codeweavers -NEEDS- to finally accept that fact so they can start working around bugs. Instead we have the situation where fixing one bug in an API implementation regresses almost everything else that uses that API. Every single time. Way past time to accept that they need to emulate windows behavior in addition to implementing windows API's. Wine -NEEDS- to be an emulator. It -IS- an emulator.

I don't think you understand what an emulator, in this context, would mean. If Wine were an emulator, you could use every single Windows DLL and have it just work.

But that's not the case, since it just re-implements the Windows API itself, and where necessary, links it to the Unix system. Some Windows DLLs can be copied over and have them work, though, but there's no emulation there, they just don't rely on low level Windows stuff.

[oiaohm]

probably the title should be "thanks to dxvk/d9vk" without these projects steamplay would still be as bad as wine. and without steamplay maybe a lot of issues will still be present in wine.

There are still people buying games on steam who don't have a vulkan supporting graphics card. So like it or not wine dx to opengl still has a market even in steam play.

oiaohm what do you mean by "As the pool of games grows so does the numbers that will not run with current windows as well." The pool of games that are too old for windows 10? or the new (as in the last 10 years maybe) and future games? cause if you talk about the later i doubt there is any (windows) game that it will not work on windows 10.

https://www.neowin.net/news/latest-windows-10-update-is-apparently-also-breaking-audio-in-games/

I am not talking about just too old for windows 10 by windows 10 first release date. Windows 10 updates ruining the means to run particular games. Newish games in the last 10 years most of them still work because they have got updates around different Windows issues. Some of the less popular games in the last 2 years are already non functional on Windows 10 with all updates even avoiding the direct game breaking updates yes they were released with Windows 10 support and they don't run now.

https://www.theverge.com/2019/10/9/20903139/indie-game-developers-creators-money-funding

This was a good write up from your smaller developers. Fairly much write low popularity games they need them to sell for decades just to break even let alone make any profit. This is over 80% of all games are in this camp. Yes this non existing budget means they cannot be investing in updating all the time. There will be future games done in by the Windows treadmill.

https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet

Lot of people heard Windows 10 will be the last version of windows and were like great. Problem is when you read this lifecycle fact sheet you see something truly horrible.

Notice something "Windows 10, version 1909" What the hell right. Why on the life cycle sheet of Microsoft is there now a version number. Now look at those dates.
We have gone from 5-10 years per version release of support on desktop solutions with Windows 8.1 and before. Down to 1.5-2.5 years of support with Windows 10 on the general desktop. So the work required to keep you game functional has gone up massively. Income for less popular games has not so more on the pool are falling into no longer works with Windows.

Dosbox has been a god send to allow selling some really old games that had not covered their cost of development yet. Valve is investing in wine and other stuff like it for steamplay because they are seeing how many games are in fact coming non functional before they have paid back cost of development let alone made any profit to attempt to extend how long these games can be on sale for. Being able to sell to the small Linux market is better than no market.

loganj is more games now are breaking now than there use to be. The faster cycles of windows is taking it toll. I guess this is not the picture you were expecting.

[oiaohm]

I think -ALL- open source devs deserve to get paid for their work, so in that sense, thank you Codeweavers.... But no thanks at all to their completely asinine development philosophy. Wine -IS- an emulator and Codeweavers -NEEDS- to finally accept that fact so they can start working around bugs.

No matter how much you argue this point wine is technically a compatibility layer and always will be. https://en.wikipedia.org/wiki/Compatibility_layer.
Wine old name Wine Is Not and Emulator. This was pure intentional.

Instead we have the situation where fixing one bug in an API implementation regresses almost everything else that uses that API. Every single time.

This is not a unique problem to Compatibility layers different console Emulators have suffered from exactly the same problem. This is part of developing compatibility with applications at times you break things.

Way past time to accept that they need to emulate windows behavior in addition to implementing windows API's.

Its a requirement of a compatibility layer to attempt to match the application requirements of compatibility in behaviour. . The big difference between emulator and compatibility layer is a compatibility layer can go screw timings.

https://en.wikipedia.org/wiki/Shim_(computing)
This is a interesting point. Why are you asking for a emulator duby229. Old applications running on windows are using a compatibility layer.

https://techcommunity.microsoft.com/t5/Ask-The-Performance-Team/Demystifying-Shims-or-Using-the-App-Compat-Toolkit-to-make-your/ba-p/374947

This stuff shims. These shims don't care about having exact timing or exact internal structure matches on Windows either and only care about the applications requirements of compatibility in behaviour. If Windows does not bother emulation for windows compatibility why should wine?

Reality old applications running on Windows are using a compatibility layer. Wine only need to be a compatibility layer spending time developing emulation most of the time would be waste of development resources.

Reality Wine is following how Windows does it.

[loganj]

oiaohm windows 10 is known to break drivers plus other things with every major updates. they will be fixed eventually. you can say the same about linux kernel too. after all i have lots of trouble with wifi and video (nvidia) card with every new version.
so in my opinion both are equal
about dxvk/d9vk and your argument about opengl games: how old are those video cards to not support vulkan? seems that amd/nvidia/intel vulkan support is quite good. of course it might be a different situation with the newer versions of vulkan. but then again if thats the case then your chances for the game to work at a comfortable fps (at least 30fps) even on windows might be zero cause the hardware is too old.
on the other hand if dxvk/d9vk were not present i doubt steamplay would be so popular. look how long it took wine devs to create vkd3d. im curious if they even consider dx12 to vulkan before dxvk was created.

i know that wine is not only about games and that wine has to do more than just dx to gl/vk. but when you consider steam and proton than vk is a very important part.

i know there is also gallium 9 for amd/intel only (probably nvidia if nouveau will get the necessary parts for 900+ gpus) that works great with opengl. i can't find a good benchmark gallium 9 vs d9vk right now but i think gallium 9 is working better. i don't know if proton support it directly or you have to patch it. gallium nine works only for dx9?

[duby229]

I don't think you understand what an emulator, in this context, would mean. If Wine were an emulator, you could use every single Windows DLL and have it just work.

But that's not the case, since it just re-implements the Windows API itself, and where necessary, links it to the Unix system. Some Windows DLLs can be copied over and have them work, though, but there's no emulation there, they just don't rely on low level Windows stuff.

Sorry for the long lost reply, I must've missed this post, just now seen it.

Bolded by me, and that's exactly the problem. When they fix a bug they are experiencing in one app, they modify their implementation of that API without any consideration at all for how that "fix" is going to break everything else that uses that API. A windows API only exposes an interface, they are entirely proprietary and there is no way to see what those libraries are doing internally. I absolutely guarantee you this "one behavior to rule them all" philosophy Wine adopted is -NOT- how windows does it. They need to emulate windows behavior and they don't.

Wine regressions are completely ridiculous because of this.

EDIT: To strive to equal or imitate. They implement the API interfaces, but they don't even try at all to imitate their behaviors (note the plural), but they -need- to....

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

[Weasel]

Sorry for the long lost reply, I must've missed this post, just now seen it.

Bolded by me, and that's exactly the problem. When they fix a bug they are experiencing in one app, they modify their implementation of that API without any consideration at all for how that "fix" is going to break everything else that uses that API. A windows API only exposes an interface, they are entirely proprietary and there is no way to see what those libraries are doing internally. I absolutely guarantee you this "one behavior to rule them all" philosophy Wine adopted is -NOT- how windows does it. They need to emulate windows behavior and they don't.

Wine regressions are completely ridiculous because of this.

EDIT: To strive to equal or imitate. They implement the API interfaces, but they don't even try at all to imitate their behaviors (note the plural), but they -need- to....

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

Right, I see your point now. Basically, you want Wine to implement the shims and hacks that Windows does for specific apps. I agree, actually. But it's still not an emulator though, that's why I was confused.

With Wine they generally write generic tests and if they pass on Windows (i.e. they're the correct behavior or implementation of a function, in general) then it's what gets implemented in Wine. But Windows sometimes has specific behavior and quirks for specific apps (see the AppCompat directory, too) or shims/hacks. Those won't show up on the generic Wine tests, and I doubt they'd want to upstream them anyway...

Yeah it sucks.

Note that the shims/hacks are only needed because the applications are broken and misuse the Windows API.

[duby229]

Right, I see your point now. Basically, you want Wine to implement the shims and hacks that Windows does for specific apps. I agree, actually. But it's still not an emulator though, that's why I was confused.

With Wine they generally write generic tests and if they pass on Windows (i.e. they're the correct behavior or implementation of a function, in general) then it's what gets implemented in Wine. But Windows sometimes has specific behavior and quirks for specific apps (see the AppCompat directory, too) or shims/hacks. Those won't show up on the generic Wine tests, and I doubt they'd want to upstream them anyway...

Yeah it sucks.

Note that the shims/hacks are only needed because the applications are broken and misuse the Windows API.

But who's to say what correct behavior is for a proprietary Windows API? MS sure doesn't, none of their interfaces are open. Take Khronos API's for example, all their interfaces have documented expected behavior, it is up to the device driver implementing them to emulate that expected behavior. Take Windows and none of their API's have documented expected behavior and if you consider Wine to be a sort of "Windows driver" then it too has to have the burden of emulating expected behavior. Except nobody knows what expected behavior is, only what exhibited behavior is, so it must be emulated app by app. That's the only solution.

Synthetic tests won't work and can't work because nobody knows what expected behavior is and exhibited behavior is different on an app by app basis. The only possible way is to test against whole suites of real world apps and games and when bug fixes in API behavior happen then they need to be per behavior shown to be exhibited. It's not hard to figure out, when a bug fix regresses everything else so badly, then you know that is an example of behavior. Every single release needs tested against all known behavioral outliers using the actual real world app in question and not some imaginary fake synthetic.

Until they actually begin this process of emulating behavior using actual windows apps then they will continue to horribly regress every single release just as they do now and always have. Wine sucks ass because of this.

[oiaohm]

oiaohm windows 10 is known to break drivers plus other things with every major updates. they will be fixed eventually. you can say the same about linux kernel too. after all i have lots of trouble with wifi and video (nvidia) card with every new version.

Nvidia here is the problem child.

about dxvk/d9vk and your argument about opengl games: how old are those video cards to not support vulkan? seems that amd/nvidia/intel vulkan support is quite good.

I have a old nvidia 650 Gtx I know this is old being 2012 card. You read the vulkan list and Nvidia says it works with vulkan 1.0. It does if you install a old closed source driver without stability fixes. You install the current closed source driver for that card under Linux and you have no Vulkan because the card will not do vulkan 1.1. You have opengl 4.5 perfectly fine but that does not let you Vulkan applications work.

We can fairly much bet that when Vulkan 1.2 or what ever the next version of Vulkan is that Nvidia will throw another stack of cards under the bus of screwed back to opengl. This is one of the limit factors why we cannot just straight up drop opengl.
.
I would say Amd and Intel support of Vulkan is decent if you amd/intel gpu is support for 1.0 vulkan it will at least have that with never versions of drivers under LInux. Even with Amd closed source drivers have been that way.

look how long it took wine devs to create vkd3d. im curious if they even consider dx12 to vulkan before dxvk was created.

https://source.winehq.org/git/vkd3d....gs/vkd3d-0.0.1 12 of Oct 2016 is the start of vkd3d February 16, 2016 was the release of Vulkan. So yes 8 months dx12 on Vulkan was what the wine project was working on. Jan 14, 2018 is the first release of dxvk. dxvk is a lot younger.

A lot miss when wine started on vkd3d because while it was still needing third party patches it wine core it was not being marketed much.

i know that wine is not only about games and that wine has to do more than just dx to gl/vk. but when you consider steam and proton than vk is a very important part.

When you consider proton users with the ass that Nvidia is the gl part is still a important part to get working the best as it can. Because we can be sure there will be people using proton today with vk that after a driver update some point in future will be thrown back on opengl.

i know there is also gallium 9 for amd/intel only (probably nvidia if nouveau will get the necessary parts for 900+ gpus) that works great with opengl.

Nouveau one is mostly Nvidia being a ass with documentation and not providing shippable firmware to allow power management to work.

i can't find a good benchmark gallium 9 vs d9vk right now but i think gallium 9 is working better. i don't know if proton support it directly or you have to patch it. gallium nine works only for dx9?

Gallium 9 only works with dx9 they gave up there dx10-11 tracker. I have not found any good benchmarks between gallium 9 vs d9vk. d9vk does have advantage that it does work with dxvk so it can work in a solution providing dx 9-11 and work that it gets along with vkd3d this would give a solution that covers from Windows Vista to current.

Its one of the fun thing some dx10/dx11 games drop back to dx9 to render videos. That party why Gallium 9 is next to impossible to include by default. Remember wine is trying to get to the point you just click on application and it runs without you have to mess with any settings. dxvk and d9vk combination might be possible as in if Windows version is X or newer use them.

[oiaohm]

Synthetic tests won't work and can't work because nobody knows what expected behavior is and exhibited behavior is different on an app by app basis. The only possible way is to test against whole suites of real world apps and games and when bug fixes in API behavior happen then they need to be per behavior shown to be exhibited. It's not hard to figure out, when a bug fix regresses everything else so badly, then you know that is an example of behavior. Every single release needs tested against all known behavioral outliers using the actual real world app in question and not some imaginary fake synthetic.

Wine test suite is not synthetic. The wine test suite is black box. As it the test in there are based off recorded behaviours of real windows applications. Its lot faster to run tests than full applications.

Until they actually begin this process of emulating behavior using actual windows apps then they will continue to horribly regress every single release just as they do now and always have. Wine sucks ass because of this.

Basically this statement is completely false because you don't understand how wine regressions happen 99.9 percent of the time.

No the reality is wine sucks that anything runs is a miracle. Lets look at some numbers instead of your crap guess work.

https://test.winehq.org/data/497b9ed822a6171b3a7253ee4291cbecda9ae3ea/index_Linux.html

There is 675 unit tests. 19 error as in crash as application. 361 report not functioning correctly maybe good enough. 2.8% don't work at all. 53.5% might work for some applications. The result is only 43.7% of wine by its own test suite in fact works properly.

Since wine test suite is based on real applications there is a lot of broken there. Wine is in it stable release process for the year. This is when a huge stack of applications are run against wine to detect if the test suite is right wrong or indifferent as well. You will notice that winetricks has a huge stack of applications it can in fact install this is for the yearly lets install a stack of real applications and check.

The horrible reality here most(99.9% of them) of Wine applications regression is that something in the 56.3% in fact gets implemented correctly now something else in the 56.3% that is not implemented correctly that has not been problem now is because since the part has been implemented correctly the application code path changes and it now wants to use more functions including the stuff that don't work. This is the true nightmare game of pick up sticks.

Wine is not even half complete that a surprise to most people for how many programs in fact work.