Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Wine Ubuntu Linux Technology

Wine Developers Concerned With Ubuntu Dropping 32-bit Support With Ubuntu 19.10 (linuxuprising.com) 209

An anonymous reader shares a report: The news that Ubuntu will drop support for the 32-bit x86 architecture was discussed recently by the Wine developers, on the Wine-devel mailing list. The Wine developers are concerned with this news because many 64-bit Windows applications still use a 32-bit installer, or some 32-bit components. "In practice, the only cases where 64-bit only wine will be useful are when 64-bit applications are packaged some other way (such as a .zip, Steam Play, or packaging specifically for Wine) or for running Wine builtins like msidb." Ubuntu's solution for using Wine on 32-bit going forward, which is to publish applications as snaps, or use an Ubuntu 18.04 LTS based LXD container that has full access to multiarch 32-bit WINE and related libraries, was also discussed by the Wine developers, with Vincent Povirk of CodeWeavers saying that there's no point putting much effort into this temporary solution. The maintainer of the Wine OBS repository also mentioned that he has no interest in maintaining so many libraries.
This discussion has been archived. No new comments can be posted.

Wine Developers Concerned With Ubuntu Dropping 32-bit Support With Ubuntu 19.10

Comments Filter:
  • by Anonymous Coward

    If this flows down to Mint, etc., start planning your migration.

    Glad I got out of Ubuntu when they tried to shove Unity down my throat.

    • Re: (Score:2, Informative)

      by Anonymous Coward
      Unfortunately this is the case. I work in embedded systems and have to use specific compilers/IDEs in the build tests. Those compilers/IDEs are 32-bit programs and to get them installed I have to add in the 32-bit stuff to my Linux build machines. They're running 18.04, but if I want to keep them up to date I'll have to migrate to another distro which still offers 32-bit support.

      I also model my embedded systems and conduct unit tests on the Linux build machines as part of my validation/test strategy. Th
      • by xvan ( 2935999 )
        Embedded 32 bits in X86? Haven't seen it. Embedded 32bits ARM support isn't dropped.
        • by caseih ( 160668 )

          I think the OP is referring to proprietary toolchains that support a variety of embedded systems these days. I'm sure these vendors could easily produce 64-bit binaries of their cross compilers, though.

          • by chrish ( 4714 )

            You've probably never worked with embedded systems.

            One of our clients is using a TI chip that requires a custom TI compiler, provided by TI. It doesn't even do C99. It sort of does "Embedded C++" but that standard died in 2002.

            Nobody's going to update this toolchain.

  • Just to clarify... (Score:5, Informative)

    by Anonymous Coward on Friday June 21, 2019 @09:12AM (#58798932)

    This isn't about dropping support for 32 bit kernel, and 32 bit packages, it's dropping support for any 32 bit compatibility libraries. Dropping the 32 bit install and kernel makes sense. Personally I don't have any 32 bit only computers anymore, and haven't for at least 10 years.

    Dropping support for 32 bit compatibility libraries is a little odd, especially since Debian, from which Ubuntu is derived is still supporting 32 bit.

    • by Anonymous Coward

      Then some other distribution will pick up the slack from Ubuntu.

      • by Anonymous Coward

        > pick up the slack from Ubuntu.

        I see what you did there. I think...

  • by The123king ( 2395060 ) on Friday June 21, 2019 @09:19AM (#58798960)
    Ubuntu drops 32bit Wine drops Ubuntu
  • The maintainer of the Wine OBS repository also mentioned that he has no interest in maintaining so many libraries.

    Right. So the OS devs should just support 32 bit and relieve you of the need to do it? What's wrong with virtualization/containerization of a 32-bit compatible release if you really really need a Windows XP era app to run under Wine?

    The user story that the Wine devs are wringing their hands over has to be a tiny and rapidly shrinking target. Most people I have known over the years that run setu

    • Re:So let's see... (Score:5, Informative)

      by Carewolf ( 581105 ) on Friday June 21, 2019 @09:25AM (#58798996) Homepage

      You could you know, read at least the summary.. Even modern Windows games released tomorrow and most applications still have 32bit installers.. So you need 32-bit support to run pretty much ALL windows application regardless of whether they otherwise have 64-bit binaries.

      Also It is easier for the distro to still build the 32bit packages. They also need them to still support steam, many of my gog games, and anything else ever distributed in binary form on Linux..

      Or you know they can SUCK

      Which we are warning them they will.

      • These companies had a decade to fix the problem. Fuck em if they can't get with the times.

        • Re:So let's see... (Score:4, Interesting)

          by Carewolf ( 581105 ) on Friday June 21, 2019 @12:25PM (#58800186) Homepage

          These companies had a decade to fix the problem. Fuck em if they can't get with the times.

          What companies, what problem?? The only problem here is Ubuntu breaking support for existing binaries.. Binaries, being binary are not somthing that magically changes, no matter how much you believe in magically fairies fixing things.

          • A decade to find a 64 bit installer executable. Most of those installers are sold by third parties anyhow.

            • And the problem is where? The driver is where? Up until today there hasn't been the slightest talk of any OS dropping support for executing 32bit binaries. Up until *today* there hasn't been a problem that needed solving.

            • A decade to find a 64 bit installer executable. Most of those installers are sold by third parties anyhow.

              That would at most fix it for new games... What about stuff we already own?

            • by fgouget ( 925644 )

              A decade to find a 64 bit installer executable. Most of those installers are sold by third parties anyhow.

              And why would they do that? Where did you see that Microsoft is planning to drop 32 bit support in Windows?

        • These companies had a decade to fix the problem. Fuck em if they can't get with the times.

          Some of these companies are gone and they're not fixing anything, but we still want to run the binaries. It's not a Linux problem, it's an Ubuntu problem, and if they want to be a problem then the easiest way to solve the problem is to use a different Debian derivative.

    • Comment removed (Score:4, Insightful)

      by account_deleted ( 4530225 ) on Friday June 21, 2019 @10:17AM (#58799278)
      Comment removed based on user account deletion
      • Re:So let's see... (Score:4, Informative)

        by dissy ( 172727 ) on Friday June 21, 2019 @11:10AM (#58799648)

        On a different note, a question for Slashdot, not you necessarily (seeing as I don't think you read the summary), how practical would it be for Wine to statically link the 32 bit GNU/Linux libraries it needs for 32 bit components of the system, or are there too many executables in the 32 bit Wine chain for that to work?

        The main issue with that is the task would fall on the distros package maintainer to do.
        The same maintainers that have no interest in keeping the 32 bit library packages in the first place.

        If they did nothing, no exerting effort, so far as leaving the library packages for wine to use, there wouldn't be a problem.
        They are exerting effort to go about removing those libraries so they aren't available.

        I would take that as a sign they would also not want to statically include them either, since they would still "exist" which is counter to their goals.

        Even if they did, we all know why it's not a great idea to do. You end up with a bunch of library versions you can't easily upgrade, exposed to windows executables :P

        I also learned something recently that's related somewhat.
        A statically compiled executable built on a 32 bit system, will run fine on a pure 64 bit system, so long as that 64 bit kernel has the CONFIG_IA32_EMULATION option enabled.
        I don't know if Ubuntu plans to do that or not with their stock kernel moving forward.

        Now that said, the libs I used were really simple ones: libc, libz, and libm
        I have no idea how that will fall apart once you start using more complex things with their own dependencies.
        Wine sounds to me like it would go quite deep down that rabbit hole.
        Would the X11 libs need statically linked too? That sounds utterly terrifying!

      • Last time I checked Wine cannot be linked statically.

        You cannot statically link NVIDIA Open GL libraries.

        You don't want to statically build anything at all, 'cause it will be a nightmare to maintain, distribute and update.

    • Re:So let's see... (Score:5, Insightful)

      by Rob Y. ( 110975 ) on Friday June 21, 2019 @10:18AM (#58799282)

      As long as Windows continues to support 32-bit apps, WINE needs to support them. It's not trivial to port WIN32 code to WIN64 (perhaps not that hard, but not trivial), and chicken-and-egg considerations mean a lot of code isn't going to get ported until Microsoft drops 32-bit support. So why should Ubuntu drop it arbitrarily when the market still needs it? That doesn't mean the 32-bit libraries need to be installed by default (they aren't now). But continuing to maintain them doesn't hurt - the hard work of dealing with multiple sets of libraries has already been done. Seriously, this reeks of a Jobs-like 'we're so great, we can force you to upgrade stuff you didn't think you needed to' hubris. Ubuntu is no Apple - it doesn't have a dedicated fan base with no alternatives. Get over it.

      And Snap is a lousy solution. I don't know why Canonical continues to stress it. Snaps add bogus filesystems to your system - for what? Sure, it makes it easy for 3rd parties to support multiple distros. But for open source code that can be built by the distros and included in their repositories, recommending Snaps is idiotic. Ubuntu already has a bunch of packages available in both formats - which is both confusing and counterproductive.

      Ironically, WINE has helped make WIN32 the most portable binary format around. Sure, it's a stopgap for most Ubuntu users, but as far as checking the 'you can continue to use that odd Windows-only app you rely on' box, it's vital. Canonical could do a lot worse than to contribute to the efforts of the WINE developers and work to make WIN32 apps integrate even better into the Ubuntu desktop. I use a few, and they work pretty well. Only issues are minor ones with fonts, occasional problems with Alt-Tab leaving WINE thinking the Alt key is stuck on, and of course themeing support, which is still pretty dreadful. But if you need the app, you need the app...

      • Sure, it makes it easy for 3rd parties to support multiple distros. But for open source code that can be built by the distros and included in their repositories, recommending Snaps is idiotic.

        So it makes it easier for 3rd parties to support multiple distros but it would be idiotic to do so?

        Snap wasn't created in a vacuum, and also wasn't the only container created for that matter. It solved a very real distribution problem that exists in Linux, not the least of which is problems with the maintainer managed, developer bypassed distribution model.

        • by Rob Y. ( 110975 )

          I said it's fine for 3rd party apps. It's the open source stuff that Canonical provides in its native repos as well as in snaps that makes no sense to me. Snaps are a clumsy way to get around the need to compile natively for a specific distro - but if the distro is already compiling an app natively, then surely that's preferrable to using a snap-distributed version, no?

  • by xack ( 5304745 ) on Friday June 21, 2019 @09:28AM (#58799012)
    Because open source only wants to work on shiny things and not the long term support that Windows and yes Internet Explorer provides. And it can do it with high prices and telemetry. Microsoft will continue to support their legacy 32bit customers for years to come.
    • by Anonymous Coward

      Because Linux works on much older and more varied hardware, with those variations being actively maintained and supported. There are also LTS variants of Linux.

      On the other hand Windows has changed driver models dropping support for tons of hardware multiple times, they dropped Win16 support, DOS support is horrible under Windows, we use tons of third party tools and shims to get old programs and games to work...

      What was your point again?

      • by tlhIngan ( 30335 )

        On the other hand Windows has changed driver models dropping support for tons of hardware multiple times, they dropped Win16 support, DOS support is horrible under Windows, we use tons of third party tools and shims to get old programs and games to work...

        Win16 works just fine - on Windows 10 it loads up NTVDM and runs under that. Of course, it only works on the 32-bit version of Windows 10, because of the way x64 works. When you run in x86 mode, you can run in 16 or 32 bit mode (x86 was always a 16-bit pro

    • Four words (Score:5, Insightful)

      by rsilvergun ( 571051 ) on Friday June 21, 2019 @11:12AM (#58799656)
      Games for Windows Live. Oh, and let's not forget their music business. Or the Zune. Or Bob. Ok, let's forget Bob.

      Microsoft is there for you as long as your money spends. Currently they're killing IE and replacing it with Chrome because it's no longer worthwhile to dominate the browser market. There's more money in their own web apps then there is stopping other's from doing it.
  • 64 bit or bust.

    No need to hold the rest of the world back over their BS.

    • by caseih ( 160668 )

      Whose BS? No this wouldn't be holding back the rest of the world. And bust it could well be. This need to drag everyone kicking and screaming into the new, modern age (without a lot of tangible benefit), is a bit strange. As if 64-bit pure has some kind of magical properties.

      Wine is probably one of the most important Linux projects, in terms of making Linux useful to the mainstream user. The fact that Ubuntu is removing all 32-bit multi-arch packages from the distro is a real dilemma. There are plenty

      • As if 64-bit pure has some kind of magical properties.

        It doesn't, but it does have mundane properties which are beneficial, like not having to build or provide or support the 32-bit packages. On the other hand, I want to be able to run Wine without having to run a VM, so I find it objectionable. On the gripping hand, I already left Ubuntu, so this won't affect me.

    • Windows developers use 32-bit installers because they just work everywhere.

      Windows will continue to support 32-bit packages.

      If Ubuntu drops it then Windows developers aren't going to care. That's not their target market anyway. The only result is Linux users suffer.

    • 64 bit or bust.

      No need to hold the rest of the world back over their BS.

      How does shipping the existing 32 bit support hold anything back?

  • Genuine question - I don't know the answer. Can I run a 32bit OS image, on a 64bit-only supporting host OS, inside a VM?

    Question is arising for me on macOS, and seems like it might arise for me on Linux soon as well.
    • yes. I currently do it with a vmware workstation on a 64bit version of linux to run 32bit versions of windows xp.
      • by mccalli ( 323026 )
        Thanks. I'm going to need to virutalise a few things prior to the macOS upgrade - noticeably 32 bit music plugins on the Mac. I've also got a few 32bit Windows things kicking about. No need for a 32bit Linux here, but plenty of need for the guest OS.
  • wine developers needs to build wine capable of running 32 bit windows apps on wine that was built on a pure 64 bit Linux distro, i dont have any multi-lib libraries & compilers, this is a pure 64 bit linux distro, its the direction Linux is going, 32 bit has been dead a while, you cant even find a 32 bit PC anymore unless you dig up some old stock sitting in the back of a newegg's warehouse collecting dust or something like that, and then the janitor will be mad because newegg sold the old box he was us
    • by Anonymous Coward

      Why is this WINE's problem? WINE is just the most common issue for needing 32 bit compatibility. As an end user, of course I want 32 bit compatibility on my box. Every other distro doesn't seem to view this as a bugbear. Debian, which Ubuntu pulls from, doesn't have this problem. Fedora doesn't have this problem. This is an Ubuntu-specific issue.

    • by Rob Y. ( 110975 )

      The whole point is that 32 bit is decidedly not dead. Sure, nobody needs a 32-bit kernel, but as long as Linux wants to check the 'you can run those last few Windows apps you depend on' box (and, seriously, do you think Canonical can afford not to?), it needs WINE. I don't know if it's possilbe to build a 64 bit WINE capable of running Win32 binaries, but at least you seem to get that it's still necessary to support Win32 binaries somehow. So, given that, if Canonical wants to go 64-bit only, they ought

    • No, it is the goddamn distros problem. I have games I have bought for Linux, that are Linux native, but just happens to be 32bit. I expect them to run, why wouldn't they, x64 is fucking backwards compatible... A distro that breaks existing stuff for no fucking reason, can FUCK the FUCK off.

      • so the wine developers are that unable to innovate and develop a new wine package that can run 32 bit windows apps on a pure 64 bit linux? fuck wine, its an antiquated piece of shit that should have been left for dead 10 years ago, nobody buys 32 bit hardware anymore and supporting a multi-lib distro is far more work than what wine will ever do or even ever dream of doing, fuck wine
        • by caseih ( 160668 )

          It's far more complicated than just cranking out a 64-bit binary with GCC. Wine implements a 32-bit Windows EXE loader that implements the 32-bit kernel and win32 api layers. Wine essentially passes API calls through think translation layers to Linux equivalents. Again the kernel is not the problem. 32-bit Wine already runs on 64-bit distros just fine, because of the multi-arch 32-bit libraries that are shipped on those distros.

          Like I said before I would like to know more about the techical issues surro

          • It's far more complicated than just cranking out a 64-bit binary with GCC. Wine implements a 32-bit Windows EXE loader that implements the 32-bit kernel and win32 api layers. Wine essentially passes API calls through think translation layers to Linux equivalents. Again the kernel is not the problem. 32-bit Wine already runs on 64-bit distros just fine, because of the multi-arch 32-bit libraries that are shipped on those distros.

            Like I said before I would like to know more about the techical issues surrounding Wind loading and running 32-bit code on 64-bit environments. What are precise the obstacles to having Wine load and run 32-bit EXEs on a 64-bit clean system? Could the translation thunk dlls be made to link to 64-bit Linux shared libraries?

            I'm not likely to find the answer here. I will go check out the wine mailing list.

            No. The application is either in x86 or x64 mode. You can't switch between the modes when calling to libraries, and there is no point in translating when calling the kernel as it can understand both. Wine would need to write the all wine 32bit APIs without using any libaries, not even the C library, to be able to run on a distro refusing to provide i686 basic libraries.

  • by Anonymous Coward

    Red Hat did this with RH7, and it was a cluster fuck. If not for the community run repos (which RH now controlls too), they'd have even less marketshare then they do because there is a _lot_ that depends on 32 bit.

    It is of course an uphill battle you can't win with the kids running these projects no matter how hard you try. The idea for example that such applications are very real, mean nothing to them. Essentially they will deflect the arguments, calling them "legacy", or "insecure". I'm not talking

    • by rklrkl ( 554527 )

      If you're talking about RHEL 7 (and its free clone CentOS 7), then they dropped the 32-bit version of the OS, but for the 64-bit OS kept the 32-bit multilib packages to allow 32-bit binaries to run. I have 64-bit CentOS 7 installed and run the 32-bit Steam client fine, along with 32-bit Windows/Linux games under Steam. The Ubuntu change will be massively different because they will not include the 32-bit multilib packages.

      And that's not forgetting that RHEL is an enterprise distro where the number of users

  • It's interesting that application distribution on Linux keeps getting more Windows-like.

    Whether it's extracting an archive in /opt or one of those fancy "installer" systems like Snap or AppImage or even Docker images, the tendency of developers to ship all their required libraries and not rely on the libraries in the distribution's package manager is interesting. It's a bit like when Microsoft said that all of a program's libraries should be installed in "C:\Program Files" instead of dumped in "C:\WINDOWS"

  • Does this mean Wine now needs its own WOW64? Windows On Windows 64 is the mechanism of how 64-bit Windows runs 32-bit Windows programs.

  • Are there substantive differences between ia32 and ia64 ISA's such that a 32-bit "MOV A, B" can't work in 64-bit registers, even with zero-padding?

    I thought amd64 was mostly backwards-compatible with ISA, stack, and encodings. Somebody enlighten me on what's the big deal as I have been out of the assembly game for too long.

    I do know it's really annoying to have to pull in and update a huge amount of ia32 arch to run a couple of tiny Windows apps. I can't imaging how many TB of data Debian handles just for

  • Next step: Ubuntu drops IPv4 and HTTP.

It is not best to swap horses while crossing the river. -- Abraham Lincoln

Working...