Final decision: No ARM32 support (only ARM64)

[andrewleader]

We'd love your feedback on this topic, we'll be making a decision midday PST on 2/2, please let us know if you have any feedback before then!

Proposal: Reunion won't support ARM32 (only ARM64)

Background info: ARM32 has only been supported in Windows on UWP, we never built the support for Win32 apps. In addition, future ARM processors are deprecating ARM32 ISA support. All of our efforts are centered around ARM64, both native and emulation for X64 apps running on ARM64. Our Microsoft apps are planning on migrating to only ARM64.

Proposed decision: Given the deprecation of ARM32 ISA support (hardware), the migration of applications to ARM64 generally and the specific migration of Office ARM32 UWP to ARM64, there are no significant clients for ARM32 support and the trend in the marketplace is clear. Project Reunion will not produce ARM32 binaries, the only native flavor we will produce is ARM64. No statements are being made here regarding hybrid streams (e.g. ARM64EC), such support will be the topic of a different decision.

Final decision (2/10/2021): Proposed decision confirmed: For ARM architectures, only ARM64 will be supported. We appreciate all the feedback and discussion, thank you everyone!

Big thanks to Eho on our team for capturing and writing up all this info :)

[driver1998]

Technically it can't support ARM32 Desktop if Microsoft don't open up desktop Win32 APIs on ARM32 MSVC (there is a hard block in Win32 headers that checks for ARM32 and fail).
But ARM32 UWP might be here to stay, at least WinUI 3 will support back to RS4, which includes ARM32. Also IoT Core LTSC (RS5) still have several years of support, and ARM plays a big role there.

[sylveon]

there is a hard block in Win32 headers that checks for ARM32 and fail

that's odd, I've been able to compile C++ Win32 apps for ARM32 with no issues. never been able to run them tho because I don't have the hardware for it.

[driver1998]

But on the other hand, .NET 5 just dropped Windows ARM32 support, so Reunion following that is not a bad thing.

[prayaas-a]

To clarify, does the lack of ARM32 ISA support also imply 32bit x86 apps won't be emulated on Windows anymore? If so, then it's probably a good idea for folks interested in that kind of thing to request 32bit x86 only app developers to at least port their apps to 64bit x86 if not ARM64.

I'm thinking of the standard Visual Studio. VS has resisted moving to 64bit for a long time now and I'm wondering if that will change. This should be relevant to Project Reunion because Visual Studio is the tooling/IDE through which one would consume the library and with computers seeming to move in the direction of ARM, it would make more and more sense for Windows developers to start using Windows on ARM devices for development. Further, if Microsoft is going to port VS to 64bit (which I've read would be a lot of effort), they might as well start porting it to ARM64 because emulation as it stands is pretty slow. Before you ask if there is really a market for that, remember Xcode runs on the M1 Mac just fine. :) Developers often want to use the devices they target.

[andrewleader]

@EHO-makai can you comment on this?

[marswe]

Emulation of 32-bit x86 apps works by translating x86 code directly to ARM64 instructions, which means ARM32 support isn't involved or necessary. That means existing 32-bit x86 apps will continue to run on ARM64 Windows regardless of ARM32 ISA support in hardware.

[prayaas-a]

Thanks @marswe, that's exactly what I was looking for. I wasn't sure how the instructions function at a low level and if they relied on 32bit registers.

[tringi]

Well, the "ARM32 [...] we never built the support for Win32 apps" is a lie. Back in the day, there were couple dozens of apps circling the internet, crosscompiled by modified MinGW GCC that run on jailbroken Windows RT perfectly well. It was just loader-locked by strictly requiring binaries to be signed by certificate Microsoft didn't give anyone. Win32 is still there, and everything relies on that layer.

While I understand the devs don't make marketing decisions, I know good amount enthusiasts and independent devs that still hope, that Microsoft would somehow unlock their old Surface devices, so that they'd become more than trash again.

@prayaas-a

The discussion on 64-bit Visual Studio is going on for quite a few years now. There are many reasons, especially all existing extensions being 32-bit. But one rarely discussed thing is that just recompiling as 64-bit will make it slower. Software with heavy use of pointers tends to. I've done some synthetic measurement here if anyone's interested.

Also I'd absolutely love ARM64 native Visual Studio on my NovaGo laptop (Snapdragon 835). Using the emulated one is painful.

[riverar]

I'm disappointed by the short lead time here; posting this on a Friday with a Tuesday deadline is definitely antithetical to the Project Reunion principle of working out in the open.

That aside, I agree with this proposal.

[andrewleader]

I hear you and agree with you Rafael. Our policy going forward is at least 7 days of time for public feedback (notice #413 posted earlier today has a deadline of 2/9, our decision meetings are on Tuesdays). We had hoped to get this first proposal out earlier to meet that 7 day period, however schedules shipped but we decided to keep the decision date the same for this specific proposal.

If you feel that we should extend this decision period for ARM32 out till 2/9, please let me know. We certainly do not want to lose the trust of the community. Also, I'd love to know if you think 7 days is enough time for public feedback going forward. And most importantly, thank you for the honest and helpful feedback!! 😍

[AathifMahir]

All in for this decision, since Arm32 deprecated very soon. I think going with this option is much better instead of wasting resources on Arm32, we can use that resources to expand Project Reunion in more ways.

[Alovchin91]

To add to all the other answers, as far as I understand it, Apple’s M1 CPU doesn't support ARM32 instructions at all. So this proposal is only logical, since people will run Windows in emulation on M1 Macs. What's also important is to indeed make sure all stock apps are also ported to ARM64 — AFAIK some apps (Microsoft Store for example) don't run on Parallels on M1 Macs now.

[MarkIngramUK]

I support this. Our desktop apps are 64-bit only, as well as our iPad apps. Apple dropped support for 32-bit 4 years ago now:

https://www.macworld.com/article/3163248/the-future-of-ios-is-64-bit-only-apple-to-stop-support-of-32-bit-apps.html

[saint4eva]

Background info: ARM32 has only been supported in Windows on UWP, we never built the support for Win32 apps. In addition, future ARM processors are deprecating ARM32 ISA support. All of our efforts are centered around ARM64, both native and emulation for X64 apps running on ARM64. Our Microsoft apps are planning on migrating to only ARM64.

Supported. Please drop the support for ARM32.

[Tourniquet88]

To be able to give a good answer it would be very helpful to know where Windows 10 is going. Since Windows 10 Desktop ARM64 already supports x86 Emulation and also soon AMD64 Emulation. It would be interesting to know how and if will ARM32 work on Windows 10 in the future, when ISA support is not there anymore.

We also don’t know if Microsofts own Chips (SQ) will drop support for ARM32 or not.

All we were hearing from Build sessions so far was always: “Go ARM64 or ARM32, they are both equally supported.”

Overall, I would say given that Project Reunion aims for 17763 it would be bad to not be able to use that for Platforms like IoT Core which still supports ARM32 for a long time.

For me personally, I never saw a big reason to ever jump to ARM64. All of my current UWP Apps are still ARM32 only and I don't see a reason yet to upgrade to ARM64.

[Alovchin91]

Please note that likely none of your apps will work on Macs with M1 chip in virtualized Windows.

[EzraWard]

From the standpoint of simplifying the work of the Project Reunion team, providing higher quality deliverables for the supported architectures, and the pending removal of hardware ARM32 support, I agree with the plan to not include ARM32 support in this project.

[andrewleader]

Final decision: Proposed decision confirmed: For ARM architectures, only ARM64 will be supported. We appreciate all the feedback and discussion, thank you everyone! Moving this to the final decisions category.

[andrewleader]

Hi PokeCodec, please see the first posting for our reasoning. This decision is now final and closed. Thanks!