Valve's Proton 4.2-3 Released With Wine-Mono Integration Plus DXVK 1.0.3, Updated FAudio

[oiaohm]

No, ntdll is the one which has syscalls and syscall numbers. Kernel32 by itself is userspace.

Did you not read my link. The table to access not directly exposed syscalls is in kernel32.dll. The functions to use that table is ntdll. So microsoft system libraries have to link to ntdll and kernel32 to use special syscalls.

System libraries are those that ship with the system and aren't redistributables. They all have stable API/ABI based on the contract.

This is true but anything that is not a System library as not linked to the kernel. Microsoft by contract is free to skip shipping in future versions of windows and you need to bundle with your application. Like old versions of visual studio runtime were include with old versions of windows out box but they are not included any more on Windows 10.

By the way some of the libraries that are now in redistributables with Windows when they were first released they only came with X version of windows. Microsoft does make redistributes after the fact. Microsoft define of a system library does not in fact include all libraries that are currently not in redistributables their define that the ABI stable contract is provided on is any library that cannot in fact be ever packaged up as a redistribute separate to the kernel. By Microsoft define no Linux library is a system library. All Linux distribution libraries are redistributables by Microsoft define and totally removable at any time. Basically get yourself a copy of windows core and that is basically all Microsoft has given you a ABI promise on of being present.

Basically this is Weasel having define wrong so most likely miss reading and over expecting what Microsoft runtime promise in fact covers.

Now start apply Microsoft method to the Linux world. Next point disappears.

And they will stop working once GTK2 or whatever is unavailable. Because of course, in Linux userland, it's trendy to remove old versions of a library.

If you are following what Microsoft does with Windows when GTK2 disappears from main distributions a runtime installer of the removed library should be made. Basically done with old loki games so they still play.

Microsoft does the same thing with high level toolkits being MFC from visual studio. So its not trendy the reality is once a library comes unmaintained it comes a security problem so be it windows or linux or os x it will disappear from default install.

Again will they really stop working if someone at the time gtk2 disappears decided to provide a install-able run-time for the programs. http://www.improbability.net/loki/
So your idea they will stop working is FUD.

You think how many old programs fail to work because developer did not bundle visual studio runtime with them. Linux distributions have supported chroot for old version of distribution for a very long time. Old version of program at times be it windows or linux equals extra hoops to jump though due to libraries removed on security grounds due to being unmaintained.

Again Weasel this is another bogus difference Microsoft with windows is removing old libraries and people installing old programs have to work around this. In fact Microsoft Windows when you hit a program that does not work due to something being removed there are many times where its not possible to fix.

Linux old programs have higher odds of being able to be got working but it has a higher effort curve. I have pointed to the debian snapshot system before allowing you to pick a date and time in history an make a chroot of how debian looked on that date these chroots are only useful due to the fact syscall are ABI stable and protocols that provide another set of stable interfaces. Notice something windows does not provides either..

Linux worked you want a old library back you historically chroot. Windows you want a old library back you install runtime and hope the program is using SXS with it defined correctly and its a library that can be installed by runtime.. This is a difference but does this mean Linux distributions cannot run old programs. Hell no it just you have different steps to get there.

The stable system calls and stable protocols of the Linux system allows installing very old libraries. I do give this could be made more user friendly. Those provided tar.gz binaries when gtk2 disappears could be simply bundled into a flatpak and have a old runtime assigned.

Basically Weasel you just put up fib difference between Windows and Linux. Both Microsoft Windows and Linux distributions remove old libraries. Both remove old libraries at times in ways they cannot be simply reinstalled. In the case you have a library that cannot be reinstalled
1) Windows you are forced to virtual machines.
2) Linux chroot/containers solutions good enough.

As I said in the last time try to be factual. I will say this as well. "DON"T USE FAKE DIFFERENCE BETWEEN WINDOWS AND LINUX EITHER". I will pull you up on that as well.

[Weasel]

In fact kernel32 is a wrapper library to functionality provide by NT kernel.
https://www.cs.uaf.edu/courses/cs301...notes/syscall/
The windows syscall numbers to access the kernel and other features are stored in kernel32.dll. This is not a pure userspace dll this dll has to be kept absolutely aligned with your Windows kernel or you programs are going to break. Kernel32.dll is your windows syscall interface numbers. So kernel32.dll is a interface to the NT kernel from userspace code that is not in fact need when you have stable syscalls.

No, ntdll is the one which has syscalls and syscall numbers. Kernel32 by itself is userspace.

No this is not true less than 25% of the libraries in system32 are system libraries. Some of the graphical tools are system because there is a graphical toolkit that is part of the windows kernel. Linux does not have a full blow graphical toolkit as part of kernel.

System libraries are those that ship with the system and aren't redistributables. They all have stable API/ABI based on the contract.

Gecko is firefox engine right.

https://www.mozilla.org/en-US/firefox/new/

You got to mozilla download the tar.gz containing binaries for Linux from here and hang on you have 1 file for all current distributions using glibc and going back at least 5 years.
Now lets look at your next example mono.

https://github.com/mono/linux-packaging-core-setup

Again there is another generic tar.gz file containing binaries that is for all current distributions using glibc and going back at least 5 years.

And they will stop working once GTK2 or whatever is unavailable. Because of course, in Linux userland, it's trendy to remove old versions of a library.

[oiaohm]

Well I have a new example for you. I just got The Treehouse Man which JUST released a native Linux version. Start it up and nothing. Use GDB to figure it out, it's a SIGSEGV somewhere in libX11, go figure, I suppose wayland vs X possibly? (I'm running gnome/wayland).

Remember libX11 is a highly stable ABI backed by a protocol so a sigsegv in libX11 is normally something else has screwed up. You are normally look at the library that has called libX11.

Switch the game to use Windows version via proton and presto, I can play it no issues. Go figure...

Most of your normal issues gnome/wayland that normally fault in libX11 would also see proton fault as well.

Backtrace of crash (reported to devs too): https://ghostbin.com/paste/muajw

If you have used this on your crash report its gone by the time I have read this message.

You have to remember game developers do successfully release games for windows that crash under particular windows configurations. The reverse is more common that the windows game will not run under proton yet the native Linux game works this is by steam collected statistics not your personal biased testing.

Yes people on windows who are playing games have a windows game that does not run either. The reality is it basically part of gaming these days that from time to time a game does not work.

https://store.steampowered.com/steam_refunds/

Yes Valve with steam hands out quite a few refunds on windows and OS X because games don't run as well yes OS X is limit hardware configurations yet developers still fail to test everything..

Thing is with proton and linux native you get two rolls of the dice. https://github.com/ValveSoftware/Proton/issues/1344
OS X is does not have proton yet so it will come a two roll system as well.

This double dice roll is good for end user and developer. Why because if the game you just had complete failed to work you would have been able to request a refund this means the game developer does not get paid either. The fact the game worked under proton for you. You got to play the game and the game developer got paid. Now if the reverse had happened where the native worked and the proton failed game developer still gets paid as well.

With the valve statistics you want the least number of refunds as a game developer you will release a Linux native version even if it not perfect.

Almindor is really simple to let personal bias make you ignore the statistics. Valve numbers are clear the most likely way to work is steam runtime native ok this is most likely not 100 percent. The steam native runtime using binaries when they exist has a higher percentage of working than windows game on windows of course that miles ahead on numbers from windows game on proton. This is why I will absolutely not talk against developers doing native versions on the steam runtime because it has such high success numbers.

Problem is the reality is that no matter the platform windows, os x, Linux native and Proton in this day and age there are always be games released by developers that crash and will not run for you for many reasons no matter what platform you are running that valve and other game distributors will have to pay out refunds on. So the every time you get a game its a roll of the dice if it will work for you or not. 2 rolls of the dice are better than 1 particularly if you really want to play X game.

I do agree with most people that if a game works for you or not should not be luck but the reality that is what we have these days on all PC like platforms.

[Almindor]

Lets pull this apart. Old LOKI games have GLIBC ABI version mismatch and compositor funkyness from X11 stuff. dbus is too modern for Loki.

http://www.improbability.net/loki/

Those 20+ year old programs run on current day distributions using an over 6 year old run-time that has not need to be updated that often.

Linux ABI is a lot more stable if applications are shipped with runtime.


Again with flatpak and steam runtime why would you be fighting with all the different distributions.

Yes steam is in provide on flathub in flatpak format and this can be useful to work around particular issues.


So is this a xwayland bug. Really it would be interesting to put those games in flatpak and not set wayland. Because if wayland is not set on flatpak package and x11 and the system is wayland it will use xwayland.

http://docs.flatpak.org/en/latest/sa...rmissions.html

Really adventure creator games will not work under wine if you remove the visual studio runtime they install either. So they ship with a runtime on Windows and don't ship with a runtime on Linux. Hello problem.

Please also note adventure creator games with the resolution setup issues also fail under windows it wine virtual desktop lie allows them to work under proton and nesting X11 allows the native one to work.

Basically if adventure creator games are not finding a bug in xwayland they should be able to made work converted to flatpaks. Yes at times steam installed by flatpak with sandbox permissions altered to disable wayland leaving only X11 on wayland based desktops have been a work around to get particular native games to work that have broken wayland implementations.

Final note of importance I missed is the reality is to have proton always work on any distribution you could end up using flatpak anyhow. Please note proton/wine does not support wayland out yet instead on wayland desktop is depending on xwayland.

Well I have a new example for you. I just got The Treehouse Man which JUST released a native Linux version. Start it up and nothing. Use GDB to figure it out, it's a SIGSEGV somewhere in libX11, go figure, I suppose wayland vs X possibly? (I'm running gnome/wayland).

Switch the game to use Windows version via proton and presto, I can play it no issues. Go figure...

Backtrace of crash (reported to devs too): https://ghostbin.com/paste/muajw

[oiaohm]

I never talked about syscalls. kernel32 is pure userland and it was just an example anyway.

In fact kernel32 is a wrapper library to functionality provide by NT kernel.
https://www.cs.uaf.edu/courses/cs301...notes/syscall/
The windows syscall numbers to access the kernel and other features are stored in kernel32.dll. This is not a pure userspace dll this dll has to be kept absolutely aligned with your Windows kernel or you programs are going to break. Kernel32.dll is your windows syscall interface numbers. So kernel32.dll is a interface to the NT kernel from userspace code that is not in fact need when you have stable syscalls.

Most dlls shipped in system32 are system libraries so idk what your point is. Yes even the graphics toolkits.

No this is not true less than 25% of the libraries in system32 are system libraries. Some of the graphical tools are system because there is a graphical toolkit that is part of the windows kernel. Linux does not have a full blow graphical toolkit as part of kernel.

I mean... if we look at wine... It's just one wine-mono or wine-gecko package. Just one for all distros or operating systems that Wine supports. You know why? Because it's compiled as Windows DLLs and environment.

Gecko is firefox engine right.

https://www.mozilla.org/en-US/firefox/new/

You got to mozilla download the tar.gz containing binaries for Linux from here and hang on you have 1 file for all current distributions using glibc and going back at least 5 years.
Now lets look at your next example mono.

https://github.com/mono/linux-packaging-core-setup

Again there is another generic tar.gz file containing binaries that is for all current distributions using glibc and going back at least 5 years.

On the other hand look at the pathetic mess that is the actual wine package with .so files and Linux imports, which is built for every god damn distro due to dependencies. I'm sick of this.

Reality what you just wrote is false. If you look at winehq repository and you start checksumming the executable binaries inside the distribution packages you will find something surprising. Same release number same arch same executable binary checksums is what you find in side. Building for every Linux distribution wine provided packages for plus all the testing would burn up more server resources than the wine project has.

Wine from winehq is in fact multi packaged but only in fact built once most of the time. Why its done for being simple for users to install all the dependancies. Playonlinux ships custom versions of wine also depend on the fact that wine itself as a binary is basically distribution neutral as long as the required dependencies to run wine are installed that they get around by installing the distributions version of wine. Yes Playonlinux is a second party that builds 1 binary of wine for basically every Linux Distribution so its not like wine the main project is doing anything special.

Distributions decide to apply their own custom patches to wine so they build wine themselves as well this is why before digging into bugs we have users install the version from winehq. Yes there are quite a few parts distributions customise..

Flatpak is a lazy way out but cross distributions packages don't in fact depend on it like the many large examples that do 1 tar.gz binary package for all not end of life glibc distributions those examples include firefox, wine(from playonlinux), mono, blender,xonotic and many more.

Yes most who attempt to pretend a linux stable ABI does not exist for application development on Linux are pretending that cross distribution packaging don't exist. I will give you that Linux cross distribution packages normally end up 20 megs bigger than their windows one but about 30 megs smaller than the OS X one. The price of being protocol based is this little extra bloat but not as much as being on OS X.

Weasel basically your last post successfully hit zero facts correct. So please try to come up with a factual arguement.

Factual arguement might be that it too hard for new developers to find the process to make cross distribution packages. With the number of projects that make cross linux distribution packages you cannot argue that it cannot be done.

By the way most of the reasons why you have to update wine are to-do with video cards so that wine can provide information applications expect on windows that cannot be sourced on Linux. And about once every 10 years a ABI break in a library like freetype that wine does not bundle can be worked around by bundling.

[Weasel]

When you said stable system api you started talking about syscalls. By Microsoft define it a system api if it part of Window core .

Yes you started with Stable ABI then you stepped it up to Stable System Api when you add the word system you are wrong the answer to Stable System Api on Linux is always the syscalls because if you get what Microsoft lists as system .dll you will find almost all their functionality is in the syscalls.

I never talked about syscalls. kernel32 is pure userland and it was just an example anyway.

It was not a valid example. Kernel32.dll is a system library none of the Windows system libraries should be attempted to be used in a arguement about Linux ABI stability because they are replaced by syscalls on Linux.

Most dlls shipped in system32 are system libraries so idk what your point is. Yes even the graphics toolkits.

I mean... if we look at wine... It's just one wine-mono or wine-gecko package. Just one for all distros or operating systems that Wine supports. You know why? Because it's compiled as Windows DLLs and environment.

On the other hand look at the pathetic mess that is the actual wine package with .so files and Linux imports, which is built for every god damn distro due to dependencies. I'm sick of this.

And no, "supplying the entire dependency chain" is not a solution, it's a workaround (aka what flatpak does), and proves even more why it's shit currently.

[ssokolow]

Really one of the reasons why I am interested in flatpak so much is the portal system. https://github.com/flatpak/flatpak/wiki/Portals at long last dialogs defined behind a protocol.

That link is outdated and incomplete. See https://flatpak.github.io/xdg-deskto...rtal-docs.html instead. (It's linked from http://docs.flatpak.org/en/latest/de...n.html#portals if you're wondering how I found it.)

[oiaohm]

Dude stfu about syscalls or the kernel I'm talking about the userland

When you said stable system api you started talking about syscalls. By Microsoft define it a system api if it part of Window core .

Yes you started with Stable ABI then you stepped it up to Stable System Api when you add the word system you are wrong the answer to Stable System Api on Linux is always the syscalls because if you get what Microsoft lists as system .dll you will find almost all their functionality is in the syscalls.

No, that was just an example.

It was not a valid example. Kernel32.dll is a system library none of the Windows system libraries should be attempted to be used in a arguement about Linux ABI stability because they are replaced by syscalls on Linux.

Windows "toolkit" is in user32/gdi32/shell32/comctl32 and so on. Why can Windows have a stable "toolkit" while we have piece of shit gtk4 already on Linux?

Again there is a design difference. Have you not notices you have like the X11 Protocol, Dbus Protocol.... All these things on Linux ending in Protocol so instead of needing exact libraries you can have multi libraries that talk those protocols and everything works out fine. KDE, Gnome, systemd all using different dbus libraries it does not matter. The protocol difference in the Linux world mean you can have more duplication. Windows you don't have protocols like this so you have to use the wrapper libraries over the Microsoft hidden protocols. This does increase what you need to bundle.

Now this is get term correct. You are after a stable toolkit. As normal you screw up again you don't know when to stop. Also Linux does have a stable toolkit for graphical.

https://docs.microsoft.com/en-us/win...ntrol-versions comctl32 is a interesting bit of evil with that version macro wonder what this is.
2) Tightly controlled build environment with bundling of libraries. This is Netscape/Mozilla developers invention they have been doing for over 2 decades with firefox/netscape and other products of theirs that they make tar.gz binary packages of. This has been replicated by Xonotic/Nexuiz and others so this solution absolutely works. There is now the https://phusion.github.io/holy-build-box/ Yes someone has started this holy build box that provides this method in an easy setup for developers and step by step instructions.
Yep what I said you could do before on Linux.

Lets look at the basic X11 basic toolkit.

https://abi-laboratory.pro/index.php?view=timeline&l=libx11

This is common called xlib. Never had a single ABI breakage ever. GTK/Qt are in fact a level up. There is a interesting point neither GTK/Qt have a protocol.

Basically this is another case of you being wrong there is a stable graphical toolkit on Linux. Does not come with a nice set dialogues or any extra fancy dressing.

Reality is using Gtk or QT on Linux is really the same as using them on Windows you need to ship them with your application if you are making a multi distribution application using them but you don't need to use either to make a graphical application on Linux blender is a good example it uses a opengl based graphical and ships tar.gz files for linux distributions.

Basically weasel with Gtk you are not looking at a platform toolkit you are looking at a toolkit you are to bundle.

Yes you would have a arguement to complain that the Linux stable ABI graphical toolkits are a little too bare bone. Not that they don't exist. Yes the three ABI stable toolkits for graphical xlib/libx11, libwayland-client0 and opengl. There are stable ABI toolkits on Linux for printing and many other things.

Other than not having your nice dialogues/theming your stable ABI toolkits on Linux cover a hell of a lot more than the dlls windows provides. Most of the items that are in fact stable ABI are either wrapper library on top of the syscalls or interface for a protocol on Linux the great part about this is that you can ship a version with your application and if it old on a new system it still works.

Weasel basically you have started with the idea Linux world does not have stable ABI. Problem is Linux world does have a Stable ABI and the line is draw fairly much in the same place as if you were building your application to ship on Windows. If you treat building an application for Linux distributions as if you were building it to ship on windows and bundle all the same things 99% of the time the result is your application only using libraries outside that bundle that are stable ABI and stable named libraries as well. This is why I class your arguement as complete garbage from a clueless person who has never researched the problem properly. Tightly controlled build environment restricted to only the stable ABI libraries is a lot more feature rich than what you would be thinking.

Linux distributions make it insanely simple to build your application and not bundle then have it explode in your face with changes. This is why when someone says you have to build for a distribution they are normally a idiot they have just made an application that is not bundled and most likely latched to some library the distribution will remove in future.

There is a difference Linux userspace stable ABI libraries is very feature sparse in places like it has enough functionality to do graphical applications but you don't have the nice stuff like premade dialogues. Windows does provide premade dialogues but you see them are also done in restricted API/ABI model. Even so the stuff missing from the userspace stable ABI of Linux does not make it non functional for building your applications. Like most adobe applications on windows are using Qt so they don't use the provided dialogues by windows anyhow.

Really one of the reasons why I am interested in flatpak so much is the portal system. https://github.com/flatpak/flatpak/wiki/Portals at long last dialogs defined behind a protocol.

Biggest problem developers really do themselves with Linux is treating it different to windows when building applications. The process for making a portable binary on Linux and Windows is basically the same. Yes you have to ignore the candy store of distributions that will do you in.

[Weasel]

Your complete argue here is fail.

Find kernel32.dll on Linux. Guess what it does not exist as a .so file. Why these are the Linux kernel stable syscalls do all the functionality of the kernel32.dll under windows. Windows does not have a stable syscall interface exposed to applications so the system32 contains a stack of wrapper libraries that don't exist on Linux systems.

Linux has quite a large stable ABI once you look at the syscalls.

No, that was just an example. Windows "toolkit" is in user32/gdi32/shell32/comctl32 and so on. Why can Windows have a stable "toolkit" while we have piece of shit gtk4 already on Linux?

Basically Linux does have STABLE SYSTEM APIs is the that are always there these are the Linux kernel syscalls.

Dude stfu about syscalls or the kernel I'm talking about the userland.

For reference, here's the post where it started: https://www.phoronix.com/forums/foru...37#post1093937

Here's my quote:

It's not my fault that MS can design a proper stable API and the retarded Linux userland devs can't. Your TV show suggestion obviously shows up where your intelligence lies.

Guess what "userland devs" means.

[oiaohm]

So? It's like installing a dependency. You install only the visual studio libs NOT THE ENTIRE SYSTEM like the Steam "runtime". The visual studio libs use other system libs, which have stable APIs, so you don't have to supply kernel32.dll, user32.dll and all the other crap you use as a "runtime".

Your complete argue here is fail.

Find kernel32.dll on Linux. Guess what it does not exist as a .so file. Why these are the Linux kernel stable syscalls do all the functionality of the kernel32.dll under windows. Windows does not have a stable syscall interface exposed to applications so the system32 contains a stack of wrapper libraries that don't exist on Linux systems.

Linux has quite a large stable ABI once you look at the syscalls.

If the steam runtime is anything more than libc then your point is invalid.

Visual studio runtime does not just include libc it also include MFC and other basic bits. So this is a pure fail arguement again.

The point is that a MISSING runtime, such as the visual studio runtime, links against STABLE SYSTEM APIs. You don't supply the entire system32 folder and "chroot" into it on Windows, so shut the hell up, it's not even comparable.

Basically Linux does have STABLE SYSTEM APIs is the that are always there these are the Linux kernel syscalls. Really some time look at what is in system32 on windows and how many of those .dll don't in fact exist on Linux because on Linux they are just syscalls. Having stable syscall structure alters things a hell of a lot.

Basically Microsoft windows core developers defines stable ABI by wrapper libraries. Linux kernel defines stable ABI by syscalls. Two different ways to take on the problem. Windows define by library on the theory they can change the syscalls any time they like. Linux simple you implement syscall you keep it stable.

Newlib(an alternative to glibc) is not needing to link against any other libraries provided to work on Linux yet newlib built for windows will be linking against kernel32.dll and other parts. This was the first time I got clued in on a clear difference. You look closer and you see the linux code is just straight up using syscalls and the windows code is calling wrapper .dll files.

Yes windows and linux are different. Linux big difference the core of the operating system does not have a stack of hanger on .so files where windows you have a stack of hanger on .dll files. Really spend some time learning how many windows system libraries simply don't exist on Linux because they don't need to because they are totally in fact replaced by the syscall system.