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

[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.

[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]

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.

[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]

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.