Skip to main content

Microsoft reportedly working on x64 app emulation for ARM PCs

Microsoft Surface Pro X
Microsoft Surface Pro X (Image credit: Daniel Rubino/Windows Central)

What you need to know

  • Microsoft is reportedly working on 64-bit (x64) app emulation for Windows 10 on ARM PCs.
  • The feature may be aimed for a debut in the first half of 2021.
  • Microsoft previously indicated that 64-bit app emulation was not in the cards for ARM PCs.

Microsoft may be working to break down one of the biggest barriers to using Windows 10 on ARM PCs: the inability to run 64-bit (x64) apps. According to a report from Neowin, Microsoft is working on bringing 64-bit app emulation to Windows 10 on ARM, potentially with a debut in a feature update in the first half of 2021.

Currently, Windows 10 on ARM can emulate 32-bit (x86) apps, though that comes with a slight performance hit. There is no current option for emulating 64-bit apps in the same way, prohibiting their use on Windows 10 on ARM PCs. If Microsoft were to add emulation for 64-bit apps, it's likely there would be larger performance impacts than we've seen with 32-bit apps thus far.

Still, this would be a major deal for Microsoft's ARM efforts. Qualcomm is also continuing to push forward with its dedicated ARM chips for PCs, with the latest Snapdragon 8cx making serious strides in improving performance. It's possible that by the time 64-bit app emulation is available, the performance impacts of emulating such apps won't be as noticeable as they would with the current slate of chips.

Windows 10 on ARM had a slow start, with only a few devices hitting the market after its announcement. It still hasn't taken off in a way that could seriously challenge Intel's domination of the PC platform, but Microsoft showed its support for the platform by launching the Surface Pro X this year. The Surface Pro X runs Windows 10 on ARM, powered by the Microsoft SQ1 chip, a customized version of the Snapdragon 8cx.

As Neowin notes, however, there may be some issues beyond performance to think about with 64-bit app emulation. Namely, it's unclear what the default app version will be for ARM devices when you try to install one. Will vendors prefer 32-bit or 64-bit when deciding what to offer any given PC?

If 64-bit app emulation is in the works for ARM PCs, there will be some concerns Microsoft will have to address, but it could ultimately make using one of these PCs less of a hassle for consumers.

Black Friday buyer's guide: Windows 10 laptops

Dan Thorp-Lancaster is the Editor in Chief for Windows Central. He began working with Windows Central as a news writer in 2014 and is obsessed with tech of all sorts. You can follow Dan on Twitter @DthorpL and Instagram @heyitsdtl. Got a hot tip? Send it to daniel.thorp-lancaster@futurenet.com.

55 Comments
  • A little late in my opinion.
  • Late? Bruh, there's a lot more on ARM hardware and innovation that's coming. This is a multi-year project. No one was or is expecting ARM to dominate, it's going to be a slow burn as the ecosystem grows. Also, 95% of software run on PCs like the Pro X are 32-bit, not 64-bit. This doesn't solve anything with Adobe, which will benefit from recompiling, not from 64-bit support, which is a band-aid.
  • Microsoft is either not desperate enough or too stagnant to think straight. They can straight up making tool to 100% conversion for all the apps in Android or ios and their own win32 apps better than trying to toy with emulator.
  • But a problem here is are those ios and android developers going to dump their apps in the windows store or other easy to reach place for Windows devices? (if not than hardly anyone is going to (or can even) use them)
    Besides the fact that in many cases these apps require Google or iOS API's to work properly.
  • I have no idea what this means.
  • @tompham "Microsoft is either not desperate enough or too stagnant to think straight" That makes no sense Tom. Usually the more desperate someone is the less able they are at thinking straight.
  • @Daniel Rubino Bruh? No Daniel, just no!
  • > Also, 95% of software run on PCs like the Pro X are 32-bit, not 64-bit. Well... that is an odd argument -- Pro X could not run 64-bit Intel applications, so 95% of what it could run is 32-bit, so it does not need 64-bit support. Does sound circular to me... And if "like" means broader category of devices... on my (non-pro) Surface 3, directory "Program Files" contains 50 entries and "Program Files (x86)" -- 42 entries. I am sure yours is different, as is everybody's else, but I doubt your percentage holds in the Intel world.
  • "Like" as in light computing Windows devices. On those you don't need software that uses more than 4GB of RAM. The argument isn't circular at all. And the vast majority of Windows users are never going to need apps that are 64 bit.
  • Either your have chosen to ignore the second half of my post or (non-pro) Surface 3 is not "light computing Windows device" in your classification. If the latter is the case, would you count things installed on your light device in 'Program Files' and 'Program Files (x86)' respectively and share these numbers. I suspect it is not going to be 95/5 breakdown, but I have been wrong before.
  • You own a novago or other sd 835 device lol? Jokes aside I kind of agree on this but only because it would have prevented reviewers from constantly hammering on it, while in practice it does not make all that much of a difference for these current type devices.
  • "Will vendors prefer 32-bit or 64-bit when deciding what to offer any given PC?" I think the answer to this depends if the emulation of 32bit apps results or rather maintains the Win32 RAM limitation of circa 4 Gigs (unless PAE is used but that's primarily for the server space). In the event it does, most vendors will opt for 64bit emulation as x64 supposedly has a limit of 16 exabytes....
  • I don't see the benefit in that. The only x64-only apps are some games, which are not made for touch in mind. All touch-enabled games can be recompiled to ARM64 at the click of a button, as they use UWP.
    They should use the manpower in helping companies release ARM64 builds of their apps.
  • Really sounds like MS has more faith in intel/AMD chips catching up to ARM, as why they too aren't supporting ARM64.
  • Let's revisit this comment in a month.
  • Oooooh... me-thinks someone is sitting on some juicy insider info....
  • Awesome. Looking forward to whatever you're hinting at!
  • Also all Win32 can be recompiled. The Windows SDK fully supports Win32 ARM64. There is no difference really between Win32 and UWP with respect to ARM64 support.
  • > Also all Win32 can be recompiled. Go find an article about why new Edge is not going to be available for ARM at launch, come back and say that again with the straight face.
  • Dude, the fact that it won't be available at launch doesn't mean it can't be recompiled. A canary Build of the ARM64 Edge (which is a Win32 app) was released yesterday. The fact that it isn't ready for prime time is a separate matter.
  • You (and Cruncher04) are absolutely right -- everything could be recompiled. The issue is that them pesky consumers want things to *work*...
  • By comments here and more on previous articles, I think people misunderstand the importance of 64-bit apps. Having a 64-bit OS is important so the OS as a whole can access more than 4GB of RAM, but it's rare than an individual app needs that much, which is why most apps are still 32-bit. Also, many users run Windows 10 on lower end 32-bit processors, so for compatibility with all systems, almost all apps are available in a 32-bit version. MS Office, for example, is 32 bit. Browsers can run in 64 bit or 32 bit mode. The only real benefit to 64 bit over 32 bit apps is access to more than 4GB of RAM for that app. That can come into play for a database and potentially for some really high end graphics work (but even there, caching out to the drive with a dedicated 4GB of RAM is usually sufficient). There are some graphics packages from Adobe, Corel, and others that do require 64 bit, but I can't think of much else. Sure, having the compatibility is better than not having it, but the % of users affected by only supporting 32-bit compatibility only is tiny. I run a bunch of 64-bit apps, because they exist so I tend to opt for the 64-bit version over the 32-bit version, but because they tend to be larger with no other real benefit, I'm probably just wasting RAM to do so.
  • Agreed, to add to this:
    1) the WOA devices are currently not workstations or such so they are not meant to run ram heavy programs etc.
    2) Corel and Adobe stuff (at least Corel PSP x9 and Photoshop 2018(?)) have 32 bit exe's also.
  • > many users run Windows 10 on lower end 32-bit processors Would you mind giving an example of such a processor? I am struggling to come up with something produced by Intel that is less than 10 years old and not 64-bit capable. > The only real benefit to 64 bit over 32 bit apps is access to more than 4GB of RAM for that app. No it is not, not even the main one. Anything that does integer math with any degree of precision (think images, crypto, etc.) benefits from 64-bit. Accessing files, larger than 2GB benefits from that as well. Than there are costs of making the call from 32-bit application into 64-bit kernel and returning data back from this call. There is a reason why macOS 10.15 (whatever the fancy name is) dropped support of 32-bit applications.
  • A 32 bit app is perfectly capable of using a 64 bit variable. long ints and double floats have existed for a long time.
  • You are absolutely right in that the 'long int' existed for the long time. Matter of fact, they existed much longer than they were 64-bit in size (short int <= int <= long int is all your are ever guaranteed by the standard). Heck, even 'int64_t' existed for quite a while. The question is how efficient are the operation on those things in 32-bit mode.
  • Excellent news. I really hope they get it done. Contrary to myth, they could do this if they use a "clean-room" implementation of the emulated x64 instruction set so as to not step on Intel's toes. It's legal (at least in the U.S.). As for that tidbit as to what the default app version would be for ARM devices, well obviously ARM64 or ARM32, duh! If a WOA device user installs an app, the Windows Store should first give the user an ARM32 or ARM64 binary BEFORE resorting to x86/x64, and in the case of non-store apps, the developer should ideally make all the binaries available or even just ARM32/x86 32-bit and call it a day if their app won't particularly benefit from 64-bit (either ARM64 or x86_64), problem solved.
  • Considering how Lisa from Mobile Tech Review pretty much blasted this device, I don't see emulation of x64 being the answer. It’s inferior to the Surface Pro 7 in nearly every imaginable way. A lower priced Pro 7 beats the water out of the Pro X due to the performance hit because of the emulation which in turn takes a hit on the battery life. This device is way overpriced if you are just expected to use low quality ARM64 apps. This is at best a guinea pig project.
  • I've been using my Pro X for about a week and I haven't encountered one problem with "low quality ARM64 apps". I have not turned on my Pro 4 once except to check passwords. I'm not concerned about what bench marks Lisa from Mobile Tech has said. Only thing that matters to me is does it work as my daily driver. Answer = definitely.
  • Lisa has generally speaking good reviews, but with the Pro X I think as an artist herself she focused to much on Photoshop. While not enough testing popular software used within many offfice companies (Office, Citrix etc). The number of Office users is e.g. much larger than Photoshop users but for some reason many reviewers tend to focus on Photoshop and video rendering software (probably because they themselves use that a lot) and use that as a benchmark for everything next to some synthetic benchmarks.
  • Agreed that Lisa has generally great reviews. I think she hits on a smaller, but significant segment of people who are attracted to the Surface Pro line because of the pen (artists). I think ARM is a long-play for sure... but you only get one chance to make a first impression. And it's a real pity that the first impression on the Pro X is generally "great looking device crippled by ARM compatibility/emulation woes". The Pro X is definitely impressive in showing off how far the ARM strategy has progressed. It is legitimately impressive that the emulation works as well as it does... but random errors do still crop up in specific apps, and certain operations in specific key apps are particularly laggy in emulation mode. The challenge is that emulation has to be ABSOLUTELY perfect for people to avoid the anxiety of THEIR key apps not working flawlessly. I wonder if Microsoft could pull off a pre-compile and compatibility pass like they did for many of the original XBOX games to make them playable on the newer XBOX hardware... in fact I wouldn't be surprised if that same strategy is basically the core of what they are doing here to enable general emulation.... maybe they are just missing some edge cases on compatibility that are causing the occasion app error for folks. But yea, the better outcome is that enough of these devices are successful to push devs to release ARM32/64 recompiled editions of their apps. The classic chicken/egg problem...
  • Yeah first impressions in generally could be done better, agreed. But I think the blame lies partially here with reviewers.
    I think that Office should have been used more as a benchmark for these arm devices cause in the end that is what (I think at least) many buyers are mainly going to use on it. If every reviewers burns the device because it cannot run Photoshop than those previously mentioned buyers might get the wrong impressions even though it could be a great device for them.
    Especially since Photoshop is a bad way to test the speed of the translation process, since the reason why it scrolls slowly etc it because Photoshop cannot find the igpu for gpu acceleration (Adobe has not yet implemented that yet in their code)
    , so the lags say nothing about the translation process's performance itself (yet many reviewers present like this is the case).
  • Most tech popular tech reviewers don't know anything about Windows unless they're gamers. At least Lisa Gade knows something about Windows. But she's right - at that price, the SPX is a showcase device (like the first Pixelbooks), not a good value proposition when you can just get an excellent SP7 and, generally, do more. I agree with DR that not having Chrome/new Edge ready for AMD64 was a blunder. That having been said, the only emulated app on SP7 that really matters is Chrome. The reviewers care about Adobe software, but only a tiny fraction of users care about that. Once Chrome (and new Edge) are native ARM, the SPX will be amazing for 95 percent of users, and newer, cheaper devices will be on the market that take advantage of WoA. The future for real, everyday users is bright, and so is the WoA market unless Intel blows ARM out of the water with new chips.
  • It is a two edged sword really. With x64 emulation support there is less incentive for developers to finally recompile their apps for ARM64...which should be the mid term goal.
  • I think that incentive is still there because developers (with heavier apps) don't want to see their app run handicapped (I am exaggerating a bit here but you get the idea).
  • > developers to finally recompile their apps for ARM64 I thought Edge/ARM story should have given people like you at least some idea while "recompile" is far from the whole effort, but, apparently, not...
  • By the time they achieve it, Windows on ARM will already have flopped. Microsoft should have waited until this is done before trying to push for WoARM. The Surface Pro X reviews have been mostly awful and much of them all point to Windows on ARM being the issue (again).
  • I said it last year, will say it again, ARM is a multi-phase strategy. You're about to see a new phase begin. It's not going away because literally everyone recognizes how important ARM is to computing.
  • I agree this is a multi-phase strategy. But time after time they release stuff that is half finished. You only have 1 chance to make a good impression. It's the same old Microsoft. Release now, fix later. By the time this is finished, people (non-techies) would have already moved on. This is exactly what happened to Windows Phone. I'm not saying it's an absolute failure. But it's too expensive for what you get.
  • @Tapatio_00 Yeah, MS never seem to learn by their mistakes. Daniel himself pointed to this in his article on why MS don't seem to be all in with W10X just a few days ago.
  • Link to this article? I don't see it.
  • @Daniel Rubino RT and WP/WM probably had multi-phase strategies too. Oh well, time will tell.
  • @Daniel: I wonder whether you are old enough to remember how important MIPS was to computing or, for that matter, what MIPS was :)
  • New phase? Windows 10X on ARM? It doesn't make sense to put ARM in anything else, and these machines better be cheap. I can go buy a brand new iPad for $279, Microsoft needs quality products at that price point or below.
  • My take on this is that Microsoft has a little insight on ARM processor development - it must be looking pretty good. I also think that Microsoft is doing this to serve as somewhat of a utility for those that need the 5% of software not represented in 32-bit. I see Microsoft discovering the most used and needed x64 apps and working with the developers to stand up an ARM 64-bit version, but accounting for those that don't conform. I'll say again, I think this speaks a little more to the possible advancements in ARM processor development.
  • Great strides but sometimes I wonder if the hardware stuff software teams at Microsoft are in sync? Cases of either great hardware but missing essential software or vice versa have been plugging Microsoft products for the longest time and eventually of to the downfall of some of their greatest product releases
  • One question is whether the x64 emulation supports drivers. It only support arm64 drivers, means many of your hardware are not supported for now.
  • > many of your hardware are not supported for now Your case is, obviously, different from mine or everyone else, but I feel that it is less of an issue for the device like SPX where your expansion is limited to USB and Bluetooth, where bus drivers are provided by Microsoft and device-specific functionality lives in userspace anyway.
  • I don't see the point of doing this to begin with. Users who want or need to run mostly x64 apps should buy an Intel/AMD device instead of ARM. Win32 emulation is already turning off some users on some heavy apps due to lower performance, x64 emulation will just make it worse. The fact that almost all x64 apps that users are clamouring to run on ARM devices are all heavy, resource hungry apps, running under emulation will only worsen the experience making ARM devices even less desirable. These apps are better off recompiled into ARM64.
  • > Users who want or need to run mostly x64 apps should buy an Intel/AMD device instead of ARM. Well, the problem is: I am not sure whether you can find anything worth mentioning speaking SSL and still 32-bit, but I suspect that 5 years down the road, whatever people will use for secure transport will require at least 64-bit integer math and that done very efficiently. And yes, I know that one can do 64-bit math in 32-bit app, and yes, I know how efficient that really is.
  • I can see why MS wants to do this.
    Come, devs, come. Then users will start comparing, talk about the performance and demand devs to compile ARM64 binary. Or I will have to choose other products.
    Same as win32 support of MSIX and UI 3.0. Think that's the plan.
  • You will have to start paying developers before you can start treatening them with "choosing other products". Until there is enough revenue to justify support of yet another platform, loss of the user is actually beneficial to the developer -- if you are gone, I do not have to support you and it is A Good Thing (sm).
  • Paying developers doesn't work. They tried that with Windows Phone.
  • > Paying developers doesn't work. Hm... you do sound like my previous manager. Let me tell you -- he was WRONG! :-)
  • That is perhaps to black and white. It can work and it probably did work with WP, just not enough.