I think the inverse argument can be made against shared libraries: if an update introduces a vulnerability, now all programs which depend on that library become vulnerable.

Security problems often exist for years at a time.

Rather than making all of those applications vulnerable at the same time, they slowly become vulnerable as the release binaries are linked against bugged code. If it's not linked at runtime, or recompiled, it'll be vulnerable forever.

I would like to think that projects overall tend to fix more bugs than introduce them. It's not like projects go from orderly to disorderly over time.

But some are high value targets (crypto ones, etc).

If I write malware, I guess it’s possibly easier to infect one library than thousands of executables.

> but years ago there was serious vulnerability in a very common open source library library whose name escapes me (it wasn't libgcc, someone help a brother here).

I believe you're referring to an OpenSSH vulnerability?

...though, I did a search just now to find when it was from (I remember there being a major one around the time you're thinking of), and instead found posts from only two months ago about another one that has existed for at least 18 years.

I think this represents a fundamental (and rather annoying) difference between Linux and Windows.

On Windows, the only platform-supported global library format is COM, and that requires a very specific programming style--HRESULTs and all the rest. True, registered COM DLLs can be linked to without separate header/symbol files, and installing new programs/libraries never requires local compilation, but the extra overhead of COM itself, and the fact that it's a walled garden code-wise, makes it rather unpopular. It's also nigh on impossible to port COM code to other apps without resorting to something like WINE (which can't compete performance-wise when running highly parallel COM apps/services). Not to mention how ugly C++ COM source files are.

It would be so nice for us all if Windows shipped with compilers, straight-up C libraries with headers, a package manager, a better shell, ...

Windows has C-style, shared libraries just like Linux - DLLs. The entire Win32 API that is the backbone of Windows is implemented in system DLLs.

Every compiler that produces native binaries for Windows links with these DLLs (C, C++, Go, FreePascal/Delphi, etc.), either statically or dynamically, using C calling conventions.

COM is the Component Object Model, which is implemented in DLLs, but is something different:

https://en.wikipedia.org/wiki/Component_Object_Model

COM, or some form of it, is used heavily with .NET and the new UWP runtime, but those are newer runtimes that sort of sit on top of the Win32 API (to some extent, UWP is actually integrated into the OS itself, but, AFAIK, still uses the underlying Win32 APIs).

Thanks for the corrections.

You sound extremely confused. COM has not been the only global dependency format on Windows since.. longer than I can remember. Heck, even when .NET first shipped in 2000 or 2001 you could register .NET binaries in the GAC. And any DLL in system32 is automatically available for global consumption.

I think. You can have global DLLs in Windows. They just need to be in PATH.