> Generally, the performance was underwhelming compared to my expectations. I know from my work overclocking Raspberry Pis there are diminishing returns when you force-feed more power into a chip that's optimized for a certain level of performance.
> There's a lot more power, a lot more heat, and only marginal performance gains. It looks like the Snapdragon X Elite on a laptop at 20-30W is only 15-30% less performant than the X Elite on the Dev Kit running at 80-100W!
> And it's downright embarrassing, efficiency-wise, compared to Apple's M3 and M4 chips (M2 is close to comparable, at least).
Im not sure how it differs technically from macos universal binaries but the user experience is basically the same - one download no matter what architecture you are on.
This is completely different from the experience on macOS where I can have an exe and even dynamically linked dlls that are all universal binary and it works without any action from the user.
That's not actually a windows feature. The way Obsidian did it was they bundled the x64 and ARM into the same installer package, while the installer runs as x64 (thus, running on ARM devices in compatibility mode).
This only works if your installer framework (InstallShield, MSI, Wix, Advanced Installer, ClickOnce, etc.) supports such a trick. If it doesn't, you're forced to ask users on the download page which version they want.
If the users guess correctly, it's great. If the ARM users guess x64 incorrectly, it still works. If the x64 users click the ARM version by mistake, they will be greeted with a warning, from Windows, saying this software does not work on their device. This is technically correct but a conversion killer. The odds of this happening are also much larger than 1%, in which case, offering an ARM download is actually likely to be financially harmful on a business level.
(The smartest way of handling this I've seen is to only offer an x64 download, but your app's auto-updater "updates" your app to ARM in the background as though it were an app update. Good luck convincing developers to write all the logic for that though, on top of an existing most-likely-third-party update system, for such a niche market.)
I thought the same too, and my best guess would be that: backwards compatibility with older Windows is important, and Microsoft has a much harder time with that than Apple. It's both technical and social.
macOS fat binaries are not actually mach-o "binaries", but they are really just an "archive file" which contain multiple files within them. When you execute one, the OS gets to pick which file to use. When you dlopen, it picks the right one, and so on. That's basically the long and short of it.
But an important aspect to note of the macOS design is that "fat binaries" would not work on systems that do not implement support for it. For example, I'm not sure Mac OSX 10.3 (Panther) had support for fat binaries, but 10.5 (Snow Leopard) added them when the Core 2 x86_64 transition happened. This is obvious when you think about it for a second, but here's the key: macOS users actually upgrade their operating systems, quickly. What that means in practice, I think, is that if you started publishing fat binaries with multiple architectures, you could be reasonably sure that within, say, 1-2 years, 99% of your users will be using an operating system that will support fat binaries. The transition window where you need to support the old stuff for Panther users is there, but it's a small window in the grand scheme.
Now think about how it works on Windows. Windows has been using the PE format for decades, and it does not have any notion of "separate sections for separate architectures" (just like Mach-O.) So, if you wanted "fat PEs", you'd need to introduce an entirely new executable format. But you can't introduce new executable file formats for Windows 8, just like how Apple couldn't add fat binaries to Panther. But millions of PCs still run Windows 8, whereas Panther was obsolete within a very short timeframe.
So, if developers start publishing "Fat EXEs" that were actually in a different non-PE format, then you're not going to be able to use those on any older operating system. And the support gap for Windows is significantly larger, so you'd be supporting the transition for potentially many years depending on your userbase. That's a significantly different trade off compared to what MacOS developers and users might stomach.
That said, they could still add support for "Fat PEs", and it would be great. But given the above calculus, I can see why they might not have gone this route, at least initially.
This is my best educated guess and I don't know anyone who could confirm this kind of thing, but that's my 0.02c.
Mac OS X 10.3 did have support for fat binaries, it supported both ppc and ppc64 (although there were very few system libraries that could be used from ppc64).
Mach-O fat binaries date back to NeXT though, since NeXTSTEP ran on many architectures (there were quad-arch apps back then which ran on i386, m68k, hppa, and sparc).
I agree with you but Windows Arm has existed for a long time now (remember Windows RT?), Microsoft then lacked the foresight to add this to their system when they should have instead of doing nothing for so long.
> So, if developers start publishing "Fat EXEs" that were actually in a different non-PE format, then you're not going to be able to use those on any older operating system.
Couldn't the ARM code be put at the end of the x86 code, so operating systems unaware of the change would run the x86 code like before, but the ARM devices shipping an updated version of the OS would skip to the ARM code.
This review feels a little underdone to me. I feel I should agree with all his points, but there's something about it. Maybe its the way he doesn't put comparison numbers for other systems in his benchmark numbers table. Or maybe it's because he doesn't mention why linux isn't working (is it locked down, or too new?) Or perhaps its because the value-prop for these systems is laptops with long battery life, not dev systems.
I will agree that the fan is too loud and that Windows 11 seems to suck (I don't use it much, mostly linux here).
By the way a Mac Mini with 32GB of RAM is $1699, not the hypothetical $1200-$1400 he estimates, but you get a M2 Pro, which is a better processor. So this system is cheap for the RAM you get.
What a winning pitch to developers. Spend $900 of your own money ($400 more than the Apple Transition Kit, which itself was then fully refunded) to build ARM-native apps; for a <1% market after a disastrous launch with the Recall and Copilot controversies.
And then what? Confuse your customers by asking users to pick x64 or ARM? You'll pay more in customer service costs helping confused customers, and from lost customers who downloaded the ARM version for their x64 PC and wrote off your software as dysfunctional (or, heaven forbid, they see the notice from Windows saying this software is not compatible with your device), than you'll ever gain from native ARM.
At least for $900 you get to keep this one? The Apple DTK had to be given back after 6 months with your consolation prize (after some kvetching too) being a coupon to buy something in the Apple Store.
Well, that's even worse. Pay $900 and then be forced to redirect your users to the Microsoft Store so they aren't confused, where they'll be forced to see other competing software and/or sign in with a Microsoft Account, in order to cater to a <1% market.
Most folks are already signed in with a Microsoft Account, thanks to years intensifying setup shenanigans. It's very hard to create a local-only user on initial boot.
So I had to do a fresh install yesterday, it works like this now, you need to shift+F10 as soon as the install start and disable the wifi
netsh interface set interface "Wi-Fi" disable
Then reboot, then when the screen comes that asks you to select a WiFi network but the list is empty you need to bring cmd.exe again with shift+F10 and type OOBE\BYPASSNRO and then it will automatically reboot and have a new screen that has a button made of only text that doesn't look clickable that you can click to skip and it will let you set up a local account.
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a flashlight.”
“Ah, well, the lights had probably gone.”
“So had the stairs.”
“But look, you found the notice, didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”
― Douglas Adams, The Hitchhiker’s Guide to the Galaxy
A telling bit:
> Generally, the performance was underwhelming compared to my expectations. I know from my work overclocking Raspberry Pis there are diminishing returns when you force-feed more power into a chip that's optimized for a certain level of performance.
> There's a lot more power, a lot more heat, and only marginal performance gains. It looks like the Snapdragon X Elite on a laptop at 20-30W is only 15-30% less performant than the X Elite on the Dev Kit running at 80-100W!
> And it's downright embarrassing, efficiency-wise, compared to Apple's M3 and M4 chips (M2 is close to comparable, at least).
Why didn't Microsoft went the Universal Binary way like Apple did? Does anyone knows why the Windows binaries have to be specific to each platform?
They have universal installers.
https://forum.obsidian.md/t/obsidian-for-windows-1-6-5-insta...
Im not sure how it differs technically from macos universal binaries but the user experience is basically the same - one download no matter what architecture you are on.
This is completely different from the experience on macOS where I can have an exe and even dynamically linked dlls that are all universal binary and it works without any action from the user.
That's not actually a windows feature. The way Obsidian did it was they bundled the x64 and ARM into the same installer package, while the installer runs as x64 (thus, running on ARM devices in compatibility mode).
This only works if your installer framework (InstallShield, MSI, Wix, Advanced Installer, ClickOnce, etc.) supports such a trick. If it doesn't, you're forced to ask users on the download page which version they want.
If the users guess correctly, it's great. If the ARM users guess x64 incorrectly, it still works. If the x64 users click the ARM version by mistake, they will be greeted with a warning, from Windows, saying this software does not work on their device. This is technically correct but a conversion killer. The odds of this happening are also much larger than 1%, in which case, offering an ARM download is actually likely to be financially harmful on a business level.
(The smartest way of handling this I've seen is to only offer an x64 download, but your app's auto-updater "updates" your app to ARM in the background as though it were an app update. Good luck convincing developers to write all the logic for that though, on top of an existing most-likely-third-party update system, for such a niche market.)
I thought the same too, and my best guess would be that: backwards compatibility with older Windows is important, and Microsoft has a much harder time with that than Apple. It's both technical and social.
macOS fat binaries are not actually mach-o "binaries", but they are really just an "archive file" which contain multiple files within them. When you execute one, the OS gets to pick which file to use. When you dlopen, it picks the right one, and so on. That's basically the long and short of it.
But an important aspect to note of the macOS design is that "fat binaries" would not work on systems that do not implement support for it. For example, I'm not sure Mac OSX 10.3 (Panther) had support for fat binaries, but 10.5 (Snow Leopard) added them when the Core 2 x86_64 transition happened. This is obvious when you think about it for a second, but here's the key: macOS users actually upgrade their operating systems, quickly. What that means in practice, I think, is that if you started publishing fat binaries with multiple architectures, you could be reasonably sure that within, say, 1-2 years, 99% of your users will be using an operating system that will support fat binaries. The transition window where you need to support the old stuff for Panther users is there, but it's a small window in the grand scheme.
Now think about how it works on Windows. Windows has been using the PE format for decades, and it does not have any notion of "separate sections for separate architectures" (just like Mach-O.) So, if you wanted "fat PEs", you'd need to introduce an entirely new executable format. But you can't introduce new executable file formats for Windows 8, just like how Apple couldn't add fat binaries to Panther. But millions of PCs still run Windows 8, whereas Panther was obsolete within a very short timeframe.
So, if developers start publishing "Fat EXEs" that were actually in a different non-PE format, then you're not going to be able to use those on any older operating system. And the support gap for Windows is significantly larger, so you'd be supporting the transition for potentially many years depending on your userbase. That's a significantly different trade off compared to what MacOS developers and users might stomach.
That said, they could still add support for "Fat PEs", and it would be great. But given the above calculus, I can see why they might not have gone this route, at least initially.
This is my best educated guess and I don't know anyone who could confirm this kind of thing, but that's my 0.02c.
Mac OS X 10.3 did have support for fat binaries, it supported both ppc and ppc64 (although there were very few system libraries that could be used from ppc64).
Mach-O fat binaries date back to NeXT though, since NeXTSTEP ran on many architectures (there were quad-arch apps back then which ran on i386, m68k, hppa, and sparc).
I agree with you but Windows Arm has existed for a long time now (remember Windows RT?), Microsoft then lacked the foresight to add this to their system when they should have instead of doing nothing for so long.
> So, if developers start publishing "Fat EXEs" that were actually in a different non-PE format, then you're not going to be able to use those on any older operating system.
Couldn't the ARM code be put at the end of the x86 code, so operating systems unaware of the change would run the x86 code like before, but the ARM devices shipping an updated version of the OS would skip to the ARM code.
That is a cool approach. And Windows files already support appending files too - or at least I know exe files do.
This review feels a little underdone to me. I feel I should agree with all his points, but there's something about it. Maybe its the way he doesn't put comparison numbers for other systems in his benchmark numbers table. Or maybe it's because he doesn't mention why linux isn't working (is it locked down, or too new?) Or perhaps its because the value-prop for these systems is laptops with long battery life, not dev systems.
I will agree that the fan is too loud and that Windows 11 seems to suck (I don't use it much, mostly linux here).
By the way a Mac Mini with 32GB of RAM is $1699, not the hypothetical $1200-$1400 he estimates, but you get a M2 Pro, which is a better processor. So this system is cheap for the RAM you get.
What a winning pitch to developers. Spend $900 of your own money ($400 more than the Apple Transition Kit, which itself was then fully refunded) to build ARM-native apps; for a <1% market after a disastrous launch with the Recall and Copilot controversies.
And then what? Confuse your customers by asking users to pick x64 or ARM? You'll pay more in customer service costs helping confused customers, and from lost customers who downloaded the ARM version for their x64 PC and wrote off your software as dysfunctional (or, heaven forbid, they see the notice from Windows saying this software is not compatible with your device), than you'll ever gain from native ARM.
At least for $900 you get to keep this one? The Apple DTK had to be given back after 6 months with your consolation prize (after some kvetching too) being a coupon to buy something in the Apple Store.
Microsoft expects users to get apps from their store which I imagine will choose the correct binary automatically.
Well, that's even worse. Pay $900 and then be forced to redirect your users to the Microsoft Store so they aren't confused, where they'll be forced to see other competing software and/or sign in with a Microsoft Account, in order to cater to a <1% market.
What a garbage pitch.
> or sign in with a Microsoft Account
Most folks are already signed in with a Microsoft Account, thanks to years intensifying setup shenanigans. It's very hard to create a local-only user on initial boot.
So I had to do a fresh install yesterday, it works like this now, you need to shift+F10 as soon as the install start and disable the wifi
netsh interface set interface "Wi-Fi" disable
Then reboot, then when the screen comes that asks you to select a WiFi network but the list is empty you need to bring cmd.exe again with shift+F10 and type OOBE\BYPASSNRO and then it will automatically reboot and have a new screen that has a button made of only text that doesn't look clickable that you can click to skip and it will let you set up a local account.
“But the plans were on display…”
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a flashlight.”
“Ah, well, the lights had probably gone.”
“So had the stairs.”
“But look, you found the notice, didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”
― Douglas Adams, The Hitchhiker’s Guide to the Galaxy
… except for all the people who upgraded from Windows 10, which gets a free grandfathered in local account during setup.
More than 1% of your users will come from that background.