Clarifying Microsoft’s Plans for 64-Bit Apps on Windows 10 on ARM
- Paul Thurrott
- Apr 06, 2018
-
52
Microsoft always gets low marks for communication. Here’s the most recent example.
This week, the software giant inexplicably told a non-programmer from Engadget that it was about to enable 64-bit apps on Windows 10 on ARM. But as Mehedi reported, the story is a lot more nuanced than that.
Windows Intelligence In Your Inbox
Sign up for our new free newsletter to get three time-saving tips each Friday — and get free copies of Paul Thurrott's Windows 11 and Windows 10 Field Guides (normally $9.99) as a special welcome gift!
"*" indicates required fields
So let’s set the record straight.
First of all, Windows 10 on ARM is a 64-bit operating system, and there is no 32-bit version of it available. By comparison, Windows 10 on Intel/AMD ships in both 32-bit (x86) and 64-bit (x64, sometimes called AMD64) variants.
Mainstream (Intel-type) 64-bit Windows versions can run both 64-bit and 32-bit (x86) applications. Likewise, mainstream (Intel-type) 64-bit Windows 10 versions can also run both 64-bit and 32-bit Store apps. This includes both “pure” Universal Windows Platform (UWP) apps and Desktop Bridge (“Centennial”) apps.
In its initial shipping version, however, Windows 10 on ARM is only compatible with 32-bit apps*. This includes 32-bit UWP Store apps that are compiled to ARM (which run natively), 32-bit x86 UWP or Desktop Bridge Store apps (which run in emulation), and 32-bit (x86) desktop applications (which also run in emulation).
(* The one workaround is that a developer using Visual Studio today could compile a desktop application for x86, ARM32, and/or ARM64, and, in doing so, create a 64-bit ARM64 desktop application. But it’s not officially supported. Literally, no one does this.)
However, Microsoft has always maintained that it will bring ARM64 apps to the platform; this includes both ARM64 UWP Store apps and (official support for) ARM64 desktop applications. Not included, ever, are 64-bit x64/AMD64 desktop applications (which includes 64-bit Desktop Bridge apps in the Store): Windows 10 on ARM will never emulate x64/AMD64, Microsoft says.
The revelation that Microsoft provided to Engadget, for some reason, was that support for 64-bit ARM Store and desktop apps was coming sooner than we had expected. But the messaging was confused, which makes sense since this topic is confusing. It made it seem like any 64-bit app, including 64-bit (x64/AMD64) desktop applications would somehow magically start working on Windows 10 on ARM.
I asked Rafael about this and he confirmed what I had been told previously: x64/AMD64 applications will never run in emulation on Windows 10 on ARM. So I asked Microsoft for clarification, just to be sure. Today, finally, I got the following statement.
“To clarify, Microsoft is planning to release a preview of the Windows 10 ARM64 SDK for Store and desktop apps, allowing developers to recompile their Win32 desktop apps to ARM64 so they can run natively without emulation,” the Microsoft representative told me. “With the SDK, x64 apps and x86 apps will also be able to recompile to ARM64 and run natively. We will be sharing more details on the ARM64 SDK Preview at Build.”
Long story short, my central point, that x64/AMD64 applications will never run in emulation on Windows 10 on ARM, is still very much the case. But there is some new info in there.
So let’s step through this statement and pull out what’s really happening.
Microsoft is planning to release a preview of the Windows 10 ARM64 SDK for Store and desktop apps. The Build release of this SDK is only a preview, so it’s not really happening sooner than expected. I had previously figured this capability would ship as part of Windows 10 version 1809 and that appears to still be the case.
This SDK will allow developers to recompile their Win32 desktop apps to ARM64 so they can run natively without emulation. This is new; today, developers can only (officially) recompile x86/x64 desktop apps to ARM32. What this means is that those developers who created desktop applications with Visual Studio will be able to recompile them for ARM64 and create native ARM64 versions of those apps. Does this mean that Photoshop Elements (a 64-bit Desktop Bridge Store app) will one day appear on Windows 10 on ARM? Maybe. That application, like so many Win32 applications, is complex and large, and I doubt that simply checking a box in the compiler is enough to make this work. But it does open up that possibility.
With the SDK, x64 apps and x86 apps will also be able to recompile to ARM64 and run natively. I’m not sure how this differs from the previous sentence. Perhaps the word “Store” was left out, as developers today can create x64, x86, and ARM64 UWP Store apps from the same project. This SDK will add ARM64 to the matrix of target platforms. ARM32 and ARM64 apps compiled in this way will run natively on Windows 10 on ARM.
We will be sharing more details on the ARM64 SDK Preview at Build. I eagerly await this. 🙂
Microsoft, please. Next time tell someone (cough, me? Rafael, even better) who can explain this accurately. Just a thought.
Tagged with
Conversation 52 comments
-
skane2600
<blockquote><a href="#260301"><em>In reply to Waethorn:</em></a></blockquote><p> "I'm skeptical that this will provide what developers really want."</p><p><br></p><p>I suspect that what most Win32 developers really want is continued enhancement of the Win32 platform that they've invested so much time, effort, and money supporting.</p>
-
skane2600
<blockquote><a href="#260306"><em>In reply to RM:</em></a></blockquote><p>"So, this fall 64-bit Win32 apps will be available are ARM devices"</p><p><br></p><p>No. What Paul is saying is that 64-bit Win32 apps will NEVER run on ARM. Now, if those applications were rewritten and recompiled to be ARM64 apps (and thus, no longer Win32 apps) then they will run on ARM. </p><p><br></p><p>The issue, of course, is whether this conversion represents a valid business case for the 64-bit Win32 developer.</p>
-
skane2600
<blockquote><a href="#260326"><em>In reply to hrlngrv:</em></a></blockquote><p>It think it's too late to rename it but incorporating bit-sizes into platform names or even variable names is a bad idea.</p>
-
skane2600
<blockquote><a href="#260377"><em>In reply to Dick_O_Rosary:</em></a></blockquote><p>It's still not clear if Microsoft will eliminate all non-S-mode versions of Windows 10, but I would assume that anyone who is forced to buy one and wants to run their legacy applications will upgrade to Pro very quickly. Given the failure of the Windows 10 S operating system, making S mode the default on every new Windows PC would be a very risky move IMO. </p><p><br></p><p>As far as "what do you have to lose" is concerned, the answer is time, money and opportunity (which are always at stake in any business venture).</p>
-
skane2600
<blockquote><a href="#260618"><em>In reply to Dick_O_Rosary:</em></a></blockquote><p>I don't think I understand your point. What "barrier" are you referring to?</p>
-
skane2600
<blockquote><a href="#261249"><em>In reply to Dick_O_Rosary:</em></a></blockquote><p>Of course "unlocking" S mode is a Microsoft induced barrier.</p><p><br></p><p>I don't understand the difference between downloading a program from the Internet via a website and downloading a program from the Internet via the Microsoft store. </p><p><br></p><p>I don't know where the misconception that users are constantly updating their programs came from. Historically most people upgraded when there were significant new features they wanted to obtain. </p><p><br></p><p>The convenience of automatic updates has to be weighed against the potential havoc that changes in functionality and UIs can potentially cause. Not to mention the possibility of new bugs. </p>
-
skane2600
<blockquote><a href="#260375"><em>In reply to Dick_O_Rosary:</em></a></blockquote><p>The question is whether that strategy will succeed. Microsoft's track record hasn't been very good the last few years. It's also not clear if ARM64 performance can catch up with X64/AMD64.</p>
-
skane2600
<blockquote><a href="#260617"><em>In reply to Dick_O_Rosary:</em></a></blockquote><p>I think "near native performance" is a generous evaluation for emulation based on what I've read. ARM64 programs' performance will certainly be "native" on ARM64 processors, but the issue is whether that native performance will be able to match or surpass Intel's. As you say, it's the hardware that will determine that. </p>
-
skane2600
<blockquote><a href="#261250"><em>In reply to Dick_O_Rosary:</em></a></blockquote><p>Windows on Intel is obviously going to be the primary competition. The issue isn't necessarily a question of which device performs better at the high end (i.e the kind of power that "not everyone needs") but the relative performance at each price point. </p><p><br></p><p>Developers need a reason to develop ARM64 programs and users need a reason to buy the PCs that support them.</p>
-
skane2600
<p>I think part of Microsoft's communication problem is that they allow too many employees to speak for the company which leads to inconsistent or incomplete statements.</p>
-
skane2600
<blockquote><a href="#260499"><em>In reply to jd80:</em></a></blockquote><p><br></p><p>I haven't read any statement from Microsoft claiming that 100% of Windows legacy APIs will be included in Windows on ARM (if there is such a statement, I'd like to hear it). If less than full compatibility is provided, it won't be as simple as recompiling in the general case. </p><p><br></p><p>There's a difference between "frequently used" by a large group of users and "frequently used" by each individual. When an individual is considering buying an ARM-based PC, only their own needs will be relevant. </p><p><br></p><p><br></p>