2 ms·

Exactly how I understood it. So you can not just xcopy deploy an EXE (or on macOS an .app). You need to build an installation package that wraps both architectu

by andix 5y ago

Exactly how I understood it. So you can not just xcopy deploy an EXE (or on macOS an .app). You need to build an installation package that wraps both architectures and install it. During installation the correct architecture is chosen. My prediction: there won't be any ARM builds for most of the applications for the next 10 years. It must become super easy, like in Xcode or Android studio, where you just tick a check-box for another architecture and it gets build and bundled automatically.

gjsman-1000 5y ago
Nope, you can't. You would need to make an installation package and install the right one. No unified .app for Windows. Honestly, I've become more appreciative over the years how on Macs everything is a .app in the Applications folder instead of being scattered across the OS, and if you want to back them up or uninstall them you can just move them around like files. I was hoping just a little that with Microsoft's sandboxing efforts we'd get a sandboxed .app-like file for Windows, but no luck. The biggest problem, I think, that Microsoft has is that if I'm a company, there is literally almost zero reason to support ARM. It's technically complex, the userbase is tiny, the performance is slow on the few computers that have it, and those users don't technically need it for your app to run. So why bother? It's almost the same level of asking a company to support Linux machines. There are probably more Linux machines floating around than Windows on ARM. It would almost make more financial sense to port your app to MacOS than Windows on ARM if you do cost/benefit.
- andix 5y ago
  For software developers it must be easy and cheap to support ARM. Nobody will change their complete development and deployment pipeline just to support a few ARM users. Every packaging framework I used on windows introduced it's own problems so far. It can take literally hundrets (!) of development hours until your Installshied, MSI or MSIX package works on all your customer systems. If you have a big user base it can happen that customer support spends thousands of hours to anlyse and fix installer issues.

by andix 5y ago

gjsman-1000 5y ago

Nope, you can't. You would need to make an installation package and install the right one. No unified .app for Windows. Honestly, I've become more appreciative over the years how on Macs everything is a .app in the Applications folder instead of being scattered across the OS, and if you want to back them up or uninstall them you can just move them around like files. I was hoping just a little that with Microsoft's sandboxing efforts we'd get a sandboxed .app-like file for Windows, but no luck. The biggest problem, I think, that Microsoft has is that if I'm a company, there is literally almost zero reason to support ARM. It's technically complex, the userbase is tiny, the performance is slow on the few computers that have it, and those users don't technically need it for your app to run. So why bother? It's almost the same level of asking a company to support Linux machines. There are probably more Linux machines floating around than Windows on ARM. It would almost make more financial sense to port your app to MacOS than Windows on ARM if you do cost/benefit.

andix 5y ago
For software developers it must be easy and cheap to support ARM. Nobody will change their complete development and deployment pipeline just to support a few ARM users. Every packaging framework I used on windows introduced it's own problems so far. It can take literally hundrets (!) of development hours until your Installshied, MSI or MSIX package works on all your customer systems. If you have a big user base it can happen that customer support spends thousands of hours to anlyse and fix installer issues.