Hacker News Reader

Comment by tonymet | Hacker News Reader

Apple and third party developers were collectively much better prepared to transition to ARM, to the point that it was totally seamless. Developers were experienced with ARM on iOS, and Apple had a robust dual-binary & backward compatibility system to make sure all apps ran smoothly.

I don't anticipate this level of compatibility with Arm on Windows. You're going to get your new machine, and many if not most of your apps won't run. The intel simulator performance will suffer.

Sometimes the migration path needs even more investment than the end product.

View on HN

I think it's also a chicken and egg problem. How many people have Windows ARM laptops, and how much incentive / how easy is it for developers to make their apps ARM-native?

There was some talk earlier about the Windows equivalent to 'fat-binaries', the new ABI and executable format.

http://www.emulators.com/docs/abc_arm64ec_explained.htm

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

You're right. In those cases a lot of up-front investment needs to be made to hit critical mass

I agree with you. But you don’t need to anticipate, right? This is like attempt number, what, 4 for Windows on ARM? Or maybe we could see this as a continuation of one of their previous failures.

Windows will never leave x86. The only reason to use Windows is that it is the legacy platform for x86 PC type programs.

The first year or two were a mess with support for Apple. I remember as late as 2023 to struggle with running certain, modern, tech stacks on the MBP M1.

It is only within the last year that I feel like the ecosystem has entirely cought up.

Obviously MS will benefit from this, if they are able to run, eg., arm64 docker images etc.

I didn’t hear consumer complaining about it much.

I recall people complaining about things like… was it docker? Other dev tools. But programmers are a niche, and a technically competent niche that can both get into trouble and find other solutions. It is essentially the opposite of consumer support.

A consumer is happy as long as they can run Edge on their computer and log in to Facebook. They will not complain about windows on ARM either.

However, we can definitely agree that certain sectors will struggle more with Windows on ARM. My intuition is that a lot of really conservative industries run on windows. Some with a bespoke program for Windows 95 they still keep running on XP.

If I wipe the windows as usual, ARM Linux should scream on here. With the usual new machine driver drama.

That would require drivers, though. With Qualcomm producing the CPUs, we'll probably need an Ahasi-scale project to make Linux usable on these devices, and that won't happen unless Windows on ARM takes off.

https://www.phoronix.com/news/Linux-6.8-ARM-Changes

https://www.phoronix.com/news/Snapdragon-8-Gen-3-Linux-6.8

> Granted, this is just about the SoC support and Snapdragon 8 Gen 3 devices of upcoming smartphones/devices will still need their respective Device Tree files added to the kernel along with any other peripheral driver support or pieces like the Qualcomm AI engine we haven't seen open-source patches for yet.

Another article seems to go into more detail (https://www.phoronix.com/news/Qualcomm-Mainline-Linux-2024):

> But still a work-in-progress is audio support, DP Alt-Mode, enabling the DSPs, USB-C power delivery, and GPU acceleration.

Hopefully the hardware is similar enough to older models that it's not too difficult to port existing open source GPU drivers, but with Qualcomm, I'll believe it when I see it.

I'm more concerned about drivers than apps, because that's where you'll absolutely need native ARM builds rather than being able to fall back on emulation.

extremely good point. Also drivers can be even more disruptive. You have a scanner you use 1 / mo but for a critical business. Everything's great on your new Arm / Windows laptop and then you find out the 5 y/o scanner driver doesn't work. Your meeting is in the morning.

Not sure about modern Windows, but on modern MacOS and Linux, at least, drivers for things like scanners and printers are generally user-mode, so can run under Rosetta-type stuff.

I'm not an expert, but it seems that Windows does have a framework call User-Mode Driver Framework, but that wouldn't help with the bulk of conventional drivers that were written in kernel-mode. Going forward it could help though but that would take years

https://learn.microsoft.com/en-us/windows-hardware/drivers/w...

Microsoft sabotaged their ARM ecosystem decades ago with their restrictive policies. The reality is that getting most Windows applications to run on ARM will be as simple as a re-compile. If Windows on ARM is unsuccessful it won't be due to technical issues but rather social ecosystem issues.

As simple as a recompile, which is not simple at all when you have a ton of third-party dependencies that are closed-source. Some applications will have (or already had) an easy time porting, while others will be forever stuck in x86 DLL hell.

ARM64EC is one of Microsoft's mediation to this. It allows incremental porting of applications to ARM.

The reality is that getting most Windows applications to run on ARM will be as simple as simply running them

Never had all that much of an issue running pretty much anything with Arm Windows on Apple Silicon.

I think it's much easier to do if you're abandoning video games entirely, something that would make no sense for windows. The only reason I'd buy a non-amd64 PC is if it's better at running amd64 software than amd64 processors.

Having seen what box64 can do on my phone, I don't think it'd be that terrible. The graphics intensive system calls are all native system library code. The CPU parts will run slower, of course, but if they can beat the M3, I don't think the result would be all that bad.

ARM has tremendous efficiency benefits. I'd happily trade off top-line performance for 3x battery life and no fans

i read this with a smile while program under rosetta crashes for the third time today

Another good comparison is WSL on windows vs Unix interface on MacOS. Ignore the technical limitations for a sec and just think about the user experience.

WSL is far less usable due to hardware, networking and filesystem inconsistencies when compared to MacOS's complete native integration.

Now I like WSL and use it as my daily driver, but the UX is not complete enough for mass market.

This ARM transition needs to be utterly seamless. 100% compatibility, 100% performance within a year and double-click ease of use

I don't get it, WSL is fundamentally not a mass market feature. Meanwhile the "Unix interface" on MacOS is ancient stuff that everyone who actually wants to use it immediately replaces wholesale with something from brew or whatever is en vogue.

You're right in some sense. The Unix interface (Darwin) is the POSIX api & toolchain that Homebrew tools are built on . Yes the included CLI tools are primitive. That Homebrew works so well IMO is a testament to Darwin

Really I find the exact opposite issue. Way to many things have started to differ between Mac and Linux for Mac to be of any real value. It's actually a negative in a lot of ways because it's close enough to trick you.

I've had to switch to just native linux but when I don't have my work laptop WSL works perfectly for all our tests while Mac fails.

Part of this is that a lot of things have become a lot more tightly coupled with Linux in the past couple decades. OS X Snow Leopard, often positioned as the “best” macOS release, also had a number of significant differences from Linux, but those differences were more frequently accounted for in software.

Historically, a lot of it was simply Linux vs BSD differences, but nowadays there's a growing gap from Apple's unwillingness to ship any GPL3 code, leaving them with some tools either stuck in time or replaced with alternatives.

It's a valid concern that linux devs should be aware of , and a reason I use Windows (If 90% of my work is in a linux vm, why pay $2000 more for the privilege with less flexibility).

"Unix interface on MacOS" which is OSX being basically built off of Free/Net BSD, is so broken that it spawned brew.

IMO Homebrew's success is a testament to the compatibility layer. All of the modern "linux" tools run natively (resident, same FS, Network, hardware) on MacOS and the patches are minimal.

I think the reference to Homebrew may have been using it as a cautionary tale, not a success story. ie. implying the Unix environment that OS X/macOS provides is so messed up that even a project attempting to remedy the shortcomings ended up producing the rather unhinged brew.

I think GP understands that and just disagrees with it.

Brew looks pretty much like a package manager that has to handle binary distributions alongside ports-style source distributions across a range of OS versions and releases and two instruction sets needs to look. It’s a bigger problem than apt purports to solve, for example, more along the lines of FreeBSD with pkg/ports having to coexist via poudriere.

But since nobody really has said why they think it’s ‘unhinged’ that’s just speculation ;)

I don’t think of what MacOS UNIX offers as being equivalent to WSL at all. One is MacOS and the other is Linux and the two are definitely not the same.

MacOS is a nice OS but if you expect it to be Linux you will have a bad time.

Seamless? How long was it that you couldn't even run Docker?

Reply on news.ycombinator.com