20 ms·
Wine Developers Concerned with Ubuntu Dropping 32-Bit Support
- xvilka 7y agoWell, the best solution would be to fix Wine for 64 bit platforms and applications. And use docker + wine for 32 bits ones.
- the_duke 7y agoThe very first paragraph in the article explains why this does not work... Unless you mean building a 32bit emulation layer into Wine itself.
- wtdata 7y agoI do use Wine (and Steam with it's various levels of Windows API calling), and I am happy about this. Sure, it will create some issues during the first stages of this migration, but, more than once, I botched my system in the past with the needed i386 libraries (it didn't happen lately, can't tell if because I finally got my head around it of because they improved the tooling). Still, in the end, we will all have a "cleaner" system. Either because they migrate parts of the Windows calling to 64bit or because they will keep everything neatly in containers, or, probably, due to a mix of both. But it's high time we improve the current state of these tools. P.S.: Still trying to get WINASIO to work properly with Wine using one of the latest versions (I am trying to run Ableton in Wine, but the latency is just too high). If anyone has experience doing this, any tips would be apreciated.
- holy_city 7y agoI think even if you got the drivers working you'd have too much latency. You need the PREEMPT_RT kernel patch to get reliably low latency. You can also try Bitwig, it has native Ubuntu support and most feature parity with Ableton.
- wtdata 7y agoI tried the preemptive kernel and didn't make a difference. I also tried Bitwig and it's great, but I use a Push I. That creates an issue (Bitwig support for Push fails in 2 major points: note repeat, and delete functionality... and they keep making changes without adding something as simple as that to the devices API).
- james-mcelwain 7y agoI'm so happy that Bitwig is supporting Linux as a first class platform, but it's still unstable enough on Linux that I would never consider using Bitwig on Linux for, e.g., a live performance. I'm sure they consider crashes on Linux real bugs, so hopefully it's just a few more years of work to have a rock solid DAW on Linux. Super excited about the future of Bitwig.
- postit 7y agoIn the current state of technology, wine doesn’t make sense anymore. 20-ish years ago was impossible to have an interchangeable application between two OS, without a huge effort on porting and adaptations trade off. Now we have the web applications running in a handful of different systems. We’re also watching the people theorizing supporting webassembly binaries directly in the kernel. If you don’t want to run a webapp you have virtualization to rescue you. My last straw with Wine was when I bought navicat for Linux and they shipped a wine wrapped windows app. Really, some tech should just retire.
- tombert 7y agoFirst off, there are plenty of older Windows applications that currently exist that aren't going to get a port to a modern web app any time soon that work perfectly fine with Wine; even Microsoft doesn't support running Windows 3.1 programs anymore. You could argue that nothing from that era is worth preserving, but are you saying that applications like DOSBox, Snes9X, or UAE aren't useful? Second, while I definitely support the push to web technology, I'd still rather have something on Linux or Mac than nothing, and often times Wine is the only realistic way of doing that. I agree it's a little annoying when you buy a "Linux" app, and it's just a wine wrapper, but at the same time, at least it's officially supported and works. I didn't get upset with SEGA when I bought the Sega Genesis collection and it used emulation instead of native ports.
- jostmey 7y agoDoes the Microsoft Office executable file even come in a 64bit package? It's not Ubuntu's or Wine's fault
- MikusR 7y agoOffice has been 64bit for 9 years. And this year it's the default.
- coldpie 7y agoAlmost all Windows installers are 32-bit, even if the application installed is 64-bit. This is so the installer can do something elegant when run on a 32-bit-only system. While this might be changing, 32-bit support is effectively required for almost every Windows application ever released.
- whatshisface 7y agoI use Ubuntu, but should I switch to Debian or something else? What do I get with Ubuntu that I don't get with Debian? The ability to run Windows binaries is important to me.
- momokoko 7y agoThe biggest difference is probably the desktop UI. After that Ubuntu has a bit more of a unified experience. Part of that is because Ubuntu tends to make a lot more decisions for you, whereas Debian gives you more options upfront. There is a nice integrated GUI(I know Debian has one but its less integrated) for installing packages. Online resources tend to discuss Ubuntu specifically due to its larger market share on the desktop. There is the Ubuntu PPA(Personal Packaged Archives) which don't always work easily in Debian. They are both fairly similar internally. I have been a long term Debian user(decades), and I never feel out of place working with Ubuntu. That is not always the case when I'm working with Red Hat or Arch or some other distributions. Debian probably requires a bit more fiddling and a bit more general Linux and computing knowledge, but if you have been using Linux for a bit, I think you would be just fine.
- momokoko 7y agoI'm curious about Wine's usage and relevance at this point in the Linux desktop story. My assumption is that Linux users(myself included) that use Windows applications(not games), tend to just run a VM in seamless mode for Windows functionality. I would be curious if others had any insight(anecdotal or otherwise) about Wine usage these days.
- mushufasa 7y agomany of the applications for which you would want to run wine (e.g. gaming, the primary use) are performance-heavy. adding a layer of a vm is substantially more performance overhead.
- mchristen 7y agoThat doesn't have to be true with hardware passthrough.
- deleted 7y ago[deleted]
- junaru 7y agoYou still run Windows in VM. Some people switched to Linux to get away from that.
- implr 7y agoThat is much more difficult, might require various unsupported hacks and for a truly robust solution you'd need two GPUs. For games having a Vulkan or DX12 (via DXVK) renderer, wine can be as fast as native Windows with almost none of the hassle. DOOM(2016) is a very good example.
- Shorel 7y agoMany games ban the players for using that setup. Examples: Rust, Rainbow Six Siege, DayZ. All the games using BattlEye can be banned. On the other hand LoL handles GPU passthrough well.
- 7y ago
- richard_todd 7y agoI immediately wondered about macOS, which is dropping 32-bit support as well. One of the first links I found[1] seems to say that there is no 64-bit wine on macOS regardless of library issues, due to an ABI incompatibility. So on the surface it seems like the world is shifting under wine's feet, and they are going to need to do a second level of emulation eventually to keep 32-bit stuff running. [1]: https://forum.winehq.org/viewtopic.php?f=9&t=23005 https://forum.winehq.org/viewtopic.php?f=9&t=23005
- philistine 7y agoThat's big news. It looks like if Wine is forced to emulate the CPU, the few benefits it has over a VM would be negated.
- sigstoat 7y agoone benefit that would never go away is not needing a license/copy/installation of windows.
- kitsunesoba 7y agoCould this be as “simple” (I am aware significant work would be required) as bolting qemu onto the backend of WINE? It’s also becoming more common for OS vendors to ship virtualization toolkits (Hypervisor.framework for instance), could those be an option?
- coldpie 7y agoThe change Ubuntu is proposing is far less harsh than what macOS is doing. Unlike macOS, Ubuntu will still run 32-bit processes, you just have to provide all of the userspace libraries. Applications like Steam for Linux already do this for binary compatibility reasons, so their usecase won't change much. Wine's official Ubuntu packages currently rely on the OS to provide these userspace libraries. They would "only" need to change to also build and ship the rest of the libraries, instead of relying on the OS to provide them. Meanwhile on macOS, you can't even run 32-bit binaries, working around that is a much, much larger task.
- deleted 7y ago[deleted]
- EamonnMR 7y agoWINE needs 32 bit support. The bulk of windows programs that people still care about are from the 32 bit era, and as they point out many 64 bit apps use 32 bit installers. Maybe it's time for x86 box like DOSbox.
- 0815test 7y ago> Maybe it's time for x86 box like DOSbox ...or Virtualbox.
- oarsinsync 7y agoYou're suggesting an emulator, which is absolutely correct and a worthwhile reminder that we can emulate 32bit without any problem. It's also worth considering the context, WINE (WINE Is Not an Emulator) provides an abstraction layer that doesn't require the overhead of an emulation layer. DOSbox is similar. (EDIT: apparently it's not, and is actually an emulator. TIL.)
- EamonnMR 7y agoOr the overhead of running an entire other OS.
- Narishma 7y agoDOSBox is an emulator.
- cwyers 7y agoWhich is one of its big selling points - old DOS games were used to direct hardware access. Some of them even depend on the clock rate of the PC they're running on. So an emulator that can convert Roland and Soundblaster to modern sound and such is necessary for making old DOS games playable.
- AnIdiotOnTheNet 7y agoWhat's interesting about this is... doesn't WINE also support Win16 applications? My understanding was that it does, yet it doesn't seem to require 16 bit libraries from the host OS...
- bstar77 7y agoCan't you still setup a 32bit chroot in 64bit Ubuntu (or any other distro for that matter)?
- chrisseaton 7y agoBut the 32 bit code physically won't be part of the distribution. What do you imagine you'd be running?
- yjftsjthsd-h 7y ago32-bit Debian chroot on 64-bit Ubuntu? Works, mostly conforms to user expectations, seems decent?
- chrisseaton 7y agoWell yes if you're going to run another distro that's fine. This issue is about that people can't run new Ubuntu. You can't run new Ubuntu in 32-bit.
- zapzupnz 7y agoSo presumably they'd run old-Ubuntu 32-bit chroot in new-Ubuntu.
- bstar77 7y agoI figured there would be a 3rd party repo that provides the required packages for Wine.
- chrisseaton 7y agoThere could be. This article is just about how Ubuntu isn't going to provide that code any more. But it's all the system libraries, not just Wine.
- ketsa 7y agoDebian will keep 32 bit support for a while... No problem here.
- devit 7y agoI think you can just use 32-bit libraries from Debian for the most part (I assume Debian is going to maintain i386 forever).
- yjftsjthsd-h 7y agoI would be concerned about the stability of mixing distros like that, even within a family. If nothing else, those packages are built against different versions of libraries.
- AnIdiotOnTheNet 7y agoWhich is one of the many reasons I think package managers are awful. If we lived in a sane world this sort of thing would be a simple matter for any and all distros. In fact, you wouldn't even need distros because you could trivially mix and match the software you wanted without concern for this garbage.
- dooglius 7y agoPresumably, the kernel will continue to support 32-bit, it's just that Ubuntu won't package various 32-bit libraries anymore. But, can't Wine just bundle any library dependencies itself?
- olliej 7y agoBut why not just do a translation — 32bit x86 to 64bit x86 doesn’t meaningfully restrict available instructions, then just* plant a bunch trampolines in the low 4gig to the real implementations in the 64bit adds space. * I know this isn’t a trivial “just” but it seems like a plausibly achievable approach to me
- yjftsjthsd-h 7y agoI wonder if it'd be easier to use qemu's binary compatibility features? Granted, I've only seen that used in Linux, but it's an existing layer that supports running code for another processor as if it were native.
- makomk 7y agoThat qemu mode requires a full set of libraries compiled for the processor the code you want to run executes on, so it doesn't help here - if you've got that you can just use the Linux kernel's built-in 32 bit compatibility layer which isn't going away any time soon and get better performance.
- deleted 7y ago[deleted]
- AgentME 7y ago32-bit binaries have a different ABI. I think you could put 32-bit code in a 64-bit process and have it use the 32-bit API, but then you still need a set of libraries that work with the 32-bit ABI. Ubuntu is just discontinuing packaging their own copies of the 32-bit ABI compatible libraries. Projects like Wine will just need to distribute that on their own.
- olliej 7y agoYou have the trampolines be responsible for abi translation - that’s what the old OS X ppc emulator did, or I assume the windows arm layer does
- trollied 7y agoI have a sneaking suspicion that Microsoft will release their own Wine-a-like subsystem some time soon. It's the missing link, and I can't see them ignoring it given how their direction has changed over the last few years.
- RussianCow 7y agoI doubt that's the case. Everything they've been doing with WSL is precisely to keep you inside the Windows OS. It doesn't make sense to go the other way and give you a reason to use Linux instead.
- dragonwriter 7y ago> It doesn't make sense to go the other way and give you a reason to use Linux instead. It makes sense for every business unit except Windows to make it easier to run their software on Linux/MacOS (for desktop software, more the latter, for server software, more the former.) A common shim that lets you so that with the same codebase rather than maintaining separate Linux and MacOS versions or porting the whole existsling software to a cross-platform base rather than a Windows base makes some sense. Of course it doesn't make sense for the Windows unit to promote Linux, but Windows isn't all of Microsoft.
- RussianCow 7y agoI could be wrong, but I think the overlap of people who use Linux but would also pay for Microsoft software like Office is small enough to not justify the engineering effort.
- dralley 7y agoThat was what WSL v1 was, literally. WSL v2 is an actual linux kernel. They're moving in the opposite direction.
- postit 7y agoThis makes no sense. Microsoft is on the way to bring Linux inside Windows. They have zero competitive advance, fomenting another system at this moment.
- TazeTSchnitzel 7y agoI had assumed that because 64-bit wine did the “Program Files (x86)” thing, it ran 32-bit Windows apps in a 64-bit process. But now that I think about it, that doesn't make sense. WINE needs kernel and userland support for running 32-bit x86 code unless it adds an emulator, because WINE actually loads the Windows executable's binary code into the current process (I assume exec() is a good comparison?) together with OS shared libraries. Maybe relevant for understanding this: https://wiki.winehq.org/Wine_Developer%27s_Guide/Kernel_modules#The_Wine_initialization_process https://wiki.winehq.org/Wine_Developer%27s_Guide/Kernel_modu...
- speeder 7y agoLots of people in my company use Ubuntu and Wine... Those news indeed are concerning, specially because a lot of "bureacracy" related software is win32 only for stupid reasons (there is even one company that purchases from us, that only negotiate the actual deals using a online platform that only runs on IE6 and needs some Win32 plugins...)
- RosanaAnaDana 7y agoI've used Wine to run a number of instrument specific pieces of software via Ubuntu and all of them were 32 bit.
- sneakernets 7y agoI'll admit I'm a very fringe case, but I loved the ability to play the original Microsoft Entertainment Packs on my Mac using WINE. There's just something about how simple and clean those games are, and people actually like to see them when I have a paused game of rodent's revenge on one of my screens. I really don't want to lose that!
- writepub 7y agoWhat would it take for wine to run in 64 bit mode and emulate Win32?
- Otnix 7y agoThere are thousands and thousands of applications available for Linux, and even more being developed as you read this. As much as I love Linux and Open Source, sometimes you happen to love a Windows application so much that you wonder if only this was available on Linux I would completely switch
- giancarlostoro 7y agoThis will make me more likely to spin up a ReactOS VM if I really want to run any Windows only software, since running Windows in a VM is very resource consuming. I was looking at computers at Walmart with only 4GB of RAM, the task manager said 3 GB out of 4 GB were being used, and it was just on standby. I don't know what happened around Windows 8 to 10 but having 8 GB of RAM is too little for Windows, the OS takes up half of it out of the box whilst idle.
- deleted 7y ago[deleted]
- FeatureIncomple 7y agoYep That, and it's also almost impossible to run Windows 8 or 10 with a HDD drive, even for basic stuff like internet browsing, etc. SSD is basically required now. Sad, because Linux is still pretty fast with HDD for basic usage.
- asark 7y agoCan confirm, had a huge "WTF?" on installing Win8 on an HDD and seeing the friggin' OS UI pause constantly for no obvious reason. It was like running Win98 on a 75Mhz Pentium with 16MB of RAM. On my beefy quad-core Intel with 16GB of RAM. Added an SSD, problem went away. They're relying on the SSD to make up for some really lazy crap in their code.
- boybd 7y agoIf ReactOS ever reaches the point where it can be used instead of Wine, I might as well just boot ReactOS and drop Linux completely. I like Windows but I don't like the way it's heading. A perpetual XP/7 would be great.
- randyrand 7y agoHow hard is it to statically convert a 32 bit process into a 64 bit one? And why?
- WhatIsDukkha 7y agoThis actually seems like a GREAT thing to untangle all the otherwise useless? 32bit support from the underlying filesystem. Why have windows apps accessing your 32 bit libraries in /usr (which only the Windows apps need at this point) and instead just a flatpak library of sandboxed 32 libraries? My steam install is already flatpaked, I'd be much happier if the community just moved this way - https://winepak.org/ https://winepak.org/ Seems like much closer to what I would want when running ANY Windows app in my otherwise completely open source desktop in the first place.
- tracker1 7y agoIt seems to me, we'll probably wind up with a base linux container for 32-bit wine support... now, what that is based on, and how well it's maintained is another issue entirely. By comparison there's DosEMU, DosBox and others for DOS, but Windows/Wine is a much larger surface. I can only hope there's enough community to create effectively a "virtual distro base" that's 32-bit so that said apps can continue to run. Should be fairly similar to the effort on windows for WSL2 ... Would be interesting to see MS take a similar approach for DOS/Win32 support. Given the changes in MS, would actually be VERY interesting to see MS support Wine32 under WSL2 so that they could remove the 32bit support from windows as well. Unlikely, but one can dream.
- Frenchgeek 7y agoIsn't the Steam client 32 bits too?
- xemdetia 7y agoI agree that a virtual 32 bit distro is probably the only way this makes sense. I can't imagine that a project like wine has any capacity to do all the security updates and dealing with all of multi distro complexities to work around the fact that they could have wildly different library sets to stand on. It could potentially be done as part of a distro package for Ubuntu but it would be a single person replicating the effort of the core libs for ubuntu over again, just for this one corner project. Either that or someone's going to have to rebuild WOW64 on top of wine? I guess that could happen.
- tzs 7y agoHow different is the 32-bit Windows application environment from the 64-bit Linux application environment on x64 systems, as far as how system calls are invoked goes, and how memory is accessed? We had a somewhat similar issue of wanting to run code from a different, narrower, system, although the systems involved were not anywhere near as different as Windows and Linux, back in the mid '80s at ISC. We were doing the 386 port of System V Release 3 under contract from AT&T. Part of the contract required that we add the ability to run binaries from the 286 ports of System V Release 2 and System V Release 3 [1]. The approach was similar to what Wine does, if my limited understanding of Wine is correct. We wrote a program, i286emul, which could be pointed at a 286 program. It would allocate memory for the 286 program and load the program into that memory. 386 Unix was using a simple paging memory model. The 386 still used the selector/offset system even when using paging, but the selectors were loaded once when a program started and not touched again. I think it was using what, in 16-bit land, would be called "small model" (one code segment, one data/stack segment), but with all the segments set to 4 GB, and the real memory management done via that paging system that operated below the output of the selector/offset system. We had to add a system call (or maybe it was a new command added to an existing ioctl...I don't remember for sure) that allowed i286emul to ask the kernel to set up some 16-bit selectors referencing the parts of the i286emul 32-bit address space at which it had loaded the 16-bit program, or at which it had allocated memory for the 16-bit program's data and stack. That let i286emul load a 16-bit program into i286emul's address space, get the selectors set up, and then it could load the selectors and jump into the 16-bit program. Eventually, the 16-bit program would try to do a system call. Fortunately, 16-bit 286 Unix and 32-bit 386 Unix happened to use different mechanisms for invoking system calls, so that when 16-bit tried to do a 286 Unix system call it would be an illegal instruction or a segfault or something like that (I don't remember the exact mechanism it used), instead of something that would try to invoke a 386 Unix system call. (As far as I know, this was pure luck that the people who decided on the 386 system call interface mechanism picked something different from the 286 system call interface mechanism). So, to handle system calls we just had to have i286emul handle the fault, recognize that it was caused by the 286 program trying to do a system call, and emulate that call. I don't remember if that was as simple as installing a signal handler for the fault, or if we needed some kernel help. The only other kernel change I remember was making exec recognize 286 binaries, and turn the exec into an i286emul exec, with the path to the 286 program passed as an additional argument. Later, when AT&T and Microsoft made a deal to add Xenix binary compatibility to 386 Unix, we got the contract for that, leading to x286emul, which was very similar to i286emul. There were a couple of minor areas in which Xenix and Unix differed that we could not take care of in user mode, so had to add a kernel flag [2] to have it slightly change some behavior for x286emul. How hard would it be to take a similar approach with 32-bit Windows on 64-bit Linux? That is, make it so that a Linux process can reasonably mix 32-bit and 64-code, and give it some control over how 32-bit code sees the processes address space, and then implement a version of Wine that can handle 32-bit Windows programs translating their system calls to 64-bit Linux calls? The issues I can see include: 1. What is actually different between 32-bit code execution and 64-code execution as far as the kernel goes? Is there some flag that marks 32-bit/64-bit, or is it mostly that 32-bit code is simply going to use addressing mode that refer to the double word registers instead of the quad word registers? 2. We greatly benefited on i286emul/x286emul by the very different memory models of the two systems. I'd expect 32-bit Windows and 64-bit Unix to have very similar models which could be a problem...but I'd expect 32-bit Windows and 32-bit Linux to be even closer, and Wine dealt with that, so I'm not sure 32-bit/64-bit would add much difficulty. 3. We also benefited from 286 Unix and Xenix being similar to 386 Unix, so mostly 286 system calls mapped directly to corresponding 386 system calls, with just a little translation of arguments and return codes. Windows and Linux are very different. But Wine is already dealing with that, so as with memory model it is not obvious that 32-bit vs. 64-bit makes much difference. [1] ...not that there were actually any System V Release 3 on the 286 programs anyone cared about, because as far as I know that port was never completed. We were doing that one for AT&T, too, but there were too many assumptions about memory management baked into the 3B2 source that were not right for the very different memory environment of the 286, and maybe halfway through the port AT&T realized that Release 3 on the 286 was going to suck unless we did some major rewriting rather than just porting, and the 386 was so much better than on one was going to give a damn about running Release 3 on a 286 even if it did not suck, and dropped the port. [2] That stupid flag led to the most annoying meeting I have ever attended. For x286emul, we were just doing the user mode code. Microsoft was doing any kernel changes we needed. They said an issue arose with our request for this flag that could not be resolved by email or phone. Me and the other guy who were writing x286emul had to fly from LAX to SEATAC, go all the way over to Redmond, to resolve this thing in person. We got to the meeting, and they presented the issue: should controlling the flag be via a new system call, or via a flag on the system call (or ioctl...I never can remember which it was) that is used for some of the other 286 emulation control? We gave out preference on that, and were sent home. How the heck could that not have been handled by email or phone?
- dafran 7y agoThere's ecen an Ubuntu dev urging for more testing before implementing this: https://discourse.ubuntu.com/t/results-of-testing-games-on-64-bit-only-eoan-19-10/11353 https://discourse.ubuntu.com/t/results-of-testing-games-on-6...
- yellowapple 7y agoI took Ubuntu's dropping of 32-bit support to only apply to the machine itself, like how openSUSE Leap only supports running on 64-bit hardware but still supports 32-bit libraries[1]. Sounds like Ubuntu's taking it to an even greater extreme. Regardless, I can think of a couple ways around this: - Build the 32-bit versions of the relevant libraries and ship them in a third-party PPA (or - ideally - convince Canonical to do this for Ubuntu, thus doing what openSUSE Leap is doing) - Ship Wine in a snap or AppImage or flatpak or what have you with the relevant 32-bit (and 64-bit) libraries [1]: https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.64bit.html https://doc.opensuse.org/documentation/leap/reference/html/b...
- FrozenVoid 7y agoAlot of non-technical people use (mostly closed source) 32bit windows apps/games through wine on Ubuntu(the most popular desktop linux) - some without equivalents/alternatives. The only result of this is ubuntu usage share dropping - people run Operating Systems for Apps/Games/Software, not the other way around.