Why Windows isn’t ready for Arm developers | ZDNet

A recent column of mine hit a sour note with one open-source software developer. As it turns out, the Windows on Arm software development situation doesn’t all come down to silicon and hardware availability. Read on. — Jason Perlow

In a recent blog post, ZDNet’s Jason Perlow suggested that the main obstacle to Windows on Arm is the hardware. If only the hardware were available, we could have a great experience because the software and developer tools are ready. This is simply not true when you consider the state of developer tools on Windows for Arm.

Microsoft’s official developer toolchain is quite bad on Arm. Microsoft doesn’t provide Arm versions of Visual Studio, VS Build Tools, or even just Microsoft Visual C++; they expect Arm developers to cross-compile C++ software on an x86 host or emulate x86 software. 

There is native Arm support for .NET and VS Code, but this doesn’t help C++ developers. Since MSVC is closed source, the only way to get native support for MSVC on Arm is for Microsoft to implement it. See https://developercommunity.visualstudio.com/t/native-Arm-support-for-visual-studio/1161018

The open source situation isn’t any better. There are no Arm implementations of the MinGW or MSYS development environments; therefore, no Arm GCC or Arm Clang toolchain is available yet on Windows, either. There are feature requests open for them to add native Arm support, but it is not ready yet. If you go to Arm’s website, they have a page where you can download MinGW GCC for an x86 device to cross-compile for an Arm device. It really says something when the only way to compile your product on Windows is to use a competitor’s product.

Another popular C++ compiler on Windows is the Intel C++ compiler (ICC). This is not available on Arm for obvious reasons, and it requires Visual Studio to be installed anyway. Therefore, 0 out of 4 popular C++ compilers are available for Arm Windows.

There is no Arm native Windows version of Python yet, either. However, this will likely be resolved sometime this year: See https://bugs.python.org/issue33125

You might be wondering why it is so important to have native Arm support for compilers. Many developers already cross-compile from their computers to other devices when developing software for smartphones or consoles, so why can’t they do the same with Arm Windows devices? They can, but it’s a second-class experience.

Cross-compilation is not a native Arm toolchain for Windows

A Windows computer that can’t natively run a compiler and needs another computer to cross-compile binaries/executables for it to run is in the same class as a smartphone since you can’t develop and test on the same device. The difference here is that smartphones and consoles are not intended to be development platforms; it’s possible but unusual to write code on your phone.

Let’s imagine that you are an aspiring software developer and go to the store to get a computer so that you can learn C++. In situation A, you buy an x86 Windows device, take it home, install an IDE such as Visual Studio, write some C++ code, hit a button, and then your code is running. That’s great, you’re developing on a platform with first-class support. Now in situation B, you buy an Arm Windows device, take it home, realize that there is no Visual Studio or any C++ compilers for your computer. So what do you do? Many people would go back to the store and return the computer and buy an x86 one. Or, in situation C, you go back to the store to buy a second computer which is x86, take it home, install Visual Studio, set up a cross-compile development environment, write some C++ code, hit a button, and wait 10 seconds for it to be deployed on the Arm device. At which point you, an aspiring developer, will wonder why you shouldn’t just develop targeting x86 so you only need one computer and you can return the second-class Arm device.

Another disadvantage of Windows for Arm is no OpenGL or Vulkan support. Even if you set up a cross-compile toolchain, you are out of luck if your application uses Vulkan. If you have an OpenGL application, Microsoft’s suggestion is to use ANGLE to translate OpenGL to DirectX. 

Microsoft’s message is clear: If you want to support our new Arm Windows platform, you have to use our proprietary APIs. Similarly, the PlayStation, Xbox, Switch, and iPhone require developers to use proprietary graphics APIs, and none can run a compiler, so you have to cross-compile from another device. What developers hear is also clear: Windows for Arm is a toy operating system that can’t run industry-standard graphics APIs or compilers and therefore isn’t a serious development platform and should be treated as a phone or console.

As long as developing on an Arm Windows device is an inferior experience, developers will choose to use x86 because it has first-class support; they will never give Arm Windows the same level of support as x86. 

This second-class status will cause consumers not to want an Arm device if they would have to emulate x86 for their applications anyway, which leads to a feedback loop of developers not caring about Arm since it’s a bad experience and has few users. This, in turn, leads to hardware manufacturers not caring enough to make powerful Arm Windows devices because few people will want to spend lots of money on a second-class device. The only way to start to break this cycle is for major developer tools like Visual Studio to support Arm.

By comparison, Arm support for developer tools on macOS and Linux is much better. GCC, Clang, and Python are readily available for Arm on these operating systems and work great. You can download native versions of these developer tools and compile them natively with one device, and it works exactly as one would hope. 

Would developers think of Apple differently?

Just for a moment, I’d like you to imagine if Apple released Arm macOS without porting Clang to it and without OpenGL support. In this situation, a developer would have to get an old x86 Mac to use for development and cross-compile for the Arm Mac. If this happened, there would be an uproar, leading to fears that Apple is turning macOS into iOS, that it would be locked down, that if you couldn’t compile your own software, then soon you couldn’t run your software. It would make Arm support second-class, and people would hate it.

Purely from a C++ developer’s perspective, you could argue that Linux has better RISC-V support than Windows has Arm support. RISC-V is an open-source CPU architecture that’s very new and not ready for consumers. Linux on RISC-V is not a great experience, but there is still a compiler available so that you can do native development with native software on one device with no cross-compiling. That’s an advantage over Windows for Arm.

Microsoft’s first attempt at an Arm device was the original Surface tablet released in 2012, which ran Windows RT (Windows 8 for Arm). If Microsoft was serious about supporting Arm, they should have ported MSVC and Visual Studio to Arm back in 2012, similar to how Apple had day one support for Xcode and Clang when they released the first ARM Macs. Looking at their history, I doubt Microsoft will port Visual Studio to Arm soon. It took Microsoft until 2022 to port Visual Studio to the 64-bit version of the same architecture. That’s 19 years after the first 64-bit x86 CPU was released in 2003, the Athlon 64. To be fair, they did port MSVC itself to 64-bit x86 back in ~2005, so there is hope, but for a good developer experience, they need to port the entire Visual Studio stack to Arm.

I bought an Arm MacBook Pro 14″ to do macOS development and Arm development for Windows and Linux in Parallels VMs. I aim to support Arm macOS and Arm Linux. However, given the current state of affairs, I won’t put any additional effort into Arm Windows development until Microsoft decides it’s a real computer and there is native Arm support for Visual Studio, MSVC, OpenGL, and Vulkan. I’m sure that Microsoft will get there eventually, but the simple truth is that the Windows for ARM developer tools are not ready today even if the hardware was ready.

About the Author: Aaron Franke (@aaronfranke7) is an open source software developer based in Texas. He is a frequent contributor to the Godot 2D/3D game engine project, some of his recent contributions include porting the engine to the RISC-V CPU architecture and working on improving support for non-x86 architectures overall.