3 ms·

I just did a double take at "Windows and macOS aren't as bad as Linux". Packaging for Windows is truly horrible. Even getting the dependencies to build your ap

by s20n 2mo ago

I just did a double take at "Windows and macOS aren't as bad as Linux". Packaging for Windows is truly horrible. Even getting the dependencies to build your app on Windows is a nightmare (the author mentions winget which is no good for libraries)? I maintain an app that uses libsfml, libfluidsynth and a bunch of other dependencies. Packaging on windows was only made possible by MSYS2 and pacman which is literally a linux package manager.

nemomarx 2mo ago
I always assumed those were statically linked into the binary or installer or something on Windows. Are people pulling down dependencies through the .msi?
- s20n 2mo ago
  Yes, the DLLs are usually installed along with the binary by the installer on Windows. What I was talking about was the setup required on your machine/CI to get the dependencies to build those DLLs.
- okanat 2mo ago
  Windows provides almost 100% of the system-level dependencies you need. You don't need to specify things like "I need gstreamer for video decode" or "openSSL for my network". Those are all part of a standard Windows system and they have stable API/ABIs. Only thing you ship with your application are the libraries specific to your app. If you use Qt, you ship Qt libraries as bundled DLLs. If you use Havok physics engine, you ship that as a bundled DLL. MSI can trigger things like installing optional Windows components but it is not a package ecosystem like apt or dnf. It is more like dpkg or rpm.
inigyou 2mo ago
You seem to be assuming building for Windows in a Linux-like flow. If Linux is a series of tubes, Windows is a truck. On Windows, you build the library and statically link it to your executable. The executable is one big monolith that doesn't get cut up into miniscule pieces like on Linux. If you really need a DLL for some reason, you use as few as possible, and put it right next to the executable. On Windows, binary artifacts are "heavy". Of course this assumes your main product is an executable - if you're intentionally shipping a COM object or something, which is a DLL, different guidelines may apply. In that case you should still ship a "heavy" single-DLL COM object.
- embedding-shape 2mo ago
  > The executable is one big monolith that I don't think this is entirely accurate and in fact, I think you'll encounter limitations in how big the .exe could actually be, before the OS says no, compared to Linux or macOS where you can pack more into it. But still, on all platforms, you won't have multi-GB binaries, you have external resources which among them are DLLs and whatever, and the binary ("executable") itself ends up some MBs. At least most (if not all) of the large professional software I use on Windows is packaged like that.
  - inigyou 2mo ago
    Large professional software has components like COM servers, or several executables sharing the same app code which then goes in a DLL. What they don't do is divide up their DLLs any more than necessary. An open source library could be a DLL to comply with LGPL but it won't be one just because they can, while on Linux it would be a separate .so because it's separately updated. What are you making?
- okanat 2mo ago
  I think this approach is misguided. Shipping your own DLLs is standard with Windows applications and good workflows using Visual Studio can quite easily can bundle everything you need. If you need somewhat Linux-like build infrastructure, conan is very helpful to install all your dependencies and to create deployment packages.
  - inigyou 2mo ago
    Shipping in C:\\Program Files\\Your Name is standard with Windows applications; DLLs aren't shared between different applications like in Linux, so there's no reason to use them. Additionally, the Windows dynamic loader doesn't squish all DLLs into one global namespace like the Linux one does. Every time you call a function from a DLL there is extra friction, even for the programmer. There's also the libc linking problem. Each DLL may get its own copy for libc, either because they are statically linked or because they are compiled with different versions. If you try to fopen in one DLL and fclose in another, or malloc in one and free in another, it's liable to crash. This might've been solved in the 20 years since I learned about it, though.
embedding-shape 2mo ago
> Packaging for Windows is truly horrible. Even getting the dependencies to build your app on Windows is a nightmare (the author mentions winget which is no good for libraries)? The only sane way I've found to do this, is ensuring I never package it on a personal computer/computer with state, always a CI worker with fresh everything, isolated from everything else, with nothing assumed. Then for the packaging, define all required dependencies up front, and you won't end up with the typical "oh, I forgot to ship/package lib X and I didn't get any errors because I have it installed". Helps to set all this up with Nix too, can help you manage the VM lifecycle, and makes reproducible cross-platform a lot easier :)
lpghatguy 2mo ago
99% of applications on Windows will just include all their dependencies in a folder with the exe. It’s great — it works, it’s compatible, it’s simple! Getting dependencies to build your app is definitely harder on Windows but the fact that you can just throw things in a folder for a binary distribution is unbeat!
okanat 2mo ago
You're trying to force Linux-style packaging where declaratively specified dependencies from a single(-ish) repository and shared DLLs are a necessity due to intentionally hostile architecture of GNU/Linux for shipping binary-only software. You have to build everything as one single OS, because that's how Unix people did in 80s. Unix people weren't designing an OS for general binary software distribution. You need to give up Linux-style thinking first. Windows-native tools like Visual Studio, WiX, MSI etc. make it nice and easy to vendor your own DLLs. They are designed for closed-source and binary-distribution first. And if the libraries are designed for this ecosystem, you just import them in VS. If you don't want to give up Linux-style dependency management you can use source-based build systems. You can use `conan` as a source package manager to get something closer and then export every single binary dependency `conan install . --deploy=runtime_deploy --output-folder=dist`.

by s20n 2mo ago

nemomarx 2mo ago

I always assumed those were statically linked into the binary or installer or something on Windows. Are people pulling down dependencies through the .msi?

s20n 2mo ago
Yes, the DLLs are usually installed along with the binary by the installer on Windows. What I was talking about was the setup required on your machine/CI to get the dependencies to build those DLLs.
okanat 2mo ago
Windows provides almost 100% of the system-level dependencies you need. You don't need to specify things like "I need gstreamer for video decode" or "openSSL for my network". Those are all part of a standard Windows system and they have stable API/ABIs. Only thing you ship with your application are the libraries specific to your app. If you use Qt, you ship Qt libraries as bundled DLLs. If you use Havok physics engine, you ship that as a bundled DLL. MSI can trigger things like installing optional Windows components but it is not a package ecosystem like apt or dnf. It is more like dpkg or rpm.

inigyou 2mo ago

You seem to be assuming building for Windows in a Linux-like flow. If Linux is a series of tubes, Windows is a truck. On Windows, you build the library and statically link it to your executable. The executable is one big monolith that doesn't get cut up into miniscule pieces like on Linux. If you really need a DLL for some reason, you use as few as possible, and put it right next to the executable. On Windows, binary artifacts are "heavy". Of course this assumes your main product is an executable - if you're intentionally shipping a COM object or something, which is a DLL, different guidelines may apply. In that case you should still ship a "heavy" single-DLL COM object.

embedding-shape 2mo ago
> The executable is one big monolith that I don't think this is entirely accurate and in fact, I think you'll encounter limitations in how big the .exe could actually be, before the OS says no, compared to Linux or macOS where you can pack more into it. But still, on all platforms, you won't have multi-GB binaries, you have external resources which among them are DLLs and whatever, and the binary ("executable") itself ends up some MBs. At least most (if not all) of the large professional software I use on Windows is packaged like that.
- inigyou 2mo ago
  Large professional software has components like COM servers, or several executables sharing the same app code which then goes in a DLL. What they don't do is divide up their DLLs any more than necessary. An open source library could be a DLL to comply with LGPL but it won't be one just because they can, while on Linux it would be a separate .so because it's separately updated. What are you making?
okanat 2mo ago
I think this approach is misguided. Shipping your own DLLs is standard with Windows applications and good workflows using Visual Studio can quite easily can bundle everything you need. If you need somewhat Linux-like build infrastructure, conan is very helpful to install all your dependencies and to create deployment packages.
- inigyou 2mo ago
  Shipping in C:\\Program Files\\Your Name is standard with Windows applications; DLLs aren't shared between different applications like in Linux, so there's no reason to use them. Additionally, the Windows dynamic loader doesn't squish all DLLs into one global namespace like the Linux one does. Every time you call a function from a DLL there is extra friction, even for the programmer. There's also the libc linking problem. Each DLL may get its own copy for libc, either because they are statically linked or because they are compiled with different versions. If you try to fopen in one DLL and fclose in another, or malloc in one and free in another, it's liable to crash. This might've been solved in the 20 years since I learned about it, though.

embedding-shape 2mo ago

> Packaging for Windows is truly horrible. Even getting the dependencies to build your app on Windows is a nightmare (the author mentions winget which is no good for libraries)? The only sane way I've found to do this, is ensuring I never package it on a personal computer/computer with state, always a CI worker with fresh everything, isolated from everything else, with nothing assumed. Then for the packaging, define all required dependencies up front, and you won't end up with the typical "oh, I forgot to ship/package lib X and I didn't get any errors because I have it installed". Helps to set all this up with Nix too, can help you manage the VM lifecycle, and makes reproducible cross-platform a lot easier :)

lpghatguy 2mo ago

99% of applications on Windows will just include all their dependencies in a folder with the exe. It’s great — it works, it’s compatible, it’s simple! Getting dependencies to build your app is definitely harder on Windows but the fact that you can just throw things in a folder for a binary distribution is unbeat!

okanat 2mo ago

You're trying to force Linux-style packaging where declaratively specified dependencies from a single(-ish) repository and shared DLLs are a necessity due to intentionally hostile architecture of GNU/Linux for shipping binary-only software. You have to build everything as one single OS, because that's how Unix people did in 80s. Unix people weren't designing an OS for general binary software distribution. You need to give up Linux-style thinking first. Windows-native tools like Visual Studio, WiX, MSI etc. make it nice and easy to vendor your own DLLs. They are designed for closed-source and binary-distribution first. And if the libraries are designed for this ecosystem, you just import them in VS. If you don't want to give up Linux-style dependency management you can use source-based build systems. You can use `conan` as a source package manager to get something closer and then export every single binary dependency `conan install . --deploy=runtime_deploy --output-folder=dist`.