Clarifying Microsoft’s Plans for 64-Bit Apps on Windows 10 on ARM

Posted on April 6, 2018 by Paul Thurrott in Dev, Windows 10 with 50 Comments

HP Envy x2 Preview: Here Comes the Future

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.

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

Join the discussion!

BECOME A THURROTT MEMBER:

Don't have a login but want to join the conversation? Become a Thurrott Premium or Basic User to participate

Register
Comments (52)

52 responses to “Clarifying Microsoft’s Plans for 64-Bit Apps on Windows 10 on ARM”

  1. Avatar

    Waethorn

    I guess the next question that they'll have to answer is how hard it will be for developers to take existing 64-bit codebase that is platform-agnostic, and get it to run on ARM64.


    Sure, you can't take an x86-64 app and just hit "recompile" if it contains low-level code, but what if a developer wants to still use 64-bit memory address space? If they don't use low-level processor features, is this intent of the new SDK features? Will developers get direct access to ARM64/v8 platform features like 64-bit NEON SIMD registers and direct GPU features?


    Is the Hexagon DSP in the Snapdragon 835 available to them?


    The alternative question I would pose is: is this just a straight recompile option to get x86 32-bit apps to run "natively" through some sort of shim compile system to ARM64 (which is the base OS arch type) so that they don't use emulation to run, and will perform faster on the same machine?


    I dunno about this. I'm skeptical that this will provide what developers really want.

  2. Avatar

    fanchettes

    This compatibility issue continues to plague all versions of Windows. It seems like when Apple switched to intel their basic position was "if you want your programs/apps to run on our machines, you need to change them to fit us." Any discussion about Windows is the other way around; "how can we modify/change/cripple Windows to accommodate the apps we last updated in 2007?"



    • Avatar

      Falex

      In reply to fanchettes: Any discussion about Windows is the other way around


      Thats because I use computer to run the applications, not Windows. Modern Windows is a platform that supports new hardware and security, but that’s only a means to an end - I only care that my application runs. There a lot of (productivity) users like me.

      Specifically, if a version of Windows can’t run my KeyNoteNF (a very old application) then I don’t care about that version of Windows - I might as well be running MacOS or a Linux dist.


  3. Avatar

    ZeroPageX

    Good to hear! Once Windows on ARM was announced, I started looking into porting my native apps. I was expecting that recompiling "portable" pure C++ desktop apps for ARM would be dead simple as I am used to writing code that can be compiled as 32 or 64 bit on Windows or Linux (ugh), but there are some unexpected differences with ARM. I have always targeted x86 processors, and I made assumptions about alignment and how the stack works. I now need to re-learn what "portable" means. It's not Microsoft's fault. It's just the nature of RISC processors. It's fascinating.

  4. Avatar

    train_wreck

    So even if a heavy x64-based “traditional” program could eventually be compiled for ARM64, I wonder what performance of such a program would be like? My gut feeling is that it would be dog slow, without some serious rearchitecting...

  5. Avatar

    Tony Barrett

    Despite Microsoft trying to push Windows in the direction *they* want it to go (no users *ever* asked for any of this ARM desktop stuff), I have a strong suspicion WinRTv2 is going to crash'n'burn just like v1 did. MS are trying to find a new market for Windows that nobody wants or needs. Who actually asked for 'always connected' Windows??? Who actually wants to pay for yet another data plan for this to work??? We all want longer battery life, but that's actually more about battery technology than anything else.

    WoA is actually just another step in MS trying to dump win32. The emulation they've put together is just a stop gap measure. They assume, eventually, that people won't even know whether the apps they're installing from the app store are x86 emulated or native ARM, and of course the app store is where MS want everything. As usual though, Microsoft's big problem is getting devs onboard, and without those, all this could stop dead in it's tracks.

    If MS get there way, Windows is heading towards being a super dumbed down, app store locked, walled garden, data slurping conduit to MS cloud services. It's NOT the Windows we grew up with, that suited power users, that was robust, tested to death IN HOUSE and offered flexibility and reliability. The last version that offered this was Win7, and MS are doing their best to kill that too.

  6. Avatar

    BlackForestHam

    The Engadget blurb is clear and didn't give anyone the impression Windows 10 on ARM was going to run 64-bit desktop apps without recompilation. It's this article, Paul, that is needlessly confusing. Keep the beer drinking to after hours, please.

  7. Avatar

    alexoughton

    Glad to see this clarification. It was always confusing that some were saying desktop apps wouldn't work with the new SDK, as people were doing this way back when we had the Windows RT 8.0 jailbreak. I had a few natively-recompiled ARM Win32 apps on my device, and they worked great. Until RT 8.1 killed the jailbreak that is...!

  8. Avatar

    skane2600

    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.

  9. Avatar

    jd80

    Just a couple of clarification I think are needed after reading some of the comments.


    Win32 (most of the time) does not have anything to do with 32-bit architecture or AMD/Intel. It simply refer to a set of system calls (API) that applications can refer to.


    And in WoA, those APIs have been recompiled to ARM. So an application using any Win32 API, be it an ARM or x86 application, will run that part natively. That the reason why some x86 app can run quite smoothly on ARM hardware compared to other. It's a matter of custom code vs API call (or dev code vs MS code). In x86 apps, custom code is emulated and API calls are not. E.g.: a game would have quite a good amount of custom code in it and would thus most probably run poorly without being re-compiled to ARM (and even then we can all agree it might not be enough depending on the game). On the other hand, if an application rely more on API calls then it might run quite well even if the remaining custom code is emulated.


    An advantage of a UWP app is that, once submitted, MS can recompile it at will to any architecture. That's why UWP apps have been immediately available on ARM hardware, no developer had to do it manually.


    As Paul once said: today the number of frequently used non-store application is pretty low. The most mainstream are the likes of Chrome, ITunes, Photoshop, Visual Studio, 3dsMax, AutoCad, just to name a few. There aren't that much more if you think about it, the others are mostly in-house apps and those probably won't run on ARM hardware anytime soon.


    Once the big apps will be compiled to ARM32/64, I think WoA could be in a good position to answer the needs of most customers.

    Of course some might never do it (e.g.: if their custom code rely heavily on some x86/x64 instructions which don't have (performant enough) equivalent on the ARM world), but I bet most will.


    hrlngrv talked about SKU hell, but I think it's really a thing of the past, like "install from a disc" past. We already stated that it's invisible for apps from the store and even for non-store app, like Chrome, most of the time there is a single download button on their webpages that select for you the best architecture to use. Most people won't even notice.

    • Avatar

      skane2600

      In reply to jd80:


      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.


      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.



  10. Avatar

    glenn8878

    The question really is when will WOA be sold to the public and how many Apps will it have? This messaging is a waste since no one will buy it without 64 bit app support regardless of how it’s implemented. Still, Microsoft will still come up with a Not Ready for Primetime version that dies prematurely.

  11. Avatar

    Sandy

    I don't think a lack of x86-64 (AMD64) emulation is a big problem for Windows 10 on ARM.


    It seems some people aren't looking past - & at the reasons for - the failures of Windows 8 on ARM, the troubles with the Windows/Microsoft Store, WinRT/UWP, etc.


    A huge problem has been the reality of the new platform (with its limited target audience) versus the large PC install base (Windows 7 & earlier) which can't run WinRT/UWP/Store apps; this is changing as Windows 10 usage has gone up and will change further after Windows 7's extended support ends in 21 months (on 2020-01-14), but of course that isn't the only issue.


    The chicken/egg problem which strangled Windows Phone is in-play here again:

    When (if ever) will enough Windows ARM laptops be out there for the makers of major 3rd party programs (e.g. Chrome) to see it as worthwhile to port their software to ARM64? Or will enough potential customers (early adopters) purchase ARM laptop despite the current limitations/lack of native ARM software?


    Unlike what happened with the Core chip designs (which replaced Intel's then very high GHz/frequency & power-hungry Pentium 4 chips), it appears Intel don't have a subsidiary/acquisition or skunkworks with a power-efficient chip design to challenge ARM, so let's hope Windows 10 on ARM does get good enough (even if it may not be for power users like us).

  12. Avatar

    edboyhan

    Modern compilers are pretty good at optimizing for all the performance tricks (pipelining, register scoreboarding, out of order execution, etc.) of different Instruction Set Architectures (ISA's). Of interest here are the X86 (both 32 & 64 bit flavors), and ARM ISA's. If one could ensure that all the code in one's app was compiled for a given target ISA, then one could be assured that your app would run, and that performance would be as good as possible given ISA architectural constraints.

    As an app dev, I can certainly compile my source code for a target ISA (X86 or ARM). But that's only part of the battle. My app is sure to invoke a variety of API's ( libraries, DLL's, COM objects, etc.). For the most part I, as an app dev, am not going to have access to source for these API's. They could be provided by Microsoft (things like .NET, win32, winrt, etc.), or from other 3rd party sources. So the question becomes how to handle the API calls your app makes? You might be able to find a winrt API that matches the functionality of a win32 API. Microsoft might have recoded some or all of the API's under their control into ARM native versions (probably most likely for winrt), or they may provide ARM emulation of some X86 API's (hopefully the decision of which API's are natively coded and which are emulated is made based on some frequency of use telemetry). Hopefully, over time most of the API's will be recoded for native ARM (that is a huge undertaking). A lot of this was done earlier for the WINRT OS, but clearly no where's near all. The Windows 10 mobile effort has resulted in virtually all of the core W10 OS having a native ARM version.

    Microsoft can do a lot to ameliorate conversions of apps to native ARM. However, there is little they can do for 3rd party API's/libraries

    Hopefully, at Build, it will become clearer as to what will run native, and what will be emulated..

  13. Avatar

    Tony Barrett

    I'm pretty sure you can't just assume that 'any' Win32 app will run on ARM. MS have their 'poster child' apps which make it look good, but there are literally hundreds of thousands of win32 apps, and I'd say >99% haven't been tested. Anyhow, x86 emulation is only there as a stop gap to try and get people onto the ARM platform. If/when MS reach critical mass, the emulation will become less relevant. Not that I think that will ever happen though. WinRTv2 will likely fall flat on it's ar*e.

  14. Avatar

    mmuntean

    :))) Well haven't you been used to MS joke communication style? Let's get serious, what dev would ever bother recompile to ARM just to please MS and their FAILED ARM attempt? Does really MS think this move would bring devs to recompile and add apps to the Store?? :)) It's not gonna happen and you know it.

  15. Avatar

    RM

    With Windows 10 on ARM being new and 64-bit, I wonder how many will actually make applications available for ARM32 after ARM64 is released this fall? I am guessing it depends on if coding changes would be needed.


    So, this fall 64-bit Win32 apps will be available are ARM devices and this will be about the time the Andromeda foldable device is released. Maybe this is one of the reasons the Andromeda has not been released yet.

  16. Avatar

    jhoersch

    This is great since it will enable shell extensions, which need to be ARM64 since that's what Explorer.exe is compiled as.

  17. Avatar

    StudBen

    Yes, as I don't actively follow Windows 10 on ARM, I just always assumed it had this functionality so when I first saw the news article I assumed it meant x64. I was a bit confused given Microsoft's previous statements on this. The problem for me came from the fact I assumed that the ability to run ARM64 was a given in 2018 so my confusion came more along the lines of, "Wait you mean up to this point Windows 10 ARM couldn't run ARM64???"

  18. Avatar

    hrlngrv

    Seems like MSFT will be sharing the SKU Hell with ISVs.

    32- and 64-bit versions for Intel/AMD and 64-bit version for ARM?

    Anyway, shouldn't it be easier to build Windows for ARM software from source code developed for Windows Intel/AMD when all the system calls would presumably be the same than build Windows. macOS and Linux versions of the same software from a single code base? Maybe not change one setting and everything rebuilds without a hitch, but there should be a lot less conditional compilation, no?

    • Avatar

      Silversee

      In reply to hrlngrv:

      There is no "SKU hell" if developers release their apps through the Store. The package management is done for you, and users receive the correct build for their device automatically.

      • Avatar

        PeteB

        In reply to Silversee:

        What developers do you believe are lining up to create windows 10 store apps?


        This is pure fantasy. With windows phone dead, UWP and the 10 store have no reason to exist.

        • Avatar

          Dick O'Rosary

          In reply to PeteB:


          Well, people have been saying the store is "dead" for years now, yet its still there. And it also looks like many new computers will default to "S" mode. So the question is, "what have you got to lose?"

          • Avatar

            skane2600

            In reply to Dick_O_Rosary:

            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.


            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).

            • Avatar

              Dick O'Rosary

              In reply to skane2600:

              "Microsoft will eliminate all non-S-mode versions of Windows 10"


              This doesn't matter because if a lot of laptops will come with S mode by default, why not make the app available on the store. Why create a barrier for the prospective customer? Why force him to upgrade to upgrade?

              • Avatar

                skane2600

                In reply to Dick_O_Rosary:

                I don't think I understand your point. What "barrier" are you referring to?

                • Avatar

                  Dick O'Rosary

                  In reply to skane2600:

                  The barrier of having to unlock S mode, going to a website, downloading a .exe from a filehosting site if you can't host it yourself, manually install and update software. All of these are barriers to your customer.

                • Avatar

                  skane2600

                  In reply to Dick_O_Rosary:

                  Of course "unlocking" S mode is a Microsoft induced barrier.


                  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.


                  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.


                  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.

          • Avatar

            mmuntean

            In reply to Dick_O_Rosary:

            Being there does not mean it's alive. No dev would bother wasting resources building for a store that has no interest when he can develop the classic win32 way, and not giving MS 30% of the 0.00001% sales...Why would I ever use VLC for example from the store when the classic one is kicking great?? Same goes for Spotify. There is NO reason like there is no reason to stick with a crippled S mode instead of upgrading to Pro and unlock the full functionality

    • Avatar

      Dick O'Rosary

      In reply to hrlngrv:

      If you go the UWP route, I think you can avoid a lot of this "hell."

  19. Avatar

    rosyna

    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”


    Microsoft doesn’t tend to take advantage of any features a new architecture offers when they release the first SDKs for a new architecture. So it might actually just be a checkbox to get initial app support.


    For example, it wasn’t until recently that Visual Studio defaulted to allowing more than the first 3GB of memory to be used in x64 apps because they wanted to 1. Avoid most pointer truncation issues, even though it reduced security, 2. so that x64 apps could be quickly released with little changes.


    There’s no reason to believe this situation won’t repeat (if third party devs manage to care about Windows on ARM). Especially since the developers did a lot of the work to move to x64 and WoW.

  20. Avatar

    PeteB

    "x64/AMD64 applications will never run in emulation on Windows 10 on ARM."


    This will be the passage on WoA's tombstone.

    • Avatar

      Dick O'Rosary

      In reply to PeteB:

      On the contrary. If MS didn't make a way for developers to recompile their apps to run ARM64 natively and relied solely on emulation, that would kill the platform.


      x64/AMD64 was never going to run emulated. From a technical standpoint, the instruction set would become too complex and you will never get a good enough performance (unacceptable performance of emulated x64/AMD64 apps, I imagine wold be the real tombstone passage, rather than its absence ;) ).


      So, it appears that the strategy is for 32bit win32 app emulation + UWP/store apps would get enough software compatibility on the nascent platform to make it acceptable for most users in the short term, while ARM64 support will provide compatibility, [and more importantly, performance] in the long term.

      • Avatar

        mmuntean

        In reply to Dick_O_Rosary:

        No devs would ever bother to recompile. This is yet another dream from MS that any dev would ever give 2 *** cents over their failed store platform. They simply don't get it!

      • Avatar

        skane2600

        In reply to Dick_O_Rosary:

        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.

        • Avatar

          Dick O'Rosary

          In reply to skane2600:

          ARM64 performance vs. x64 will be dependent on how powerful the hardware is. The only thing ARM64 support on the other hand, will guarantee for Windows on ARM is "native performance," not the "near native performance," that emulation is getting now.

          • Avatar

            skane2600

            In reply to Dick_O_Rosary:

            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.

            • Avatar

              Dick O'Rosary

              In reply to skane2600:

              The issue has never been about "surpassing Intel." Not everyone needs that kind of power, the issue is about getting rid of "performance losses" through emulation by rendering it unecessary.

              • Avatar

                skane2600

                In reply to Dick_O_Rosary:

                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.


                Developers need a reason to develop ARM64 programs and users need a reason to buy the PCs that support them.

  21. Avatar

    Angusmatheson

    It’s funny. Apple has abandoned 32 bit apps on iOS, and is now is forcing Mac users to abandon 32 bit apps on Mac soon. While Microsoft is going backwards with windows on ARM only able to use desktop 32 bit apps. Maybe that is good, because it keeps the legacy stuff that a lot of Windows users want and need. But desktop computing has been 64 bit for a long time. It just seems to be going backward to revive and use 32 bit desktop apps in 2018.

Leave a Reply