Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Nitpick: not even Microsoft can run 64-bit Windows Apps on ARM. (to be fair, that was probably what you meant)
Sounds like Rosetta2 can quite happily cope with x64 code. Maybe if Microsoft ask Apple very, very nicely they'll license the tech to them...

Go back and reread what I wrote:

"Microsoft Arm-based PC run 64-bit (Arm64) apps, 32-bit (Arm32) apps, or 32-bit (x86) in emulation mode. Currently, 64-bit (x64) apps won’t work. Early 2021 is the scheduled date for an x86-64bit emulator." - Exiting x86: Why Apple and Microsoft are embracing the Arm-based PC

So right now not even Microsoft can run x64 code on ARM. There are rumors of Microsoft and Apple being in talks which makes sense. Apple has a reasonable x64 translator and Microsoft has a reasonable x86 translator so the partnering up makes sense. According to the rumors the issue is licensing not hardware or performance.

I was very clear on what I meant.
 
  • Like
Reactions: throAU
Go back and reread what I wrote:

"Microsoft Arm-based PC run 64-bit (Arm64) apps, 32-bit (Arm32) apps, or 32-bit (x86) in emulation mode. Currently, 64-bit (x64) apps won’t work. Early 2021 is the scheduled date for an x86-64bit emulator." - Exiting x86: Why Apple and Microsoft are embracing the Arm-based PC

So right now not even Microsoft can run x64 code on ARM. There are rumors of Microsoft and Apple being in talks which makes sense. Apple has a reasonable x64 translator and Microsoft has a reasonable x86 translator so the partnering up makes sense. According to the rumors the issue is licensing not hardware or performance.

I was very clear on what I meant.

An over complicated analysis.
Apple and Microsoft are talking, but they’re not talking about hardware or software, they’re talking about certificates.

AS Systems use a secure boot mechanism that requires a signed operating system, the same way that iPhones and iPads require signed apps.( The iPhone and iPad also require a signed operating system).

Users, can turn off this mechanism in Apple Silicon Machines, so there’s no doubt, that Microsoft can build a version of windows on arm that would run. But no one wants to require the user to turn off the signed mechanism. Remember Microsoft sells business software, and businesses are not interested in reducing security. so to make windows on arm running on Apple silicone , A viable business opportunity for Microsoft, they would need a certificate so they could boot just as macOS does.
That’s what they’re talking about. I personally hope the Apple sees the immense opportunity that they have here, and decides to grant Microsoft, a long-term trusted partner, such a certificate.

I guess we should note that licenses cost money, so that is also a part of the discussion.
 
Last edited:
TL:DNR: even 18 months ago it was possible to run Windows 10 for ARM64 on a Raspberry Pi 3B by obtaining the image from an unofficial source. It sucked big time - but then it was running on a $30 maker board using an industry surplus set top box SoC (not even the latest Pi 4 which is substantially more powerful) with no graphics acceleration and a SD card as the only mass storage, so what do you expect? If a tech journalist can get it running in a couple of days, with no official support, on a feeble Pi then it's not going to take a Manhattan Project for someone with resources to get it going in a Hypervisor on Apple Silicon. It will need someone to write paravirtualised drivers for graphics etc. (or for the hypervisor to emulate something it can drive) but the same goes for any guest OS. Basically, it will happen unless (a) Microsoft refuses to allow it or ((b) nobody actually wants it.
One thing to keep in mind though is WoA can run 32-bit ARM code/apps but I’m pretty sure that ASi can’t. Apple only implements 64-bit ARM instructions in their CPUs. That might make it difficult for an ASi Mac to run WoA unless Microsoft makes OS changes. The Raspberry pi has no trouble running 32-bit ARM code.
 
Last edited:
Running windows on mac, is a necessity.
Today I visited a doctor in hospital.
He had a macbook pro. Besides health issues, we talked a little about macs.
He told me that he loves his mac, but he is forced to use windows through parallels, because lot of medical applications run only in windows. Fortunately, parallels allow him to have them all on his macbook pro.

This is just an ordinary example of professionals, that really need running windows on their macs.

So, apple, microsoft, they have to find a way to do it on new macs.
 
  • Like
Reactions: mburkhard
Running windows on mac, is a necessity.
Today I visited a doctor in hospital.
He had a macbook pro. Besides health issues, we talked a little about macs.
He told me that he loves his mac, but he is forced to use windows through parallels, because lot of medical applications run only in windows. Fortunately, parallels allow him to have them all on his macbook pro.

This is just an ordinary example of professionals, that really need running windows on their macs.

So, apple, microsoft, they have to find a way to do it on new macs.

The only thing this shows is the programmers are idiots. There is no reason, in this day and age, to have platform specific software. Anyone intelligent writes the software with a IFF (InterFile Format) tie in but, and here is where it gets really stupid, medical software is generally incompatible and some of it is very badly written.

Case in point the doctor, nursing home, and hospital we use can't directly talk together even though they all use Windows. The reason is they all got software from different companies that is incompatible with each other and has no IFF. So you have to get a hard physical copy which goes along with the patent which the place they go to uses to update their records.

It is even more nuts as thanks to the programmer one piece of software being a clueless bumbler they misclassified medicare as medicaid in their system and so you have this nonsensical medicaid plan A and medicaid plan B (actually medicare plan A and medicare plan B) showing up in the internal paperwork.

This nonsense went totally pear shaped with my grandfather who had a no code (no resuscitation order) at both the nursing home and the hospital. But because the ambulance company had a totally different system their system literally didn't have the memo and he was resurrected on route. No surprise we never got a bill regarding any expense after that (or from the ambulance company) because none of the three wanted to explain to a judge or jury how their software cockup had resulted in what amounted to violation of the law.
 
  • Like
Reactions: throAU
The only thing this shows is the programmers are idiots.

All of what you write may be true but it doesn't detract from the point that @cool11 was making. I agree with everything except for the conclusion. I think Apple might very well decide that they can live without the users who will be affected by this limitation. I'm not saying that's a smart choice, but it's definitely a choice I can imagine Apple making.

Apple Silicon is the end of the road for me because I need performant x64 virtualization for Docker. Apple are apparently fine leaving me by the roadside. Perhaps people who have a lingering need for the occasional Windows application are in the same category.
 
  • Like
Reactions: cool11
All of what you write may be true but it doesn't detract from the point that @cool11 was making. I agree with everything except for the conclusion. I think Apple might very well decide that they can live without the users who will be affected by this limitation. I'm not saying that's a smart choice, but it's definitely a choice I can imagine Apple making.

Apple Silicon is the end of the road for me because I need performant x64 virtualization for Docker. Apple are apparently fine leaving me by the roadside. Perhaps people who have a lingering need for the occasional Windows application are in the same category.

Docker can run on ARM64. See https://medium.com/nttlabs/buildx-multiarch-2c6c2df00ca2
 
Sure, of course. Just like "Windows can run on Arm." It's technically correct but ignores all the reasons why people use Docker (or Windows). Docker does nothing for me if I can't create, use, and share images with my fellow developers and our production infrastructure.

I think the point of the article is that you should be able to build multi-arch images on an ARM Mac. I don't know how well this will work, or whether it will be too much of a hassle.

Why not just build your x86 images on an cloud instance? I use AWS EC2 for this and it works a treat.
 
  • Like
Reactions: Maximara
I think the point of the article is that you should be able to build multi-arch images on an ARM Mac. I don't know how well this will work, or whether it will be too much of a hassle.

Why not just build your x86 images on an cloud instance? I use AWS EC2 for this and it works a treat.

It makes more sense to just use a computer which can actually perform the tasks I need to do for my job. I’d prefer that it be macOS, but if that’s not possible I’ll move to a platform that does work for me.
 
It makes more sense to just use a computer which can actually perform the tasks I need to do for my job. I’d prefer that it be macOS, but if that’s not possible I’ll move to a platform that does work for me.

I can't argue with that :) You should choose whatever is most suitable for your specific tasks.

I will add that having local virtualization capability was once essential for my work (enterprise software implementation), but it no longer is. I used to run various VMs with application servers, databases, process management and integration software, and it took a lot of time to set up and manage - and it never seemed to be fast enough on a laptop. I bought desktop server solutions maxed out with ECC RAM and fast discs and spent a lot of money and time setting it up.

These days, I can build all of the above on AWS or MS Azure in less time (from existing machine images or managed services), and provided I turn it off or tear down the stack when I don't use it, it's quite cheap - no more than a few dollars a day. It's just a lot less work and I'm convinced that cloud services are the future of enterprise computing, and a good part of personal computing as well.

We still need client machines of course...at least until sci-fi voice-only interfaces become a reality, and I prefer Macs for this purpose, which is why I frequent Macrumors!
 
Sure, of course. Just like "Windows can run on Arm." It's technically correct but ignores all the reasons why people use Docker (or Windows). Docker does nothing for me if I can't create, use, and share images with my fellow developers and our production infrastructure.
Read Getting started with Docker for Arm on Linux especially the "Register Arm executables to run on x64 machines" and note the date: Jun 07 2019. Over a year ago.

How do I, a mac user that that barely knows docker from a doctor, know this and you don't?!

I think the point of the article is that you should be able to build multi-arch images on an ARM Mac. I don't know how well this will work, or whether it will be too much of a hassle.

If the Getting started with Docker for Arm on Linux is any indication it is nearly as easy as using Xcode on a mac. While AFAIK there is no Xcode for Windows (I saw rumor of one coming but I can't find the article so we'll assume it was one of those rumors) there is Swift. So between Docker and Swift writing x86/AS code should be relatively sane as long as you are NOT taking shortcuts like directly accessing the hardware or undocumented APIs (something that despite Apple and Microsoft both saying is a very bad idea some programmers think is a great idea...and then blame Apple or Microsoft when a software patch kills their code)
 
Last edited:
personally il use a shadow.tech cloud gaming pc for my windows needs be it gaming or x86 compatability $11 a month is minimal for the ease of access it provides gotta have internet though
 
  • Like
Reactions: Maximara
How do I, a mac user that that barely knows docker from a doctor, know this and you don't?!

Respectfully, your advice is not helpful. You’re not familiar with docker and how it is used, so that’s understandable, but believe me when I tell you that running docker on Arm is technically possible but is practically useless in reality.

The way docker is used in modern devops relies on platform compatibility in the x64 Linux world. Being able to run arm docker images is not useful for a developer who needs to produce and share docker images with coworkers on intel platforms and production infrastructure which is also x64 based.

As you said, you don’t know docker from a doctor. It’s understandable that the realities are not familiar with you.

Just like with “windows on arm” it sounds workable but it really isn’t.
 
Respectfully, your advice is not helpful. You’re not familiar with docker and how it is used, so that’s understandable, but believe me when I tell you that running docker on Arm is technically possible but is practically useless in reality.

Not according to the article I linked to:

"Install the qemu instruction emulation to register Arm executables to run on the x86 machine. For best results, the latest qemu image should be used. If an older qemu is used some application may not work correctly on the x86 hardware."

"Create a multi-architecture build instance

(...)
As we have seen, building multi-architecture containers can be created with buildx in the same way as with Docker Desktop for Mac and Windows. Give it a try for yourself and start making the transition to multi-architecture Docker images today."

One of the other articles linked to at the end of the originally liked article is Arm and Docker: Better Together April 24, 2019 (ie over a year ago)

"With today’s announcement, we enable all of them to instantly become Arm developers, targeting everything from an embedded endpoint to an Arm Neoverse server in the cloud, using the same PC or Mac development environment they have always used.

(...)

This announcement is the result of our multi-year investment in the development community, software ecosystem, and the over 400 open source projects we actively contribute to. That long-term dedication to infrastructure is why most of the official images on DockerHub already support Arm and why every week there are about 200 million container images pulled from DockerHub that can also be downloaded for Arm. It is also why we are so excited about our partnership with Docker which will continue to innovate around lifecycle management, distributed workload management, heterogeneous compute, and security."

A little more searching produced:

"Docker Desktop provides binfmt_misc multi-architecture support, which means you can run containers for different Linux architectures such as arm, mips, ppc64le, and even s390x." - Leverage multi-CPU architecture support

Deploying Docker Containers on Arm Hardware Just Got Easier (Apr 25, 2019)

Leverage multi-CPU architecture support

As you said, you don’t know docker from a doctor. It’s understandable that the realities are not familiar with you.

The above is the reality over a year ago. And this year (Jun 23, 2020) there is: Preparation toward running Docker on ARM Mac: Building multi-arch images with Docker BuildX

"So, Docker will no longer be useful when you want to run the same image on Mac and on x86_64 cloud instances? Nope. Docker will remain useful, as long as the image is built with support for multi-architectures.
If you are still building images only for x86_64, you should switch your images to multi-arch as soon as possible, ahead of the actual release of ARM Mac"

"To build multi-architecture images, you need to use Docker BuildX plugin (docker buildx build ) instead of the well-known docker build command."

Docker BuildX provides the three options for building multi-arch images:
  1. QEMU mode (easy, slow)
  2. Cross-compilation mode (difficult, fast)
  3. Remote mode (easy, fast, but needs an extra machine)
Though when they say slow they mean SLOW.

Again how do you not know this?
 
Last edited:
Again how do you not know this?

How arrogant you are. Can you at least entertain the notion that your five minutes of Googling about a technology you’ve never used isn’t really sufficient to understand it better than people who use it professionally?

Of course I know all this. But you so deeply and fundamentally misunderstand the nuance of the situation that I don’t even know how I would begin trying to explain.
 
  • Angry
Reactions: Maximara
You can run x86 Windows (and other) virtual machines on an iPad or iPhone right now, by sideloading an app called UTM.

This is not really a practical solution because of memory and other limitations, but if UTM can emulate 30+ processors on Apple Silicon, Parallels can probably figure out how to emulate just one.


 
  • Love
Reactions: Maximara
How arrogant you are. Can you at least entertain the notion that your five minutes of Googling about a technology you’ve never used isn’t really sufficient to understand it better than people who use it professionally?

Of course I know all this. But you so deeply and fundamentally misunderstand the nuance of the situation that I don’t even know how I would begin trying to explain.

It would certainly help us understand the limitations if you could at least try to explain in order to share your knowledge :)

It does *appear* to be theoretically possible to build x86 containers on an ARM-Mac, but we don't know if this will actually be supported or not. This is worth a look: https://medium.com/macoclock/what-does-arm-mean-for-developers-using-macs-ecc7697584ef
 
How arrogant you are. Can you at least entertain the notion that your five minutes of Googling about a technology you’ve never used isn’t really sufficient to understand it better than people who use it professionally?

Of course I know all this. But you so deeply and fundamentally misunderstand the nuance of the situation that I don’t even know how I would begin trying to explain.

The irony within this post amazes me. Docker support for multi-arch images renders your entire gripe about not being able to "create, use, and share images" a moot point. Maybe it won't work for you in your niche scenario, but that has no bearing on the majority of developers using Docker. There are several good resources from Docker that outline this process for MacOS, Windows, and Linux:




You can even build these multi-arch images via AWS Graviton, so this is not a niche process by any means.
 
  • Love
Reactions: Maximara
How arrogant you are. Can you at least entertain the notion that your five minutes of Googling about a technology you’ve never used isn’t really sufficient to understand it better than people who use it professionally?

Of course I know all this. But you so deeply and fundamentally misunderstand the nuance of the situation that I don’t even know how I would begin trying to explain.
The old argument from authority fallacy.

The irony within this post amazes me. Docker support for multi-arch images renders your entire gripe about not being able to "create, use, and share images" a moot point. Maybe it won't work for you in your niche scenario, but that has no bearing on the majority of developers using Docker.
Right, Professionals can be wrong, out of their wheelhouse, or very poor at their job.

Case in point. When I was providing free tax service as part of my associate's degree we were required to use software the IRS had provided. Compared to Turbotax the software was horrible but both pieces of software were by professionals. Doesn't change the fact the IRS software looked and felt like it was programmed by a single person who was overdosing on Jolt cola while the Turbotax software looked and felt like it was done by group who knew what the sam hill they were doing.

Of course in that case we are talking about the government :) But don't worry the people who run our goverment are professionals and so must know what they are doing and what is best. :p

You know what is really sad? There are people who actually believe that last statement and won't realize it is ironic.

It would certainly help us understand the limitations if you could at least try to explain in order to share your knowledge :)

It does *appear* to be theoretically possible to build x86 containers on an ARM-Mac, but we don't know if this will actually be supported or not. This is worth a look: https://medium.com/macoclock/what-does-arm-mean-for-developers-using-macs-ecc7697584ef

Actually this may be supported right now in the form of Swift:
"Swift is a general-purpose, multi-paradigm, compiled programming language created for iOS, OS X, watchOS, tvOS and Linux development by Apple Inc.

"Swift for Windows" is a free, open source tool that provide runtime environment for swift programming language to compile and run on Windows OS with graphical interface."

But to run on Windows OS Swift has to either compile in x86 or be using a x86 container to run the ARM code iOS uses. Heck, back in 2017 "When you run your program for the iOS simulator, always remember that it does not execute ARM code, rather it compiled the code using x86 only." (A short story of ARM Architecture)

Now I don't know how long Apple will support Swift's ability to generate x86 code but with Universal 2 I would guess a reasonable amount of time.
 
Last edited:
It would certainly help us understand the limitations if you could at least try to explain in order to share your knowledge :)

Perhaps, but an in-depth treatise on my work environment isn't really on topic for this thread, and @Maximara's combative attitude hasn't really led me to think that he has any actual curiosity or interest beyond just shouting down my experiences. I didn't see much point to spending the effort explaining my situation for someone who clearly doesn't actually care.

Of course I'm quite familiar with multi-arch Docker images. I actually do make use of them routinely. But the reality is that you don't have to stray very far in a Docker workflow to run into performance and compatibility challenges, even when dealing with an "interpreted" language like Python. We've had issues with Python 3 code resisting cross-platform operation with Tensorflow libraries (which are C accelerated) as well as intractable performance issues that make it unreliable to have developers building and testing on one platform for eventual deployment on another platform. My organization is using, producing, and deploying docker images written in Golang, Python, C++, and Haskell. Probably a few other languages I'm forgetting. All being deployed to an x64 Kubernetes infrastructure.

Often in production our developers have a need to download the exact containers that are running in the cluster to pull locally for dtrace and debugging runs, to nail down peculiar and difficult to diagnose bugs.

Even if 95% of things can be made to work predictably and reliably in a multi-architecture environment, the impact of that last 5% is enough to push an organization to consolidate on a single architecture. It's cheaper with much less risk.

Suggestions that we just re-write everything in Swift are not really tethered to reality.
 
Even if 95% of things can be made to work predictably and reliably in a multi-architecture environment, the impact of that last 5% is enough to push an organization to consolidate on a single architecture. It's cheaper with much less risk.
That seems to be counter intuitive as all get out. Especially when "architecture" can be so broad to mean a specific combination of Motherboard, various cards, the RAM and other components.

One example of how extreme it could get was the two Dragon's Lair ports to the Mac back in the 1990's - they would run only on 68020 Macs (Macintosh II and LC) and no other type of Mac. It had to be one of the biggest "what the...?" moments I had seen.

Suggestions that we just re-write everything in Swift are not really tethered to reality.
Well there is Livecode which "runs on iOS, Android, OS X, Windows 95 through Windows 10, Raspberry Pi and several variations of Unix, including Linux, Solaris, and BSD.)" :) There is even an open source Community Edition available to mess around with.

@Nugget At the same time, ARM Macs will probably make deploying to ARM servers easier. This could give a much necessary push towards ARM clusters becoming mainstream.
I agree. Let's face it ARM is more widespread than Intel and Intel seems to be hitting a wall with as far as it can go sizewise with its x86 CPU and so they keep throwing more cores at it...which requires more power...which makes the chips run hot...which make there performance in laptops less then stellar.

I don't know if it was a one time fluke or a sign of things to come but Former Intel Engineer Explains Why Apple Switched to ARM showed there were quality control issues with Intel chips. "When your customer starts finding almost as much bugs as you found yourself, you're not leading into the right place"

As Intel in trouble? Is ARM The Future? the hardware margins are so thin on the PC side that pre installed bloatware and spyware became commonplace. (the earlier Intel is in serious trouble. ARM is the Future. says much the same thing)

ARM would change all that (which is why Microsoft has been trying to get people to use ARM PCs for two years now) but the issue has been the legacy x86 software but Apple shows that a reasonable translator (rather then an emulator) for x86/64 is possible with Rosetta 2 and Microsoft has a way to run x86/32 code on ARM.
 
Last edited:
  • Like
Reactions: dmccloud
@Nugget At the same time, ARM Macs will probably make deploying to ARM servers easier. This could give a much necessary push towards ARM clusters becoming mainstream.

Perhaps Apple have enough influence over the devops space to encourage this sort of shift, but it seems like a long shot to me. Microsoft is certainly working really hard right now with WSL to lure developers back to Windows and Linux on the desktop gets fractionally, marginally better each release. It’s anyone’s guess where things will land once the dust settles.

On the whole, I agree with what Linus Torvalds has to say on the subject. His point being that there isn’t really a good path for Arm to win in the cloud/deployment space incrementally. The benefits of homogeneity make it difficult for alternatives to become competitive.

edit to add: not sure why my link above isn’t working on mobile. If it doesn’t link to the post for you try:

 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.