Wine 3.20 Released With Several Improvements

[phoronix]

Phoronix: Wine 3.20 Released With Several Improvements

Wine 3.20 is now the latest bi-weekly development release for this increasingly popular code-base for running Windows programs/games on Linux and other operating systems...

http://www.phoronix.com/scan.php?page=news_item&px=Wine-3.20-Released

[pinguinpc]

In this wine version steam still have login problems

[mzs.112000]

I think Wine needs to set a specific goal for Windows compatibility....
First they should set Windows 7 as their goal, then once they get 95% API compat with Windows 7, they move on to Windows 8, then 8.1, and then Windows 10 1509, and so on. Because, right now, they are working on adding Windows 10 API functions, when there are still missing functions that date back to XP. Entire DLL's(some dating back to XP) are still just stubs.

[Xaero_Vincent]

Nah. 100% API implementation in DLLs shouldn't be the first priority. My likely unpopular opinion is that Wine should continue to work on improving things average Linux users care about: Windows games and Windows game client support. For productivity software, alternatives are usually fine unless you are a pro user who demands the best (in which a Windows virtual machine with a free trial version of Windows 10) is generally ok. I think most average, no pro users are fine with alternatives for software but finding FOSS alternatives for games is a no go.

[ssokolow]

Nah. 100% API implementation in DLLs shouldn't be the first priority. My likely unpopular opinion is that Wine should continue to work on improving things average Linux users care about: Windows games and Windows game client support. For productivity software, alternatives are usually fine unless you are a pro user who demands the best (in which a Windows virtual machine with a free trial version of Windows 10) is generally ok. I think most average, no pro users are fine with alternatives for software but finding FOSS alternatives for games is a no go.

Agreed. Prioritize the functions with the highest return on investment. (ie. the functions that are required by the widest range of desired software.)

[Michael_S]

I would take it in a different direction - as far as I understand it, a lot of the Wine developers are volunteer. If they're not being paid to get a particular set of applications working, they can target whatever they want.

But I have to admit that the only Windows application I still use is Starcraft 2. That works well enough now, so I have no desire to ask for more work. I'm sure I would feel differently if my favorite Windows-only program didn't work on Wine.

[AdamOne]

Wine needs to be Valve-ized. Just like they did with Proton, creating it, support for Windows platform software must be uniform, and use a dedicated developer group who do it for a living. Linux desktop will *always* lack support for something that is easily available on Windows, which makes the current state tough to say the least. Why would you stop liking Arma 3 multiplayer because all the linux compatible servers are unpopulated? A person isnt just gonna *turn off* what they fancy.

Windows is a gaming machine, to say the least, and something's got to give for the current state to change.
I wanna express myself one way, then thats what i freakin wanna do. The current situation is really tough I would say. It would light up a lot of users day if they could get a couple of hours in in their exclusive windows app. Oh, and apropos dual booting, since I hear you bring it up; on a 250 gig SSD where the game is ~35 gigs easily nowadays, its a crappy solution to begin dual booting. Other than that there arent a lot of solutions.

To be continued. 5 AM in Europe and no sleep *dunk* Zzz... Zzz...

[oiaohm]

I think Wine needs to set a specific goal for Windows compatibility....
First they should set Windows 7 as their goal, then once they get 95% API compat with Windows 7, they move on to Windows 8, then 8.1, and then Windows 10 1509, and so on. Because, right now, they are working on adding Windows 10 API functions, when there are still missing functions that date back to XP. Entire DLL's(some dating back to XP) are still just stubs.

This does really match reality. You have the 80/20 rule that is Pareto principle. Any large ABI fairly much obeys this.

It works out that roughly 80% of all the applications only use 20% of the ABI. Also the remaining 20% roughly only using 80 percent of the API. This leaves 20% of ABI.

Please note I wrote use.

Some of those libraries that are stubs can be the tits on bull functions. These are horrible class of function. I came across these the first was attempt to get a Dx5/6 game rollcage to work on wine. Wine dx1 to dx7 had been implemented exactly to Microsoft software reference dx implementation at the time. Guess what the reason why my program would not work is because it had been implemented exactly to Microsoft software reference dx implementation. There is a feature that no real GPU driver ever implemented for dx1-7 and that feature was sending program south. So now you have application going complete fail because you have implemented exactly to Microsoft documentation.

Tits on bull functions the function has to exist but also has to not work. There are deprecated functions in Windows 10 that use to in fact do something in Windows 7 so its not just WIne with tits on bull functions windows has them as well. Reality there are some functions in Linux API/ABI that are also this.

If a function has been intentionally turned into a non functional tits on bull function it can be that there is something critical wrong with the way that API/ABI was designed. So the function is better to fail 100 percent of the time than cause applications to have random crashes because it works. So focus on Windows 7 and move forwards does not exactly work.

Yes you have to look at latest version of window you can to check of functions that have been made non functional. No point attempt to implement something if you 1 don't need to implement it and 2 by implement it all you do is make program unstable.

Also the idea of 95% API compat is bogus requirement. About 10% of the export functions from Windows DLL files you cannot find a single program ever that uses that function. Yes the function is written into the MSDN since it wrote into the MSDN Microsoft has to keep on providing the function just in case some developer at some point writes a program that uses it. Yes some of these functions there were better ways added to perform the task in the same windows version so you have to be nuts to use that function. These are the totally useless functions that if wine does not even have stubs for them users will never notice the difference. People developing ABI/API make mistakes little bit more often than most people would think.

DLL that are pure stub wine go back to windows 3.11. Some are shocking that no current application that ever used that dll ever expects that dll to work because the application developer never tested what it should do when it does work so application updates broke it. Yes the code when some of the stub out dlls is swapped working version results in some programs crashing because there code for when the dll works is not tested and was broken like a decade ago.

Yes it makes sense for wine developers to go forwards to current windows and be kind of working backwards so they can learn what Microsoft has altered because this can save them running into the same mistakes.

[oiaohm]

Wine needs to be Valve-ized. Just like they did with Proton, creating it, support for Windows platform software must be uniform, and use a dedicated developer group who do it for a living.

Problem has always been paying the bills. Codeweavers have for years provided a paid for crossover front end. This is to pay people to work on wine. Valve with Proton is working with codeweavers and valve is also working with other parties to improve Linux binary support as well.

A distributor seams to be in a good place to collect a tax from a stack of different programs and use the income from that tax to fund the developer group.

Proton is just valve front end to wine with a few add ons. So Proton has the same core developer group as wine.

https://www.codeweavers.com/about/blogs/jwhite/2018/8/22/wine-and-steam-a-major-milestone

Yes valve and codeweavers(company behind cross-over and employee many core developers of wine) with proton have been working with each other. Including valve paying codeweavers for work.

So there has been a dedicated developer group with wine for quite some time. Wine project is not providing the best interface because if they did how would the core developers get their wages paid.

[uid313]

But is Win32 dead?
Maybe now its all about .NET Core, WPF and UWP?