10 ms·

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

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.

jayd16 6y ago
>MacOS have much more complete suites of software available MacOS does? By what measure?
- tyingq 6y ago
  Vs Linux, I get (Like the MS office suite), but I think the OP meant vs Windows, which is hard to grok.
- ogre_codes 6y ago
  > 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.
  - pjmlp 6y ago
    Yep, for those 8% of world wide desktop users.
  - jayd16 6y ago
    Ah you're assuming they will at launch, not what currently exists.
    - chrisseaton 6y ago
      Adobe have demonstrated Photoshop etc running on Apple Silicon.
  - yyyk 6y ago
    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).
- mixmastamyk 6y ago
  It is in the process of. All maintained apps will get ported, either from macos or the ios version.
solarkraft 6y ago
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.
- Koshkin 6y ago
  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.)
  - rat9988 6y ago
    >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.
  - ogre_codes 6y ago
    Is there even a Windows ARM server platform which the public can port software to?
    - justincormack 6y ago
      There is no publically available Windows Server Arm, no.
      - jareds 6y ago
        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.
deleted 6y ago
[deleted]
microcolonel 6y ago
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.
- saagarjha 6y ago
  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.
  - microcolonel 6y ago
    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).
- hedora 6y ago
  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.
  - microcolonel 6y ago
    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-container-on-x86/ https://www.stereolabs.com/docs/docker/building-arm-containe...
josteink 6y ago
> 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)
- ogre_codes 6y ago
  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.
unnouinceput 6y ago
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.
- ogre_codes 6y ago
  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.
  - AnIdiotOnTheNet 6y ago
    > 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.
    - aib 6y ago
      > the least software support, even in this limited scope I think they were talking about ARM.
    - ogre_codes 6y ago
      > 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.
pjmlp 6y ago
The Steam Survey shows how little Microsoft has to worry regarding the Year of Desktop Linux.
- fnord123 6y ago
  Steam doesn't run on ARM so the survey obviously doesn't have any relevant results.
  - pjmlp 6y ago
    Which means 0% sales from Steam games, so even less.
    - imtringued 6y ago
      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.
      - pjmlp 6y ago
        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.
      - int_19h 6y ago
        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.
yyyk 6y ago
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.
- zapzupnz 6y ago
  > 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.
  - ogre_codes 6y ago
    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.
- ogre_codes 6y ago
  > 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.
deleted 6y ago
[deleted]

jayd16 6y ago

>MacOS have much more complete suites of software available MacOS does? By what measure?

tyingq 6y ago
Vs Linux, I get (Like the MS office suite), but I think the OP meant vs Windows, which is hard to grok.
ogre_codes 6y ago
> 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.
- pjmlp 6y ago
  Yep, for those 8% of world wide desktop users.
- jayd16 6y ago
  Ah you're assuming they will at launch, not what currently exists.
  - chrisseaton 6y ago
    Adobe have demonstrated Photoshop etc running on Apple Silicon.
- yyyk 6y ago
  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).
mixmastamyk 6y ago
It is in the process of. All maintained apps will get ported, either from macos or the ios version.

solarkraft 6y ago

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.

Koshkin 6y ago
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.)
- rat9988 6y ago
  >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.
- ogre_codes 6y ago
  Is there even a Windows ARM server platform which the public can port software to?
  - justincormack 6y ago
    There is no publically available Windows Server Arm, no.
    - jareds 6y ago
      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.

deleted 6y ago

[deleted]

microcolonel 6y ago

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.

saagarjha 6y ago
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.
- microcolonel 6y ago
  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).
hedora 6y ago
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.
- microcolonel 6y ago
  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-container-on-x86/ https://www.stereolabs.com/docs/docker/building-arm-containe...

josteink 6y ago

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

ogre_codes 6y ago
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.

unnouinceput 6y ago

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.

ogre_codes 6y ago
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.
- AnIdiotOnTheNet 6y ago
  > 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.
  - aib 6y ago
    > the least software support, even in this limited scope I think they were talking about ARM.
  - ogre_codes 6y ago
    > 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.

pjmlp 6y ago

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

fnord123 6y ago
Steam doesn't run on ARM so the survey obviously doesn't have any relevant results.
- pjmlp 6y ago
  Which means 0% sales from Steam games, so even less.
  - imtringued 6y ago
    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.
    - pjmlp 6y ago
      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.
    - int_19h 6y ago
      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.

yyyk 6y ago

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.

zapzupnz 6y ago
> 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.
- ogre_codes 6y ago
  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.
ogre_codes 6y ago
> 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.

deleted 6y ago

[deleted]