Comment by dstaley | Hacker News Reader

Comment by dstaley | Hacker News Reader

Parent Full thread

I was a bit surprised the article didn't mention Windows on ARM at all. Following the Apple announcement, I managed to snag a Windows laptop that uses the Qualcomm Snapdragon 850 ARM SoC for dramatically less than MSRP on eBay. (To be fair, they were selling it for parts since they couldn't figure out how to remove the password. Wiping the drive and reinstalling Windows was easy enough.) For the most part, it feels just like Windows. Every app I've downloaded has _just worked_. That being said, there's definitely at least one app that won't (Wireguard since it requires an ARM64 driver to work). I've actually been tracking which software provides an ARM64 version[1]. Sadly, it looks like virtually every toolchain still needs to update to support ARM64 on Windows. I'm tracking a handful of GitHub issues, and support is definitely in the pipeline, but it's slow going. For example, .NET _still_ doesn't support Windows on ARM, despite the fact it's the flagship way to build apps on Windows, and ARM64 Windows devices have been available for almost two years.

[1] https://iswindowsonarmready.netlify.app/

Apple has tight enough grips on their hardware and software ecosystem that they can force major architectural changes onto the userbase with a hardline take-it-or-leave-it attitude, which led them through the previous three transitions. It's much harder to succeed in massive transitions when the userbase is not being forced to and are perfectly free to stay where they are and avoid the transitional inconveniences (Itanium, IPv6, Windows on ARM, etc, etc, etc.)

They also have a fair amount of software out of the gate as well as experience developing for the ISA.

And on the Apple AppStore, developers ship LLVM-IR that can be compiled to different architectures (ppc64le, x86_64, arm64, etc.), instead of pre-compiled binaries.

So when Apple releases a new chip, it can just re-compile the LLVM-IR to it, to make use of newer features and compiler optimizations for that chip.

Basically, the only applications that have to do anything to transition to Arm on Apple are those that are not using the AppStore... which from the platform's perspective, is kind of their own fault.

Bitcode is architecture-dependent, you can’t just recompile it for a random target. Additionally, Mac AppStore apps are shipped without Bitcode.

> Bitcode is architecture-dependent, you can’t just recompile it for a random target.

In general, you are correct. LLVM-IR is architecture dependent. Things like the size of a pointer, the size of an `int`, parts of the calling convention, or "architecture-specific defines in C code" have already been "hardcoded"/expanded into the generated IR.

In practice, you can easily re-compile x64 IR to arm64, as long as the IR does not use, e.g., "arch-specific" LLVM intrinsics (like explicitly using, e.g., NEON intrinsics). Apple does not let you ship this kind of bitcode to the AppStore, so if you want your software to use NEON on iOS, you need to call the opaque Apple math libraries, which they can just provide for a different architecture.

The other things you need to worry about is, e.g., calls to system libraries (e.g. you can't call a Windows API, generate IR for it, and then try to re-compile that IR for Linux, because that API will fail to link). In practice, if you provide the symbol, everything will work, and the system APIs for MacOSX, iPadOS, and iOS are quite similar.

The x86-macos IR won't be recompilable to Linux or windows, but can be made recompilable to arm-macos.

Note also that this is not the first time Apple does this with the AppStore. They silently migrated all apps from 32-bit ARM to 64-bit ARM, recompiling the software for you. This hints that they have additional capabilities to changing some architecture details in the AppStore's IR, like pointer-sizes (these Apps are not running in 32-bit compatibility mode in 64-bit CPUs, but are running as native 64-bit apps).

>Additionally, Mac AppStore apps are shipped without Bitcode.

The Apps themselves are shipped to users as binary blobs, but developers ship bitcode to the AppStore, which Apple has been recompiling for each new arm processor in their iphones (so on an iPhone 11 you get a different binary blob than on an iphone 6, but the developer didn't ship two blobs, nor they recompiled their App).

Commenting on this post from my Galaxy Book S, which is an Snapdragon ARM laptop running Windows 10 Pro.

It's currently driving 2x 1080p screens over USB C + DisplayPort chaining. It can drive 3 of these chained in this way. Keyboard and mouse are connected to the USB hub on the display, so it's a single cable connection from my laptop to start working in the morning.

I hope to have a phone at some point that runs Windows 10 Pro, that I can plug into a USB C plug and get straight to work, that would be amazing!

MSFT Edge and Windows Terminal both have ARM64 builds (and so does VS Code Insiders), and WSL works great. I work with tmux+nvim on Ubuntu ARM, which runs almost everything I need.

A lot of stuff _doesn't_ work though, but the stuff that does works well. I hope that we see some inexpensive (200-300USD?) NUC style devices that can run Windows 10, it would make for a great little computer.

I am quite sure that .NET supports Windows on ARM via UWP, and has been doing so since Windows 8 got released.

That's .NET Native, which is a completely different beast unfortunately. .NET Core is set to add support for ARM64 in .NET 5. Furthermore many .NET apps for Windows were built using WPF, which won't support ARM64 until .NET 5.

It is compatible with .NET Standard 2.0 and the latest version makes use of .NET Core 2.3.

So plenty of stuff is available.

Besides it is not like one can blindly run .NET on other platforms, because plenty of applications make use of COM or DLLs written in C++.

Sure, and that's why a good number of UWP apps have ARM64 versions. But UWP apps represent a miniscule fraction of the .NET Windows apps out there. What makes it even smaller is the fact that .NET Native is even a subset of .NET Standard, so some things like Reflection don't work without some additional tweaking. Can you write a UWP app using .NET that runs on ARM64? Sure! But basically every non-UWP Windows .NET app needs to wait for .NET 5 to build for ARM64.

Is plain win32 API supported on arm64/Windows? Is there a version of MSVC? Or does one use mingw?

Hello,

Win32 is supported with MSVC just fine.

You can also use MinGW with LLVM (not MinGW with GCC), available at: https://github.com/mstorsjo/llvm-mingw

Win32 is supported, and a supported tool chain comes with Visual Studio.

I wonder why apple is abandoning bootcamp if windows on ARM is fine?

My opinion is that Apple needed bootcamp to reassure users they could still use their windows software even if they were switching to Mac back when bootcamp was released. Now Apple and its ecosystem don't need windows anymore, in fact they would not like you to use anything other than ios and macos...

Alternatively, it looks likely that Apple will use their own GPU designs in at least some, if not all, of their ARM Macs. So running Windows on ARM would necessitate Apple porting drivers for their GPU to Windows. I have to imagine they did a cost analysis on that and decided it wasn't worth the time to support a competing platform which most users would only want for its own compatibility layer, some for games, which would need proper DX9/10/11/12 drivers for said GPU.

(this also is probably part of the reason apple deprecated opengl, I imagine)

>Alternatively, it looks likely that Apple will use their own GPU designs in at least some, if not all, of their ARM Macs.

Apple Removing Support for AMD GPUs in macOS Arm64

https://news.ycombinator.com/item?id=23754055

This is not "removing", this is "not adding yet"?

Quite likely they'll support eGPUs, and maaaaaybe big MacBook Pros with Apple SoC + AMD GPU could eventually happen??

OpenGL is still supported (and still marked deprecated) on Apple ARM

Microsoft only makes the ARM version available to OEM's, there is no retail version you could use.

I suspect the real reason is people don't use it much anymore, there were some figures published that showed the number of bootcamp users had fallen from 15% to 2% over its lifetime.

I still use it although I will probably be retired by the time my current machine needs replacing.

Reply on news.ycombinator.com