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)
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.
On Windows isn't it possible to have the OS deal with the DLL version issue by using side-by-side assemblies? I believe in practice that's only ever used by DLLs provided by the OS, but I thought it was possible to apply the mechanism to other DLLs as well.
Maybe? I haven’t really done a deep dive into that. You’d still have to bundle them along with the installer though since there isn’t a good way to request 3rd-party DLLs (heck, there isn’t even a good way to request a specific version of MSVCRT…)
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)