With Microsoft’s launch of the Surface Pro X last week, questions were once again raised about the apps that can run on it. The answer is that like any Windows 10 on ARM PC, it can run native ARM (ARM and ARM64) apps, and it can run emulated 32-bit Intel (x86) apps. This leaves out 64-bit Intel (AMD64, or x64) apps, so if you want an app that’s only available in an x64 flavor, such as Adobe Premiere Pro or Photoshop Elements, you can’t use it.
That’s going to change though. Speaking with several sources, I can confirm that Microsoft is indeed working on bringing x64 app emulation to Windows on ARM. When that will happen is a bit more unclear, but it seems like it could be in Windows 10 21H1, which would mean that the general public will have access to it in the first half of 2021, and Windows Insiders will be able to test it out next year.
Developing tools and technologies like this always carries an inherent risk – if it’s slow and cumbersome, people will complain and won’t want to use your operating system. If it’s fast and seamless, however, developers have little to no incentive to develop native ARM64 applications for Windows on ARM. That’s a fine line to tread, and definitely something Microsoft will have issues with.
On a related note, the ARM64 version of Microsoft’s new Edge browser has been released.
Developers follow the market. Even if the x64 code does run fast and seemless (and seriously, if it does – that’s great), they’ll still eventually want to deliver native bundles, once the market has proven itself. That’s just how developers are.
I also didn’t understand Thoms logic here. When 64bit CPU’s came out they ran 32bit software just fine, yet the market shifted to 64bit software by the time most people had replaced their hardware. 32bit is now completely seen as legacy and MacOS dropped it entirely recently. Apparently developers did feel motivated to adjust their software (as long as the tooling and market are there)
I prefer it that way, it requested time for people to get used to dealing with 64 bits and keeping 32 bits around would have mixed bad habits. Like the transition from ASCII to UTF-8/Unicode. Took time to get used to and now ditch out the useless knowledge.
The 32bit x86 on ARM has been benchmarked, and it’s not great…in fact it’s bad.
https://www.techspot.com/review/1599-windows-on-arm-performance/page2.html
I think it’s safe to say 64bit emulation won’t be any better. These ARM computers are not targeting high performance x86 apps. It’s not necessarily about performance though, a lot of times with productivity apps, it’s often about being able to run those proprietary apps, period.
The native performance stacks up better though, assuming most of your apps are available it’s obviously the way to go.
Those benchmarks were done on the Snapdragon 835, of course running in emulation, and testing things like “working on a large 288 MegaPixel photo in PhotoShop”. Who would even try such a task on any non-high-end machine? For zipping and Excel it all seemed to work just fine and the emulation overhead seemed like a non-issue.
We are now talking about the SQ1 which is basically the 8cX or 855 on steroids. Especially the graphics chip should have improved a lot
It is still emulation of a processor, any thing considered real work is going to be slow as hell. It evens says if you want Chrome, prepare for a terrible emulated experience. As for GPU stuff, it says right at the the end of the first page “least reliable,” and they had trouble getting those tests to even work, a sign of high level emulation where they see if they can just translate the GPU calls to their own GPU architecture. It’s not something that I would ever expect to work well, and will likely be limited to just the most popular apps as it will need constant work to keep compatibility whenever the 3rd party software publishes updates.
As far as I know it’s not exactly emulation. It’s dynamic binary recompilation, just like Parallels used to do back on G5 PPC Macintosh in order to run Windows. Or Transmeta back in the day.
The 32 bit Intel machine code is read, analyzed and rebuilt into ARM machine code. This is not exactly hard. Code built by compilers does not use Intel’s stranger instructions.
Chrome is probably especially bad for this because it spends so much time writing JIT versions of Javascript. Which then has to be rewritten into ARM code. With duplicated memory pages and lookup tables to match the different versions of code together.
>> This is not exactly hard.
Not so fast. We’re talking about x86, where
1) 100% reliable x86 decoder is not an easy task.
https://blog.trailofbits.com/2019/10/31/destroying-x86_64-instruction-decoders-with-differential-fuzzing/
2) An attempt to emulate Strong memory ordering on Weak ordering machine is a good recipe for random weird bugs.
https://preshing.com/20120930/weak-vs-strong-memory-models/
This seems to be about natural evolution, given the death of 32-Bit. So I suppose this tells us that the alleged ARM / Legacy 32-Bit support is already of fixed longevity.
Someone has looked at all the effort required and said we are not going to do this twice!
FWIW, Photoshop Express has been available in the Microsoft Store since this time last year and Adobe are allegedly already working on a WinRT “port” of the full creative suite.
Without any background technical knowledge about why this is so hard despite already supporting x86, purely strategically speaking “sometime in 2021” is way too late. They should have had full support for all Intel apps ready from day one – just like Apple did when they supported PPC apps during the transition to Intel. I know it’s not entirely comparable – MS is supporting both Intel and ARM rather than full-on switching – but that’s no reason for a half-hearted effort. Leaving gaps in app support like this open is not going to help them sell ARM machines, and without market share there is going to be less incentive for developers to compile to ARM native… it’s a chicken and egg problem, but MS are really shooting themselves in the foot by not having all the pieces in place from day one.
WinRT apps have been around since Windows 8. If you look at everything that’s in the Microsoft Store you’ll find that Microsoft’s majority of applications are already available there — and they’re universal so they’ll run on any hardware architecture that Windows runs on. So the question you’re asking should be, “Why hasn’t Microsoft encouraged 3rd parties to ready their apps for WinRT?” And I don’t know the answer to that but it’s not as if this is suddenly a brand new platform. They had a prior ARM platform named after WIndows Runtime (RT) so this is their second run at it but this time they have SOME emulation whereas before they had none. Also, as discussed previously; emulating another CPU architecture has a performance cost so it’s in everyone’s best interest to avoid that where possible and build universal WinRT apps instead. What gets lost for the developer is that they’re bound to Microsoft’s distribution model unless they want to encourage users to side load their apps.
MS did try their damndest to encourage devs to use WinRT, but in the end devs weren’t really interested in rewriting their software and consumers weren’t impressed with the quality and selection of WinRT apps that were available. The current situation is MS backpedaling on its previous strategy, after the failure of WinRT and the Surface RT laptop made them realize it wasn’t working.. Heck, even the majority of Microsoft’s own products – notably Office and the new Chromium Edge – continue to be “classic” Windows apps, not WinRT.
Then; Microsoft and Qualcomm decided to try emulation of 80×86 and Intel threatened to sue them for infringing patents, so they decided not to support anything recent (AVX, etc) to avoid Intel’s patents and released “32-bit only” because that’s what you’re left with.
If Microsoft are planning to release emulation of 64-bit 80×86 in 2021; then it’d be interesting to see which of Intel’s patents expire in 2021.
They didn’t even had native browser at day one, AFAIK.
I don’t have any Windows-on-ARM device here, so I cannot test this but I think you are wrong about this. I assume that by default a current Edge, compiled for ARM, is included. (The one that Microsoft started making almost 5 years ago to replace IE11 and Trident with EDGEHTML)
The last comment “On a related note, the ARM64 version of Microsoft’s new Edge browser has been released.” refers to the new EDGE, based on Chromium.
So unless my assumption is wrong your statement is very misleading:
* They did have a native browser at day one
* They released another, new, native browser for it a week later. (Well, a beta I assume because new-Edge will be released for all platforms mid Januari)