This is an odd place for Microsoft to be, on ARM, both Linux and MacOS have much more complete suites of software available than Windows. Obviously both Windows and MacOS support emulation of their respective x86 platforms, but in terms of native software, Windows is kind of a distant 3rd place.
I guess this opens up the chance JetBrains will point IntelliJ and PyCharm over.
As much as I'd like it to be I don't think Linux is a serious desktop contender for most people, so Microsoft is just in second place - and it's not that distant yet, since the Apple transition has just started.
But of course the real (and perhaps obvious) difference is that Apple is much more strict about its ecosystem, having decided ARM will definitely be a thing and developers need to follow to stay relevant.
The Windows version is "maybe there will be ARM devices one day, maybe". That's not nearly as convincing.
I believe the most convincing thing for developers (besides rewards like promotion and filters in the store, which MS badly sucks at) would be a wave of serious ARM devices coming out in the very near future. The longer it takes the slimmer the chance that Windows on ARM will really catch on.
> As much as I'd like it to be I don't think Linux is a serious desktop contender for most people, so Microsoft is just in second place - and it's not that distant yet, since the Apple transition has just started.
My point here is:
- A huge chunk of Linux software (desktop or server) has been ported to ARM or will soon be.
- A huge chunk of MacOS software will likely be ported within the first few months of launch.
- A very small percentage of Windows software has been ported to ARM. Even the usual Windows strongholds: Games and corporate software have poor support for Windows ARM. Windows x86-64 bit emulation is missing (or at least was at launch) so a significant amount of pro software and games won't run even under emulation.
> The Windows version is "maybe there will be ARM devices one day, maybe". That's not nearly as convincing.
Exactly this. Microsoft has had so many false starts on platform shifts they have a hard job selling this.
> Windows software written in .NET and Java has little to worry about what CPU is being used, and there is plenty of it to chose from.
Considering many/ most pro apps like Photoshop are not written in .NET or Java, it is a significant concern. Likewise games—a category of software Microsoft has long dominated—are not generally written in Java/ .NET. Likewise, huge chunks of legacy corporate software is not very portable.
> Also outside HN bubble right there in the real world, macOS desktops are about 8% across the whole world. It doesn't really matter what CPU they have.
I wasn't talking about unit sales, I was talking about how much software the platform supports. Regardless of whether the Mac has 3% or 99%, there is going to be a better selection of software available for Mac on ARM in 6 months than for Windows ARM.
Sure they are, most modern Windows software is a mix of .NET and C++.
As for modern Windows programming, UWP has been able to target ARM since ages.
Yeah, not everything will be available, then again it doesn't matter how much software is available, if only a subset of those 8% of the computing world population is going to get it.
At least for right now. We'll see how things look in a few years. If Intel can't get back on track, ARM might actually surpass them and that's a very good reason for Microsoft to be looking to support ARM.
Lack of 64bit-only pro software isn't matter for 2019-2020 because lack of SoC performance. Possibly MS support 64bit emulation in time for SoC performance improving.
You can play the c++ version of Minecraft on the Surface X, however you couldn't play the Java version. Maybe the openjdk can fix this problem but I'm not really optimistic.
>As much as I'd like it to be I don't think Linux is a serious desktop contender for most people, so Microsoft is just in second place - and it's not that distant yet, since the Apple transition has just started.
I think market evidence points to the contrary. The Raspberry Pi is a fully fledged Linux Desktop, it's running and marketed with full fledged desktop software. Last I checked 25 million units have been sold.
It's use/sales far outstrips Windows RT or Surface Pro X which from what I know are the only current uses for Windows on ARM.
So yes I think Windows is in a clear 3rd place on ARM architectures.
> The Raspberry Pi is a fully fledged Linux Desktop,
I'm not sure I agree with this, lots of Pis are sold for projects which don't involve use as a desktop. In fact—from what I've seen—only a small percentage of Pis are actually used as day-to-day computing devices.
But in addition to the Pi, there is Pine64 which is exclusively sold as a "Desktop" platform with both laptops and workstations.
But I was talking more about the number of apps available on the platform than the number of units sold.
Software support for Windows ARM is a bit of a crapshoot which makes it hard to estimate what's out there.
It may not majority be used as a desktop, but it is marketed as such. You go to the raspberry pi store in Cambridge, and the first thing you see is it's use as a desktop.
The use cases for the Raspberry PI is ridiculously varied which I think reinforces it's application support relative to Windows on ARM.
I have seen it used for openstack development, as a desktop, home theatre pc, pihole, nextcloud instance, emulator etc... I haven't really found software that I can't just install/use.
Can you say the same for any windows on arm deployment? Especially if they are only just coming out with mainstream support for OpenJDK and Electron support.
In fact the alternative uses for the Pi are arguably as interesting/ important to its significance as a platform. A lot of little side projects which the Pi gets used for now used to be low end Windows boxes.
>I think market evidence points to the contrary. The Raspberry Pi is a fully fledged Linux Desktop, it's running and marketed with full fledged desktop software. Last I checked 25 million units have been sold.
That's a statistical error level compared to the number of PCs in the world.
And even the premise is wrong. The "Raspberry Pi" is not bought as a "fully fledged Linux Desktop" (whether it's marketed as such or not), but used mostly for special utility purposes, from automation and DIY experiments to multimedia servers and such...
Even if you add all Linux desktop machines, it's like 2% or something...
We aren't comparing it to the total number of PCs in the world and that marketshare relevance. I am sure there aren't particularly accurate statistics for that usage anyway.
This is a comparison between Linux on ARM and Windows on ARM. Not against Windows vs Linux as a whole. I assume this is in the context of future consumer desktop platforms on ARM hardware. In that context, OEMs who want to release a functional desktop product with ARM chips would find it a lot easier/appealing with ARM than on Windows at present.
In that context, Linux on ARM is vastly ahead of Windows of ARM.
My argument is that the total number of raspberry pis being used a Linux ARM desktop outstrips the amount of Windows ARM desktops (which are composed of surface RT/X tablets).
Well, we weren't talking about the desktop, were we? Especially when Java is involved. (Unless, of course, it is Java code development, in which case Linux is still a better platform anyway.)
Uh, what? Java started as a write-once-run-anywhere platform for applications. Java gained popularity as a browser plugin for richer UIs. Significant amounts of enterprise and in-house software are written in Java using AWT/Swing, SWT, etc.
I'm not concerned about the server. If the performance were good and Microsoft's built in Narrator screen reader worked well with vscode I could use an arm computer for all my hobby programming now. I don't know how well Narrator works with vscode but unfortunately as far as I can tell NVDA is not being ported to arm. Yet another example of the lack of software. I'd consider getting a cheep Windows ARM laptop to investigate porting it but it looks like everything is over $500.
> Obviously both Windows and MacOS support emulation of their respective x86 platforms, but in terms of native software, Windows is kind of a distant 3rd place.
Much (most?) new Windows software these days is written in .NET and might just work out of the box, since that's technically speaking what .NET is supposed to enable.
(With the obvious reservations about platform specific quirks. I've ported my fair share of code to different platforms, and now it's often not that simple)
There is also a lot of legacy 32 bit code and industry specific tools which are getting left behind. Plus a lot (most?) of Pro tools and games use C++ or something a bit lower level.
I know Adobe is dragging their feet supporting Windows ARM and there is very little gaming support for it either. Both Adobe and Unity have announced "Apple Silicon" ports, Adobe has been dragging their feet on Windows ARM support and I don't even think Unity has announced they will migrate to Windows ARM.
Transparent DBT for userspace programs has been a thing on Linux the whole time, more or less. QEMU could stand to do a lot better performance-wise, though, for programs that actually care about that.
Off topic: I have a scanner with excellent x86 32/64 bit linux drivers.
Has someone come up with a smooth way to use them on ARM? (The leading contender is a qemu chroot with the scanner gui and driver installed, but that sounds hard to maintain over time).
I really want to just link the x86 .so into an arm binary, performance-be-damned.
Sorry, now I see you wrote scanner and not printer so here is my response to printer :
----
You could put it in a container, and connect it with CUPS. CUPS is network-transparent and there should be nothing stopping you from running it in a container.
It is not unheard of to use QEMU userspace DBT in containers[0].
If your scanner drivers hook into SANE, I think saned supports sharing a local scanner over the network, so you could set that up in a container, similar to setting up CUPS in a container for printer drivers. Here's the document for setting that up: https://wiki.debian.org/SaneOverNetwork
A container is nice because you can also be sure that the scanner container only exposes the saned socket, and has no other network access.
QEMU is bordering on unusably slow even for applications that are not performance sensitive, mostly because of memory ordering issues. TSO is not really easy to do dynamically.
Yeah, my primary use case for it has been running proprietary utilities to inspect/operate hard disks, and things like that, which may only be available as statically-linked ia32 binaries, potentially until the end of time.
There is a lot of performance left on the floor by real-time-only DBT when applied to binaries which do not jump into dynamic memory at all. QEMU is also, in my opinion, too general-purpose to be efficient. I think high-performance SBT and DBT is crucial to the adoption of new ISAs, it should maybe be something RISC-V International/The Linux Foundation puts up a bounty for (along with native ports of popular JITs like v8 and HotSpot).
Microsoft is a software producing company. It makes sense for them to be able to support their software on every hardware/OS that is good as a business decision. The fact that they produce an operating system as well, it's irrelevant in current landscape. I don't get your oddness.
For me, and I suspect for many people, the singular reason we used Windows in the 00s was the fact that Windows was the platform with the most software support. The Mac and Linux were secondary and tertiary platforms respectively for most developers.
Things have changed a lot since then, but to me, seeing Windows being the platform which has the least software support, even in this limited scope, is a sign of how much of a reversal Windows has seen.
> Windows being the platform which has the least software support
What a strange universe you must inhabit. Windows still utterly dominates the software landscape except in web stuff. I have yet to work at an org that didn't have a dependence on many pieces of software that are exclusively Windows.
> I have yet to work at an org that didn't have a dependence on many pieces of software that are exclusively Windows.
You do know we are talking about Windows on ARM here right?
I haven't said that every time I've been talking about this, but that's the context, Windows on ARM.
> Windows still utterly dominates the software landscape except in web stuff.
Again, Context. Windows on ARM doesn't dominate anything. That's why I said "even in this limited scope" right after the phrase you quoted. I figured folks would recognize we were still on the same topic.
I wouldn't bet against MS regarding backward compatibility. I'm sure that everything running on x86 runs or will soon run on ARM. Perhaps a little slower yes, but your average consumer will be unaware of the difference beside that, so for every practical purpose Windows will have 'more complete suites of software available'.
There's one Windows software sector that this is not good enough for - games (really care about performance+latency, unlikely to ever port to ARM), but that sector is the least likely to want to switch to ARM in the first place. Gamers will go Windows+AMD anyway.
The bigger problem for Windows-on-ARM is that non-Apple desktop-class ARM processors are right now rather weak, and that affects all applications, even ported apps.
> I wouldn't bet against MS regarding backward compatibility. I'm sure that everything running on x86 runs or will soon run on ARM.
Oddly, Microsoft has 32 bit x86 apps running on ARM, but 64 bit x86 apps are broken. More or less exactly the opposite of Apple in terms of legacy software. This means there are some pretty notable holes in the Windows ARM Pro software scene -> Adobe being the biggest, most obvious.
The message from Apple is "Everything that runs on Catalina runs on the new Macs", but software which has been ported will run best. The messaging from Microsoft is much more nuanced.
> The bigger problem for Windows-on-ARM is that non-Apple desktop-class ARM processors are right now rather weak, and that affects all applications, even ported apps.
This is why Apple can afford to go all-in on ARM while Microsoft has to tap-dance back and forth between the two platforms.
>Oddly, Microsoft has 32 bit x86 apps running on ARM, but 64 bit x86 apps are broken.
It has been argued on HN that the reason was x86_64 patents that will very soon expire. Once that happens, Windows-on-ARM is very likely to have x86_64 emulation as well. Besdies, 99% of Windows software is available as 32bit.
The software sectors that don't will either never port old stuff (games) or will port anyway for Mac and have an easy Windows port as a result (e.g. Adobe).
>This is why Apple can afford to go all-in on ARM while Microsoft has to tap-dance back and forth between the two platforms.
Microsoft is mostly a software company, rather than an hardware one. It doesn't matter to them on what processor type you run so long as it's their software. I suspect the biggest reason for focusing on ARM isn't Mac, it's Azure.
Game developers have been porting their games to ARM for long time now. Sometimes, like GTA San Andreas, even for windows ARM, but these days the platform is usually iOS, Android, or Nintendo Switch. Historically there were others, PS Vita, Nintendo DS, they all had ARM CPUs.
The context was referring to existing software libraries, of course it is technically possible for new titles to have an ARM version. Existing games are rarely supported, some popular ones sometimes get a 'remake' or a 'remaster' which then might port them, but often games are left as is.
> I'm sure that everything running on x86 runs or will soon run on ARM. Perhaps a little slower yes, but your average consumer will be unaware of the difference
Windows-on-ARM already has 32-bit x86 emulation — and it's slow as molasses. Believe me, people do notice the slowdown.
But Microsoft has everything to gain by upping the performance to match what macOS is doing with Rosetta 2, so it's definitely a space to watch closely.
Apple's leg-work on the lead up to this migration is really standing out here. By deprecating 32 bit app support over the past ~2 years, Apple only needs to emulate 64 bit x86. For Microsoft, 32 bit support is still more important than 64 bit support, but big chunks of Windows applications want 64 bit support as well. Microsoft has had one foot on both sides of the 32/64 bit divide for years and it's making this migration a lot tougher.
Did I miss a beat and somehow thousands of developers have ported their apps to Windows ARM?
Last I heard Adobe only had a few tools working on the ARM version of Windows and only a few other developers were onboard.
From the sounds of it, when Apple Silicon goes live, there is going to be a pretty big selection of native apps (Plus they have iPad/ iPhone apps). The fact that Windows ARM didn't support emulating 64 bit x86 out the gate didn't help either since a lot of pro tools are 64 bit.
You're comparing two different timeframes - an expectation for what Apple may have when it launches, compared to Windows-on-ARM has today. That's not reasonable.
Most likely, everyone who will port their software to Apple ARM will also port to Windows ARM at the same time (same application core).
Isn't that because Microsoft locked Windows 10 on ARM down and forces you to use the Microsoft store? There are no competing stores on Windows on ARM by design.
Windows on ARM was Store-only back in Surface RT days. It's not the case with the more recent take that's used in devices sold today. Now, they come out of the box in S Mode, which is Store-only (although the store now supports desktop apps, unlike in RT); but you can easily switch that off, and then it's as open as Wintel.
I guess this opens up the chance JetBrains will point IntelliJ and PyCharm over.