Announcement

Collapse
No announcement yet.

Kernel Patch Revved For Syscall User Redirection To Help Newer Windows Games On Wine

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

  • Kernel Patch Revved For Syscall User Redirection To Help Newer Windows Games On Wine

    Phoronix: Kernel Patch Revved For Syscall User Redirection To Help Newer Windows Games On Wine

    It looks like the syscall user redirection support could soon be mainlined to the kernel for this new Linux feature that was originally motivated by helping Windows games running on Wine...

    http://www.phoronix.com/scan.php?pag...Redirection-V4

  • #2
    This most likely wouldn't be needed if Wine had a proper implementation of a binary translation technology.

    https://en.wikipedia.org/wiki/Binary_translation

    Comment


    • #3
      Originally posted by atomsymbol View Post
      This most likely wouldn't be needed if Wine had a proper implementation of a binary translation technology.

      https://en.wikipedia.org/wiki/Binary_translation
      What do you mean by that? Wine doesn't need binary translation, it's designed to run windows binaries for the same architecture as the host OS. Even if it used some kind of binary translation, it wouldn't help at all because the issue is not with the binary but with the kernel's syscall ABI. In other words it's a kernel personality problem. So far Wine assumed that apps used the userland syscall wrapper API and so it didn't need kernel personality emulation, but now it needs it and this patch will bring it.

      Comment


      • #4
        Originally posted by atomsymbol View Post
        This most likely wouldn't be needed if Wine had a proper implementation of a binary translation technology.

        https://en.wikipedia.org/wiki/Binary_translation
        Someone missed the memo that Wine Is Not an Emulator
        The application is still x86 arch so what's the point of binary translation.

        Comment


        • #5
          Originally posted by atomsymbol View Post
          This most likely wouldn't be needed if Wine had a proper implementation of a binary translation technology.

          https://en.wikipedia.org/wiki/Binary_translation
          Applications wine run can contain nice anti-debugging/copy protection/anti-cheat... All that get really upset when they detect modification. Yes this fairly much rules out using static binary translation as some of these like anti-cheat can be downloading new binary code while running and expect to run quickly. This means using dynamic binary translation like qemu usermode yes this is not without it fair share of over head and performance overheat can trip the anti-cheat/copy protection and anti-debugging.

          Please note atomsymbol Microsoft does not recommend directly calling syscalls. The functions like _findclose that Microsoft says is syscalls if you use visual studio end up calling msvcrt of some form then syscalling. Of course since wine most replaces these libraries these syscalls does not happen. Yes wine is needing to trap syscalls because applications are doing direct syscalls that Microsoft does not recommend because Microsoft reserves the right to change the syscall function to number assignment at any time.

          Applications doing direct syscalls under windows are the items like Anti-cheat/copyprotection/anti-debugging that don't give a rats if their program works in future. Some don't care if they have a 5 percent failure on real Windows users. Rock very hard place atomsymbol like it or not.

          Now I other uses for this syscall stuff outside wine.

          Lets say you want to run a very old Linux binary that is using a syscall that has been removed from current kernel the work they are doing would allow a loader to be made that is performing like a preload over syscalls to put emulations of that old syscalls back.

          Lets say you were attempting to run android native applications using android only syscalls. Yes this would allow emulating these without having to emulate the complete lot.

          Funny enough this would allow running freebsd and other unix binaries with syscalls on Linux as well.

          Comment


          • #6
            I can't wait for this and fsync2 ! Given that Vulkan drivers and DXVK/VKD3D improve all the time, it won't be long till we could be playing almost everything at good performance.

            Comment


            • #7
              Originally posted by TemplarGR View Post
              I can't wait for this and fsync2 ! Given that Vulkan drivers and DXVK/VKD3D improve all the time, it won't be long till we could be playing almost everything at good performance.
              Its already there for me. Most of what I play already has good performance as-in its good enough. Anything else they get is a bonus. But, I haven't seen a performance issue that made me need Windows really for sometime now.

              My biggest problem is dx12 and Ray Tracing which is non-existent here, some games that don't work, and the work in progress wmf and other Windows media playback that is taking some time. After that, I might not need Windows at all for games. Probably looking at a few more years at least though or another 10 or more depending lol.
              Last edited by ix900; 07-17-2020, 10:51 AM.

              Comment


              • #8
                Originally posted by oiaohm View Post

                Applications wine run can contain nice anti-debugging/copy protection/anti-cheat... All that get really upset when they detect modification. Yes this fairly much rules out using static binary translation as some of these like anti-cheat can be downloading new binary code while running and expect to run quickly. This means using dynamic binary translation like qemu usermode yes this is not without it fair share of over head and performance overheat can trip the anti-cheat/copy protection and anti-debugging.

                Please note atomsymbol Microsoft does not recommend directly calling syscalls. The functions like _findclose that Microsoft says is syscalls if you use visual studio end up calling msvcrt of some form then syscalling. Of course since wine most replaces these libraries these syscalls does not happen. Yes wine is needing to trap syscalls because applications are doing direct syscalls that Microsoft does not recommend because Microsoft reserves the right to change the syscall function to number assignment at any time.

                Applications doing direct syscalls under windows are the items like Anti-cheat/copyprotection/anti-debugging that don't give a rats if their program works in future. Some don't care if they have a 5 percent failure on real Windows users. Rock very hard place atomsymbol like it or not.

                Now I other uses for this syscall stuff outside wine.

                Lets say you want to run a very old Linux binary that is using a syscall that has been removed from current kernel the work they are doing would allow a loader to be made that is performing like a preload over syscalls to put emulations of that old syscalls back.

                Lets say you were attempting to run android native applications using android only syscalls. Yes this would allow emulating these without having to emulate the complete lot.

                Funny enough this would allow running freebsd and other unix binaries with syscalls on Linux as well.
                Well, but binary translation is quite trivial to implement in the beginning: The translator parses assembly instructions in 4K pages which triggered a page fault and replaces original jump/call targets with its own jump/call targets. Just code needs to be translated, data is not being translated at all unless the application reads/writes from/to pages containing the translated code (such reads/write are unlikely because the translated code pages are being allocated at addresses making such conflicts improbable).

                I would like to see Wine running Windows x86-32 code in Linux x86-64 mode - maybe the extra CPU registers available in 64-bit mode can be used to speedup the x86-32 code by 2%.

                Comment


                • #9
                  Originally posted by ix900 View Post

                  Its already there for me. Most of what I play already has good performance as-in its good enough. Anything else they get is a bonus. But, I haven't seen a performance issue that made me need Windows really for sometime now.

                  My biggest problem is dx12 and Ray Tracing which is non-existent here, some games that don't work, and the work in progress wmf and other Windows media playback that is taking some time. After that, I might not need Windows at all for games. Probably looking at a few more years at least though or another 10 or more depending lol.
                  You must not be playing the most recent AAA games then. There is a big performance penalty in many games on WINE. I have missed Windows many times. I could play Skyrim SE on my machine MAXED at 60fps, yet i can only do the same on medium settings on WINE, and with issues with the audio. And that's just one example. Even Deux Ex Human revolution runs very bad.

                  Comment


                  • #10
                    Just curious... When will they implement virtualization facilities? (for VMProtect)

                    Comment

                    Working...
                    X