1. 20
  1.  

  2. 4

    How many ARM devices exist that run Windows by default? IIRC MS made a Surface product but it was basically a Chromebook, not a “real” machine. If that’s pretty much the space that ARM occupies in the Windows ecosystem then I really wouldn’t expect Adobe, for example, to pay any attention at all. They will port to macOS ARM because that’s all there is going to be in a few years (in terms of new machines) and, at the very least, “real” machines will have ARM CPUs, not just the budget versions (which, let’s be honest, Apple doesn’t even make in the first place).

    I’m not passing judgement on whose strategy is better, BTW, just noting that Apple is going all-in on this (at least that’s their claim) whereas MS, at least from where I’m sitting, hasn’t given anyone a powerful incentive to release ARM builds.

    1. 6

      I definitely agree that Microsoft hasn’t put as much focus on the ARM side of things as Windows. That being said, the Surface Pro X which runs on a semi-custom Qualcomm ARM SoC is decidedly not a Chromebook competitor. Having done this site, I honestly think the biggest barrier is that WPF, the framework many Windows apps are built with, doesn’t support ARM. Microsoft’s modern framework, UWP, supports it, but they couldn’t even get developers using UWP for x86.

      1. 4

        I’m typing this from a Surface Pro X machine, it is not a chromebook. It’s a real machine that can be used quite well depending on your workload. Can it be used for creative professionals working in media industries? No. Can it be used for a web developer like me? Yes. The CPU in it is not a budget CPU, it is currently the top of the line that qualcomm offers. Apple CPUs will be better of course but that doesn’t mean this one is bad, and more importantly, this machine exists now, it is available now, and it works. The only missing ingredient is more software, but even that is getting better. As soon as NodeJS and Qt become available, and the new dotNet versions ship, a ton of software will work.

        1. 2

          It’s not only about Windows support or the strategy of computer manufacturers (eg: using ARM for cheap devices). The truth is Apple’s ARM SOCs are way beyond anything in the market right now.

          I have no doubt Qualcomm et al will push for more performance and bigger chips designed for desktop but Apple is years ahead in this game and it’s going all in. If Apple can pull this off (which still remains to be seen) they will probably have the best desktop platform in the world.

          Intel and AMD are pushing for smaller processes which will produce even more heat dense chips. This is not a big problem for desktop towers but it is a problem for laptops, mini PCs and AIOs where I suspect Apple will dominate for the next 5-10 years in terms for performance, battery time, heat, etc, until the Windows world catches up.

          I wouldn’t be surprised if ARM also caught up in the server space. Less power and less cooling means much cheaper data centers.

          1. 3

            I wouldn’t be surprised if ARM also caught up in the server space. Less power and less cooling means much cheaper data centers.

            Graviton is so much cheaper at the same performance point than x86. It hasn’t taken over the market (yet) but I cannot expect that to last long.

        2. 4

          Zig has experimental Windows ARM support:

          $ zig build-exe hello.zig --strip -target aarch64-windows
          $ file hello.exe
          hello.exe: PE32+ executable (console) Aarch64, for MS Windows
          

          Not sure how to test this binary though!

          MinGW-w64 supports Windows on ARM. Zig ships with mingw-w64 source and can (almost!) use it to cross compile C code for Windows on ARM:

          $ zig cc -o hello.exe -target aarch64-windows-gnu hello.c
          lld: error: undefined symbol: __chkstk
          >>> referenced by /home/andy/Downloads/zig/lib/libc/mingw/crt/pseudo-reloc.c:472
          >>>               libmingw32.a(pseudo-reloc.o):(_pei386_runtime_relocator
          lld: error: undefined symbol: __udivti3
          >>> referenced by libcompiler_rt.a(compiler_rt.o):(__muloti4)
          

          Just needs a few contributions to add some ARM-specific implementations of compiler-rt functions (these can be ported from llvm’s compiler-rt project).

          (EDIT) the above were done with a commit which I ended up reverting after a conversation with Martin Storsjö. It seems that there is a little bit of work to be done within mingw-w64 to add proper aarch64 .def files for ntdll. He did, however, run the hello.exe from above on a real Windows ARM machine and it worked!

          (EDIT2) Martin followed up with:

          btw, I posted patches for proper shared ntdll.def.in for all platforms on the mailing list

          1. 3

            I’m glad to see some level of support! If you move ARM64 Windows to Tier 2, please do let me know! I think that would probably be the minimum bar where I’d consider it “available”. It would also need to be listed on the downloads page, but from a quick glance it looks like you’re already including all Tier 2 supported targets there anyway.

            1. 1

              I’m just trying this from a Surface Pro X running the i386 version of the last stable release and I think the compiler is locked up, or it takes a ton of time to compile a hello world. It has been some minutes…

              1. 1

                It has to build mingw-w64 from source for the target, it does take a couple minutes. Only once, then it’s cached for that target from then on. Windows support for the terminal-based progress bar was added after 0.6.0.

                1. 2

                  it crashed on my Surface Pro X, both running the 32bits version on windows trying to cross-compile to aarch64, and on WSL2 running the Linux aarch64 trying to cross-compile to windows-aarch64. I don’t want to add noise to your bug tracker, do you want an issue added there, or is it something that you folks are not looking for right now regarding that platform?

                  1. 2

                    Please do report it if you have the time!

            2. 2

              That page is missing that VSCode has an Insiders version for ARM64 and that Firefox has been shipping Windows on ARM64 versions of their browser since forever on the beta, dev, and nightly channels. Go can compile ARM32 apps for windows, I just used that last week. Rust can cross-compile to windows on arm or mozilla wouldn’t be able to ship Firefox.

              1. 1

                I’m tracking the release of VS Code so that when the ARM64 version lands in stable we’ll update the site. Firefox might get marked as available depending on if Firefox Installer.exe installs the ARM64 version. Go supports ARM32, which is more for Windows RT, not Windows 10 on ARM. Finally while Rust has an ARM64 toolchain, it requires additional steps to install. We’re discussing that here.

              2. 2

                With the introduction of macOS on ARM, I was curious how well Windows applications have been updated to support Windows on ARM, which was first released a little over two years ago. Since then, well, it doesn’t look like much progress has been made. Of the popular applications I was able to come up with, only one, VLC, has support for ARM64. I think a large part of this difficulty is the fact that virtually no development platforms support ARM64. Many Windows apps are built with WPF, which doesn’t support ARM64. Even on the Microsoft side, only a handful of applications are compiled natively for ARM64.

                I hope that by calling out the lack of support for ARM64 I can help push the platform forward and encourage more applications to release ARM64 versions!

                1. 8

                  Microsoft doesn’t have fat binaries. That makes a huge difference.

                  On macOS I press “Build” in Xcode and ship it. Assuming the code was portable, that’s all I need to do. Users don’t even need to know what CPU they have, and apps will continue to work—natively—even when the user copies them to a machine with a different CPU.

                  For Windows, I need to offer a separate download, and ask users to choose the version for the CPU they have, and then deal with support tickets for “what is CPU and why your exe is broken?” Or maybe build my own multi-arch installer that an ARM machine can run under emulation, but it can still detect and install for the non-emulated CPU. I don’t have time for either of these, so I don’t ship executables for ARM Windows, even though I could build them.

                  1. 4

                    On macOS I press “Build” in Xcode and ship it.

                    I don’t mean this to be too snarky, but do you test it on both systems?

                    I already have a multi-arch installer, and my code compiles for ARM64 fine, but I wouldn’t want to update the installer to point to a binary that I’ve never executed. The lack of supported virtualization options is noteworthy here. Right now my only real option is to spend $500-$1000 on an ARM Windows machine for this specific purpose.

                    Without a Mac devkit it’s hard to be sure, but I’d swear I saw a demo where Xcode can just launch the x64 version under Rosetta, so it becomes possible to test both on one machine. Unfortunately developers need new hardware because there’s no reverse-Rosetta for running ARM code on x64, so porting will still take time.

                    1. 3

                      Unfortunately developers need new hardware because there’s no reverse-Rosetta for running ARM code on x64

                      I’m not so sure that we really need reverse-Rosetta. The iOS simulator runs x86_64 binaries and is really accurate (except performance-wise). The Apple ecosystem already has an extensive experience of supporting both ARM and x86_64 binaries, and most Macs should be ARM in a few years in anyway. And there is already the ARM Mac mini thingy for developers.

                      1. 1

                        do you test it on both systems?

                        I haven’t, actually. In case of PPC and x86->x64 switches I just bought the new machine and tested only there. I already knew my code worked on the old architecture, so testing on both didn’t seem critical. In Apple’s case these are transitions rather than additions of another platform.

                      2. 3

                        Microsoft doesn’t have fat binaries

                        I don’t know if anyone is actually shipping things like this, but it is possible to do this on Windows by building the application as a DLL and then using a tiny .NET assembly that queries the current architecture and then loads and P/Invokes the correct version of the DLL. I saw a proof-of-concept for this a very long time ago, but I don’t think there’s tooling for it.

                        I’m not really convinced by how Apple does fat binaries. It might be a space saving if the linker could dediplicate data segments, but (last I checked) ld64 didn’t and so you really end up with two binaries within a single file. The NeXT approach was a lot more elegant. Files specific to each OS / Architecture (NeXT supported application bundles that ran on OpenStep for Windows or OpenStep for Solaris as well as OPENSTEP) was in a separate directory within the bundle, along with directories for common files. You could put these on a file server and have apps and frameworks that worked on every client that mounted the share, or you could install them locally and trivially strip out the versions that you didn’t need by just deleting their directories.

                        The ditto tool on macOS was inherited from NeXT and supported thinning fat bundles and was extended to support thinning fat binaries when Apple started shipping them. That’s a bit awkward for intrusion detection things because it requires modifying the binary and so tooling needs to understand to check signatures within the binary, whereas the NeXT approach just deleted files.

                        Now that no one runs applications from a file share, the main benefit from fat binaries is during an upgrade. When you buy a new Mac, there’s a migration tool that will copy everything from the old machine to the new one, including applications. With a decent app store or repo infrastructure, such a tool would be able to just pull down the new versions. Honestly, I’d much rather that they just extended the metadata in application and library bundles to include a download location and hash of the versions for other architectures. Then you could go and grab them when you migrated to a different system but not waste bandwidth and disk space on versions that you don’t need.

                        1. 2

                          Now that no one runs applications from a file share, the main benefit from fat binaries is during an upgrade. When you buy a new Mac, there’s a migration tool that will copy everything from the old machine to the new one, including applications. With a decent app store or repo infrastructure, such a tool would be able to just pull down the new versions. Honestly, I’d much rather that they just extended the metadata in application and library bundles to include a download location and hash of the versions for other architectures.

                          Obviously this was way back before code signatures became very load bearing on OS X… during the Intel transition I used to have a script that would spin over an app bundle and use lipo to create “thin” binaries so I could have enough room on my little SSD for all the things I used. I also pruned unnecessary localization files.

                          I forget what size that SSD was, but the difference was significant enough that learning lipo and scripting it out was worth my time.

                        2. 1

                          I can definitely understand how confusing it would be to offer multiple architecture downloads. That being said I would strongly encourage you to at least provide a way to get to the ARM64 version if it’s trivial for you to build for it. That way seekers can run your app with the best performance on their machine.

                          Honestly I’m surprised that tools like MSIX don’t support multiple architectures.

                            1. 1

                              Glad to see that! I figured they’d have some sort of solution there.

                        3. 1

                          Ended up submitting three PRs because it seems that you didn’t notice that Rust and Firefox literally just work as native Arm, Visual Studio Code has it in the beta channel, with release happening within the month too. :-)

                          1. 2

                            (Just as a note for anyone not following the GitHub discussion)

                            VS Code will be marked as available once the ARM64 version is in the stable channel.

                            Rust requires an additional step not required by the x86 version, so until the experience is transparent to the user I’m not going to mark it as available. That being said, I’ll be filing an issue with rustup to hopefully get it to install the ARM64 toolchain by default.

                            Firefox might get marked as available depending on if Firefox Installer.exe installs the ARM64 version.

                        4. 1

                          This is very sad, as ARM based systems get better battery duration. I was almost sure that it was better than this.

                          1. 1

                            Adobe remembers when they ported InDesign to OSX and Quark didn’t… and when was the last time you heard about Quark? This will drive a bunch of apps that are currently cross-platform x86 to be cross-platform and cross-arch. Once that’s done, there’ll be a lot more software for ARM Windows, which will accelerate its adoption and in-turn, further 3rd party support.

                            1. 2

                              I think the biggest issue is that there’s no real incentive for Adobe (or anyone really) to release ARM versions for Windows. With Apple, you know that every Mac will be using an ARM CPU. But with Windows I highly doubt we’d ever get to a point where even a majority are using ARM CPUs.

                              1. 1

                                Microsoft will have to strong-arm it a bit (badum-tsh) but I see it happening, otherwise all their millions sunk into Windows are going to go away.