Wine Developers Concerned with Ubuntu Dropping 32-Bit Support

Post by pedrocx486 » Sat, Jun 22, 2019, 2:32 AM UTC

djsumdog wrote: post #143

AnIdiotOnTheNet wrote: post #101

Earlier quoted context omitted.

What'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...

Windows doesn't even support 16-bit applications (unless you use 32-bit Windows with NTVDM enabled). There was another post on here a few months back about someone getting Win16 apps working on modern 64-bit Windows machines: https://hackernoon.com/win3mu-part-1-why-im-writing-a-16-bit...

Post by zapzupnz » Sat, Jun 22, 2019, 4:26 AM UTC

olliej wrote: post #181

AgentME wrote: post #176

Earlier quoted context omitted.

32-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.

You 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

Post by tambre » Sat, Jun 22, 2019, 7:04 AM UTC

jjwhitaker wrote: post #110

coldpie wrote: post #84

Earlier quoted context omitted.

The 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" n…

I wonder why Wine doesn't have those libraries on standby. I can understand keeping installer/total install size and footprint down for any application but especially emulation which is already complex and going to push hardware. If Wine includes the right components, what performance hit may be suffered? Or maybe I have this wrong and it won't really matter.

Post by Shorel » Sat, Jun 22, 2019, 6:00 PM UTC

yjftsjthsd-h wrote: post #65

Al-Khwarizmi wrote: post #25

Earlier quoted context omitted.

I run mIRC on Wine. I know, I know, there are plenty of Linux native IRC clients. In fact, mIRC has been quite stagnant lately. But to me, its UI is still unsurpassed (20 years of muscle memory also help), and it has less latency than alternatives (even with Wine).

I'm surprised that nobody's made an open source clone, since it's a long-standing app, apparently better than the available alternatives, and fundamentally IRC just isn't that hard.

Post by atq2119 » Sun, Jun 23, 2019, 7:11 AM UTC

londons_explore wrote: post #158

makomk wrote: post #145

Earlier quoted context omitted.

Remember, though, that the hardware-specific OpenGL library for the user's specific graphics hardware is also a userspace library that has to be provided in a 32-bit version. Even Steam doesn't bother shipping that because it's just not feasible. Without at least some library support from distros it's just not practical to continue 32-bit compatibility.

You can have a little 64 bit process which communicates with the 32 bit process with a named pipe, and acts as a proxy and makes all the syscalls and loads and calls the 64 bit libraries and returns the responses. Obviously it adds extra context switches and will reduce performance, but if you're running ancient legacy 32 bit code, you can probably afford that.