4 ms·

Are there finally fat binaries? Once again you would need to build and deploy separately for ARM. Put some logic into your installer or your software, which ver

by andix 5y ago

Are there finally fat binaries? Once again you would need to build and deploy separately for ARM. Put some logic into your installer or your software, which version to install. macOS, iOS and Android have built in solutions for years, to just publish Packages with multiple architectures and the system executes the appropriate binary.

my123 5y ago
On modern Windows, you can have multi arch packages as .appxbundle or .msixbundle.
- andix 5y ago
  And so far nobody is using that.
  - ripley12 5y ago
    Yeah, MSIX is a mess and I'm not surprised by the low uptake. It's evolved from the ultra-locked-down AppX days slowly and in a very messy way; documentation is often out of date/incomplete, VS tooling is buggy, and the kicker is that App Installer (required to install an MSIX package with a double-click) doesn't even ship on all versions of Windows. I have mostly learned to live with it, but I certainly do not like it.
    - pjmlp 5y ago
      It is not being used, because Microsoft isn't Apple so everyone keeps using Installshield and friends.
      - fomine3 5y ago
        Also all installer solution is somewhat hated.
arthur2e5 5y ago
The whole point of the new ABI is to not require that much rebuilding. You can keep the main application in x64 and only the performance-critical functions in a ARM64EC library. Or you can have a ARM64EC application that loads a x64 plugin or third party lib.
- andix 5y ago
  Yeah, but ARM64EC applications won't run on a x64 Windows. So you need to be able to deploy both (x64-version and ARM64EC-version). Or did I mix up something?
  - gjsman-1000 5y ago
    ARM64EC is so that you can ship a semi-ARM version of your app without having to do a full ARM port. You still need to ship two versions of your app - you can't create a binary that runs on x64 and ARM like Apple's Universal 2.
    - 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.
mappu 5y ago
Windows on ARM already had CHPE binaries which mix ARM and x86 in the same address space - i wonder if this new ABI is a related effort,
baybal2 5y ago
> Are there finally fat binaries? No, it's more than that. It's a mix-and-match of x86, and arm binary code, so you don't have to keep a two separate copies of every binary.
- andix 5y ago
  Is it though? It is a binary format for Windows ARM, so you can mix x64 and ARM code there. x64 or x86 Windows will still require the old binary format. So you once again have to build and deploy two versions.
- 1propionyl 5y ago
  > It's a mix-and-match of x86, and arm binary code, so you don't have to keep a two separate copies of every binary. That's what a fat binary is. Multiple architectures supported by a single binary. In the simplest case, simply by including both, though some de duplication of data segments can be managed.
  - baybal2 5y ago
    > though some de duplication of data segments can be managed. Not just duplication, but they want to make the gigatons of binary only software, and libraries available for WinARM without their authors doing a thing. Most commercial companies would simply not care enough about WinARM to move a finger.

by andix 5y ago

my123 5y ago

On modern Windows, you can have multi arch packages as .appxbundle or .msixbundle.

andix 5y ago
And so far nobody is using that.
- ripley12 5y ago
  Yeah, MSIX is a mess and I'm not surprised by the low uptake. It's evolved from the ultra-locked-down AppX days slowly and in a very messy way; documentation is often out of date/incomplete, VS tooling is buggy, and the kicker is that App Installer (required to install an MSIX package with a double-click) doesn't even ship on all versions of Windows. I have mostly learned to live with it, but I certainly do not like it.
  - pjmlp 5y ago
    It is not being used, because Microsoft isn't Apple so everyone keeps using Installshield and friends.
    - fomine3 5y ago
      Also all installer solution is somewhat hated.

arthur2e5 5y ago

The whole point of the new ABI is to not require that much rebuilding. You can keep the main application in x64 and only the performance-critical functions in a ARM64EC library. Or you can have a ARM64EC application that loads a x64 plugin or third party lib.

andix 5y ago
Yeah, but ARM64EC applications won't run on a x64 Windows. So you need to be able to deploy both (x64-version and ARM64EC-version). Or did I mix up something?
- gjsman-1000 5y ago
  ARM64EC is so that you can ship a semi-ARM version of your app without having to do a full ARM port. You still need to ship two versions of your app - you can't create a binary that runs on x64 and ARM like Apple's Universal 2.
  - 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.

mappu 5y ago

Windows on ARM already had CHPE binaries which mix ARM and x86 in the same address space - i wonder if this new ABI is a related effort,

baybal2 5y ago

> Are there finally fat binaries? No, it's more than that. It's a mix-and-match of x86, and arm binary code, so you don't have to keep a two separate copies of every binary.

andix 5y ago
Is it though? It is a binary format for Windows ARM, so you can mix x64 and ARM code there. x64 or x86 Windows will still require the old binary format. So you once again have to build and deploy two versions.
1propionyl 5y ago
> It's a mix-and-match of x86, and arm binary code, so you don't have to keep a two separate copies of every binary. That's what a fat binary is. Multiple architectures supported by a single binary. In the simplest case, simply by including both, though some de duplication of data segments can be managed.
- baybal2 5y ago
  > though some de duplication of data segments can be managed. Not just duplication, but they want to make the gigatons of binary only software, and libraries available for WinARM without their authors doing a thing. Most commercial companies would simply not care enough about WinARM to move a finger.