4 ms·

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 ma

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 https://forum.winehq.org/viewtopic.php?f=9&t=23005

philistine 7y ago
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.
- sigstoat 7y ago
  one benefit that would never go away is not needing a license/copy/installation of windows.
kitsunesoba 7y ago
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?
coldpie 7y ago
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.
- jjwhitaker 7y ago
  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.
  - iokanuon 7y ago
    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 https://superuser.com/a/14600
  - tambre 7y ago
    > [...] 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.
  - atq2119 7y ago
    I doubt packaging graphics drivers is feasible for Wine, and those are target important for games...
- makomk 7y ago
  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.
  - londons_explore 7y ago
    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.
TazeTSchnitzel 7y ago
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.
- donatj 7y ago
  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.
  - fastball 7y ago
    Do you mind if I ask what apps these are which you can't find modern replacements for?
    - blihp 7y ago
      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!)
  - coldpie 7y ago
    We're working on running 32-bit Wine applications on 64-bit-only macOS for CrossOver, but it's a huge and difficult problem.
adrianmonk 7y ago
Are they going to have to change their name to "Wine Is Now an Emulator"? At least it's only one letter difference.
fnord77 7y ago
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-intel,38668.html https://www.tomshardware.com/news/apple-mac-arm-cpus-2020-in...
- mr_toad 7y ago
  I’d say if, rather than ‘when’. Given the report came from Bloomberg I’d put the odds at about 50:50.

philistine 7y ago

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.

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

kitsunesoba 7y ago

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?

coldpie 7y ago

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.

jjwhitaker 7y ago
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.
- iokanuon 7y ago
  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 https://superuser.com/a/14600
- tambre 7y ago
  > [...] 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.
- atq2119 7y ago
  I doubt packaging graphics drivers is feasible for Wine, and those are target important for games...
makomk 7y ago
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.
- londons_explore 7y ago
  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.

TazeTSchnitzel 7y ago

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.

donatj 7y ago
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.
- fastball 7y ago
  Do you mind if I ask what apps these are which you can't find modern replacements for?
  - blihp 7y ago
    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!)
- coldpie 7y ago
  We're working on running 32-bit Wine applications on 64-bit-only macOS for CrossOver, but it's a huge and difficult problem.

adrianmonk 7y ago

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

fnord77 7y ago

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-intel,38668.html https://www.tomshardware.com/news/apple-mac-arm-cpus-2020-in...

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