ARM64EC: Building Native and Interoperable Apps for Windows 11 on ARM
blogs.windows.com
blogs.windows.com
Instead, what ARM64EC is, is that you can put some ARM code inside a normally x64 binary and ship that to ARM customers like Surface Pro X users. ARM64EC doesn't run on Intel. It's just meant to speed up the porting effort of Intel programs to ARM because you don't need to make everything ARM, just some of it, to go. The Intel bits will be translated using Microsoft's slower-than-Rosetta-2-on-already-slow-hardware translator.
How many people will use this? Considering how successful Windows on ARM has been, coupled with how apathetic most Windows developers are... I give it a low chance, but who knows?
It's not like Apple, who said that they were going full ARM on all devices, get on board or run 30% slower than you could, and we won't have that translator forever. The investment to support Apple ARM is obvious in how it pays off.
Whereas, this? You're looking at how few people have Snapdragon devices, the (by comparison to M1) truly lethargic performance, slow translation, and the fact that your x64 binaries will still work with the translator. What's the business case for adding ARM support? Almost nobody uses it, and those that do don't strictly-speaking need it for your app to work.
The only reason Microsoft has really given for supporting ARM is that you'll do it out of the mercy of your heart for those few ARM users, in the hopes that you'll help build their ARM platform for them. Tough sell.
The software support for ARM in Windows has taken big leaps and bounds in the last ~6 months; this, the more general x64 emulation, Office, WPF, and probably many others that I'm forgetting. Hardware-wise, we're finally getting a cheap ARM developer kit and we're seeing some very cheap ARM laptops like the Galaxy Book Go.
The whole thing's frustratingly slow compared to Apple's transition, but I would not be surprised if ARM is a sizeable chunk of new Windows machines a few years from now.
The cheap hardware development kit comes with a Qualcomm Snapdragon 7c. For a development kit, that chip is a joke. It's slower than almost every Windows on ARM laptop you can buy right now, which already aren't known for having good performance. It also comes with only 4GB of RAM and 64GB of storage, hardly enough to even put Visual Studio on it.
Microsoft's idea is that you'll only remote-deploy to it for testing because it's not powerful enough to actually do most programming on it. Compared to the $499 Apple Developer Kit which gave you an A12Z, 16GB of RAM and a 512GB SSD... this thing better be, what, $200 at most? It's hardly a development kit if you can't actually develop on it.
You also need to remember that Microsoft and Intel's fates are bound together. Intel can put up with Microsoft's affairs and flirtations, but if it ever started getting serious, Intel won't permit it to ever get to even minor threat level.
https://arstechnica.com/information-technology/2017/06/intel...
Officially though, it is not considered as supported.
1. It came out with 64-bit support right out the gate when Microsoft had spent over 2 years on their translator only supporting 32-bit apps, and only just recently rolled out 64-bit support for translation.
2. Unlike Microsoft's translator, Rosetta 2 scans the file ahead of time and essentially creates a small "map" of the binary to help speed things up. This results in a ~15-20 second delay you open an app in Rosetta 2 for the first time, but much faster performance afterward, while Microsoft's translator doesn't do any of this pre-mapping and has no idea what's coming next.
3. Apple's M1 SoC implements many "shortcuts" within the hardware, such as having native ability to remap Intel memory ordering. This means Rosetta 2 doesn't even have to convert x86 to ARM fully, but instead can convert x86 binaries into a hybrid of x86 and ARM together and can skip steps like memory reordering that Microsoft's translator has to do.
Some Windows fans initially said that comparing Microsoft's emulator to Rosetta 2 was unfair because Rosetta 2 "is cheating." Of course, this line of reasoning didn't last long because any cheats to get to the same end results are fair game.
Think this is just a typo - you meant the other direction?
I mean, there's no real "hybrid" thing going on at all, it's just a matter of what instructions get emitted by the compiler to match the externally observable semantics. In fact are already ARM platforms that use sequential consistency (TSO) for the memory model besides the M1; Nvidia's Jetson platforms are one such example, and a Rosetta-like translation layer on that platform would be able to take advantage of it all the same.
I guess it's just a matter of wordsmithing at the end of the day, though!
macOS, iOS and Android have built in solutions for years, to just publish Packages with multiple architectures and the system executes the appropriate binary.
I have mostly learned to live with it, but I certainly do not like it.
Or did I mix up something?
My prediction: there won't be any ARM builds for most of the applications for the next 10 years. It must become super easy, like in Xcode or Android studio, where you just tick a check-box for another architecture and it gets build and bundled automatically.
Honestly, I've become more appreciative over the years how on Macs everything is a .app in the Applications folder instead of being scattered across the OS, and if you want to back them up or uninstall them you can just move them around like files. I was hoping just a little that with Microsoft's sandboxing efforts we'd get a sandboxed .app-like file for Windows, but no luck.
The biggest problem, I think, that Microsoft has is that if I'm a company, there is literally almost zero reason to support ARM. It's technically complex, the userbase is tiny, the performance is slow on the few computers that have it, and those users don't technically need it for your app to run. So why bother?
It's almost the same level of asking a company to support Linux machines. There are probably more Linux machines floating around than Windows on ARM. It would almost make more financial sense to port your app to MacOS than Windows on ARM if you do cost/benefit.
Every packaging framework I used on windows introduced it's own problems so far. It can take literally hundrets (!) of development hours until your Installshied, MSI or MSIX package works on all your customer systems. If you have a big user base it can happen that customer support spends thousands of hours to anlyse and fix installer issues.
No, it's more than that. It's a mix-and-match of x86, and arm binary code, so you don't have to keep a two separate copies of every binary.
x64 or x86 Windows will still require the old binary format. So you once again have to build and deploy two versions.
That's what a fat binary is. Multiple architectures supported by a single binary. In the simplest case, simply by including both, though some de duplication of data segments can be managed.
Not just duplication, but they want to make the gigatons of binary only software, and libraries available for WinARM without their authors doing a thing.
Most commercial companies would simply not care enough about WinARM to move a finger.
Will there be two versions of every system dll, one for each ABI?
Historically system DLLs on windows aren't vulnerable to this kind of API skew because there's a special ABI specifically for windows APIs referred to as "stdcall", everything exported from user32.dll etc is exposed via that ABI. I would expect the same to be true here. Note also that historically there aren't separate copies of all the system DLLs on windows for 32 and 64 bit, most of the 32 bit DLLs are full of thunks that jump to the 64-bit ones if you're running on a 64-bit Windows. So that approach would also be possible here.
GCC would not work for now without the devs having even seen it, but there is no reason they would not add it. It does support stdcall on x86 after all!
ARM64EC will be a documented ABI for 3rd-party compiler developers.
Native code isn't bytecodes.
In what concerns tablets, everyone that I see not carrying an iPad most certainly are carrying hybrid/foldable laptops with Windows on them.
It has also now been done (unofficially) on Windows 11 and it works. [1] Obviously not for the faint of heart and is completely 'unsupported'.
Or you could do it yourself, today.
Looks great. It helps ARM migration for software that heavily depending native plugins maybe like DAW.
I suspect the successor to the Qualcomm 8cx Gen 2 will integrate X2 cores, which should give the M1 a run for its money.
And by that time I guess M2 will drop... As much as I dislike Apple's walled garden, I'm having hard time finding a reason to choose Windows on ARM over it.
https://www.cpubenchmark.net/compare/Microsoft-SQ2-vs-Micros...
However, yes I suspect Apple will retain dominance for at least the next few years. Thankfully for incumbents though, Apple doesn't want to be an OEM, else they'd be in some real trouble!
Qualcomm has been trying to catch up to Apple ever since the Apple A7. I don't think they'll manage to do it but I'd love to be wrong. They are probably catch up to the M1 when the successor or even the successor of that one is available.
When the PowerPC transition took place, much of the system remained in emulated 68k. PowerPC applications were typically data fork (regular file) demand paged, but they could also live as resources. The point being, once you got some data in memory, you were able to call it 68k -> PPC or PPC to 68k using something known as the MixedMode Manager.
Since a big part of the way the classic MacOS was designed was to supply function pointer callbacks, there was a tedious phase where you had to wrap any function pointers supplied to the system with a thunk that would perform the ABI translation for you.
You typically wouldn't have to write those yourself - all the toolbox APIs had a macro / inline defined that would create the thunk for you - the legacy of this can still be seen in the vestigial CarbonCore/MixedMode.h and related headers.
Anyway, it was fairly trivial to wind up with code that not only mixed processor architectures and ABIs, but also supported in process loading of third party code (like PowerPC accelerated photoshop plugins, or After Dark screen saver modules.)
But that is now gone, and I never bothered to make use of my DeX enabled devices in such context.
Android Java performs really well nowadays. It will be messy to make everything so cross-compatible but I appreciate being able to use my Windows apps on a phone that also integrates with my Android apps. Also, it might save me having to upgrade my desktop. My mobile device might be all I need from now on
I am looking forward to see if "Google for Games Developer Summit" will finally bring any improvement to the now 10 year long NDK usage pain of writing JNI boilerplate by hand, and C APIs to what is actually written as C++ underneath.
Can you brute-force it? Yes. Mobile devices? Maybe the tablet market, but Apple has that market owned in the US for premium tablets, and Microsoft's closest competitor is a more expensive and much slower device called a Surface Pro X, or a Surface Pro 7 with Intel even though the tablet experience on that thing is pretty abysmal. It's a much better laptop than tablet software-wise.
The original migration strategy was "make everyone write in C# for UWP, then it'll run everywhere". While that's almost true, only Apple can force that kind of migration.
For Microsoft to move to ARM, they will need to the whole Windows ecosystem, and every software maker to create, and maintain ARM versions of everything.
ARM64EC is a very desperate move to try working around that.
On Linux, it's simple. ./configure, make, and go for a coffee break.
Their decision to go with binary-centric model now came back to bite them. They have no future in the ARM dominated world.
Beware: microsoft has so much money. Wars are lost, if you have enough money, the other side will eventually lose. I don't think they can be written off just yet. Even considering Linux has been running well on arm for a long time, the arm world is not irrecoverable for microsoft.
Because Linux is so tied to open-source, just-recompile-everything software distribution, it will never take over the Desktop. Linux is forever trapped on the server (and embedded systems which break with the aforementioned assumptions).
> ARM64EC is a very desperate move to try working around that.
This is a narrow view. I wish software developers would spend more time in the "real world" to see how a lot of software is actually being used. Not everything is SaaS in a web browser.
> On Linux, it's simple. ./configure, make, and go for a coffee break.
Yes, and when you return, you will most likely find yourself with a set of build errors unique to your system, not a working binary.
> Their decision to go with binary-centric model now came back to bite them. They have no future in the ARM dominated world.
I don't think so. They'll actually make it work without breaking a lot of stuff. I value that. It's one of the reasons why I don't use Mac OS.
There is a big difference between Apple's transitions between architectures and failed attempts by Microsoft - Apple is also a sole creator of its hardware, not only software. After they announced transition no more PowerPC would be sold few years later. Microsoft can only dream of banning hardware producers from making x86 laptops/desktops
Classic MacOS had them before that, during the transition from 68k to PPC.
NextStep called them Multi-Architecture Binaries since Next ran on 68k, x86, and a couple of RISC CPU flavors.
> ./configure, make
Nothing involving autoconf is ever simple.
But for simple apps, "dotnet build" now achieves that level of simplicity.
https://sinclairinat0r.com/2020/02/05/compiling-net-core-for...
Ext-VOS was supposed to be the runtime that would unify VB, C++, COM and everything else that was going to come.
Their sabotage of projects like Longhorn, Managed DirectX, XNA, Singularity, Midori, C++/CLI stagnation, C++ only APIs on WinRT, are a clear indication that it will never happen.
I would be gladly be proven wrong, but I have watching this movie since Visual Studio.NET was released.