3 ms·

> Part of the problem is that no one can (or wants to) force the issue. Apple got up on stage and said, "three years from now, we won't be selling Intel-based l

> Part of the problem is that no one can (or wants to) force the issue. Apple got up on stage and said, "three years from now, we won't be selling Intel-based laptops. If you don't get on the train, you'll be left behind." Microsoft won't do that. Without that commitment, why should a software firm port its applications to ARM? Every software firm should be thinking, "if we don't do any work, Windows on ARM will be miserable and never get traction." Likewise, any chip maker is going to say, "I don't want to invest in ARM laptop/desktop chips until it's clear that ARM is going to be a major part of the Windows ecosystem." Finally customers are going to think, "I'm not going to buy an ARM laptop until it's clear that Microsoft, the chipmakers, and software firms are all behind this." No one is willing to commit to the future because that future won't exist unless they all move in unison. Honestly how hard is it to port software to ARM? Electron apps just work, .NET just works and Java does too. So does every language that isn't C/C++. And even on the C/C++ side, unless you are doing some funky things I doubt it's more effort than adding a release configuration that targets ARM in the build pipeline.

CountSessine 6y ago
Honestly how hard is it to port software to ARM? Electron apps just work, .NET just works and Java does too. So does every language that isn't C/C++. And even on the C/C++ side, unless you are doing some funky things I doubt it's more effort than adding a release configuration that targets ARM in the build pipeline. In my C/C++ experience - it’s a big push that a software company would just rather not make. Even if you already have an ARM SKU for a different OS, all sorts of things can cause trouble. If you’re coding in C/C++, you’re probably pretty interested in performance and you’ll have a lot of hand tuned assembly and/or SIMD operations, and that can be a big pain to port, especially with different compilers and intrinsics. I can only imagine the conversations that go on at Adobe or Autodesk or others when debating new platforms and SKUs. Given that even Microsoft wasn’t committed enough to ARM Windows to make a x64 emulator for it probably worked against this.
- physicsguy 6y ago
  We had a chat about this at work. We can’t even get started porting until some third party libraries (in the 3D modelling kernel sphere) that we license get ported - they’re integral to the software, so going without them isn’t an option.
Eric_WVGG 6y ago
"Electron, .NET, Java" so you're skipping over Win32, which has to be the largest slice of all. Photoshop falls into this bucket. It's on the C++ side and does "some funky things" in the way of SIMD to eke out more performance. If memory serves, it took them about eighteen months to get an Intel native version out the door after the PPC/Intel transition started. Any serious audio apps are going to have an equally hard time, they do a lot of hardware tricks in order to lower latency, and since they're not mainstream apps like MS Office or Adobe CS, they have much smaller teams of developers. That whole industry is very slow moving. Finally you've got CAD and 3D stuff. Obviously that requires good drivers. In fact, that's another way in which Microsoft will have a much harder time with this transition. Apple only has to write a driver for the one audio device that's in every Mac, the one GPU, etc.
- nicoburns 6y ago
  > Photoshop falls into this bucket. It's on the C++ side and does "some funky things" in the way of SIMD to eke out more performance. I wonder how much of that codebase is shared between Windows and macOS though. It's quite possible that Microsoft could take advantage of a lot of porting work that has already been done for Apple's M processors. If you support Windows/x86 and macOS/arm then it's probably not much more work to create a Windows/arm port. Unless there are compatibility issues with the Win32 APIs themselves?
legulere 6y ago
Lots of C/C++ programs do stuff that won’t work on ARM. Be it highly optimized assembly or intrinsics or reliance on memory access being atomic and having total store order.

CountSessine 6y ago

Honestly how hard is it to port software to ARM? Electron apps just work, .NET just works and Java does too. So does every language that isn't C/C++. And even on the C/C++ side, unless you are doing some funky things I doubt it's more effort than adding a release configuration that targets ARM in the build pipeline. In my C/C++ experience - it’s a big push that a software company would just rather not make. Even if you already have an ARM SKU for a different OS, all sorts of things can cause trouble. If you’re coding in C/C++, you’re probably pretty interested in performance and you’ll have a lot of hand tuned assembly and/or SIMD operations, and that can be a big pain to port, especially with different compilers and intrinsics. I can only imagine the conversations that go on at Adobe or Autodesk or others when debating new platforms and SKUs. Given that even Microsoft wasn’t committed enough to ARM Windows to make a x64 emulator for it probably worked against this.

physicsguy 6y ago
We had a chat about this at work. We can’t even get started porting until some third party libraries (in the 3D modelling kernel sphere) that we license get ported - they’re integral to the software, so going without them isn’t an option.

Eric_WVGG 6y ago

"Electron, .NET, Java" so you're skipping over Win32, which has to be the largest slice of all. Photoshop falls into this bucket. It's on the C++ side and does "some funky things" in the way of SIMD to eke out more performance. If memory serves, it took them about eighteen months to get an Intel native version out the door after the PPC/Intel transition started. Any serious audio apps are going to have an equally hard time, they do a lot of hardware tricks in order to lower latency, and since they're not mainstream apps like MS Office or Adobe CS, they have much smaller teams of developers. That whole industry is very slow moving. Finally you've got CAD and 3D stuff. Obviously that requires good drivers. In fact, that's another way in which Microsoft will have a much harder time with this transition. Apple only has to write a driver for the one audio device that's in every Mac, the one GPU, etc.

nicoburns 6y ago
> Photoshop falls into this bucket. It's on the C++ side and does "some funky things" in the way of SIMD to eke out more performance. I wonder how much of that codebase is shared between Windows and macOS though. It's quite possible that Microsoft could take advantage of a lot of porting work that has already been done for Apple's M processors. If you support Windows/x86 and macOS/arm then it's probably not much more work to create a Windows/arm port. Unless there are compatibility issues with the Win32 APIs themselves?

legulere 6y ago

Lots of C/C++ programs do stuff that won’t work on ARM. Be it highly optimized assembly or intrinsics or reliance on memory access being atomic and having total store order.