Hacker News Reader

Comment by drvdevd | Hacker News Reader

The short answer is that phone hardware is all over the place .. x86/64 has actually made generic kernels (including Windows) possible by having a slew of very similar machines. You can't expect the same thing from ARM systems yet - each system has to be specially targeted.

View on HN

There are Windows versions that work on ARM: phone/mobile, and Win10 IoT.

They update just fine, sometimes even on the major versions. E.g. my phone initially had windows phone 8.1 and now it’s windows mobile 10. And despite the phone is 3 years old, I'm still regularly getting OS updates.

That’s why I don’t believe ARM hardware is responsible.

Not sure about ARM/Windows vs ARM/Android, but I do know that unlike the PC, Android ARM phones at least do not have things like a standardized BIOS, standardized peripheral bus enumeration, low-level firmware to hardware interface etc, or at least not to the same level..

This is why things like SBSA (https://en.wikipedia.org/wiki/Server_Base_System_Architectur...) were needed before ARM servers could even be talked about, and why things like Rasberry PI's are not directly compatible with BeagleBones, etc, at least for the low-level stuff..

Nothing to do with ARM itself; just lack of ARM standards.

This was similar in the early PC days and had similar headaches - compare the various CP/M machines with what became the 'standard' MS-DOS/IBM-PC 'platform'..

PCs do not have a standardized BIOS. BIOS configuration options vary widely, and often mean different things between different BIOS vendors. UEFI is standardized but sometimes difficult to adopt.

It is half-responsible, but MS did the necessary thing to achieve their capability to independently update the OS (and deliver it as binaries, instead of letting phone vendors built it from source, which MS do not want to distribute to anybody): they specified a common plateforme for ARM phones, that is, IIRC, basically ARM + ACPI.

Then they mandated secure boot with keys that cannot be controlled by the user, so that other systems can not leverage the platform on W10M hw :p . (That's in the spirit of what BG wanted for ACPI: something somehow incompatible with other OSes -- MS eventually managed to do this with a sidestep, but well, this did not really help their market share :P )

Pretty much. MS even balked at supporting mobile ATOM back in the day, because Intel had stripped out PCI support to reduce power requirements.

The The PocketPC and Windows Mobile situation was not much different from the Android situation today, i believe.

No, they're all similar enough. Only things forcing the upgrades are...

- Android breaks compat with old drivers every update - HW makers only ship (often vulnerable) binary blobs.

and you also have other things such as other pieces of hardware the the os needs to talk to. this might not be part of what "android is", in it's barebones, so you can't just hope to build an updated version of the os and that's it. a lot of vendors customise their android builds, which means that they need to be the ones pushing updates. i'm not siding with google, but that's the way it is. could they have done a better job in assuring continued security updates? yes, but they were far too focused on trying to spread android everywhere they could.

Reply on news.ycombinator.com