Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by Weasel View Post
    Prefixes are not a runtime they're just stubs and dummy DLLs. Having to install correct additions is just because Wine is not complete and misses a ton of stuff..
    Even when wine is complete having to install additions will always be required. Because Windows programs ship with runtime or expect particular run-times installed and for digital rights management/anti-cheat systems they go as far as checksumming those binaries so wine cannot ever replace those files .

    Originally posted by Weasel View Post
    If you have to separate two apps because they won't play nice with each other, then that is an issue with the app itself, and has nothing to do with the runtime.
    No its the fact the application shipped with a runtime on windows why they are conflicting. The problem with Linux native is a lot don't ship with runtime.

    Comment


    • #32
      Originally posted by oiaohm View Post
      Even when wine is complete having to install additions will always be required. Because Windows programs ship with runtime or expect particular run-times installed and for digital rights management/anti-cheat systems they go as far as checksumming those binaries so wine cannot ever replace those files .
      I'm not sure what your point is. If games ship with runtimes then they're not part of Wine (nor Windows). Games can use whatever they want. They could even ship an entire Linux distro if they want to.

      That doesn't make the runtime bad, though. Just because you aren't forced to use it. Nobody said that games are programmed properly.

      For example, a MS-DOS game could, theoretically, supply the entire environment for a AAA game today since DOS allowed you direct access to hardware. Drivers and all. And it has absolutely nothing to do with MS-DOS at this point. Just like games that supply their own runtimes have nothing to do with how sane the system's runtimes are (Windows or Linux).

      Originally posted by oiaohm View Post
      No its the fact the application shipped with a runtime on windows why they are conflicting. The problem with Linux native is a lot don't ship with runtime.
      You can't ship with the freaking runtime when you need to specifically build for a given distro. This has happened to me in the past and you always come up with excuses like "you should've X, Y, Z", well no, I don't care about crappy workarounds that may work or not.

      I don't even give a shit at this point what you say about this, I know you'll say it's wrong and bla. I don't care, because I linked you before a video in which Linus said the exact same thing as I did.

      So I know it's not a problem with me but with you.
      Last edited by Weasel; 22 April 2019, 10:30 AM.

      Comment


      • #33
        Originally posted by Weasel View Post
        I'm not sure what your point is. If games ship with runtimes then they're not part of Wine (nor Windows). Games can use whatever they want. They could even ship an entire Linux distro if they want to.
        Games need to ship Microsoft runtimes if they use the Microsoft compiler because not all visual studio runtimes are installed. This is the libc. This is the Microsoft workflow its not a choice.

        Originally posted by Weasel View Post
        You can't ship with the freaking runtime when you need to specifically build for a given distro. This has happened to me in the past and you always come up with excuses like "you should've X, Y, Z", well no, I don't care about crappy workarounds that may work or not.
        Total bullshit. Linux native games built for steam and shipped by the steam store are built against the steam runtime sdk this alone is 2000+ examples of you are wrong as this are not built against any particular distribution.

        Next you have flatpak and its runtime this runtime is not altered for distributions. Yes it detects the distributions nvidia driver and installs the same version inside. This is using the min in distribution provide.

        Look at the Firefox and Xonotic build process for the binary tar.gz file that runs on any distribution. They have a very min Linux distributions with only ABI stable parts then bundle all the other dependencies in the runtime that ships with that version of firefox. We are talking a method here over 2 decades old for making single package that installs and work on 99 percent of all Linux distributions the remaining 1 percent you can ignore.

        Then you find different enterprise .run files that create a chroot file and put a complete run-time in their with their application and this predates Linux existence first appear on unix back in the 1980s.

        There has never really been a need to build for a Linux Distribution. Why because Linux kernel to userspace ABI is stable and X11 protocol is stable and wayland is also a stable protocol.

        Weasel like it not if you say you have specifically build for a given distribution says you have not due the research on how to cross distribution package on Linux. You have taken the lazy way out and used the run-time and compiler the distribution provides pre-configured the reality doing a cross distribution binary build you cannot do this. This is not new building binaries to run on multi versions of Solaris in the 1890s you had to-do the same things.

        Thing to remember flatpak and steam runtimes are built from the ground up to be distribution neutral.

        Basically Weasel you cannot keep this bullshit up any more that you have to specifically build for a given distrobution when steam is a house hold name and flatpak is getting there that both are distribution neutral.

        Of course it was never true that you had to build specifically give a given distribution just you did not get built and configured distribution neutral runtime/sdk history so as a developer you had to create your own custom compact distribution neutral run-time and then ship your application with bundled run-time this is what mozilla/netscape developers have done for over 2 decades now so there is no question that it works. Yes flatpak and steam runtime both provide developers with out the box configured SDK and Run-times that are distribution neutral.

        Comment


        • #34
          Here is a critical fact. Proton under steam only works because of the steam runtime. This fact is why Proton can use newer libraries that a lot of distributions ship.

          Another interesting fact.
          A runtime environment for Steam applications. Contribute to ValveSoftware/steam-runtime development by creating an account on GitHub.

          You can use the steam runtime and valve built binaries of the steam runtime without having you application shipped by steam.

          Yes the steam runtime is the old chroot solution prebuilt so as a developer you don't have to make your own.

          The different cross distribution solutions.

          1) Chroot method. This is steam this method is older than Linux itself first appears on Unix systems for support multi versions with 1 binary package. This is a over 40 year old method. Valve is not doing anything new with the steam runtime most of the time it just obeying the rules so they chroot method works.

          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.

          3) Newer container solutions. Flatpak is the newer container solutions these are really descendants from the chroot method .

          All 3 methods theses days have SDK with documentation developers can download and build their application using. Does not matter what one of the 3 methods you choose you can support over 99 percent of all Linux distributions for at least 10 years. There are early enterprise chroot stuff for Linux that are from 1993 that work on current day distributions.

          Do note all there working method SDK provide their own compilers so you don't use random distribution compilers.

          Chroot/container methods are depending on that fact the Linux kernel syscalls are stable. That it takes over 10 years to remove a syscall from the Linux kernel so you have basically 10+ years notice when a syscall is deprecated. They are also depending on the fact the core X11 standard as been solid and wayland following will be as well.

          Tightly controlled build environments are depending on the fact that the Linux user space library ABI is not that unstable. Yes you do have to be highly selective.

          As Weasel said I have pointed him at solutions related to these many times. Of course Weasel goes stick his head back in the sand and see stuff built with the distribution provided run-times that then break and says see Linux has a problem. This is the developer having problem because they have not read the terms of usage of the runtime. Developers have been caught on windows with CUDA updates by Nvidia as well using sections of it that Nvidia said they would change in future. When you use a SDK you need to read the terms of use very careful like how long that SDK is going to be usable this is not a Linux unique thing. So developers screw-up their Linux ports their windows applications could also fail due to not reading SDK terms..

          Like it or not there have been a working solution for shipping binaries on multi Linux Distributions as long as Linux Distributions have existed and before wine was even a concept. We have had a problem those making closed source third party binaries not using those solutions for a long time.

          Comment


          • #35
            Originally posted by oiaohm View Post
            Games need to ship Microsoft runtimes if they use the Microsoft compiler because not all visual studio runtimes are installed. This is the libc. This is the Microsoft workflow its not a choice.
            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".

            Originally posted by oiaohm View Post
            Total bullshit. Linux native games built for steam and shipped by the steam store are built against the steam runtime sdk this alone is 2000+ examples of you are wrong as this are not built against any particular distribution.
            If the steam runtime is anything more than libc then your point is invalid.

            I don't care if it's installed by default or not. What I care about is that you don't supply the entire fucking distro as a "runtime" but only what you are missing. If you install the entire distro and chroot then it proves how unstable it is, WTF is your point even?!?? That's like static linking.


            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.
            Last edited by Weasel; 23 April 2019, 11:31 AM.

            Comment


            • #36
              Originally posted by Weasel View Post
              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.

              Originally posted by Weasel View Post
              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.

              Originally posted by Weasel View Post
              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.
              Last edited by oiaohm; 23 April 2019, 01:00 PM.

              Comment


              • #37
                Originally posted by oiaohm View Post
                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?

                Originally posted by oiaohm View Post
                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:
                Originally posted by Weasel View Post
                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.

                Comment


                • #38
                  Originally posted by Weasel View Post
                  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.

                  Originally posted by Weasel View Post
                  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.

                  Originally posted by Weasel View Post
                  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.

                  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.

                  Comment


                  • #39
                    Originally posted by oiaohm View Post
                    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.)

                    Comment


                    • #40
                      Originally posted by oiaohm View Post
                      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.

                      Originally posted by oiaohm View Post
                      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.

                      Comment

                      Working...
                      X