Valve Reaffirms Commitment To Linux While Also Releasing Updated Proton

[Weasel]

Like weasel if windows API is stable can you explain why 15 different installs of Windows 10 running exactly the same binary test suite give 14 different results
https://test.winehq.org/data/90a1e5d...dex_Win10.html
Windows 7
https://test.winehq.org/data/90a1e5d...ndex_Win7.html
Yep 17 different test installs 17 slightly different results.

Most are just corner cases or undocumented features. Some stuff is not stable because it's not documented, you're not supposed to rely on it. In fact, this is just subtle behavior change. In most other ABI breaks, like you see in Linux, you get total different prototypes aka stack smash or page faults. So stop this pathetic attempt at grasping for straws as if Windows is as unstable as Linux userland. It's not even close. Not even close.

I mean, Stefan from CodeWeavers also told you it's stable when you argued the exact same point, but clearly it's like talking to a wall. You're just hopeless like that. Keep going with that technobabble.

[ZeroPointEnergy]

This not true by the numbers.

https://popcon.debian.org/

Before 2011 32 bit was more tested that 64 bit after 2011 64 bit came more tested than 32 bit. 32 bit usage has been in decline. Systems that can run 32 bit applications are in decline.

Yes, 32bit usage has been in decline. But that is not what we are talking about. 32bit distros go clearly away, but that doesn't mean that some selected 32bit packages that are needed to have a compatiple userland for 32bit software are heavily used.

Just because I am playing game does not mean I am using 32 bit. Like playing Oad, Wesnoth, Quake3 these are all 64 bit games.

Those games are all open source and yes congratulation you found the hand full of games that are not actually a problem, since we can compile them for whatever architecture we want. But guess what, the whole rest of the games playable on Linux are.

Yes all major distributions have multilib support. Most when you do a 64 bit install don't enabled it. So when you go into package manager and search for games you are shown 64 bit games.

And? If you use steam or want to play most of the availbale games for Linux you will have to enable it.

Majority of games installed by debian popcon numbers are pure 64 bit versions. Linux users are installing more 64 bit games than 32 bit games by the stats data you can collect.

They are open source games from the repo, they are not representative for the 5000+ games we have available trough Steam today which are mostly 32bit.

Yes the majority of games available might be 32 bit. Linux world stats have the majority of games installed by Linux users as 64 bit games. With the majority of those with 64bit Linux installed don't have multilib installed.

Basically ZeroPointEnergy try again but this time try some say something that matches the statistics of the Linux world.

The stats you linked are from the Debian package manager.

Linux is mainly used as a server OS, so it is to be expected that in those usecases multilib is not used. But we are talking about the Desktop here and there IF you play games (except if you play the hand full of open source games from the repo) then multilib is REQUIRED.

Look, in the end there are enough people who need multilib and if Ubuntu and whatever distro removes it some other distro will pick it up. There are companies paying for the development and the Linux gaming community is big enough to support all the required stuff on it's own.

This isn't MacOS where we have to follow the vision of some weird dude who is disconnected from it's userbase. This is open source and we can do whatever we want, so suck it up, 32bit is not going away.

[oiaohm]

That's why winetricks exists. Ideally, it shouldn't exist, if Wine was fully implemented, but it's a work in progress, so...

This is correct but you have missed all that not implemented.

Like weasel if windows API is stable can you explain why 15 different installs of Windows 10 running exactly the same binary test suite give 14 different results
https://test.winehq.org/data/90a1e5d...dex_Win10.html
Windows 7
https://test.winehq.org/data/90a1e5d...ndex_Win7.html
Yep 17 different test installs 17 slightly different results.

Weasel you argument about Windows API stablity is like ZeroPointEnergy over Linux distribution make up its not based on documented fact. Documented fact windows ABI is unstable. Winetricks is working around 2 problems not 1.

How to exactly deal with the Windows API random mess and applications that depend on the differences in wine has not been decided on yet. So yes winetricks being uses to cover up the windows unstable ABI issue is because the system to deal with the Windows unstable ABI issue inside wine has not been coded yet. The day wine is complete most likely WINEPREFIX per application will still be required and their be like a custom system for altering the exports of exposed dlls so different applications work.

Weasel its really about time you drop the total garbage arguement that Windows ABI is stable. The hard reality its not and the system to deal with it properly inside wine is not implemented yet. Winetricks works around not implemented including the fact wine has not implemented a system to deal with Windows ABI being broken on different installs and broken between Windows version that applications can depend on being broken to run.

dlloverrides does not exist just because the wine version is broken it exists because the versions of different dll programs may need may need to be broken as well.

The reason why we tell people in support not go nuts installing as much winetricks as they can is hard reality you might be in fact breaking the ABI you applications in fact depends on to work.

Rock and hard place. Wine implementation is not complete and Microsoft provided parts are ABI unstable so either side you choose can kick you where it hurts.

[oiaohm]

No you are fucking retarded. This is required because Wine simply doesn't implement all DLLs properly or all APIs (many, many are just stubs, i.e. they have the same ABI so they don't crash, but their behavior is to just return some value always, cause not implemented). Patches welcome btw.

You don't have the long term wine experience. The first time I came aware of the windows API unstable nature was when I was wanting to run the game rollcage. Wine DX7 had been based on Microsoft software render reference DX7 because that would work in VM back then. Reason why Rollcage was not working in wine is that Wined3d implementation of DX7 had implemented a feature that the reference had that no real video card driver ever implemented.

es I even attempt to write a few patches myself to fix it but I was fixing in the wrong places because the program was going down invalid code paths due to the extra feature implemented..

So the reason why Rollcage would not work was the non uniformity of the Windows ABI not missing features in wine.

This discovery leads to https://test.winehq.org/data/ being made and constantly run monitoring windows ABI on real windows installs. We are talking a discovery made over a decade ago between me as application tester and wine developer attempting to fix fault.

That's why winetricks exists. Ideally, it shouldn't exist, if Wine was fully implemented, but it's a work in progress, so...

This is correct but you have missed all that not implemented.

Like weasel if windows API is stable can you explain why 15 different installs of Windows 10 running exactly the same binary test suite give 14 different results

https://test.winehq.org/data/90a1e5d943724f8cb5e51fe806cb38ce6c98c4c1/index_Win10.html

Windows 7

https://test.winehq.org/data/90a1e5d943724f8cb5e51fe806cb38ce6c98c4c1/index_Win7.html

Yep 17 different test installs 17 slightly different results.

Weasel you argument about Windows API stablity is like ZeroPointEnergy over Linux distribution make up its not based on documented fact. Documented fact windows ABI is unstable. Winetricks is working around 2 problems not 1.

How to exactly deal with the Windows API random mess and applications that depend on the differences in wine has not been decided on yet. So yes winetricks being uses to cover up the windows unstable ABI issue is because the system to deal with the Windows unstable ABI issue inside wine has not been coded yet. The day wine is complete most likely WINEPREFIX per application will still be required and their be like a custom system for altering the exports of exposed dlls.

Weasel its really about time you drop the total garbage arguement that Windows ABI is stable. The hard reality its not and the system to deal with it properly inside wine is not implemented yet. Winetricks works around not implemented including the fact wine has not implemented a system to deal with Windows ABI being broken on different installs and broken between Windows version that applications can depend on being broken to run.

dlloverrides does not exist just because the wine version is broken it exists because the versions of different dll programs may need may need to be broken as well.

The reason why we tell people in support not go nuts installing as much winetricks as they can is hard reality you might be in fact breaking the ABI you applications in fact depends on to work.

Rock and hard place. Wine implementation is not complete and Microsoft provided parts are ABI unstable so either side you choose can kick you where it hurts.

[Weasel]

That right wine include the means to not use it provided libraries instead use native dll in the wineprefix instead. This is required to get particular programs to run due to ABI different in windows.

No you are fucking retarded. This is required because Wine simply doesn't implement all DLLs properly or all APIs (many, many are just stubs, i.e. they have the same ABI so they don't crash, but their behavior is to just return some value always, cause not implemented). Patches welcome btw.

That's why winetricks exists. Ideally, it shouldn't exist, if Wine was fully implemented, but it's a work in progress, so...

[oiaohm]

The libraries needed by 32bit software are as much used and tested as the libraries used by 64bit software is. There is a ton of 32bit software around, mainly games that are played every day

This not true by the numbers.

https://popcon.debian.org/

Before 2011 32 bit was more tested that 64 bit after 2011 64 bit came more tested than 32 bit. 32 bit usage has been in decline. Systems that can run 32 bit applications are in decline.

The majority of games is 32bit so this is simply not true. A lot of people play games on Linux and every major Linux distribution has multilib support.

Just because I am playing game does not mean I am using 32 bit. Like playing Oad, Wesnoth, Quake3 these are all 64 bit games.

Yes all major distributions have multilib support. Most when you do a 64 bit install don't enabled it. So when you go into package manager and search for games you are shown 64 bit games.

Majority of games installed by debian popcon numbers are pure 64 bit versions. Linux users are installing more 64 bit games than 32 bit games by the stats data you can collect.

Yes the majority of games available might be 32 bit. Linux world stats have the majority of games installed by Linux users as 64 bit games. With the majority of those with 64bit Linux installed don't have multilib installed.

Basically ZeroPointEnergy try again but this time try some say something that matches the statistics of the Linux world.

[oiaohm]

NO this post of weasels should have not got a vote. Since first version of wine the following from the man page of wine has existed:
WINEDLLOVERRIDES
Defines the override type and load order of dlls used in the loading process for any dll. There are currently two types of libraries that can be loaded into a process address space: native windows dlls (native) and Wine internal dlls (builtin). The type may be abbreviated with the first letter of the type (n or b). The library may also be disabled (''). Each sequence of orders must be separated by commas.


That right wine include the means to not use it provided libraries instead use native dll in the wineprefix instead. This is required to get particular programs to run due to ABI different in windows.

So the .dll you are using to run windows programs in wine are not always fake with different copy protections there are lot of modified core .dll in the mix.

Wine design as the ABI alterable per WINEPREFIX using Dll Overrides to choose between wine provided version and other sources.

Winetricks have been loading in Microsoft parts over wine provided libraries for a long time to get programs to work. .

Weasel who keeps on pushing the idea that the WIndows ABI is stable.

https://test.winehq.org/data/

Wine project testsuite is run against windows we know that windows versions ABI don't match. Heck we know that you can have 5+ different installs of the same version of windows and have ABI differences this does make getting programs to work kind of tricky at times. Wine ABI is in fact basically a average of the different Windows ABIs so we are more than aware that we at times have to override this so applications work.

[oiaohm]

That has absolutely nothing to do with the ABI, even more so considering that the .dll files are just fake (until wine 4.10) and the actual .so files that implement the ABI are in one spot only modifiable by root. You're fucking retarded.

NO this post of weasels should have not got a vote. Since first version of wine the following from the man page of wine has existed:

WINEDLLOVERRIDES
Defines the override type and load order of dlls used in the loading process for any dll. There are currently two types of libraries that can be loaded into a process address space: native windows dlls (native) and Wine internal dlls (builtin). The type may be abbreviated with the first letter of the type (n or b). The library may also be disabled (''). Each sequence of orders must be separated by commas.

That right wine include the means to not use it provided libraries instead use native built libraries. This is required to get particular programs to run due to ABI different in windows.

So the .dll you are using to run windows programs in wine are not always fake with different copy protections there are lot of modified core .dll in the mix.

Wine design as the ABI alterable per WINEPREFIX using Dll Overrides to choose between wine provided version and other sources.

Winetricks have been loading in Microsoft parts over wine provided libraries for a long time to get programs to work. .

Weasel is the moron who keeps on pushing the idea that the WIndows ABI is stable.

https://test.winehq.org/data/

Wine project testsuite is run against windows we know that windows versions ABI don't match. Heck we know that you can have 5+ different installs of the same version of windows and have ABI differences this does make getting programs to work kind of tricky. Wine ABI is in fact basically a average of the different Windows ABIs so we are more than aware that we at times have to override this so applications work.

[Weasel]

No, we can just stop fucking up the userland.

Short and to the point. Amen. Don't mind oiaohm, he's "special" like that.

[Weasel]

LOL moron wine it self contains containerisation in what is called WINEPREFIX. Yes even today you still get cases where 2 new windows games from different makers cannot be installed on windows at the same time and run due to conflicting dependency.

That has absolutely nothing to do with the ABI, even more so considering that the .dll files are just fake (until wine 4.10) and the actual .so files that implement the ABI are in one spot only modifiable by root. You're fucking retarded.

Of course, an app can even delete kernel32.dll or mess with another app (imagine a server/client app combination), and so two wine prefixes can prevent this fiasco here. Which has nothing to do with ABI, that's just app isolation. You can get the same shit in Linux by running an app as different users.