Hacker News Reader

Comment by ogre_codes | Hacker News Reader

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.

View on HN

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.

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.)

>Well, we weren't talking about desktop, were we?

It is implied. To be accurate, it started being implied when mac os has been brought into discussion.

Is there even a Windows ARM server platform which the public can port software to?

There is no publically available Windows Server Arm, no.

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.

Especially when Java is involved

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.

Says who?

I have been developing on Windows and deploying into whatever OS almost since Java exists, thanks to IT policies regarding desktop computers.

And yes, I also have deployed my share of Java applications running on Windows based JEE containers.

> 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.

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.

> 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.

Presumably if Photoshop is being ported to ARM for Mac, it will be ready for Windows on ARM won’t it?

> Likewise games...

Nobody who plays games will want an ARM chips anyway because they’re for low powered mobile systems, not desktops with beefy GPUs.

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.

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.

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.

What your post sounds like, and I believe this to be true, is that the primary value proposition of Windows is . . .

to run legacy software.

>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.

You are talking to the choir here.

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.

My raspberry pi alerts if there is too much water in my basement sump. No desktop there, and I suspect for most Pi's.

If Windows is in 3rd place for desktops, it's because of sales of ARM based Chromebooks, not Raspberry Pi.

>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).

Chromebooks rather than Pis amount to some percentage of Linux "desktop" used. Dunno how much but their CPUs are definitely ARM devices.

There already are ARM devices. Surface Pro X, for example.

> 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)

A good chunk is.

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.

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).

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].

[0]: https://www.stereolabs.com/docs/docker/building-arm-containe...

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.

Thanks! I wonder how hard it is to set up an x86 container on ARM. It seems like qemu’s transparent binary emulation should make it easy + clean.

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.

> the least software support, even in this limited scope

I think they were talking about ARM.

> 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'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.

> 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.

> 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 has to tap-dance because it has a very long-tail of developers that do not accept change lightly.

For Windows, these priorities make more sense, because most Win32 apps are still 32-bit only. There'd be a lot more holes if it could only do x84-64.

> unlikely to ever port to ARM

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.

>MacOS have much more complete suites of software available

MacOS does? By what measure?

Vs Linux, I get (Like the MS office suite), but I think the OP meant vs Windows, which is hard to grok.

> MacOS does? By what measure?

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.

Yep, for those 8% of world wide desktop users.

Ah you're assuming they will at launch, not what currently exists.

Adobe have demonstrated Photoshop etc running on Apple Silicon.

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).

It is in the process of. All maintained apps will get ported, either from macos or the ios version.

The Steam Survey shows how little Microsoft has to worry regarding the Year of Desktop Linux.

Steam doesn't run on ARM so the survey obviously doesn't have any relevant results.

Which means 0% sales from Steam games, so even less.

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.

I thought we were discussing about Steam on Linux ARM and its nonexistence desktop market regardless of which GNU/Linux variant is being targeted.

I have enough ARM based games on my Windows Phone.

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.

Reply on news.ycombinator.com