Wine Developers Appear Quite Apprehensive About Ubuntu's Plans To Drop 32-Bit Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • Chugworth
    Senior Member
    • Feb 2019
    • 389

    Originally posted by Weasel View Post
    You forgot monitor stands that cost $999. Yes, monitor stands. Let that sink in.
    Hey, if you paid $5000 for a monitor, would you want to put it on a $20 plastic stand that might crack and drop it?

    Comment

    • oiaohm
      Senior Member
      • Mar 2017
      • 8401

      Originally posted by Nocifer View Post
      If this is true, if WINE can make it so that every piece of Windows x86 code can be used as is with only x64 libraries, then this changes things completely. But can this really be done?


      This above is the prototype doing it using qemu. Yes the host in this case only has 64 bit wine and 32 bit windows application is run inside hangover running in 64 bit wine. The 32bit thunking libraries can basically all be built using mingw32 so windows compiler. So you only need a 64 bit host complier and a 32 and 64 bit mingw cross compilers that can be themselves built in 64 bit.

      Anything non game or old game not needing super large performance can be made work by qemu route now as long as all the parts it need thunked are done in hangover. Since hangover was made for arm64 platforms qemu was made built in. kvm instead of qemu jit drops overhead a lot.

      Basically due to the part working example with hangover all that is missing to make all Windows x86 code use host x64 libraries is the resources and time to complete complete hangover and optimise it. Optimise it being remove qemu usage on x86 platforms. kvm on x86 overhead is quite lite.

      Hangover improves things for those using arm64, power, risc-v as well needing windows applications.

      Hangover part working example does not depend on the Linux kernel itself having 32 bit syscalls it works on the worst case where someone has built the complete distribution 64 bit only being kernel and userspace. 32bit distribution support is not need for wine if enough resources are put into getting hangover functional and performing.

      Basically I am not taking a untested in theory route for the wine project. The hangover route is tested. The hangover route need a lot more developer resources to complete quickly and to optimise it back on x86 platforms.

      Comment

      • JPFSanders
        Senior Member
        • May 2016
        • 420

        It seems that Canonical is back at what it does best, which is shooting themselves in the foot, each of them.

        Removing multilib is not a mistake, it is "The mistake". This will make them lose about half the user base at the very least, including plenty of corporate users.

        It amuses me that just when gaming gets big on Linux, just when it starts shining and getting competitive with MS, just then Canonical decides on doing this retarded move.

        (Facepalm)

        Comment

        • pal666
          Senior Member
          • Apr 2013
          • 9177

          it's not wine project's job to provide packages for xyz distro. it's distro's job, so i can't understand why wine even cares. or maybe it's commercial wine packages by codeweavers? even codeweavers should just provide flatpak

          Comment

          • oiaohm
            Senior Member
            • Mar 2017
            • 8401

            Originally posted by Weasel View Post
            Drivers are either services or part of the kernel. None of which are in the address space of the process. There's no problem here unlike libraries. Callbacks are the biggest offenders anyway.

            Hangover is slow as hell for a reason.
            Yes Hangover is slow as hell for a reason. Its not optimised to use kvm to run x86 code as that does not work on arm64 so you take the big slog on performance from qemu jit.

            Most of the parts that access the host in wine would in fact under windows be in the kernel/services of windows anyhow. Please note Hangover does not hook though all functions of libraries. The functions in libraries that can run without calling out to host run in the parts that were built by 32 bit mingw cross complier. Large percentage of wine will in fact built for windows/reactos using a normal mingw32/msvc complier for 32/64 bit. Selectively thunking though the functions that need host and functions that can just run using what is contained in the wine source tree is what makes doing hangover a lot of work.

            Basically Weasel hangover shows that it can be done. Its not well optimised for x86 it using qemu jit that hurt performance a lot.

            Comment

            • pal666
              Senior Member
              • Apr 2013
              • 9177

              Originally posted by birdie View Post
              Your the cancer of open source.
              your mistaken. closed source does such things much more often than open source

              Comment

              • duby229
                Senior Member
                • Nov 2007
                • 7779

                Originally posted by xfcemint View Post

                Ok, you are probably right there, as far as I can see. The problem is that this 'long term' is about 20 years long in my opinion.

                I mean, in order for this to happen you need replacement apps for most 32-bit applications, and they have to be good and stable. You just can't run productivity apps on an emulator, it's awfull.

                Then the only thing left might boil down to games, demos and artistic creations which have a historical value, and all those can use an emulator. I mean, I'm pretty sure that an accounting app has almost no historical value.

                Of course, using an emulator for the games now solves nothing, but in the 20 years when OS platform changes sufficiently, an emulator will be required.

                So there has to be a replacement app for every currently usefull 32-bit app. I estimate 20 years needed for that.
                Also, need to wait for many years for games to transition to 64-bit. Well, in 20 years it will likely be so.
                That's not true at all. Look at all the POS apps and suites. People aren't gonna wait 20 years to run their point of sale....

                Comment

                • schmidtbag
                  Senior Member
                  • Dec 2010
                  • 6614

                  Originally posted by duby229 View Post
                  I don't have no problem with binary apps targeting a separately distributed runtime environment that is kept up to date and maintained, but distributing their own libraries is -always- a mistake. Every -single- time. It's -always- binary apps that distribute their own libraries that break. Usually because the libraries they create are compiled against an old glibc. If glibc had a stable user facing interface, it wouldn't be a problem, but it doesn't and never has and everybody already knows this. As an app developer distributing your own libraries absolutely guarantees that when the glibc you compiled against gets old your app -WILL- break.
                  In my experience it's been the exact opposite. If you mix'n'match the pre-packaged libraries with your distro's libraries, you're more likely to have a bad time. You typically have to commit to one set or the other. Most of the time, the pre-packaged libraries were tested and known to work with the application, so, there's no reason at all why it would fail unless the user starts to meddle with it.

                  Keep in mind, the older the application is, the harder it is to get it working with your distro's libraries. I've had a lot of struggles getting 10+ year old games working that didn't supply their full set of libraries, but ones that did come with everything worked just fine.
                  Last edited by schmidtbag; 21 June 2019, 09:51 AM.

                  Comment

                  • duby229
                    Senior Member
                    • Nov 2007
                    • 7779

                    Originally posted by schmidtbag View Post
                    In my experience it's been the exact opposite. If you mix'n'match the pre-packaged libraries with your distro's libraries, you're more likely to have a bad time. You typically have to commit to one set or the other. Most of the time, the pre-packaged libraries were tested and known to work with the application, so, there's no reason at all why it would fail unless the user starts to meddle with it.

                    Keep in mind, the older the application is, the harder it is to get it working with your distro's libraries. I've had a lot of struggles getting 10+ year old games working that didn't supply their full set of libraries, but ones that did come with everything worked just fine.
                    I'm -not- saying to mix and match libraries, that's retarded, I'm saying binary apps should target a maintained runtime environment. I find it hard to believe you got anything compiled against an old glibc to work.

                    Comment

                    • BwackNinja
                      Senior Member
                      • Jul 2012
                      • 144

                      Originally posted by the_scx View Post
                      Sorry, but essential libraries are provided by every sane platform. Linux is an exception here and has a problem with this.
                      Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite



                      See also:
                      Phoronix: Ubuntu 19.10 To Drop 32-bit x86 Packages Ubuntu and their downstream flavors all stopped shipping x86 32-bit images and now for the 19.10 cycle they have decided to stop their i386 support entirely. Beginning with Ubuntu 19.10, the archive/packages will not be built for x86 32-bit... http://www.phoronix.com/scan.php?

                      The pure minimum of what should be supported is a standard library (glibc) and an userspace GPU drivers (OpenGL, Vulkan, etc.).
                      We agree on the bare minimum -- let me quote myself here:
                      Originally posted by BwackNinja View Post
                      In addition, people should be thinking about where the boundary lies between the operating system and the application. Snap, FlatPak and AppImage all make this distinction a bit clearer, but both sides here need to re-examine that. Ubuntu should provide 32-bit glibc and graphics drivers (and perhaps libstdc++), while the wine devs should think of wine as the sum of the rest of its dependencies and be comfortable packaging it as such.
                      Past that, I don't agree with the list you referenced. Fontconfig, freetype, and associated dependencies are definitely system libraries. We already agreed on mesa, and I think anything else that's a device driver or otherwise acts as a layer between applications and devices should be considered a system library. What brings fontconfig and friends in is that, like drivers, they centralize configuration and mediate a shared resource -- in this case, fonts.

                      Linux doesn't have the expansive standard api that windows does. Beyond POSIX (and whatever GNU extensions, assuming you're running a GNU/Linux system), you're not really guaranteed much. I wouldn't even claim that Ubuntu has a standard api to program against. The rest of the libraries you mention are merely common; they are not necessarily libraries that should be provided by the operating system.

                      I'm slowly building a Linux distro as a hobby, and I'm exploring this distinction between the operating system and the applications running on top of it. I ran a Linux from Scratch install for several years, and the worst part is trying to update applications -- dependencies need to be updated to new abi-incompatible versions, which breaks other unrelated applications. From my perspective, decoupling applications from one another is essential for any semblance of sanity.

                      Comment

                      Working...
                      X