As you may recall, I was quite fond of the idea of ARM and x86 getting closer together, where on the one hand, Windows could run on ARM devices, and on the other hand, Intel was developing smaller x86-based SOCs in their Atom line, aimed at embedded use and mobile devices such as phones and tablets.
It has been somewhat quiet on that front in recent years. On the one hand because Windows Phones never managed to gain significant marketshare, and ultimately were abandoned by Microsoft. On the other hand because Intel never managed to make significant inroads into the phone and tablet market with their x86 chips either.
However, Windows on ARM is not dead yet. Microsoft recently announced the Surface Pro X. It is a tablet, which can also be used as a lightweight laptop when you connect a keyboard. There are two interesting features here though. Firstly the hardware, which is not an x86 CPU, as in previous Surface Pro models. This one runs on an ARM SOC. And one that Microsoft developed in partnership with Qualcomm: the Microsoft SQ1. It is quite a high-end ARM CPU.
Secondly, there is the OS. Unlike earlier ARM-based devices, the Surface Pro X does not get a stripped-down version of Windows (previously known as Windows RT), where the desktop is very limited. No, this gets a full desktop. What’s more, Microsoft integrated an x86 emulator in the OS. Which means that it can not only run native ARM applications on the desktop, but also legacy x86 applications. So it should have the same level of compatibility as a regular x86-based Windows machine.
I suppose we can interpret this as a sign that Microsoft is still very serious about supporting the ARM architecture. I think that is interesting, because I’ve always liked the idea of having competition in terms of CPU architectures and instructionsets.
There are also other areas where Windows targets ARM. There is Windows 10 IoT Core. Microsoft supports a range of ARM-based devices here, including the Raspberry Pi and the DragonBoard. I have tried IoT Core on a Raspberry Pi 3B+, but was not very impressed. I want to use it as a cheap rendering device connected to a display. The RPi’s GPU is not supported by the drivers, so you get software rendering only. The DragonBoard however does have hardware rendering support, so I will be trying this out soon.
I ported my D3D11 engine to my Windows Phone (a Lumia 640) in the past, and that ran quite well. Developing for Windows 10 IoT is very similar, as it supports UWP applications. I dusted off my Windows Phone recently (I no longer use it, since support has been abandoned, and I switched to an Android phone for everyday use), and did some quick tests. Sadly Visual Studio 2019 does not appear to support Windows Phones for development anymore. But I reinstalled Visual Studio 2017, and that still worked. I can just connect the phone with a USB cable, and deploy debug builds directly from the IDE, and have remote debugging directly on the ARM device.
I expect the DragonBoard to be about the same in terms of usage and performance. Which should be interesting.
Scali's OpenBlog™ 
Windows on ARM has no future IMO …
Microsoft’s x86 emulator doesn’t even support 64-bit instructions so having a WoA device is next to useless for modern desktop software. I don’t even think their x86 emulator covers SIMD extensions like SSE as well ?!
There has to be a convincing advantage in productivity to warrant people to transition to another architecture and I’m not seeing this with ARM based Windows devices but in fact I’m seeing this as a net minus or a liability judging from the reviews of the Surface Pro X or other devices based on Qualcomm chipsets.
Well, that depends on what kind of future you’re envisioning I suppose. It seems you are only looking at it as a full-scale replacement for x86 desktop Windows. I suppose it’s a bit too early for that.
An emulator is a piece of software. There’s no reason why future versions of the emulator can’t support 64-bit, SSE, AVX and whatnot. If there’s enough demand for that.
But in the end the emulator is just a stopgap solution. The real strength of Windows on ARM will be when desktop applications are compiled natively for ARM. For .NET applications this is trivial. Most code can be run on ARM directly, only when you interface with native code do you need to make changes to the application.
Many modern applications are even written mostly in HTML/JavaScript, and the ‘app’ is merely a browser-host disguised as a standalone application. Those can be run as-is on ARM devices.
For C/C++ code it will be somewhat more difficult, depending on how portable the code is set up (my code is generally written to be very portable, so my C/C++ codebase already runs on ARM).
I think you’re focusing too much on it being Windows, and not enough on it being a mobile device. I’m not interested in using an ARM-based Windows device for legacy/x86/desktop applications at all. I am interested in Windows IoT Core, which gives me cheap embedded devices that can run code that required relatively expensive x86 hardware until now.
Which is basically similar to smartphones, tablets and whatnot. None of them came with an x86 emulator, or any way to run Windows applications. They could only run applications specifically developed for that platform.
That didn’t stop them from becoming a huge success. I think Windows on ARM just needs to find its own niche, and then it can grow from there. It may grow into a complete replacement for x86 eventually, if all the relevant applications are available in native ARM versions.
There may be a market for tablets/small/cheap laptops that can run Microsoft Office and other basic apps (like Paint.NET), using the standard Windows look-and-feel. Windows on ARM could deliver that. And as said, Windows IoT could also be Microsoft’s ticket into the embedded/makers community. x86 was too expensive to compete with Arduino, Raspberry Pi and all that.
Windows IoT offers access to Microsoft’s cloud services and development tools, which is a very nice package.
Even I don’t foresee Windows succeeding in the IoT space, with ARM or not either way and the only code embedded devices will be running on Windows is outdated x86 software. Sure Microsoft can keep updating the emulator to add more features but this isn’t going to work out in the long term since embedded/mobile systems have lot’s of architectural/hardware limitations that prevent real-time translation of modern code being practical in a lot of cases or let alone portable. Do most ARM based counterparts even come with an AVX/AVX2 equivalent ? Leaving SIMD extensions aside, can Microsoft realistically keep coping with future x86 ISA extensions if AMD/Intel wants to keep adding new hardware features to defend their x86 walled garden ? Also how is Microsoft also going to deal with potential “slow-paths” as recently observed when AMD x86 processors executes PDEP/PEXT instructions ? Even ARM based processor designs must have such weaknesses so I shudder the thought of what will happen to any semblances of performance left if the emulation involves executing the “slow paths”.
TBH, all these questions made me realize how ARM replacing x86 desktop systems is nothing more than a fantasy because it’s absolute insanity dealing with a volatile target such as emulating x86 systems when the project is constantly threatened with facing new extensions, slow paths, or other architectural/hardware design mismatches because even Microsoft realizes the futility in this effort since progress can be undone easily.
Leaving the technicalities aside I guess the real test for Windows on ARM will be it’s ecosystem/community development as you mentioned. I still very much remain unconvinced on this front since it’s been over 2 years the platform has launched and it has yet to see headwinds in adoption by developers. How does Microsoft expect Windows on ARM to proliferate if the wider community can’t get their hands on it or worst case what if the wider community doesn’t want it ? Are there any inherent advantages for the developer to target Windows on ARM instead of Android/Linux on ARM ? There has to be some key differentiation factors for WoA to carve out this ‘niche’ that you speak of …
This is why I don’t think we should even have this discussion…
Firstly, Windows IoT Core is a stripped-down OS, which doesn’t have a desktop, let alone an x86-emulator. So it cannot run legacy x86 Windows software in the first place. That’s not what it’s meant for.
Secondly, you’re arguing like any OS can only ever succeed if it can run legacy x86 Windows software. Can linux only succeed on x86 with Wine? Or Android? MacOS? iOS? None of them rely on x86 or Windows software.
The x86 emulator is only a ‘bonus feature’ for the new Surface Pro X machine, so that people can run x86 applications as well. It’s not meant to primarily run them. Again, it’s like Wine: if you want to, the option is there. But those are not the ONLY applications you can run, and won’t be your primary choice. So it doesn’t HAVE to work out in the long term.
As I already said, for most applications it’s trivial to get them running on ARM natively. Software vendors will likely provide native ARM versions of their software, if the platform takes off.
ARM does have its own SIMD extensions, known as NEON. But performance is not the main thing for IoT devices, or embedded devices in general.
Again, I don’t see your point. It generally takes years for new x86 ISA extensions to be adopted as standard. Adding them to an emulator is not going to take all that long. So I don’t see a problem there. As for “slow-paths”, those are a hardware-specific issue, and don’t apply to emulators.
Well, I never said ARM would replace x86 desktop systems. Even so, it seems you have no knowledge of the x86 history.
People said the same about x86 in the server/workstation/supercomputer market for years. x86 is never going to work, because x86 doesn’t have the performance, can’t run existing software etc. But x86 got there in the end, and has wiped out nearly all other architectures.
ARM is basically doing the same as x86, in wiping out competing architectures in various markets. It seemed unlikely that ARM would replace cheap microcontrollers, but there are such cheap ARM microcontrollers now (like the STM32F series), that it no longer seems worthwhile to get an even cheaper 8-bit/16-bit microcontroller, with more limitations.
And again, x86 emulation is not the primary goal of Windows on ARM.
What do you mean “can’t get their hands on it”? You can download Windows IoT Core for free, and it can run on a variety of devices, including Raspberry Pi’s and Qualcomm Dragonboards.
And obviously you can also download Visual Studio Community for free. So if you have a Raspberry Pi or other supported device, you can download Windows IoT Core and the dev tools today, and get started right now.
I already answered that: the Microsoft ecosystem, with Visual Studio and other tools, and hooking into Microsoft Azure cloud services etc. For me personally, using DirectX and Media Foundation instead of OpenGL ES and proprietary hardware video decoding gives me better performance and compatibility. Also, it’s easier for me to re-use C# and native C++ code from our Windows applications on Windows IoT Core.
Pingback: The strong ARM | Scali's OpenBlog™