Hacker News Reader

Comment by richard_todd | Hacker News Reader

I 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

View on HN

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

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.

Yeah, it doesn't really matter as wine would just have to load the 32 bit libraries from a different location (say, /usr/lib/wine/lib32 instead of /usr/lib32).

Also, Wine is not that kind of emulator. It provides windows-compatibile libraries but does not do CPU emulation so there's no real significant performance hit. [0]

[0]: https://superuser.com/a/14600

> [...] but especially emulation which is already complex and going to push hardware.

Wine stands for "Wine Is Not an Emulator". It's a compatibility layer.

I doubt packaging graphics drivers is feasible for Wine, and those are target important for games...

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.

I believe this is how things like 32lives [1] work.

32/64 bit bridges are really critical when you rely on abandonware, like in media production. I know the classic response is "don't use abandonware" but a lot of that stuff is the equivalent of vintage amplifiers/effects - it has a particular sound to it that doesn't have an equivalent.

[1] https://www.soundradix.com/products/32-lives/

The performance impact makes this a no-go for graphics drivers. Lots of games are 32 bits, even recent ones, because they don't need the large address space and don't want to pay the overhead of 64 bits.

Really, this is an incredibly stupid move that has a high likelihood of killing Linux gaming on Ubuntu.

64-bit WINE exists on macOS now, I have it installed on my MacBook Air. But 64-bit WINE can't run 32-bit Windows apps because it's not an emulator, it's a binary loader and a set of system libraries.

This is really frustrating to me because I am dependant on a small handful of 32 bit Windows Apps, and happily run them in Wine on my Mac currently.

I've been wondering what the solution would be after Catilina dropped 32 bit support and I guess the answer is I'll probably have to start launching an entire VM.

Do you mind if I ask what apps these are which you can't find modern replacements for?

It's not that you can't find modern replacements for them, it's not wanting/needing to if you've got something that already works for you. Some of that crusty stuff from the 1990's and earlier works just fine and the 'modern' replacements bring nothing new to to table for many use cases. So why bother upgrading to a version that phones home and/or is tied to a subscription to accomplish performing the same task in a less streamlined way? Do I do this with most of my software? Absolutely not... generally, but not always, the newer stuff does the job better for me.

You wanted an example, so I'll provide one: I have an ancient version of MathCAD (from 1994 or so) that I still fire up once or twice a year for some computer algebra tasks. Could I upgrade or switch to another application? Sure, but why bother when what I have does the job? (I've even got a 'modern' version of Mathematica but prefer the MathCAD UI from the 1990s... ah, progress!)

We're working on running 32-bit Wine applications on 64-bit-only macOS for CrossOver, but it's a huge and difficult problem.

> But 64-bit WINE can't run 32-bit Windows apps because it's not an emulator, it's a binary loader and a set of system libraries

The history of the "wine is not an emulator" thing is interesting, since the name originally in fact meant "WINdows Emulator".

As far as I have been able to dig up, the first suggestion to change the meaning to "Wine Is Not an Emulator" came up on Usenet in 1993 [1], when there was some concern that "Windows Emulator" might run into trademark problems.

Bob Amstadt responded to that [2] telling how the name "wine" came about:

> My orignal line of thinking was "winemu", but I didn't like that. Then I thought of shortening it to "wine". This led me to think of "whine" and "whinny". I liked "whine", but felt that it was too long.

As far as I have been able to tell, nothing further came of the "not an emulator" suggestion at that time. Sometime over the next four years, it did become an alternative meaning of the name, but I'm not sure exactly when or why. From the FAQ in late 1997 [3]

> 1.2: Why call it 'Wine'?

> The word Wine stands for one of two things: WINdows Emulator, or Wine Is Not an Emulator. Both are right. Use whichever one you like best.

They didn't stop calling it an emulator until the end of 1998. The release notes for 981108 [4] described at thusly:

> This is release 981108 of Wine, the MS Windows emulator

The release notes for 981211 said [5]:

> This is release 981211 of Wine, a free implementation of Windows on Unix

I've not been able to find for sure why they stopped calling it an emulator, but it looks like there were two things. I don't have cites for these because I didn't save links. I apparently though they were somewhere I'd be able to easily find again, and was evidently wrong.

One of the reasons is that Wine can be used for more than just taking a Windows binary and running it on Unix. It could also be linked with native Unix code to make it easier to produce native Unix ports of Windows programs.

The other reason is that computers were getting fast enough that emulators of older hardware were starting to get useful enough for people to be aware of them, but were slow. Most users of Macs and DOS or Windows PCs only ever heard of emulation in that context. Tell them that they can run Unix and keep using their old Windows programs via the "WINdows Emulator" on Unix, and they were going to think that would be very slow.

It was a lot easier to simply stop calling Wine an emulator than try to explain to people that it was just emulators that had to emulate a CPU that were inherently slow at that time, and that since Wine just has to emulate Windows interfaces, which for most programs most of the time will map in a fairly straightforward way to Unix interfaces, it is very low overhead.

[1] https://groups.google.com/forum/#!original/comp.os.linux.mis...

[2] https://groups.google.com/forum/#!original/comp.os.linux.mis...

[3] https://groups.google.com/forum/#!msg/comp.emulators.ms-wind...

[4] https://groups.google.com/forum/#!msg/comp.emulators.ms-wind...

[5] https://groups.google.com/forum/#!msg/comp.emulators.ms-wind...

You're reminding me that WINE could be considered a “high-level emulator” in video game emulation parlance.

Could 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?

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

one benefit that would never go away is not needing a license/copy/installation of windows.

Are they going to have to change their name to "Wine Is Now an Emulator"? At least it's only one letter difference.

it's going to be moot on macOS when mac hardware switches to ARM.

e.g. https://www.tomshardware.com/news/apple-mac-arm-cpus-2020-in...

I’d say if, rather than ‘when’. Given the report came from Bloomberg I’d put the odds at about 50:50.

Reply on news.ycombinator.com