Isn't this big news? x64 emulation is coming to Windows on ARM

[donawalt]

It doesn't mention Apple specifically, but this sure sounds like the pump is primed for an announcement from VMware and Parallels for Windows support on Macs/ARM...

We will also expand support for running x64 apps, with x64 emulation starting to roll out to the Windows Insider Program in November. Because developers asked, Visual Studio code has also been updated and optimized for Windows 10 on ARM. For organizations, we’re committed to helping them ensure their apps work with Windows 10 and Microsoft 365 Apps on ARM64 devices with App Assure. We are working closely with Acer, HP, Lenovo, Samsung and Surface to bring these Windows 10 on ARM innovations and products to our shared customers.

It's official: x64 emulation is coming to Windows on ARM

Microsoft today made the long-awaited announcement that you'll be able to run AMD64 apps in emulation on Windows on ARM. It's coming to all generations of the platform, back to the Snapdragon 835.

www.neowin.net

Now more essential than ever — the role of the Windows PC has changed

This year brought an incredible amount of change to people’s lives. The way each of us is working, learning, creating, even how we’re connecting has changed. Many of you have turned to Windows PCs as an essential tool in these times, driving Wind

blogs.windows.com

 

[panjandrum]

This is absolutely fantastic new, and yes, it's huge (if it works). If we can get Windows running well on ARM Macs that will mean people who require Windows apps won't have to abandon Apple hardware. It also means that, hopefully, people will manage to get Window for ARM running natively on Mac hardware. Maybe Apple will even continue to support Bootcamp.

Let's keep our fingers crossed that this means reasonably decent Windows performance on Mac hardware won't soon to be a thing of the past after all.

Another article: https://www.theverge.com/2020/9/30/21495510/microsoft-windows-on-arm-x64-app-emulation

 

[donawalt]

I may be wrong, but even if the emulation incurs a 30% performance penalty, speaking as a MacBook Pro user, it won't be that long before there's a Apple-silicon-based laptop that's 50% faster than the best Intel-based MacBook Pro now. If true, then I get my few but important Windows apps running as fast or marginally faster than today, with a MacBook Pro that is significantly faster for native apps. I can live with that!

 

[thingstoponder]

Apple Silicon won’t support 32 bit apps and most Windows programs are 32 bit. Would this be problematic?

 

[donawalt]

I am far from an expert, but it says, As it stands right now, ARM64 PCs can run three kinds of apps: 32-bit native ARM apps, 64-bit native ARM apps, and 32-bit emulated Intel (x86) apps. So to the MacOS, isn't the app that matters say, Parallels, a well-behaved native app, and it uses the 32-bit x86 emulation in Windows ARM to run the Windows app? The Windows app runs inside Parallels (or VMWare), not as part of the MacOS..

 

[CWallace]

Apple Silicon won’t support 32 bit apps and most Windows programs are 32 bit. Would this be problematic?

As I understand it, Apple Silicon does not support 32-bit macOS and iOS apps natively (this is likely due to macOS 11 not supporting 32-bit macOS and iOS applications).

 

[deconstruct60]

This is absolutely fantastic new, and yes, it's huge (if it works). If we can get Windows running well on ARM Macs that will mean people who require Windows apps won't have to abandon Apple hardware. It also means that, hopefully, people will manage to get Window for ARM running natively on Mac hardware. Maybe Apple will even continue to support Bootcamp.

This means almost nothing about reviving native Bootcamp ("raw" Windows on hardware). There is a more than decent chance Apple simply does not support the boot context that Windows on ARM needs ( UEFI). So what is added to the post Windows boot context doesn't matter one lick.

If this is some kind of implied demand 'threat' to Apple ( i.e. there will be so many more millions more Windows ARM users than Mac users), then I highly doubt this move by Microsoft makes Apple that "scared" at all.

More so this is further validation that Apple's virtualized guest OS strategy path will work just fine. Windows 10 on ARM with 64bit emulation of Windows apps layered on top will probably work just fine for 85+% of the possible Window on ARM userbase out there for the next several years. Once that mode is a mainstream "norm" , Apple won't need that much more.

 

[donawalt]

I thought @thingstoponder was asking about 32 bit Win apps, which I think would work in something like Parallels per my answer #5. @CWallace replied about 32 bit MacOS and iOS apps, different but no longer aupported.

 

[deconstruct60]

As I understand it, Apple Silicon does not support 32-bit macOS and iOS apps natively (this is likely due to macOS 11 not supporting 32-bit macOS and iOS applications).

That is either one or the other. macOS 11 having no 32-bit libraries bundled or distributed on demand with it is entirely different than Apple completely stripping the 32-bit opcodes out of the ARM implementation they have done.

Not sure Apple actually gets that much flexibility with an Architectural license.

"... AArch64 provides user-space compatibility with Armv7-A, the 32-bit architecture, therein referred to as "AArch32" and the old 32-bit instruction set, now named "A32". The Thumb instruction set is referred to as "T32" and has no 64-bit counterpart. Armv8-A allows 32-bit applications to be executed in a 64-bit OS, and a 32-bit OS to be under the control of a 64-bit hypervisor.[1] ..."

ARM architecture family - Wikipedia

en.wikipedia.org

There is going to be an essential core subset of opcodes have to implement. If the ARM32 is on the "optional" list then perhaps they dropped them, but if not on the optional list then they'd have to keep them. [ ejecting the Thumb stuff is decent ejection of "old stuff probably never going to use". ] Architectural license means can add extra opcodes on top, but dropping stuff that is part of the standard would be a very dubious loophole for ARM to put into their licenses.

This impact would go past Windows though. They'd basically be nuking 32-bit apps in Linux on ARM also.

 

[deconstruct60]

I thought @thingstoponder was asking about 32 bit Win apps, which I think would work in something like Parallels per my answer #5. @CWallace replied about 32 bit MacOS and iOS apps, different but no longer aupported.

The implication about 32 MacOS and iOS is that Apple has lopped off the A32 support in their silicon implementations because Apple happens to not have any of its libraries compiled against the ARM32 opcodes. The implication is that Apple has substantially (and rather radically) forked their ARM implementation off of the AArch64 standard.

If so, that would be a big deal. That would throw a giant curveball at every other OS that expected a standard AArch64 implementation.

P.S. I wouldn't be shocked though if the A32 subsystem if still there was not optimized on Apple Silicon now and going forward. It passes required test, but Apple spends almost no time at all trying to make it faster than previous generations at all. Just "happens to be there" mode.

 

[CWallace]

Someone on a Reddit thread claimed that the A11 series does not support AArch32 execution at any level. Wikipedia does not list A32 or T32 as supported in the A11 and beyond.

 

[Marx55]

Great! Just about time. Looking forward to it in VMware Fusion for in ARM-based Apple silicon Macs.

 

[bousozoku]

Someone on a Reddit thread claimed that the A11 series does not support AArch32 execution at any level. Wikipedia does not list A32 or T32 as supported in the A11 and beyond.

Legacy Windows applications, given the chance that 64-bit Windows will run on Apple Silicon at all, will have to be 64-bit. That's not difficult for business software but hell for games. That might mean that over 95% of the applications available for Windows will no longer work. On a Qualcomm, Samsung, or other ARM-based device, things would likely be okay.

 

[Nermal]

Legacy Windows apps aren't AArch32 though. Does Windows' built-in x86 emulation actually switch the Arm to 32-bit mode or does it emulate everything and keep it in 64-bit mode?

 

[leman]

That is actually a good question. Does Apple Silicon even support 32-bit ARM? This didn't even cross my mind. If they don't, the possibility of Windows on Mac is suddenly looking much more bleak.

@Nermal if I read the Windows documentation correctly, they do use the 32-bit ARM subsystem.

 

[Icelus]

That is actually a good question. Does Apple Silicon even support 32-bit ARM? This didn't even cross my mind. If they don't, the possibility of Windows on Mac is suddenly looking much more bleak.

No, they don't, only ARM64 (same for the A11 (and later) chip).

 

[Colstan]

No, they don't, only ARM64 (same for the A11 (and later) chip).

Are you aware of that for certain?

It's clear that Apple has transitioned to only supporting 64-bit in their software. I believe the question is whether Apple Silicon has support for 32-bit instructions on the physical die, even if currently unused. It's not clear if that is the case, and may still be present either because of contractual obligations or a decision to leave it in for legacy support reasons. While 32-bit instruction support probably doesn't take up much of the die itself, if Apple is able to, there's a good chance that 32-bit support has been completely removed. Unless someone has further knowledge of this issue, we probably won't know for certain until the Apple Si Macs are released.

 

[Chozes]

This is really good news. Yes change will continue to accelerate.

For Mac users most windows stuff is 64bit nowadays.

 

[Rastafabi]

Apple Silicon won’t support 32 bit apps and most Windows programs are 32 bit. Would this be problematic?

No it wouldn’t. First off those 32bit do not run natively but rather are emulated.
Also, although this technically isn’t directly comparable with Catalina (and Big Sur) while either do not support 32bits you can install entire 32bit or 32bit compatible 64Bit virtual machines without further performance penalties but being a VM altogether.

 

[leman]

No it wouldn’t. First off those 32bit do not run natively but rather are emulated.

Not sure what you mean by "emulated". They run natively on a CPU capable of executing 32-bit code, it's just that the host OS is 64-bit.

Also, although this technically isn’t directly comparable with Catalina (and Big Sur) while either do not support 32bits you can install entire 32bit or 32bit compatible 64Bit virtual machines without further performance penalties but being a VM altogether.

Because Intel CPUs used incurrent Macs support execution of both 64bit and 32bit code. The Macs have the technical means, Apple simply deprecated the 32-bit Mac code execution (it's a limitation imposed by the OS). Operating systems that run in a hypervisor are still able to access the 32-bit hardware compatibility mode.

If Apple CPUs don't offer Aarch32 mode at all and if Windows on ARM relies on this mode being present, it simply means that Apple CPUs won't be able to run Windows — not without extensive engineering effort at least.

 

[maflynn]

It doesn't mention Apple specifically,

Emulation does not equal virtualization. Performance is going to a major issue, the last time we had a emulated windows program (on the PPC) it was dog slow

 

[The_Interloper]

Emulation does not equal virtualization. Performance is going to a major issue, the last time we had a emulated windows program (on the PPC) it was dog slow

x86 performance for 32-bit apps in Windows on ARM is awful; 64-bit is unlikely to be any better. Assuming WoA is released for Apple Silicon (and don’t forget it‘s only for a Snapdragon processor right now), I dread to think how AS is going to perform emulating Windows x86/64 apps in a Parallels WoA virtual machine.

 

[thingstoponder]

On a Qualcomm, Samsung, or other ARM-based device, things would likely be okay.

For now. The upcoming Armv9 is only 64 bit.

Are you aware of that for certain?

It's clear that Apple has transitioned to only supporting 64-bit in their software. I believe the question is whether Apple Silicon has support for 32-bit instructions on the physical die, even if currently unused..

Yes, that’s why we mean. It is our understanding that after they cut off supporting 32-bit software they cut off hardware support with their following SoC. I remember reading it at the time the chip came out. If someone wants to ask Andrei Frumusanu from AnandTech he would know, he’s andreif on Twitter and Reddit.

 

[thingstoponder]

The implication is that Apple has substantially (and rather radically) forked their ARM implementation off of the AArch64 standard.

If so, that would be a big deal. That would throw a giant curveball at every other OS that expected a standard AArch64 implementation.

Not really a fork, they just don’t support 32 bit. If an OS requires 32 bit then that would be a problem, otherwise 64 bit would work as standard. Apple showed Linux on stage so I don’t see it being a huge problem. Either way, the future of Arm is 64-bit only so software is gonna have to get dragged along eventually.

If anyone was confused my question was whether 32 bit apps could be emulated on 64 bit only silicon. Would there be a lot of overhead? Would they run worse than 64 bit emulated apps? I have no idea about this stuff.

 

[ChrisA]

x86 performance for 32-bit apps in Windows on ARM is awful; 64-bit is unlikely to be any better. Assuming WoA is released for Apple Silicon (and don’t forget it‘s only for a Snapdragon processor right now), I dread to think how AS is going to perform emulating Windows x86/64 apps in a Parallels WoA virtual machine.

Typically emulation imposes an "order of magnitude" reduction in CPU performance. But there are ways to speed this up a little, for example coding Windows system calls in native ARM. then most apps don't keep the CPU 100% loaded so you only take the 90% performance hit maybe 20% of the time when the CPU is actually in use. If the CPU is idle 80% of the time in your Windows app if does not matter so much if the emulation is very slow.

The classic example where the speed of the CPU does not matter is watching a movie. If the movie is 123 minutes long using an ulta-fast CPU does not make the movie end sooner. Likewise, if it takes you 3 minutes to read an email, it still takes 3 minutes if the CPU is slower. In most cases, the consumer would never know.

But in general, a 10X reduction in CPU speed is what to expect. If the users notice this is another question and depends on what they use their computer for. Games and media editing will run poorly in emulation.