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.
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.
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.
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.
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.
> 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.
Win32 and CRT (libc) is shared among programs, .NET framework DLLs are also shared. Industrial software does ship multiple .exes that depend on the same subset of DLLs. Anything that uses registered COM interfaces also use shared pages for the DLLs in memory.
> 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.
This is an advantage of Windows over Linux where those squish into one unified namespace create compatibility problems and force the programmer to compile everything as a one single big universe / distro. It basically makes long-term backwards compat impossible.
Compile-time linked DLLs have no significant overhead compared to Linux after they are loaded and the loader has done its relocation work.
> 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.
This still kinda exists. However, Microsoft hasn't broken their CRT ABI since 2015. It is a feature not a bug IMO. All properly made libraries ship their own allocation and free functions for this very reason. It is not specific to Windows. This does happen with Linux shared libraries when they use their custom allocators. Giving up the ability to link with different libc versions, ability to link with multiple versions of the same library or good backwards compatibility is not a good tradeoff just to have a single global `malloc / free` call.
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.