CodeWeavers' CrossOver ran 32-bit Windows Intel binary on macOS on Arm CPU emulating x86 – and nobody died

Anyone pondering how to get Intel-based Windows apps onto shiny new Apple M1 devices have been thrown a lifebelt by CodeWeavers. CodeWeavers, noted for the tweaked version of Windows compatibility layer Wine, has run up its CrossOver product on hardware based on Apple's M1 silicon. The result will give heart to those keen to …

[DJV]

I'm waiting for them to...

...run a 16-bit Windows 2 program on Windows 3.1, which is installed on top of DOS 6 that is running in a DOS emulator running inside the Amiga emulator, WinUAE, on a 32-bit Windows 10 install that is, itself, running on the 32-to-64 bridge in Wine/CrossOver on top of macOS Big Sur, on an ARM CPU that is emulating x86.

Or is that a bit ambitious?

[Anonymous Coward]

Re: I'm waiting for them to...

When this happens, and it will, you can be sure that SharePoint and Teams are somewhere in the middle of your list.

[Chewi]

Re: I'm waiting for them to...

I can't top that but I can tell you that a few months ago, I ran Windows for Workgroups 3.11 under DOSBox on a 33MHz Amiga 1200 running Gentoo Linux. It took about half an hour just to start and moving the mouse was like shifting a boulder but it really did work. Unfortunately hardly anything on Linux besides the text framebuffer supports the Amiga's weird graphics hardware so I had to run it under Xvnc and view the results remotely but it was still running on the miggy all the same!

[Anonymous Coward]

Re: I'm waiting for them to...

The internet thanks you for your efforts.

[katrinab]

Re: I'm waiting for them to...

There is a 16 bit PC emulator written in Javascript. I would guess that will run fine in Big Sur?

[jelabarre59]

Re: I'm waiting for them to...

Or is that a bit ambitious?

http://www.songlyrics.com/tom-payne/please-mr-compatibility-lyrics/

[bombastic bob]

Re: I'm waiting for them to...

I'd just like to see Wine actually WORK for applications I want to run and NOT have to use Windows "Ape" nor Win-10-nic to do it (the ones that scream how they won't support running on 7 any more, like stuff made by Intuit that I need at tax time)

[John Robson]

Re: I'm waiting for them to...

Well one game I rather enjoy is an 8 bit DOS based game, so I usually run in in DOSbox, but I used to run it under Wine.

So I can see an 8 bit game running through wine through rosetta.... but by that time the CPU required is so pitiful that it matters not how many emulation layers you run it through.

[Anonymous Coward]

Re: I'm waiting for them to...

While not that extreme, I have a fortran IV S390 program running in a DOS compatibility layer, running inside a VM, in production. I’d re-write it on a current platform but the equipment it’s needed for only has a few years left so doesn’t make financial sense to do.

The original user manuals still quote the cost to run the program on a long defunct mainframe.

[Gordon 10]

Re: I'm waiting for them to...

Anyone who doesn't add OS2/Warp to the list isn't trying as far as I am concerned.

[karlkarl]

I image that running Wine on the locked down (Cr)apple Chips is probably one of the only ways to provide an "open" platform these days.

Not that the (legacy?) Windows API is fantastic but it is still basically a decent compatibility layer that abstracts over a shite underlying platform.

[J27]

No, this isn't some sort of virtualization, it doesn't have access to bare metal. You can only do whatever the user can do inside the Mac OS environment. Wine is a library that translates windows API calls to the underlying operating system (Mac OS in this case).

Rosetta 2 dynamically recompiles x86 -> ARM. So in this case it's translating the windows application and Wine runtime library to ARM. That's pretty cool, but it's not going to get you around the limitations of the underlying OS.

[karlkarl]

What I meant was In the locked down Mac OS environment they cannot do much. Download / consumer apps, the rest is very restrictive (especially will be on (cr)Apple Chips requiring signed binaries).

At least in in a small Windows API sandbox you can install a C compiler and run most things. Wine does provide this.

Believe it or not the binary translation is not as important as an open platform to me (which Wine kind of provides). Apple flavored ARM is fine so long as I have an ARM C compiler.

[ThomH]

In macOS you can, amongst other things:

* download and run any software you want;

* download the development tools for free and write and run whatever you want; and

* use the terminal plus all the standard tools to, yes, write and run whatever you want.

Less useful things like X11 (useful on the Mac, that is) and Java may no longer be distributed directly from Apple but they remain available supposing you want them.

So if you want your ARM C compiler on a Mac then download Xcode, or install GCC or Clang in a more traditional UNIX fashion.

[karlkarl]

"So if you want your ARM C compiler on a Mac then download Xcode, or install GCC or Clang in a more traditional UNIX fashion."

So when I build the binary and run it, it will give me an error:

"No provisioning profile found on device. Cannot run unsigned binary".

.... this is not what I would call an open platform.

Are all you guys downvoting me telling me that you cannot spot this hidden DRM? Seriously, get a MacBook with a (cr)Apple Chip rather than x86* and try it. You might see what I mean when it comes to running your own software.

[ThomH]

That's not what I'd call an open platform either. It's also notably completely disjoint from how macOS operates.

When you build and run a binary on macOS it runs the binary. If you live in a conjured world of fiction it might say something about provisioning profiles, I guess. But if we're playing that game then what I don't like about Windows is that whenever I build and run a binary it will give me the error:

"Your radiance is incoherent. Cannot dance, dance, dance, dance, dance to that radio."

[karlkarl]

"When you build and run a binary on macOS it runs the binary"

Not on (cr)Apple Chips it doesn't. I.e macOS running on "Apple Silicon" is more restrictive like (Windows RT) in that it only allows signed binaries to execute. You cannot create signed binaries unless you register your machines with Apple's DRM platform and get a provisioning profile and "developer certificate".

[ThomH]

I think you're conflating Apple's new preferences for [i]distribution[/i] of software (i.e. as distinct from local build and run — once you're into the realm of 'this binary came from the internet... are you sure about this?'), which individual machines can opt out of, with the new architecture.

But that also means it's possible that I'm false bucketing things, so a citation would be appreciated.

[karlkarl]

https://mjtsai.com/blog/2020/08/19/apple-silicon-macs-to-require-signed-code/

https://eclecticlight.co/2020/08/22/apple-silicon-macs-will-require-signed-code/

"I don’t think it’s correct that the ad-hoc signing is sufficient to pass Gatekeeper, since the binary would not have a Developer ID certificate associated with it, and it would not be notarized"

So this is getting into the realms of Windows RT. Artificially crippled unlike on amd64 builds.

[Wyrdness]

@karlkarl

I'm not sure what you mean by this. I've just tried the following on my Apple Silicon Air:

me@Air ~ % uname -a

Darwin Air 20.1.0 Darwin Kernel Version 20.1.0: Sat Oct 31 00:07:10 PDT 2020; root:xnu-7195.50.7~2/RELEASE_ARM64_T8101 arm64

me@Air ~ % gcc -Wall hello.c -o hello

me@Air ~ % file hello

hello: Mach-O 64-bit executable arm64

me@Air ~ % ./hello

Hello, world!

I ain't signed nuffink and it seems to compile and run "Hello World" just fine. Can you explain what you think that the problem is?

[karlkarl]

@Wyrdness

Have you tried that compiled executable out on another Mac? Hidden DRM is fun like that.

[Wyrdness]

@karlkarl

I only have one AS Mac so can't try this. But I have disproved your assertion above that it's not possible to build and run code on AS.

One of the articles you linked to even states:

"This new behavior doesn’t change the long-established policy that our users and developers can run arbitrary code on their Macs"

[karlkarl]

"But I have disproved your assertion above that it's not possible to build and run code on AS."

Not really; you have an Apple account active and as you built the binary, the DRM, licenses and certificates were generated behind the scenes. You just don't realize. DRM is sneaky like that. If you were to do a "real" test; you need to wipe your Mac, remain offline and then try building a binary. It will fail to run.

"Starting with Xcode 12 beta 4, the toolchain will now automatically sign your executables whenever you build from Xcode, or use command-line utilities such as clang(1) or ld(1). This new mechanism generates signatures directly at link time, and doesnʼt cover any resource other than the executable"

... you fell for their trap basically.

So I go back to my original statement, soon running software in compatibility layers such as Wine will be the only way to simulate an "open-platform" where you can run software without satisfying DRM requirements.

[ThomH]

> Not really; you have an Apple account active and as you built the binary, the DRM, licenses and certificates were generated behind the scenes.

No they weren't. Notably because:

> "Starting with Xcode 12 beta 4, ...

As he clearly stated, he didn't use Xcode.

The signing tool that Xcode ships with is `codesign`, and from the terminal it must be invoked explicitly. Xcode merely automates it.

Use `codesign -d hello` if you really insist on being so tiresome in your counterfactual assertions. You'll see: "hello: code object is not signed at all".

[karlkarl]

"As he clearly stated, he didn't use Xcode."

I will repeat the earlier quote:

"Starting with Xcode 12 beta 4, the toolchain will now automatically sign your executables whenever you build from Xcode, or use command-line utilities such as clang(1) or ld(1). This new mechanism generates signatures directly at link time, and doesnʼt cover any resource other than the executable"

key part being:

---> "or use command-line utilities such as clang(1) or ld(1)" <----

Now I am assuming he is using a clang provided by Apple (usually distributed as part of Xcode command line tools)

Yes, this does the signing and ensures that only your mac can run it. Presumably unless you rent a development certificate to distribute the binary in a way so you can run it on other machines.

[Dave 126]

Hold on - you're upset because of the possibility that code you wrote on your machine won't just execute on some other person's computer unless that person has allowed it to execute?

That choice is up to the owner of the target machine, isn't is?

Or have I misunderstood you?

[karlkarl]

@Dave 126

"Hold on - you're upset because of the possibility that code you wrote on your machine won't just execute on some other person's computer unless that person has allowed it to execute?"

My worry is that the code I wrote won't work on some other person's computer unless **Apple** has allowed it to execute.

So if you built a binary, sent it to me and I wanted to execute it on my machine. I would not be able to unless you had rented a developer certificate from Apple. This is what I mean by not an open platform. Apple is the central authority. Apple is completely in control.

For example, just like iOS. No matter how much I would want to run your program, and no matter how much you want me to run your program, we would be out of luck unless we beg Apple to be so gracious as to allow us to run our own software.

[Dan 55]

Quite something the amount of people who believe MacOS on ARM is as open as MacOS on Intel.

Rosetta 2 allows unsigned Intel binary execution but unsigned ARM binaries cannot be compiled on one machine and run on another, you need an Apple distribution certificate.

Goodbye having an open source project and compiling release binaries for github or for homebrew or similar.

[karlkarl]

"Rosetta 2 allows unsigned Intel binary execution but unsigned ARM binaries cannot be compiled on one machine and run on another, you need an Apple distribution certificate."

The worst thing is that these guys don't understand this. I have been trying to explain it to them for the last couple of days on these forums but they just don't get it. Looking at the amount of down votes I have received, it is painful how naive so many people are.

This is how companies like Apple weasel their way in. Through the sheer ignorance of people who shouldn't be near a computer, let alone on the internet.

[gotes]

Perhaps people would take you more seriously if you didn't repeatedly use childish names like "(Cr)Apple".

[karlkarl]

Hmm,

"Crapple Chips" is a much more descriptive name than "Apple Silicon" though. Especially since it wouldn't be completely unthinkable for Apple to branch into breast implants and dildos in the near future.

[Steve K]

Pedantic

If we are playing at being pedantic then it would be silicone and not silicon, unless you have certain (as yet) undisclosed fetishes.......

[mankymanningBS]

I still don't quite understand this though. The mechanism is to detect whether code has been tampered with. You do not need a developer account to sign anything and can basically sign yourself with blank details. Another person could re-sign the code themselves if they wanted to as well. In what way would or could Apple prevent this code from being run?

As for not being able to download code from GitHub and compiling it - that isn't the case. It will simply create and sign the code with an ad-hoc signature during compile time.

Also how does this differ from say Microsoft or Apple preventing programs from running which have been flagged by Defender/XProtect.

[karlkarl]

@mankymanningBS,

If you compile me a simple hello, world executable for AppleARM and send it to me via email, if I tried to run it, I wouldn't be able to. No matter how hard I tried. The OS will tell me I cannot. Just like on the crippled Windows RT platform.

This differs from standard Windows and other "open" platforms by the fact if you compile me a simple hello, world executable for ARM (or x86) and send it to me via email, if I tried to run it, I would be able to. Frankly since Windows Defender and XProtect are only concerned with detecting cracks and pirate software, they wouldn't even alert me when launching your software.

This has very little to do with Defender and things like that, and more to do with signing certificates as seen on consumer iPhones, forcing users to access software from Apple's central app store and not correctly through the 3rd party vendors official website.

For example, with this in place, it would be impossible to deploy your software to an offline ARM-based Mac for example. Making this whole ecosystem unsuitable for professional or corporate computing.

[Dan 55]

Nobody's talking about compiling code from github. This is about distributing binaries, e.g. in github, homebrew or however way you see fit (your own storefront, as unfashionable as that is these days). You might think it's reasonable to compile everything from scratch, but for many people that is not reasonable.

Your ARM binary's ad-hoc certificate generated by Apple's linker is only valid on your computer so you can't distribute the compiled ARM binary to anyone else as it won't run on their computers.

XProtect doesn't matter, that checks that a binary has not been flagged as malware by Apple, but that happens later on in the launching process, only after the ARM binary's certificate has been accepted by the computer.

[karlkarl]

Yep, this will bite them in the butt when they realize they cannot download and run open-source software like Blender, Gimp, LibreOffice, etc, etc because those binaries have not been signed by their own personal certificate.

And then they will turn around and blame those projects for "not supporting Apple Chips" when really they just don't support Apple's fscking criminal DRM strategy.

[katrinab]

gcc is not clang. You would use cc for that.

[Anonymous Coward]

"Cannot dance, dance, dance, dance, dance to that radio."

But otherwise, Windows makes music to your ears...?

[Victor Ludorum]

How long before Apple stop this

Shirley it's only a matter of time before Apple put a stop to this 'unofficial' emulation malarkey. I mean, they don't want people running any old non-approved code on their devices do they...?

[chivo243]

Re: How long before Apple stop this

Until they find a way to monetize it, or monetize the legal side of it.

[Dave 126]

Re: How long before Apple stop this

Apple's happy with it. When asked about Windows on M1 Macs,

Federighi pointed to Windows in the cloud as a possible solution and mentioned CrossOver, which is capable of "running both 32- and 64-bit x86 Windows binaries under a sort of WINE-like emulation layer on these systems."

- Arstechnica

[DS999]

Re: How long before Apple stop this

That's on iOS, they have never had a problem with this on the Mac. Especially since if this, if it works for the most popular Windows apps, will help smooth the way for all of the Mac userbase to migrate to ARM rather than having some holdouts who have to be able to run some Windows stuff.

[Roland6]

Re: How long before Apple stop this

>Especially since ...if it works for the most popular Windows apps, will help smooth the way for all of the Mac userbase to migrate to ARM...

So does this mean CodeWeavers could be receiving some rather expensive handcuffs to become a part of Apple?

[DS999]

Re: How long before Apple stop this

Supporting a third party OS is exactly the sort of thing Apple would want a third party developer to be doing. If Apple wanted to do it themselves, they would have developed or acquired the technology to do this already.

[A random security guy]

Re: How long before Apple stop this

Why? Apple wants as many apps to run on their platform. And they do benefit from the open source community. They can’t possibly close off things like Python and other environments. I can run any binary I want. It just makes me give explicit permission before running unsigned binaries.

[Victor Ludorum]

Re: How long before Apple stop this

Wow, thanks for all the downvotes! I obviously used the wrong icon. ===>

[Dave 126]

Re: How long before Apple stop this

Sadly Victor, people have had a few years of reality being stranger than satire, so much as we might wish it, satire can't work the same way anymore. Posts that once would have been seen as the jokes they self evidently were now, against a backdrop of heated lunacy, can be too easily confused for earnest opinions. With no fault on the part of the reader.

It's important to note too that 'Aw, cmon, I was just joking!' is tactic that has been used by some agitators to evade serious debate about whatever their previous statement was. I'm not saying that was what you were up to, but there wasn't enough context to show that wasn't what you were up to.

[Victor Ludorum]

Re: How long before Apple stop this

The big brother icon I originally used must have been too subtle.

[Anonymous Coward]

My new M1 laptop is in order now....

I ordered one of the M1 Macbook Air's and a new M1 Mini yesterday.

The case for the Air arrives tomorrow as does the spare PSU and cables. Sadly the Air arrives Dec 9th to 16th and the Mini 16th to 23rd Dec. I am assuming thats 2020 but it's not stated. These will replace two 8GB laptops that have served since 2012 and 2013 respectively. Whilst Apple products do have a high price, my Macbook Pro has done seven years of service and was used until lockdown 8-10 hours a day 5-6 days per week for seven years. A rough calculation is 16,000 hours of usage. I recall it cost me £1,800 at the time, so thats 10p an hour to use. That's more than I thought.

I'm kinda excited seeing how fast this is and how many emulations I can run on the Air, for the first time in my life I haven't gone for the maxed out Pro version. The fact it seems to run so fast with no fan is great.