Announcement

Collapse
No announcement yet.

Wine-Staging Will No Longer Be Putting Out New Releases

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

  • #21
    Originally posted by VikingGe View Post
    If you need Vulkan support, try wine-vulkan. It's much better than the rather hacky wine-staging implementation anyway.
    ESO works on staging with DXVK, but all I get from DXVK on wine-vulkan is "Unsupported DirectX version"...

    Comment


    • #22
      In my opinion the fact that staging ever existed is validation that Wine Team is missing a BIG opportunity to provide value to the community.

      In the same way that Magento Store and many other commercial products seperate their commercial products IMO there is space for 3 products.

      1. CrossOver Commercial

      2. Wine (For Mac, Linux, ReactOS, Android, etc...)

      3. Wine Community Edition or Wine Experimental (basically what Wine-Staging was)

      As I recall ,one of the big reasons staging existed at all was because wine developers refused to add in code that solely benefited the Linux platform. For example Gallium Nine doesn't benefit MacOS users of Wine or CrossOver Mac users. Another example in the same vein might be the GTK3 support.

      I could be wrong, but I think that wine devs need to take a step back and ask themselves "Why did this fork exist and why was it so popular? And what we can do to provide for our users a similar value."

      Comment


      • #23
        Originally posted by ElectricPrism View Post
        In my opinion the fact that staging ever existed is validation that Wine Team is missing a BIG opportunity to provide value to the community.

        In the same way that Magento Store and many other commercial products seperate their commercial products IMO there is space for 3 products.

        1. CrossOver Commercial

        2. Wine (For Mac, Linux, ReactOS, Android, etc...)

        3. Wine Community Edition or Wine Experimental (basically what Wine-Staging was)

        As I recall ,one of the big reasons staging existed at all was because wine developers refused to add in code that solely benefited the Linux platform. For example Gallium Nine doesn't benefit MacOS users of Wine or CrossOver Mac users. Another example in the same vein might be the GTK3 support.

        I could be wrong, but I think that wine devs need to take a step back and ask themselves "Why did this fork exist and why was it so popular? And what we can do to provide for our users a similar value."
        Agreed.

        They use "system integration" to justify various things I always turn off (like letting my Windows applications muck with my filetype associations and games fill my documents folder with crud that belongs in AppData even on Windows). I'd love to have something which bridges in Qt or GTK+ widget drawing (preferrably Qt but I suspect GTK+ would be chosen) as a Windows theming engine.

        Comment


        • #24
          Sad and glad to finally hear some news on staging. Now they can hand over the project or people can fork it to further experimental work.

          Originally posted by ElectricPrism View Post
          In my opinion the fact that staging ever existed is validation that Wine Team is missing a BIG opportunity to provide value to the community.
          ....
          I could be wrong, but I think that wine devs need to take a step back and ask themselves "Why did this fork exist and why was it so popular? And what we can do to provide for our users a similar value."
          I think it's fine the Wine Team itself focus only on cross platform. Things can get resource intensive and politically divisive when supporting separate platforms.
          With the line drawn there, it makes it more secure for commercial or community projects to focus on those extra features which the best of can later be fed upstream.

          Comment


          • #25
            Originally posted by leipero View Post
            While it is sad that maintainers do not have time to work on staging anymore, most people use wine-staging for CSMT support, and I've used it for nine support also. That being said, most distributions do patch wine anyway with some paches (Arch adds harmony-fix by default) and add optional support (Arch does silverlight and wine-binfmt by default for packages), so it's relatively easy to add patch for CSMT support (if it's needed in 3.x???) and make PPA for Ubuntu (since people would have to add wine PPA for staging anyway, at least last time I've tried Ubuntu).

            As I'm writing, wine 3.2 and nine is building in background, will see if it works, if no one makes AUR for it, I might as well upload it (tho it is pain in the a** to maintain it, that's why I would avoid it).
            I have an aur package simply for nine, no need to bundle it with wine anymore

            Comment


            • #26
              Originally posted by wpupkin View Post
              Ok, take nvapi, nvcuda, vulkan patches and DLL Redirects support into main tree and I'm fine with this.
              DllRedirects in staging is a rejected patch.

              https://wiki.winehq.org/Wine-Staging_DllRedirects
              The current implementation of DLL redirects does not store any information about loaded dlls which were redirected. This causes trouble if an application tries to manually load the target of a redirection while the same library is already loaded under a different name. Wine does not notice that the library was already loaded and tries to load it a second time. The behaviour of builtin/native DLLs is slightly different, but in both cases an application might be confused.

              So until someone fixes the known issue it will remain rejected. Using a WINEPREFIX per application with dll overrides works stable.

              https://wine-staging.com/news/2017-0...lease-2.8.html
              This is back in history please note the improved fake dlls. Wine has merged this mainline. DLL redirects patch depends on messing with the loader provide by the OS. But since windows has started mandating signing a lot of programs that take add dlls have added there own PE Loader so the add on do not have to be signed.

              So this means dll redirects need to be complete rewritten to sit behind the fake dlls most likely required the redirected dll to be a dll.so or another form of dll outside the WINEPREFIX where the application is not normally going to find it. When someone rewrites the patch in a functional then you can have that feature..

              nvapi, nvcuda I do not know why they have not been ever submitted to wine devel.

              There is a wine-vulkan git out there. Please note its missing all the extra staging because the staging were breaking most of applications he was trying to test with.

              Comment


              • #27
                Originally posted by leipero View Post
                While it is sad that maintainers do not have time to work on staging anymore, most people use wine-staging for CSMT support, and I've used it for nine support also. That being said, most distributions do patch wine anyway with some paches (Arch adds harmony-fix by default) and add optional support (Arch does silverlight and wine-binfmt by default for packages), so it's relatively easy to add patch for CSMT support (if it's needed in 3.x???) and make PPA for Ubuntu (since people would have to add wine PPA for staging anyway, at least last time I've tried Ubuntu).

                As I'm writing, wine 3.2 and nine is building in background, will see if it works, if no one makes AUR for it, I might as well upload it (tho it is pain in the a** to maintain it, that's why I would avoid it).
                CSMT patches are merged into wine 3.0. This is part of why there is less people to support staging as the developer who was working on CSMT is now back working on mainline and not needing staging any more.

                Originally posted by Dehir View Post
                Well its not bad having different experimental tree as staging. But if it dies away. Are the all "major" and important parts from it allready included in main tree like csmt etc?

                And whats the future of Gallium fork? I think it runs best all dx9 games atleast with my rx480.

                Thou in general i think this can be better for wine in general to ease things and try to focus everything on main branch
                Gallium Nine is rejected from mainline wine because its only direct x 9. When running a dx10,11 or 12 application by the Microsoft design its legal to call dx9.

                Unless the Gallium implementation adds more versions of direct x at some point it will just be more trouble than it worth. Yes a lot of people using Gallium nine try to run a more modern program complain that it don't work and we have test results in the appdb that it does and it all caused because Gallium nine does not support multi version direct X usage. Even some old dx7-dx8-dx9 hybrid applications also explode if you have gallium nine installed. The reality is Gallium nine is a broken patch set wine developers have attempted to tell them that only to get response we are only interested in dx 9.


                Originally posted by pinguinpc View Post
                Yeah wine devs stay more interesting in functions with tests (without tests many patches dont approved)

                However step by step wine begin add more staging patches but no in same way than staging
                Wine developers have not be anti adding stuff without function tests without history. All you have to-do is look at test.winehq.org and notice how often the same test case running on different versions of windows behave differently. So you can think you have implemented something its working for you application but but someone else runs a newer or older application made for newer or older windows than what your application was and your patch has now broken it.

                The demand on test casing is 1 to prevent regressions 2 to locate functions where Microsoft/Nvidia/AMD developers have been inconstant in implementation so you know when you are heading into hell. Its not like wine runs test.winehq.org using VM machines running windows running the test cases for no good reason.

                Comment


                • #28
                  Originally posted by geearf View Post

                  I have an aur package simply for nine, no need to bundle it with wine anymore
                  Yeah, I saw one, is it "wine-nine" package that relates to github.com/iXit/wine release? If it is so, I've got strange bug with that package in Split/Second, it takes quite a while to load the game, and when it does, it stutters more than usual (not that nine is useful for that game on my hardware anyway...), it must be some problem in ixit implementation if not my error (using WINEPREFIX=PREFIX ninewinecfg as suggested after building). It still deserves upvote tho, since it is not a packaging problem .

                  oiaohm
                  CSMT patches are merged into wine 3.0. This is part of why there is less people to support staging as the developer who was working on CSMT is now back working on mainline and not needing staging any more.
                  Yeah, i realized that after attempting to patch 3.2 version with CSMT and getting error for TRUE, /* Multithreaded CS by default. */, only to see it is already set, thinking "stupid me, I should have tried it first if it is enabled", after testing I saw it is enabled.

                  Comment


                  • #29
                    Maybe its time to fork Wine Staging, with black jack and hookers. I mean with Gallium Nine and DXVK. There was never a good reason not to include Gallium Nine in Wine.

                    Comment


                    • #30
                      Sigh! Things worked nicely with staging. Used it for over 2 years now. Always have problems with the rest.

                      Comment

                      Working...
                      X