4 ms·

>> So binary sizes are going to double? If you're already supporting 2 arch it will only increase by 50 percent to support a 3rd ;-)

JKCalhoun 2y ago
And you'd like to think the binaries are still not the largest component of an app contributing to the file size. But who knows these days.
- DaiPlusPlus 2y ago
  Its the static-linking of the Swift runtime - it’s incredibly inelegant.
  - saagarjha 2y ago
    The Swift runtime is not statically linked on Apple’s platforms
    - kenferry 2y ago
      (Anymore)
      - saagarjha 2y ago
        I don't think it ever was?
        saurik 2y ago
        I do also believe it wasn't ever technically "statically linked", but the dynamic libraries were separately distributed as part of every app (and so I'd think the semantic slippage acceptable given the context). This has tons of advantages, but prevented Swift from being used in Apple libraries.
        DaiPlusPlus 2y ago
        Right; I was using loose and casual language there; I meant "bundling", not literally statically-linked. ----- I said "statically-linked" because the first thing that came to mind was go-lang's morbidly obese executable binary sizes, and mentally walked to iOS app sizes.
georgeburdell 2y ago
IME Mac binaries are much smaller than Windows for your average third party software. I don’t know why.
- ben7799 2y ago
  Windows binaries often seem to have excess statically linked libraries.. even though they are called DLLs which is supposed to mean dynamic. They might be loading it dynamically but they still seem to have decided to include their own private copy. I've even seen windows binaries have multiple different versions of the same DLL inside them, and it's a well known DLL that is duplicated multiple places elsewhere. All OSes/Apps do this but maybe a lot of Mac apps do it a little less. (I don't even have any real statistical idea how common this is with windows apps either)
  - tonyarkles 2y ago
    From having worked on Windows, OSX, and Linux desktop software over the years there's a few factors at play off the top of my head: - Windows DLLs don't usually have strong versioning baked into the filename. On OSX or Linux, there's usually the full version number baked in (libfoo.so.3.32.0) with symlinks stripping off version components. (libfoo.so, libfoo.so.3, libfoo.so.3.32) would all be symlinks to libfoo.so.3.32.0 and you can link against whichever major/minor/patch version you depend on. If your Windows app depends on a specific version it's going to be opening DLLs and querying them to find out what they are. - Native OSX software (not Electron) seems to depend much less on piles of external libraries because the OSX standard library is very rich and has a solid history of not breaking APIs and ABI across OS versions. While eg CoreAudio is guaranteed to be installed on an OSX install and be either compatible or discoverably-incompatible, the version of DirectSound you're going to have access to on Windows is more of a crapshoot. - Windows apps (except for the .Net runtime sometimes) are often designed for longevity. A couple of months ago I installed some software that was released in 1999 on my Windows 11 machine and it just worked. Bundling up those DLLs is part of why they work. - Linux apps can rely on downstream packaging to install the necessary shared libraries on demand, generally speaking. Linux desktop apps distributed as RPMs or DEBs can "just" declare which libraries they need and get them delivered during install.
Hamuko 2y ago
The most impressive I've seen has been four-arch support in a single bundle: PowerPC, 32-bit x86, 64-bit x86 and ARM64.
- pasc1878 2y ago
  Openstep had as a default 4 hppa, sparc, i386 and m68k - I often built stuff on a HP for production use on Intel and 68000 boxes and I think they also had unreleased m88k as well at the same time so internally might have had five way binaries.

JKCalhoun 2y ago

And you'd like to think the binaries are still not the largest component of an app contributing to the file size. But who knows these days.

DaiPlusPlus 2y ago
Its the static-linking of the Swift runtime - it’s incredibly inelegant.
- saagarjha 2y ago
  The Swift runtime is not statically linked on Apple’s platforms
  - kenferry 2y ago
    (Anymore)
    - saagarjha 2y ago
      I don't think it ever was?
      - saurik 2y ago
        I do also believe it wasn't ever technically "statically linked", but the dynamic libraries were separately distributed as part of every app (and so I'd think the semantic slippage acceptable given the context). This has tons of advantages, but prevented Swift from being used in Apple libraries.
        DaiPlusPlus 2y ago
        Right; I was using loose and casual language there; I meant "bundling", not literally statically-linked. ----- I said "statically-linked" because the first thing that came to mind was go-lang's morbidly obese executable binary sizes, and mentally walked to iOS app sizes.

georgeburdell 2y ago

IME Mac binaries are much smaller than Windows for your average third party software. I don’t know why.

ben7799 2y ago
Windows binaries often seem to have excess statically linked libraries.. even though they are called DLLs which is supposed to mean dynamic. They might be loading it dynamically but they still seem to have decided to include their own private copy. I've even seen windows binaries have multiple different versions of the same DLL inside them, and it's a well known DLL that is duplicated multiple places elsewhere. All OSes/Apps do this but maybe a lot of Mac apps do it a little less. (I don't even have any real statistical idea how common this is with windows apps either)
- tonyarkles 2y ago
  From having worked on Windows, OSX, and Linux desktop software over the years there's a few factors at play off the top of my head: - Windows DLLs don't usually have strong versioning baked into the filename. On OSX or Linux, there's usually the full version number baked in (libfoo.so.3.32.0) with symlinks stripping off version components. (libfoo.so, libfoo.so.3, libfoo.so.3.32) would all be symlinks to libfoo.so.3.32.0 and you can link against whichever major/minor/patch version you depend on. If your Windows app depends on a specific version it's going to be opening DLLs and querying them to find out what they are. - Native OSX software (not Electron) seems to depend much less on piles of external libraries because the OSX standard library is very rich and has a solid history of not breaking APIs and ABI across OS versions. While eg CoreAudio is guaranteed to be installed on an OSX install and be either compatible or discoverably-incompatible, the version of DirectSound you're going to have access to on Windows is more of a crapshoot. - Windows apps (except for the .Net runtime sometimes) are often designed for longevity. A couple of months ago I installed some software that was released in 1999 on my Windows 11 machine and it just worked. Bundling up those DLLs is part of why they work. - Linux apps can rely on downstream packaging to install the necessary shared libraries on demand, generally speaking. Linux desktop apps distributed as RPMs or DEBs can "just" declare which libraries they need and get them delivered during install.

Hamuko 2y ago

The most impressive I've seen has been four-arch support in a single bundle: PowerPC, 32-bit x86, 64-bit x86 and ARM64.

pasc1878 2y ago
Openstep had as a default 4 hppa, sparc, i386 and m68k - I often built stuff on a HP for production use on Intel and 68000 boxes and I think they also had unreleased m88k as well at the same time so internally might have had five way binaries.