9 ms·
ARM64EC: Building Native and Interoperable Apps for Windows 11 on ARM
- 0x0 5y agoSo is there any reason at all to use the original ARM64 ABI? Adding another ABI seems like a huge undertaking. Isn't the original ARM64 windows ABI a fairly recent invention, too? Too bad they didn't make it "ARM64EC" from the get-go? Will there be two versions of every system dll, one for each ABI?
- kevingadd 5y agoARM support for Windows seems like it would predate this emulation effort by quite a while, but I'm not sure. 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.
- lukeh 5y agoAre you sure? https://docs.microsoft.com/en-us/windows/win32/winprog64/wow64-implementation-details https://docs.microsoft.com/en-us/windows/win32/winprog64/wow... suggests otherwise.
- kevingadd 5y agoI'm not sure what you mean, it says right there in the article that the 32->64 stuff is done in user mode and that there are thunks in the 32-bit binaries.
- hrydgard 5y agoNot the case. Actual thunking is only done when calling into the kernel, you can't load a 32-bit DLL into a 64-bit process or vice versa.
- fredoralive 5y agoI think GP is thinking more of how Windows 9x did 16 and 32 bit, which was full of funky thunking and only really had one set of libraries AFAIK (awaiting inevitable correction).
- TickleSteve 5y agoCompatibility with the rest of the ARM development & tooling world is one fairly large reason to stick with the original ARM64 ABI. I would imagine, for example that GCC would not now work for ARM64EC and therefore you're getting locked-in to a Microsoft world by using this.
- arthur2e5 5y agoI can actually imagine a SysV x64 flavor of ARM64EC becoming a thing in the future, assuming of course there’s no patent barrier. 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!
- my123 5y agohttps://www.linkedin.com/pulse/emulators-paradox-new-architectures-dilemma-pedro-justo https://www.linkedin.com/pulse/emulators-paradox-new-archite... ARM64EC will be a documented ABI for 3rd-party compiler developers.
- pjmlp 5y agoIt hardly matters, it isn't as if one OS executable is blindly being put to execution in another platform. Native code isn't bytecodes.
- my123 5y agoDLLs shipped with the OS (and quite some 3rd-party ones too) are ARM64X. This means that they expose both the ARM64 and ARM64EC ABIs.
- dmitrygr 5y agothe idea of mix-and-matching architectures in one address space is the cool thing here.
- deleted 5y ago[deleted]
- fomine3 5y ago> even a module can freely mix and match ARM64EC and x64 as needed Looks great. It helps ARM migration for software that heavily depending native plugins maybe like DAW.
- lukeh 5y agoSuper interesting! I wonder how close it is to the Rosetta 2 ABI mapping.
- andix 5y agoAre there finally fat binaries? Once again you would need to build and deploy separately for ARM. Put some logic into your installer or your software, which version to install. macOS, iOS and Android have built in solutions for years, to just publish Packages with multiple architectures and the system executes the appropriate binary.
- my123 5y agoOn modern Windows, you can have multi arch packages as .appxbundle or .msixbundle.
- andix 5y agoAnd so far nobody is using that.
- ripley12 5y agoYeah, MSIX is a mess and I'm not surprised by the low uptake. It's evolved from the ultra-locked-down AppX days slowly and in a very messy way; documentation is often out of date/incomplete, VS tooling is buggy, and the kicker is that App Installer (required to install an MSIX package with a double-click) doesn't even ship on all versions of Windows. I have mostly learned to live with it, but I certainly do not like it.
- arthur2e5 5y agoThe whole point of the new ABI is to not require that much rebuilding. You can keep the main application in x64 and only the performance-critical functions in a ARM64EC library. Or you can have a ARM64EC application that loads a x64 plugin or third party lib.
- collaborative 5y agoMicrosoft one step closer to conquering the mobile space (who wouldn't want an Android-compatible, ARM Windows phone that also serves as a desktop?)
- pjmlp 5y agoI was happy with the ARM Windows phone deal, without having to deal with Android Java, NDK primitive tooling that makes me miss Symbian C++, JNI boilerplate, that resource hog duo known as Android Studio/Gradle. But that is now gone, and I never bothered to make use of my DeX enabled devices in such context.
- collaborative 5y agoI also would have liked that but developers never jumped on that train. Most apps reside on Android/iOS so the appeal for the consumer and developer is that they also work on a Windows phone 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
- pjmlp 5y agoAndroid Java performs really well when one is happy to deal with Java 8 subset and cherry picked features up to Java 11, while Java 17 is getting ready to be released, Java is getting a JNI replacement, explicit SIMD, value types, GPGPU support, all stuff that will never show up on Android Java, Google's own J++ flavour. 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.
- collaborative 5y agoAgreed. I am one of those who is happy to deal with Java 7/8. Newer versions of Java also come with their own set of problems. But the very old Java 7/8 runs really fast on Android and also on Android emulators
- maga 5y agoIs there any decent ARM CPU in works for this Windows on ARM that can be comparable to M1 in terms of performance?
- scoopertrooper 5y agoNothing you can buy today. However, I imagine AWS' ARM Neoverse based Gaviton2s are quite spritely, but you can't run Windows on them yet. I suspect the successor to the Qualcomm 8cx Gen 2 will integrate X2 cores, which should give the M1 a run for its money.
- maga 5y ago> 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.
- gjsman-1000 5y agoYou, and everyone else. The SQ1 and SQ2, which are upclocked versions of the 8cx by Microsoft, are lethargic compared to an M1. And the device they come in is more expensive. https://www.cpubenchmark.net/compare/Microsoft-SQ2-vs-Microsoft-ARM-SQ1-vs-Apple-M1-8-Core-3200-MHz/4131vs4113vs4104 https://www.cpubenchmark.net/compare/Microsoft-SQ2-vs-Micros...
- scoopertrooper 5y agoQuite possibly, but progress isn't linear. Apple managed to leapfrog ARM and Qualcomm this generation, but there is nothing to say that some manufacturer won't be able to leapfrog Apple in the next. No doubt, they've had teams carefully dissecting the M1 and drawing inspiration for future generations. 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!
- robotnikman 5y ago
- timellis-smith 5y agoI wonder if the next version of the raspberry pi would serve as a good system to run Windows on Arm on. If so, I could see opportunity for it to capture a large part of the low-end Windows market.
- avhception 5y agoIf this happens, the RPi-way of booting could end up enshrined as the way to boot ARM devices in the same way the PC BIOS did until EFI came along. But maybe not, Microsoft will probably support EFI on ARM all the way. They do, don't they?
- solarkraft 5y agoAFAIK Windows ARM devices are currently all EFI based.
- imtringued 5y agoThat's backwards because the raspberry pi SoC is backwards. The reason there is a "RPi-way of booting" is that the RPi is not an "ARM computer", it is a video core "computer" (technically the video core is just a graphics chip) running a proprietary OS called threadX that just happens to have ARM cores.
- trissylegs 5y agoYea. First Windows 8 RT ARM devices used UEFI + Secure Boot. I don't see why they would change the model.
- rvz 5y agoYou can already do this (unofficially) on a Raspberry Pi 4 with Windows 10 [0]: 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'. [0] https://www.worproject.ml/ https://www.worproject.ml/ [1] https://www.youtube.com/watch?v=zLb0d7zTsRY https://www.youtube.com/watch?v=zLb0d7zTsRY
- 5y ago
- jp0d 5y agoGreat to have some healthy competition, as long as they don't force us to login using an Outlook account.
- baybal2 5y agoBecause WinTel is so tied to closed source, backward binary compatibility, and binary distriboution, Microsoft is forever trapped in the x86 space. 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.
- marcodiego 5y ago> 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.
- baybal2 5y agoNokia also had sooo much money
- marcodiego 5y agoThe competition had more.
- gjsman-1000 5y agoApple was only about 90 days from bankruptcy when they finally brought Steve Jobs back. They then managed to get a loan, and scrape together the funds they had to bring us Mac OS X, then the iPod, then an iPhone, then an iPad bringing themselves back to stability. Cash isn't everything, talent, luck, and strategy plays a factor.
- marcodiego 5y agoCash isn't everything but it is definitely critical. If apple were 90 days shorter on money, the world today could be a bit of a different place.
- larodi 5y agoMicrosoft is very likely going to make a second attempt at mobile hardware, but this time with a different strategic approach - one that allows everyone who bet on Windows 11/ARM to be able to run whatever the like without the headaches so common for Android/iOS.
- pjmlp 5y agoSurface Duo is basically that. In what concerns tablets, everyone that I see not carrying an iPad most certainly are carrying hybrid/foldable laptops with Windows on them.
- gjsman-1000 5y agoThis is not like Universal 2 on Apple's transition, where you can have x64 and ARM versions of the program in the same binary (a "fat" binary). In Universal 2, the app runs as either 100% Intel or 100% ARM, depending on platform. 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?
- gjsman-1000 5y agoMicrosoft's biggest problem, IMHO, is the question why on earth a developer would give a rip about supporting Windows on ARM. 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.
- ripley12 5y agoI mostly agree that that's the current state of things, but I'm a little more optimistic about the future. 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.
- swiley 5y agoAt this point I feel like supporting Windows in any way is probably immoral.
- neogodless 5y agoDo you mean "supporting Microsoft", or do you mean being a part of the Windows ecosystem by writing software that runs on Windows? Could you explain why you feel it is immoral?
- thrill 5y agoMicrosoft could make the uptake of their ARM64 hardware much more likely by offering all their software products on it for free for a few years until it gains some traction. I quite like my 1st gen SPX, but it's certainly got some limitations. Windows 11 preview works pretty well on it so far, FWIW.
- salgernon 5y agoClassic (Pre Mac OS X) Mac applications were 68k code blobs that lived in the resource fork of an application (The resource fork was basically a type/id database where arbitrary data could be loaded into memory and purged (ore prevented from being purged) when memory was low.) 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.)