Announcement

Collapse
No announcement yet.

Notes From WineConf 2018: x86 On ARM Progress, Wine-Staging Needs More Help

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

  • Notes From WineConf 2018: x86 On ARM Progress, Wine-Staging Needs More Help

    Phoronix: Notes From WineConf 2018: x86 On ARM Progress, Wine-Staging Needs More Help

    Taking place last week in The Hague, Netherlands, was the WineConf 2018 conference. This year's WineConf -- on top of the usual annual discussions about this open-source project for running Windows games/applications on Linux/macOS -- took the time to celebrate the project's 25th anniversary...

    http://www.phoronix.com/scan.php?pag...onf-2018-Notes

  • #2
    So, I guess, WINE stands for ‘Wine Is Now an Emulator’ now? ;-)

    Comment


    • #3
      Originally posted by Marcus Meissner
      Additional interesting is running 32bit x86 binaries on 64bit x86
      this year, using the same/similar methods.

      Required to be addressed as MacOS will stop supplying 32bit runtime
      environment and remove even 32bit compat mode from their kernel in 2019.
      lol it really confused me. In case anybody else is: the takeaway is that to run a 32bit app wine needs 32bit system libraries; but MacOS not gonna have 32bit libs anymore, so you have to invent a way for that work with 64 bit libs.

      Comment


      • #4
        "With macOS set to strip out 32-bit x86 support in 2019"

        Source?

        Comment


        • #5
          Originally posted by Hi-Angel View Post
          lol it really confused me. In case anybody else is: the takeaway is that to run a 32bit app wine needs 32bit system libraries; but MacOS not gonna have 32bit libs anymore, so you have to invent a way for that work with 64 bit libs.
          thats good to hear , having to install tons of lib32 packages just for wine to work is not nice

          Comment


          • #6
            Originally posted by davidbepo View Post

            thats good to hear , having to install tons of lib32 packages just for wine to work is not nice
            Given the solution being worked on in terms of QEMU, you'd get a performance hit. So for anything performance-demanding you still gotta install that bunch of 32-bit libs.

            Comment


            • #7
              Originally posted by Hi-Angel View Post
              Given the solution being worked on in terms of QEMU, you'd get a performance hit. So for anything performance-demanding you still gotta install that bunch of 32-bit libs.
              I understood from the email that they just translate the API (ABI) calls so that 32-bit programs can work with 64-bit libraries. Thus on x86 it's not needed to emulate the processor to run 32-bit software. There is some performance hit from the translation though. On ARM you of course have to emulate an x86 processor.

              While this is interesting, I wonder how much problems there will be. I imagine it is a quite hard thing to do.

              Comment


              • #8
                Is it possible for us normal users compile WINE to run x86 programs and games with a ARM CPU ?

                If so, where can i find the instructions ?

                With Linux FULLY supporting ARM and with M$ FORCING deprecation of all non-W10 variants (and even of x86 for x64) plus with W10 running on ARM with emu of x86, i can see NVIDIA soon to make via its AIBs a kinda of a relatively powerful & cheap ARM APU in Mini-ITX format with support for regular PC DIMMS, etc.

                Comment


                • #9
                  Originally posted by Hi-Angel View Post
                  Given the solution being worked on in terms of QEMU, you'd get a performance hit. So for anything performance-demanding you still gotta install that bunch of 32-bit libs.
                  oh, damn

                  Comment


                  • #10
                    Originally posted by Tomin View Post
                    I understood from the email that they just translate the API (ABI) calls so that 32-bit programs can work with 64-bit libraries. Thus on x86 it's not needed to emulate the processor to run 32-bit software. There is some performance hit from the translation though. On ARM you of course have to emulate an x86 processor.
                    Direct translation is not possible. What do you do when a function in a library API returns a pointer above the 32-bit address space? What do you translate that into?

                    You'd also have to translate all pointers to 64-bits since they're 32-bit, which will be quite a lot slower, since they will likely not "fit" into existing structs, requiring reallocation and copying around, and trashing the cache.

                    Comment

                    Working...
                    X