Last week, we reported that MediaTek is planning to build a chipset for Windows on ARM. As it turns out, the Windows on ARM chipset space could be even hotter than that, because there’s a reason that we’ve only seen Qualcomm SoCs in ARM PCs so far. Qualcomm actually has an exclusivity deal with Microsoft for Windows on ARM, and speaking with people familiar with it, we’ve learned that the deal is set to expire soon.
That certainly explains the dearth of Windows on ARM devices.
Well, that, and the fact nobody wants Windows on ARM devices.
I actually want Windows on ARM. But they really have limited support for their OS. Not only drivers would be an issue (like Linux ARM, unfortunately), but they don’t sell you the Windows ARM license as a stand alone product.
I think I can get one though MSDN, but need a new subscription. But have no urgency to navigate their obfuscated “business” sales.
Back in the day Windows spread like wildfire, since anybody could build their computer from parts, and install Windows on it. Yet, today even though highly accessible entry level ARM PCs exist (like Raspberry PI 400), it is a hassle to get Windows running there: https://arstechnica.com/gadgets/2021/09/new-script-makes-it-easyish-to-put-windows-10-or-11-on-a-raspberry-pi/
@sukru
isn’t the difference that on ARM-systems there is no compatibility layer like on x86 with BIOS in the old days?
th22,
IMHO there’s lots of merit in having portable ARM computers running linux, but the lack of universal standards has been a big barrier to adoption for alt OS. Especially if you’re stuck with proprietary kernels. There are continuing efforts to reverse engineer these computers to get linux running on ARM, but it’s one of those things you wish we could just have a universal standard and be done with it already. Microsoft requires windows certified ARM computers to run UEFI, which would be fine except the same certification also requires UEFI to block the installation of alternative operating systems. Ongoing crap like this is why don’t have things that just work. The vendors who want hardware and software to be bundled consider 3rd party incompatibility a “feature”. Likewise the inability to update a kernel is also a feature for them in terms of planned obsolescence. I don’t believe they feel any responsibility or incentives to fix these issues because it’s our problem and not theirs 🙁
For better or worse, It’s possible that x86 computers will remain the most interoperable for a long time.
Wouldn’t be surprised if that exclusivity deal has to do with drivers. For those not I’m the know, drivers are a big pain point in the ARM ecosystem because SoC vendors don’t feel like supporting their hardware for more than a couple of years.
I agree with the fact nobody wants Windows on ARM. If you want a fully fledged Windows on your tablet, the efficiency gap between x86 and ARM is so narrow it’s just not worth the hassle of dealing with emulation layers and Qualcomm. I am glad Microsoft is supporting new architectures, but it’s more of a insurance policy against the price gap between x86 and ARM chips increases dramatically that Microsoft hopes they won’t have to cash.
Windows has always supported multiple architectures. PPC, Arm, Mips plus of course the various server focused chips.
But at the end of the day Intel has won war after war and x86 still holds the crown.
ARM is still not a rival because contrary to using a single name to describe the various implementations, they are not 100% compatible with one another. It’s part of why an ARM (M1) mac won’t “just work” with Linux and Windows (drivers being the other big barrier ofc)
Remember. Arm is RISC not CISC like Intel .
RISC is not designed for compatibility across different implementations.
Don’t state an intended design is a defect of the system just to further your point.
Maybe Arm 3 was classifiable as risc. These days, nah.
WTF. Huh. Where are you getting that. Maybe I’m absurdly misinformed, or you are. One of the two. But to my knowledge RISC vs CISC has nothing to do with “compatibility” or the difficultly for windows on arm. Or anything. Please enlighten me if you’re able to find any such sources.
According to Wikipedia ARM is still RISC and has not migrated to CISC. https://en.wikipedia.org/wiki/ARM_architecture#64/32-bit_architecture
tjsooley
And how does that change Bill Shooter of Bul’s point? I agree with him, RISC versus CISC doesn’t really impact software compatibility. That really comes down to standardization at much higher levels, especially a standardized bootloading process and firmware.
Windows hasn’t (to my recall) supported much other than x86 since NT4. I suppose Itanic for awhile there and ARM recently, but “always” is a stretch that only covers a few-year window in the late 1990s. That’s not to say there aren’t pet ports in labs at MS, but it’s not hard to imagine some x86-only stuff has crept in over the last 20 years.
You’re correct on the ARM issues, though, since there’s not much of a unifying standard (even in the instruction set as I understand some parts are optional). I think it may end up being a few de facto reference architectures (Raspberry Pi, maybe some of Nvidia’s boards, Apple’s M1, etc.) that end up supported or cloned by Linux distros and other stuff it’ll be up to the manufacturer (good luck).
Microsoft have traditionally hedged their bets. As an architure gains traction, they support it, as it wanes, that support drops. PPC is a good example. They created a version of Windows for it but as the market became hegemonic they dropped support. I don’t think I can name an architecture in the desktop space Microsoft hasn’t supported (not including SPARC as that was a wierd crossover)
NT 3.1: Alpha, i386, mips
NT 3.5: Alpha, i386, mips (ppc prerelease builds exist)
NT 3.51: Alpha, i386, mips, ppc
NT 4.0: Alpha, i386, mips, ppc
Windows 2000: i386
Windows XP: i386 (ia64 prerelease builds exist)
Windows Server 2003: amd64, i386, ia64
Vista/2008: amd64, i386, ia64
Win7/2008R2: amd64, i386, ia64
Win8/2012: amd64, arm32, i386
Win8.1/2012R2: amd64, arm32, i386
Win10: amd64, arm64, i386 (arm32 in phone and IoT editions)
Win11: amd64, arm64
There’s really not much x86 specific. Even for the brief time when it was an x86 only product, that was when porting to other architectures was in progress. And no, amd64 is not just x86 – it’s a totally different thing with different word size, calling convention, allowable instructions, etc. Windows doesn’t allow x86 code to just be loaded into an amd64 process or vice-versa – they’re totally different environments.
Basically, from what I understand here is the real issue.
1) Previously there was no standard for arm devices like there is with X86. This was a real pain and led to this for servers:
https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-announces-server-ready-program-for-arm-based-servers
Basically with a certified server, you can install an older extended support linux distro and be fine. And the new server that comes out two years from now will also work with that older extended support distro. Thats what we in the x86 world are used to.
2) Apple ARM M1 processors are fast fast fast fast. Vertically integrated, they have a lot of features x86 is used to seeing in discrete modules on the soc: memory, video acceleration, etc.
To complete with Apple with an ARM arch, I think you need both 1 & 2. Is it possible to do both. IDK i’m not a chip engineer. Anyone else ?
But, yes I do want arm on windows. Especially if Legacy x86 emulation is as good as it is on the M1. I don’t really understand why someone wouldn’t. I’d like to get to the point where the chipset doesn’t really matter that much. Is it x86, ARM, or riscv running my code faster than anything else? If its fast enough, does it really matter? Like what is my car engine doing Variable valve timing or is it free cylinder? Is it port or throttle body injection? I don’t think it matters, I just pay attention to the MPG on the sticker and in the car diagnostics. how it gets there is not that important to most people including me.
Bill Shooter of Bul,
They’d both be on my wish list.
I agree it’s becoming less important especially for platforms that use bytecode/JIT compilation or recompile to native code like linux. This keeps things extremely portable. It’s more of a problem for windows apps that are only available as x86 binaries. I can get behind emulation as a stop-gap measure, but I still think native code is important and cross platform emulation should be a last resort.
I agree with your point that people don’t care how it works, only that it does. Also CPUs are more than fast enough to handle typical applications even with emulation overhead. But even so that does eat into the energy & battery advantages of going ARM to begin with. So I don’t think we can completely dismiss the need for native binaries.
x86 emulation on the M1 is fast because Apple made their own microarchitecture that supports memory consistency models that are not part of the official ARM architecture.
ARM is a hard beast for Microsoft to tackle, since they are a 2nd class citizen in that world, and as such they can’t set the standards as they do on x86 land. They need to change a lot of their culture around their Windows division for them to be successful on ARM.
I most assuredly would like an ARM device with Windows on it.
However, I don’t want a locked-down UEFI like Microsoft requires, and PCIe slots would be nice, too, so I can add hardware.
Oh well.
Disclaimer: I’m a Microsoft employee.
For what it’s worth, I want a Windows on ARM device. This morning somebody pointed out the Samsung Galaxy Go, which is a lightweight $250 fanless device with great battery life. I’ve been using Atoms for this type of workload for years (and love them), but ARM should be so much better in that category. As always, it’s not right for everyone, but it sure looks exciting to me.
I’ve only toyed around with it but there is a surprisingly active community that is heavily invested in Windows IoT and it is of course almost all Arm based. Mostly it’s on the industrial side where a lot of legacy code exists that is the motivation for the use of Windows IoT. I realise it is not the Windows Desktop that people first think about, but it’s still Windows, and it is on Arm.