Hacker News Reader

Comment by Wowfunhappy | Hacker News Reader

> Notably, one thing Apple does not need to give up is Windows support: Windows has run on ARM for the last decade, and I expect Boot Camp to continue.

I brought up the possibility of Bootcamp supporting ARM Windows on HN yesterday, and others responded with some rightful criticisms.

From mrkstu:

> The problem is that Apple has moved to a home-grown stack for it graphics and deprecated OpenGL and moved wholly to Metal. [...] There is no way Apple would create a Windows driver for that custom silicon—it has always relied on AMD or Nvidia for those drivers in the past, it has no in house code base or expertise to write the requisite code in Windows and none of the silicon has been optimized for it.

And from pavlov:

> I don't think there is a standard BIOS for ARM like there is for x86, so multi-boot would probably require Microsoft to support Macs explicitly in Windows on ARM.

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

View on HN

High-end ARM servers support standards called "SBBR" and "SBSA" which means they support UEFI and ACPI. The experience of using them is not very different from using x86 machines: boot an arbitrary OS and almost everything works.

https://en.wikipedia.org/wiki/Server_Base_System_Architectur...

There's an effort to make even the Raspberry Pi support this standard: https://rpi4-uefi.dev/

I assume even Windows on ARM relies on that UEFI support. It's not just server-side stuff.

Yes, it does.

Yes. UEFI. Because your bootloader should totally be able to access a network stack for future remote attestation...I mean, trusted computing purposes!

Reading my way through the specification at the moment, and I'm failing to see how UEFI does anything user-friendly at all. It seems to only be useful to entrenched business interests (read Big *) and to a lesser extent maybe OEM implementers. Whereas all the cryptographic subsystem utilization by industry seems to be being used against users in the interests of fortifying market position.

Wish I'd have added my voice to the din back when I was first reading about it back in the oughts. Didn't realize how much of a pain in the rear it was about to make my computing life.

Too late to turn back the clock now. I just wish I understood what was so wrong with the old BIOS POST->handoff process.

Probably need to sit down with an Old HP or Dell XP box and try to figure that out. Besides the Rootkit issue (which frankly, it feels like there are less intrusive and user-abuse enabling approaches to dealing with) I don't buy that the end-user got a single blessed thing out of UEFI; only lost.

It's worth noting here that Apple was actually among the first to adopt UEFI—it was used by the first Intel Macs in 2006.

They didn't really follow the specifications so there were a lot of differences, but it was definitely UEFI. Actually, one of the reasons Hackintosh bootloaders have gotten so much better recently is they don't need to deal with BIOS ==> EFI translation.

So clearly Apple saw something in it.

Intel donated their original EFI standard to the Unified EFI Forum for further development in summer 2005.

>The Unified Extensible Firmware Interface Forum or UEFI Forum is an alliance between several leading technology companies to modernize the booting process. The board of directors includes representatives from thirteen "Promoter" companies: AMD, American Megatrends, ARM, Apple, Dell, Hewlett Packard Enterprise, HP Inc., IBM, Insyde Software, Intel, Lenovo, Microsoft, and Phoenix Technologies.

https://en.wikipedia.org/wiki/Unified_EFI_Forum

Apple started their adoption of EFI before the UEFI was a thing.

Sorry, yes, I should have said "EFI" rather than "UEFI".

Irrelevant story: Apple adopted and has trademark of OpenCL but they finally dropped it.

https://www.khronos.org/legal/trademarks/

Fun fact: Apple wrote OpenCL, open sourced it, and then handed it over to Khronos.

I doubt many would find bootcamp on ARM very interesting, especially if that means you need to run Windows-ARM.

The great thing about x86 macs is that you can run x86/x64 versions of Windows, at decent speeds, through the likes of Virtualbox or VMWare Fusion, and have access to a vast amount of legacy win32/win64 applications.

Nobody needs to run legacy arm windows binaries, there simply aren't any around.

It would be a shame to lose access to decent windows VM performance on the Mac.

Maybe we'll see a return to the days of coprocessor expansion cards?

https://en.wikipedia.org/wiki/Apple_IIe_Card

https://en.wikipedia.org/wiki/Macintosh_Processor_Upgrade_Ca...

I think a Windows desktop-as-a-service offering similar to Amazon WorkSpaces is more likely.

Indeed and I think it's where the future of the Win32 desktop is. To be clear, not Windows as a whole, but consider how Microsoft suggested not too long ago that they planned to deprecate Win32 eventually (via Windows 10 X) and render those apps via RDP.

How would games work? I understand that the Xbox One runs a build of Windows 10, and I would expect that to continue on the Series X. Are Xbox One games Win32 binaries?

> Are Xbox One games Win32 binaries?

Nope. You can run UWP on Xbox, but most games don't (because functionality is limited).

Seems possible. We use VDI at my employer for access to windows apps for developers on Macs. The performance is at least adequate although there are inevitable glitches in the experience, but the same is true of running in Parallels or VMWare. But we do rely on the ability to run the same docker containers locally that we deploy to our servers.

It already exists.

https://azure.microsoft.com/en-us/services/virtual-desktop/

I expect someone will come up with an Intel emulator, I have a vague recollection that one existed in the pre-Intel Mac days.

It was called VirtualPC and it was REALLY slow - 1/8th native speed as I recall. I found it pretty much unusable even on a good G4.

I think it’s totally possible there will be external versions of these, connected through USB 3. Around the size of a hard drive, with an Atom or i3 and it’s own RAM/storage. Figure out the right interface and maybe it could be used from an iPad Pro as well.

Apple has to significantly invest to continue with Bootcamp, only to offer people Windows on ARM. Windows on ARM is actually a great product, but it's not what people use Bootcamp for. There's no value add here for Apple, and I simply can't see them doing it. Not even if they continue using AMD graphics in (some of) their machines. It's not worth any effort to run a platform that is still as niche as Windows on ARM.

The only way I see this happening if someone else would do the work. And that someone else would have to be Microsoft. Why? They're the only ones with an incentive to do it. ARM Macs would be a highly available, highly performant development platform for Windows on ARM. Apple could be accidentally solving a supply problem here for Microsoft - a supply of quality high performance ARM desktop hardware. Apple might even be inclined to work with Microsoft (or they might not), but even if unlikely the only way I see this play out is without Apple paying for any of the work.

I wouldn't call Windows on ARM a niche product, since it supports x86 emulation, enabling, arguably, most of the use cases.

Part of them. If you just want to use one-off old software then emulation is adequate. If you actually care about performance, then no, not really.

I don't mean to speak against Windows on ARM viability - it's a necessary product and it's well executed. But Windows on ARM is still building a market, and can't run significant high performance software yet.

Even for gaming it can't run anything released in the last 15 years in the current Snapdragons, which by itself excludes a really big portion of Bootcamp use cases.

I used bootcamp for years to run real games at real speeds (windows+steam)

it was pretty much: mac workhorse by day, windows game machine by night

all that's fading away.

>> > The problem is that Apple has moved to a home-grown stack for it graphics and deprecated OpenGL and moved wholly to Metal. [...] There is no way Apple would create a Windows driver for that custom silicon—it has always relied on AMD or Nvidia for those drivers in the past, it has no in house code base or expertise to write the requisite code in Windows and none of the silicon has been optimized for it.

That's assuming there will only be ARM-based macs that use Apple GPU's, which doesn't make sense. For iMac/Mac Pro/Macbook Pro I fully expect those would still be equipped with AMD GPU's. Good as the Apple GPU's are for mobile hardware, they are nowhere near the performance and feature set of desktop-class hardware. This would also free up a lot of silicon on the CPU die to allow for higher core counts, bigger caches etc. I think ~50% of the A13 SoC die is just for graphics...

On top of that, instead of bootcamp Apple could still support virtualisation to be able to run Windows ARM on Apple ARM hardware and write a paravirtualized GPU driver that just translates guest DirectX/OpenGL/Vulkan to host Metal, similar to what pretty all other hypervisors are doing already.

> That's assuming there will only be ARM-based macs that use Apple GPU's, which doesn't make sense. For iMac/Mac Pro/Macbook Pro I fully expect those would still be equipped with AMD GPU's. Good as the Apple GPU's are for mobile hardware, they are nowhere near the performance and feature set of desktop-class hardware. This would also free up a lot of silicon on the CPU die to allow for higher core counts, bigger caches etc. I think ~50% of the A13 SoC die is just for graphics...

While I agree that the higher-end machines will still have discrete graphics, that doesn't mean they won't also use on-die graphics—after all, the MacBook Pro I'm typing this on uses Intel HD graphics when it doesn't have to spin up the Radeon.

And I wouldn't really want to bet that the Intel onboard graphics are/will be less powerful than Apple's.

> While I agree that the higher-end machines will still have discrete graphics, that doesn't mean they won't also use on-die graphics

But there's no reason those have to work in Windows. Apple isn't going to care if Windows gets crappy battery life.

The bigger question is, if Bootcamp would only work with a small portion of Apple's machines anyway, and you'd have to run a version of Windows which no one really wants, and Windows just generally isn't as necessary in 2020 as it was in 2006... is Apple going to bother?

I'm sure that Apple with its total control of hardware on Macs could get Windows running. If that's too much of a technical effort, Apple should easily be able to get Microsoft itself to lend a hand.

After all, Microsoft would like to encourage software companies to make their products available for Windows on ARM as well, being on ARM Macs would make WoA more desirable. Besides allowing Windows to run on ARM macs must be preferable to MS over Apple investing in some Win compat thingy, while Apple would like to avoid investing in Win compat. It's an obvious win-win if Apple wants to do it that way. Apple could on the other hand decide to close the platform further, or manage to do this itself.

A build of Windows 10 for ARM already exists.

https://docs.microsoft.com/en-us/windows/arm/

> > The problem is that Apple has moved to a home-grown stack for it graphics and deprecated OpenGL and moved wholly to Metal. [...] There is no way Apple would create a Windows driver for that custom silicon—it has always relied on AMD or Nvidia for those drivers in the past, it has no in house code base or expertise to write the requisite code in Windows and none of the silicon has been optimized for it.

They're derived from PowerVR cores which do have WDDM (AKA windows) drivers. They're not great, but usable. Paying a third party to write new drivers isn't a crazy idea either.

Remember, they don't have to be perfect, just usable.

> > I don't think there is a standard BIOS for ARM like there is for x86, so multi-boot would probably require Microsoft to support Macs explicitly in Windows on ARM.

Microsoft ARM machines use UEFI. It should work fine if Apple implements an UEFI loader on top of iBoot or whatever.

PowerVR graphics is quite terrible, no doubt about it. It's the reason why some Intel Atom-based or similarly low-end x86 devices are stuck on an unsupported version of Windows 10, with nothing to upgrade them to. Even Linux won't run properly on that hardware, it's that bad.

Yeah, those particular drivers were a special kind of terrible. Didn't even run the vertex shaders on the GPU.

They do have regular Linux drivers, Imagination just needs to get it's head out of it's ass and recompile them for x86.

Is the Apple's GPU core really based on PowerVR arch? I suspect that adopting PowerVR arch without grant may cause lawsuit.

Why do you think they don't have a grant?

https://www.imgtec.com/news/press-release/imagination-and-ap...

Because the license is in 2020. I don't expect Apple copies full arch without grant. The license is for patent but not for arch, isn't it?

>> One thing Apple does not need to give up is Windows support: Windows has run on ARM for the last decade

Supporting legacy x86 apps is 'windows support', not 'running windows'

> I don't think there is a standard BIOS for ARM like there is for x86, so multi-boot would probably require Microsoft to support Macs explicitly in Windows on ARM.

Apple "just" needs to properly* support UEFI for Windows on ARM to boot

*properly == supporting the minimum requirements for Windows

The other issue is that Windows for ARM is not a product you can just buy off the shelf right now.

i thought the surface pro x runs windows on arm? or do you mean you can't get a copy of the OS without the product?

Yep, WoA is only sold preinstalled in devices, you can't buy a copy (but you can install it yourself: https://github.com/WOA-Project)

You can get ISOs/WIM files if you know where to look...

Official ones are behind two-factor authentication, only downloadable using Internet Explorer. Yeah.

I know the Intel ones are available from Microsoft’s site and you can find it if you just search for “Windows 10 ISO”. Are the ARM ones different?

The MSDN Subscriber Downloads site (now “My Visual Studio” or similar) hasn’t needed IE since... 2011?

Microsoft gives away the ISOs for non-LTSB builds for free - it’s the product-keys that they care about.

Windows 10 on Arm shares the same product keys/licenses as on x86.

Microsoft would probably make them available if this were to happen, since they'd have to do work to get Windows running on the A-series chips anyway. If Apple wants it (and is willing to help, because some way of breaking their secure boot will be needed), it's beneficial for Microsoft. They get to sell more licenses, and corporate environments that buy Apple hardware to run Windows on (which is apparently not uncommon, according to r/sysadmin) will keep doing it.

> I don't think there is a standard BIOS for ARM like there is for x86, so multi-boot would probably require Microsoft to support Macs explicitly in Windows on ARM.

Windows on ARM requires UEFI, so that's not a problem.

As for standard firmware interfaces, UEFI is as much a thing on ARM as it is on AMD64. It's ugly, but it is at least standard.

The OpenGL bit is even worse than it sounds. The driver is half-broken and the version is ancient, already a decade old.

I don't see how this would change. I haven't seen anything that suggests that Apple would be moving away from using third-party GPUs in this process. The ARM move would only affect the CPU which would have no bearing on the graphics stack on the Windows side.

Also, Apple has gotten to a point where it doesn't really need to support Bootcamp anymore unlike in 2006ish when it released the first intel Macs.

Also they probably have to consider how much money they're willing to throw at this.

Switching to ARM on macOS will save them money as they don't have to pay Intel and can reuse existing designs and relationships with TSMC.

But actively investing money and personnel to support Windows, NVIDIA and AMD GPUs, virtualization, etc on a platform that sells 20ish million units in an year, compared to the hundreds of million of units that iPhones/iPads/Apple TVs, etc sell - probably doesn't make financial sense.

Especially with how they've treated macOS lately, enabling easy transitioning via Catalyst, SwiftUI support, making it easy to reuse code for iOS. Switching to and getting more revenue from services, thus them being a bigger priority.

And there's the argument of doing all of that instead of investing more time into macOS with the whole Vistalina thing going on.

Again no idea whether it makes financial sense, they've more than likely done the math and it'll be interesting to see how it plays out.

I saw some stats a couple of days ago that said Bootcamp usage had fallen from 15% of users to just 2%.

Interesting. Any source?

Personally I only used bootcamp for gaming a couple of years ago but then I just ended up building a desktop PC. It's just the better option as it will probably outlive all my Macs and I can upgrade parts as needed.

I would assume part of that is the improvement in virtualization. Those with adequate RAM can run Windows apps in a VM performantly.

You really only need Bootcamp for gaming, and with Nvidia support waning on the Mac, you're going to have a second rate gaming experience even in Bootcamp.

And I assume that because Windows hardwares getting better and Macs not or getting worse.

Around 2010-2014, MacBooks are great hardware even for Windows. But after that, some good Windows devices are released (like XPS 13) and Apple starts failing (like TouchBar, keyboard, USB-C only, ...).

Windows on Arm might not be able to make use of all the secret sauce and custom silicon these chips are bound to have. Who's going to put in that work?

Reply on news.ycombinator.com