CodeWeavers gets Windows apps running on Apple Silicon

Posted:
in General Discussion
The developers of CrossOver have announced that their latest version can run both 32-bit and 64-bit Windows applications on the new Apple Silicon M1 Macs.

Windows games running on Apple Silicon
Windows games running on Apple Silicon


As other virtualization companies work to transition to Apple Silicon M1, CodeWeavers has announced that their CrossOver software can already run Windows games and apps. The company says that there is more work to do but it is functioning under Apple's Rosetta 2.

We're making it official: @codeweavers CrossOver/Wine runs 32- and 64-bit Windows apps/games on Apple Silicon Macs!
And it works today!

Big thanks to the Rosetta folks at Apple and everyone at CodeWeavers for their hard work on this.https://t.co/yVnPkV5DDQ pic.twitter.com/RUi2X0vmET

-- Brendan Shanks (@realmrpippy)


As well as tweeting the announcement, CodeWeaver's Jeremy White has written a blog that briefly describes what they've tried out so far. "We also installed the beta version of Big Sur 11.1, because we know it has some critical fixes to Rosetta [2]," he wrote.

"After we did that, we were able to fire up CrossOver and install and run a wide range of Windows applications," continued White. "I can't tell you how cool that is; there is so much emulation going on under the covers. Imagine -- a 32-bit Windows Intel binary, running in a 32-to-64 bridge in Wine/CrossOver on top of macOS, on an ARM CPU that is emulating x86 -- and it works!"

White does note that, "it isn't perfect." For one example, he mentioned that "Team Fortress 2 showed some lag" and said, "I think we've got some work to do on that front."






Following the announcement on Twitter, CodeWeavers said that it is compiling a list of Windows apps that work. They also answered a question about older version of Internet Explorer, saying "big nope on old version of IE."

Of the other major companies producing Windows software solutions, Parallels has said that it is "excited to see" the benefits of Apple Silicon M1. It has yet to announce a date when its software will be updated to run on it, but the company has made "tremendous progress."

CrossOver differs from Parallels and other virtualization solutions in that it does not require an entire Windows install to run. It isn't yet clear how this may simplify or complicate the issues for virtualization or emulation that not having an Intel chip in the Mac induces.

Comments

  • Reply 1 of 11
    If it’s not native to the M1 it will lag which will make it almost unplayable, it will definitely not be an enjoyable experience.
  • Reply 2 of 11
    dysamoriadysamoria Posts: 3,430member
    What I want to know is what they plan to do with WINE when Rosetta 2 is inevitably removed from Mac OS.
  • Reply 3 of 11
    mjtomlinmjtomlin Posts: 2,673member
    dysamoria said:
    What I want to know is what they plan to do with WINE when Rosetta 2 is inevitably removed from Mac OS.

    This is basically a temporary solution. By the time Rosetta 2 is removed we’ll have many other options.

    Apparently Parallels is working on a solution and there’s the QEMU (qemu.org) project, which is cross platform already. And there’s an iOS an app called UTM (getutm.app) that could probably be moved to M1 Macs fairly easily.
    edited November 2020 watto_cobra
  • Reply 4 of 11
    dewmedewme Posts: 5,375member
    WINE/Crossover is targeting a different set of use cases than Parallels and VMWare. WINE is focused on getting individual apps running across platforms. Basically WINE is installing software shims and adapters to replace only the native operating system dependent calls, libraries, and services that the specific application actually uses with ones that work similarly on the non-native platform. This makes their adaptation, which is not emulation (as the WINE name asserts), very application specific and (in my opinion) very fragile. I say fragile because if the app developer updates their app to use different calls, libraries, or system services on the native platform it will probably no longer work with WINE until an updated set of shims and adapters is built.

    I liken WINE somewhat to the way I got my ancient Northgate 101 mechanical keyboard and PS2 mouse to work with a Raspberry Pi. I chained together a full sized DIN-to-PS2 adapter to a PS2-to-USB adapter that handles both the keyboard and mouse. It works because the mechanical interfaces are translated by connector adapters and the electrical signals are translated by a little controller embedded in the PS2-to-USB adapter.  Looks kludgy but works perfectly. 

    Parallels and VMWare emulate/virtualize the entire operating system on the foreign host. This sounds like it would be rather slow, but most Intel chips built over the past decade and a half have silicon level assist that improves parts of the virtualization stack significantly. Also, most modern operating systems including macOS, Unix, Linux, and Windows have various types of abstractions around the underlying hardware from applications, i.e., hypervisors, that greatly improve virtualization. All of this underlying hardware and software assist for virtualization greatly improves the performance and robustness of virtualization on these platforms.

    Did I mention WINE is not an emulator? In the case of Apple Silicon, Rosetta 2 is providing the required x86 emulation/virtualization.
    cat52watto_cobrajony0
  • Reply 5 of 11
    zimmiezimmie Posts: 651member
    dewme said:
    WINE/Crossover is targeting a different set of use cases than Parallels and VMWare. WINE is focused on getting individual apps running across platforms. Basically WINE is installing software shims and adapters to replace only the native operating system dependent calls, libraries, and services that the specific application actually uses with ones that work similarly on the non-native platform. This makes their adaptation, which is not emulation (as the WINE name asserts), very application specific and (in my opinion) very fragile. I say fragile because if the app developer updates their app to use different calls, libraries, or system services on the native platform it will probably no longer work with WINE until an updated set of shims and adapters is built.

    I liken WINE somewhat to the way I got my ancient Northgate 101 mechanical keyboard and PS2 mouse to work with a Raspberry Pi. I chained together a full sized DIN-to-PS2 adapter to a PS2-to-USB adapter that handles both the keyboard and mouse. It works because the mechanical interfaces are translated by connector adapters and the electrical signals are translated by a little controller embedded in the PS2-to-USB adapter.  Looks kludgy but works perfectly. 

    Parallels and VMWare emulate/virtualize the entire operating system on the foreign host. This sounds like it would be rather slow, but most Intel chips built over the past decade and a half have silicon level assist that improves parts of the virtualization stack significantly. Also, most modern operating systems including macOS, Unix, Linux, and Windows have various types of abstractions around the underlying hardware from applications, i.e., hypervisors, that greatly improve virtualization. All of this underlying hardware and software assist for virtualization greatly improves the performance and robustness of virtualization on these platforms.

    Did I mention WINE is not an emulator? In the case of Apple Silicon, Rosetta 2 is providing the required x86 emulation/virtualization.
    The WINE team can say it's not an emulator, but it fits the dictionary definition. The application sends a Windows syscall, and WINE's goal is to do the same thing as the Windows libraries and kernel. That means it is emulating the libraries and kernel. So WINE is emulating syscalls mostly by translating them to OS-native syscalls on the host OS. Rosetta is emulating an amd64 processor mostly by translating amd64 instructions into aarch64 instructions.

    Meanwhile, Parallels and VMware emulate most of a whole computer, except for the processor. You have to install a whole operating system in them. x86 instruction privilege levels are tracked in "rings", with lower numbers being more privileged. Ring 0 was the most privileged for a while, then they started adding negative rings with VT-x, VT-d, and so on (the "silicon level assist" mentioned above). Windows now tries to grab all the negative rings on boot to prevent malware from grabbing them. I suspect the reason Rosetta doesn't officially support virtualization is related to processor support for these negative rings. Specifically, I bet Apple doesn't feel like faking ring 0 and below, and without faking the hardware support, performance would be really bad. It may not even work at all, because the Intel processors Apple has shipped have always supported a few of the negative rings. It's possible Parallels and VMware don't have their own software emulation for those unsupported instructions in the Mac versions of their products.

    It's all emulation, or virtualization, or pathological lying. The difference is what is being lied about.
    watto_cobra
  • Reply 6 of 11
    dewmedewme Posts: 5,375member
    zimmie said:
    dewme said:
    WINE/Crossover is targeting a different set of use cases than Parallels and VMWare. WINE is focused on getting individual apps running across platforms. Basically WINE is installing software shims and adapters to replace only the native operating system dependent calls, libraries, and services that the specific application actually uses with ones that work similarly on the non-native platform. This makes their adaptation, which is not emulation (as the WINE name asserts), very application specific and (in my opinion) very fragile. I say fragile because if the app developer updates their app to use different calls, libraries, or system services on the native platform it will probably no longer work with WINE until an updated set of shims and adapters is built.

    I liken WINE somewhat to the way I got my ancient Northgate 101 mechanical keyboard and PS2 mouse to work with a Raspberry Pi. I chained together a full sized DIN-to-PS2 adapter to a PS2-to-USB adapter that handles both the keyboard and mouse. It works because the mechanical interfaces are translated by connector adapters and the electrical signals are translated by a little controller embedded in the PS2-to-USB adapter.  Looks kludgy but works perfectly. 

    Parallels and VMWare emulate/virtualize the entire operating system on the foreign host. This sounds like it would be rather slow, but most Intel chips built over the past decade and a half have silicon level assist that improves parts of the virtualization stack significantly. Also, most modern operating systems including macOS, Unix, Linux, and Windows have various types of abstractions around the underlying hardware from applications, i.e., hypervisors, that greatly improve virtualization. All of this underlying hardware and software assist for virtualization greatly improves the performance and robustness of virtualization on these platforms.

    Did I mention WINE is not an emulator? In the case of Apple Silicon, Rosetta 2 is providing the required x86 emulation/virtualization.
    The WINE team can say it's not an emulator, but it fits the dictionary definition. The application sends a Windows syscall, and WINE's goal is to do the same thing as the Windows libraries and kernel. That means it is emulating the libraries and kernel. So WINE is emulating syscalls mostly by translating them to OS-native syscalls on the host OS. Rosetta is emulating an amd64 processor mostly by translating amd64 instructions into aarch64 instructions.

    Meanwhile, Parallels and VMware emulate most of a whole computer, except for the processor. You have to install a whole operating system in them. x86 instruction privilege levels are tracked in "rings", with lower numbers being more privileged. Ring 0 was the most privileged for a while, then they started adding negative rings with VT-x, VT-d, and so on (the "silicon level assist" mentioned above). Windows now tries to grab all the negative rings on boot to prevent malware from grabbing them. I suspect the reason Rosetta doesn't officially support virtualization is related to processor support for these negative rings. Specifically, I bet Apple doesn't feel like faking ring 0 and below, and without faking the hardware support, performance would be really bad. It may not even work at all, because the Intel processors Apple has shipped have always supported a few of the negative rings. It's possible Parallels and VMware don't have their own software emulation for those unsupported instructions in the Mac versions of their products.

    It's all emulation, or virtualization, or pathological lying. The difference is what is being lied about.
    I don't really care about the semantics and I'm not going to make any moral judgements either. That's not the point.

    My point is that showing WINE support on Apple Silicon does not really demonstrate that virtualization vendors like VMWare, Parallels, and VirtualBox are in any way closer to getting a true x86 dependent OS level virtualization solution on Apple Silicon. CodeWeavers is demonstrating something that they've always been able to do on top of real x86 hardware. The only difference here is that they're piggybacking on top of Apple's Rosetta 2. Apple is doing all the heavy lifting.

    VMWare, Parallels, and VirtualBox have a lot of work to do. This demo doesn't change a thing and doesn't move the bar. Perhaps they may not be able to do it optimally with M1 and will have to wait for a later M-series SoC. What I will say is that over the last couple of decades virtualization on x86 platforms has always been a really big deal and has heavily influenced silicon and OS designs. The only question is whether there is sufficient momentum to sustain this with Apple Silicon. We've already seen that Unix, Linux, and Windows have committed to ARM at various levels, but x86 isn't going away anytime soon. 

    Personally, I'd be happy with a coprocessor or sidecar approach, like a full x86 machine-on-a-stick that plugs into USB4/TB and is on a virtual network with the Apple Silicon host machine and remoting into the sidecar machine. This allows Apple to keep its silicon as clean as possible and avoid backward compatibility and legacy baggage.
    watto_cobra
  • Reply 7 of 11
    F_Kent_DF_Kent_D Posts: 98unconfirmed, member
    Samsonikk said:
    If it’s not native to the M1 it will lag which will make it almost unplayable, it will definitely not be an enjoyable experience.
    And you know this how?
    watto_cobra
  • Reply 8 of 11
    mjtomlinmjtomlin Posts: 2,673member
    zimmie said:
    dewme said:
    WINE/Crossover is targeting a different set of use cases than Parallels and VMWare. WINE is focused on getting individual apps running across platforms. Basically WINE is installing software shims and adapters to replace only the native operating system dependent calls, libraries, and services that the specific application actually uses with ones that work similarly on the non-native platform. This makes their adaptation, which is not emulation (as the WINE name asserts), very application specific and (in my opinion) very fragile. I say fragile because if the app developer updates their app to use different calls, libraries, or system services on the native platform it will probably no longer work with WINE until an updated set of shims and adapters is built.

    I liken WINE somewhat to the way I got my ancient Northgate 101 mechanical keyboard and PS2 mouse to work with a Raspberry Pi. I chained together a full sized DIN-to-PS2 adapter to a PS2-to-USB adapter that handles both the keyboard and mouse. It works because the mechanical interfaces are translated by connector adapters and the electrical signals are translated by a little controller embedded in the PS2-to-USB adapter.  Looks kludgy but works perfectly. 

    Parallels and VMWare emulate/virtualize the entire operating system on the foreign host. This sounds like it would be rather slow, but most Intel chips built over the past decade and a half have silicon level assist that improves parts of the virtualization stack significantly. Also, most modern operating systems including macOS, Unix, Linux, and Windows have various types of abstractions around the underlying hardware from applications, i.e., hypervisors, that greatly improve virtualization. All of this underlying hardware and software assist for virtualization greatly improves the performance and robustness of virtualization on these platforms.

    Did I mention WINE is not an emulator? In the case of Apple Silicon, Rosetta 2 is providing the required x86 emulation/virtualization.
    The WINE team can say it's not an emulator, but it fits the dictionary definition. The application sends a Windows syscall, and WINE's goal is to do the same thing as the Windows libraries and kernel. That means it is emulating the libraries and kernel. So WINE is emulating syscalls mostly by translating them to OS-native syscalls on the host OS. Rosetta is emulating an amd64 processor mostly by translating amd64 instructions into aarch64 instructions.

    Meanwhile, Parallels and VMware emulate most of a whole computer, except for the processor. You have to install a whole operating system in them. x86 instruction privilege levels are tracked in "rings", with lower numbers being more privileged. Ring 0 was the most privileged for a while, then they started adding negative rings with VT-x, VT-d, and so on (the "silicon level assist" mentioned above). Windows now tries to grab all the negative rings on boot to prevent malware from grabbing them. I suspect the reason Rosetta doesn't officially support virtualization is related to processor support for these negative rings. Specifically, I bet Apple doesn't feel like faking ring 0 and below, and without faking the hardware support, performance would be really bad. It may not even work at all, because the Intel processors Apple has shipped have always supported a few of the negative rings. It's possible Parallels and VMware don't have their own software emulation for those unsupported instructions in the Mac versions of their products.

    It's all emulation, or virtualization, or pathological lying. The difference is what is being lied about.

    WINE is just an alternative API layer (aka compatibility layer). It does not emulate the OS at all. It takes Windows apps and hooks standard Windows API calls into their API's. It is very similar to how NextStep apps were able to run under different operating systems. It also why Rosetta is so fast, because the macOS APIs exist on both Intel Macs and Apple Silicon Macs... 

    The model is...
    Application -> API -> Operating System

    As long as the application only uses what's available in the API... as you move those API's to different operating systems, those applications should be able to make the move as well.
    watto_cobrajony0
  • Reply 9 of 11
    melgrossmelgross Posts: 33,510member
    What we read here doesn’t eliminate the possibility that Wine won’t be made M1 native at some point. The tech in Rosetta 2 can be used in other apps as well, other than Apple;s. We could see it in Wine, Parallels, etc. it will take some time, but developers are clever beasts.
    watto_cobrajony0
  • Reply 10 of 11
    mjtomlin said:
    dysamoria said:
    What I want to know is what they plan to do with WINE when Rosetta 2 is inevitably removed from Mac OS.

    This is basically a temporary solution. By the time Rosetta 2 is removed we’ll have many other options.

    Apparently Parallels is working on a solution and there’s the QEMU (qemu.org) project, which is cross platform already. And there’s an iOS an app called UTM (getutm.app) that could probably be moved to M1 Macs fairly easily.
    The assumption is that Apple will remove Rosetta 2 in a future OS update. I don’t think that necessarily holds true. Unlike the original Rosetta, Rosetta 2 was written in house by Apple as far as we know. The original Rosetta was licensed and at some point IBM bought the company. I think this forced Apple’s hand.

    I’ve been using Rosetta 2 for a couple of days now and it is spectacularly good. Outside of the initial launch of an application you can’t tell whether you are running a native Arm binary or a Rosetta 2 translation. It looks like Apple spent a lot of time on Rosetta 2 and might want to keep it around indefinitely. It’s only going to get better with future updates to Apple Silicon.
    watto_cobrajony0
  • Reply 11 of 11
    dewmedewme Posts: 5,375member
    jdb8167 said:
    mjtomlin said:
    dysamoria said:
    What I want to know is what they plan to do with WINE when Rosetta 2 is inevitably removed from Mac OS.

    This is basically a temporary solution. By the time Rosetta 2 is removed we’ll have many other options.

    Apparently Parallels is working on a solution and there’s the QEMU (qemu.org) project, which is cross platform already. And there’s an iOS an app called UTM (getutm.app) that could probably be moved to M1 Macs fairly easily.
    The assumption is that Apple will remove Rosetta 2 in a future OS update. I don’t think that necessarily holds true. Unlike the original Rosetta, Rosetta 2 was written in house by Apple as far as we know. The original Rosetta was licensed and at some point IBM bought the company. I think this forced Apple’s hand.

    I’ve been using Rosetta 2 for a couple of days now and it is spectacularly good. Outside of the initial launch of an application you can’t tell whether you are running a native Arm binary or a Rosetta 2 translation. It looks like Apple spent a lot of time on Rosetta 2 and might want to keep it around indefinitely. It’s only going to get better with future updates to Apple Silicon.

    Makes sense. They are doing app level translation including JIT (just in time) compiling code that uses JIT, then caching the results. This means that subsequent invocations of the same app/code are effectively running natively.
    edited November 2020 watto_cobra
Sign In or Register to comment.