Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

SecuritySteve

macrumors 6502a
Original poster
Jul 6, 2017
951
1,087
California
Given that it is unlikely we will see Windows on Apple Silicon, virtualization and bootcamp are off the table. But what about Wine emulation? Is it possible we could have a Wine emulator running native on Apple Silicon, or translated via Rosetta?

I'm sure the performance wouldn't be the best, but at least it would be something. I am not sure where to even look for answers to this specific question, other than here of course.
 
Wine is already not really full functional on Catalina and Big Sur since it relies on 32-bit support. Should Wine lose all 32-bit dependencies and support just 64-bit Windows, it is perfectly possible that it could work, yes
 
Given that it is unlikely we will see Windows on Apple Silicon, virtualization and bootcamp are off the table. But what about Wine emulation? Is it possible we could have a Wine emulator running native on Apple Silicon, or translated via Rosetta?

I'm sure the performance wouldn't be the best, but at least it would be something. I am not sure where to even look for answers to this specific question, other than here of course.
Wine Is Not an Emulator. It says so right on the box. You could likely run 64-bit Arm Windows software through it, but how much of that have you seen?
 
Wine Is Not an Emulator. It says so right on the box. You could likely run 64-bit Arm Windows software through it, but how much of that have you seen?
Anything is better than nothing. And excuse me, I should have rephrased the question as Wine's binary loader, as the FAQ clearly indicates that "Wine is not just an emulator" but rather a compatibility layer.

But you knew what I meant.
 
I fully expect WINE to run under Rosetta. From the OS perspective, WINE behaves very similar to a x86 JIT compiler (it loads executable code at runtime and links it against a provided set of libraries), and Apple has made it clear that this model of execution is supported by Rosetta. The biggest hurdle I see are the 32-bit components of WINE itself.

The simplest thing would be for someone with DTK to try it out :)
 
  • Like
Reactions: Arunachala
Based on the thread headline, I thought someone was wondering in advance what happens if they spill wine on their new Macbook :rolleyes:
 
Anything is better than nothing.
I fully agree - but without emulation (or binary translation à la Rosetta 2) what we get access to through plain Wine is basically software written for the most modern frameworks, and that's the code most likely to be easy to port to other platforms anyway (whether or not the authors actually do it).

A lot of legacy Windows software will probably struggle to work through Wine already in the latest macOS version even on Intel hardware (I frankly haven't tried, but I don't see how it could work). It won't get better with a new architecture.

I fully expect WINE to run under Rosetta. From the OS perspective, WINE behaves very similar to a x86 JIT compiler (it loads executable code at runtime and links it against a provided set of libraries), and Apple has made it clear that this model of execution is supported by Rosetta. The biggest hurdle I see are the 32-bit components of WINE itself.

The simplest thing would be for someone with DTK to try it out :)
If the past is anything to go by, Rosetta 2 will likely only be supported for a limited time. If by the end of that time you still need Win32 applications your choice will be between emulating an x86/x86-64 environment or running a separate computer for these needs.
 
Yes. Their changelog on their homepage mentions fixes for arm64 macOS:
The Wine development release 5.16 is now available.
What's new in this release:
  • Support for x86 AVX registers.
  • Some ARM64 fixes for macOS.
  • Still more restructuration of the console support.
  • Various bug fixes.
The source is available now. Binary packages are in the process of being built, and will appear soon at their respective download locations.
 
  • Like
Reactions: aberamati
but will it make it into the app store and work when apple goes app store only + maybe limited out side apps from people like MS and adobe?
 
but will it make it into the app store and work when apple goes app store only + maybe limited out side apps from people like MS and adobe?
There are few things in life more ridiculous that being frightened by ghost stories that you tell yourself. There is zero evidence to support the notion that Apple will require all applications on the Mac to be distributed through the Mac App Store.
 
Wine is already not really full functional on Catalina and Big Sur since it relies on 32-bit support. Should Wine lose all 32-bit dependencies and support just 64-bit Windows, it is perfectly possible that it could work, yes

Won't ever happen, especially considering Wine's original goal.
 
Yeh CrossOver is what I use for the windows apps I don't have on my Mac. But I am curious how they plan for the Arm, they say they work on it, but if it means running the Arm versions of the windows apps, or also emulating on top of wine. I think we'll have to wait and see.
 
Yeh CrossOver is what I use for the windows apps I don't have on my Mac. But I am curious how they plan for the Arm, they say they work on it, but if it means running the Arm versions of the windows apps, or also emulating on top of wine. I think we'll have to wait and see.
The issue of running Windows on an ASi Mac is tempest in a teapot. Microsoft, of course, has Windows on ARM. It also has Virtual PC, which has not been available as a commercial product for more than a decade. It ran genuine Windows Intel on PPC, but porting to ASi should not be a bid deal. VPC was [is?] an emulator and a virtualization environment. It ran genuine Microsoft Windows on an Intel x86 emulator.

If you are considering WINE, then you are considering open source. WINE is an open source set of cloned Windows APIs. As I posted elsewhere, WINE does not support all Windows APIs and, thus does not support all Windows applications. Although the list of supported applications is not comprehensive, it is extensive. If the applications that it supports are the applications that you want to use then you don't care about the applications that it does not support. Of course, CrossOver extends the list of APIs and, thus, the applications supported by WINE. Because WINE is not an emulator--it says so in the name--you need an emulator. This was an issue several years ago. The proposed solution was to combine the open source QEMU with the open source WINE.

I have seen comments that you cannot emulate Intel on ARM because the instruction sets are too dissimilar. That is nonsense. That is the very definition of emulate. QEMU emulates a x86 on a number of target processors including ARM. However, the ARM versions of QEMU are board-specific. There are versions of QEMU to support 18 separate ARM board families, include generic boards. However, Apple Silicon is not among the supported boards.

Support for Windows or other Intel OSes on ASi Macs are not technical issues. If there is a market for Intel Windows on ASi Macs, then someone--perhaps multiple developers--will provide it. After all, my first Power Mac shipped with SoftWindows.
 
Support for Windows or other Intel OSes on ASi Macs are not technical issues. If there is a market for Intel Windows on ASi Macs, then someone--perhaps multiple developers--will provide it. After all, my first Power Mac shipped with SoftWindows.

I mean, it is a technical issue in that there are technical challenges needed to be conquered by the developers wishing to make it happen. Not technical impossibilities, but there certainly are technical challenges.
 
Wine for Arm under Linux only runs Windows for Arm applications. To run x86 binaries on Arm Linux distros with Wine, some kind of emulation is necessary.

Currently, there are two ways to do this: one is to run an x86 version Wine in an emulator (QEMU), the other is special fork of Wine called Hangover, which comes with a bundled emulator, but is not particularly compatible so far.

I expect the situation on Arm versions of macOS to be the same.
 
No, it is not a technical question. It is rather if is it worth it. If enough people or companies find that is required for their uses, some solution will come.
 
Because WINE is not an emulator--it says so in the name--you need an emulator. This was an issue several years ago. The proposed solution was to combine the open source QEMU with the open source WINE.

Wine for Arm under Linux only runs Windows for Arm applications. To run x86 binaries on Arm Linux distros with Wine, some kind of emulation is necessary.

That's what Rosetta is there for. WINE does not need to care about ARM at all — from WINE's perspective it runs on a x86-64 machine. Rosetta will take care of the machine code translation.
 
That's what Rosetta is there for. WINE does not need to care about ARM at all — from WINE's perspective it runs on a x86-64 machine. Rosetta will take care of the machine code translation.
We don't know that yet. Your assumption it does is speculation. We had this discussion already.
 
Last edited:
We don't know that yet. Your assumption it does is speculation. We had this discussion already.

That we did :) I jut can't think of a single reason that would prevent WINE running on Rosetta — Apple documentation explicitly states that dynamically loaded code is a fully supported.
 
Dynamically just-in-time compiled code.

As a person with a background in compilers, I can assure you: it doesn't matter. The OS has no way of knowing where the code comes from. If Apple mentions JIT-compiled code, what they really mean is that someone is "manually" loading executable code at runtime. It can be JIT-compiled, loaded from disk, downloaded from the internet — whatever you want. The OS-level API is the same in every simple case. You allocate executable memory, copy your code in there and jump into it.

I think it is not difficult to guess how Rosetta works on a fundamental level. A memory page containing executable code is annotated with with it's architecture (ARM or x86). For any x86 code page, the OS will maintain shadow memory containing transpiled ARM code. If an attempt to run not yet transpiled x86 code is detected, memory exception is raised and Rosetta is invoked, which then does it's magic. For "regular" applications, transpiled code can be cached, enabling fast startup. For application that load code on runtime (be it JIT-compilers or anything else), there might be some latency, since I doubt that Rosetta can cache it.

Then again, it is also possible that I am just having a massive brain fart and that there is some other problem I can't see. I suppose we will know soon enough :)
 
  • Like
Reactions: casperes1996
So... eventually, Rosetta 2 will be gone. What will be of Wine then?
If Codeweavers can gets CrossOver/Wine ready and working for Apple Silicon Macs in Rosetta, it opens huuuge library of older Windows x86/ x64 games and apps, and for me personally much easier transition to ARM.

Also keep in mind that Wine advanced over the years and nowadays if game/app works in Wine it feels native - and even have all of the bugs of the Windows version.

At least for few years while Rosetta is supported :)
 
  • Like
Reactions: KPOM
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.