5 ms·

It seems to me that the issue isn't between shared code and no shared code but between statically and dynamically linking that code. It's a question of bundling

• erik_seaberg 8y ago
  DLL hell happened because Windows used to lack a package manager, leaving apps to bundle their dependencies and overwrite other versions (without semver names!) in common directories.
  • astine 8y ago
    Yeah, Windows has traditionally been worse than Linux in this capacity, but my point is that dependency management is a non-trivial problem. My experience is that package managers usually work but not always (I've had occasional issues on Arch) and the fact that you need a package manager, and how sophisticated they often have to be, shows how tricky the problem can be to solve.
  • pjmlp 8y ago
    As if Linux is any better, specially regarding glibc.
    • jiveturkey 8y ago
      it is better. (Unix/ELF generically, not linux). versioned symbols are a YUGE improvement over DLLs.
      • pjmlp 8y ago
        Hence why I explicitly mentioned Linux. Also Aix uses the same model as Windows. Finally, .NET Assemblies are versioned, and Microsoft has introduced Application Manifests around Windows XP. https://docs.microsoft.com/en-us/windows/desktop/sbscs/application-manifests https://docs.microsoft.com/en-us/windows/desktop/sbscs/appli... So it a matter of actually taking the effort of specifying the versions that the application works with.
        • int_19h 8y ago
          All assemblies are versioned and can potentially have unique strong names, not just .NET assemblies. A native DLL can still be an assembly. https://en.wikipedia.org/wiki/Side-by-side_assembly https://en.wikipedia.org/wiki/Side-by-side_assembly
        • btschaegg 8y ago
          > Finally, .NET Assemblies are versioned, But then, you still have to put up with defining potentially hundreds of <bindingRedirect>s in config files to even get an application to run correctly, even though they mostly don't share their DLLs. The only thing it takes is Nuget dowloading a newer version of some dependency another library depends on, even if it's backwards compatible with the old API. Which, of course, it should always be if you haven't switched to a new major version. Edit: Also, I find it very disturbing that the resulting errors always happen to be crashes during runtime instead of up-front. If that happens with a plugin or through reflection: fine. But for most of .NET code, dependencies should be able to be loaded during startup.
  • int_19h 8y ago
    To be even more specific, it happened because apps dumped DLLs into shared system directories instead of bundling them alongside the app binary. Since on Windows, each app has its own directory, it's easy to bundle in a way that doesn't mess up other apps.
    • __d 8y ago
      It became so once the DLL search path was changed to put the .exe file's containing folder first. Prior to that, the system dirs were searched first, which was the trigger for the DLL hell issue.
      • int_19h 8y ago
        I mean, if all apps avoided writing to the global folders (i.e. reserve it for OS-managed components), there wouldn't be an issue even with the old arrangement. But not even Microsoft's own products respected that in practice.
• tomatocracy 8y ago
  Static libraries are a potentially bigger problem when your library is tightly coupled to a particular version of some other process (eg an X windows server). The real distinction in my view is between tightly coupled components and loosely coupled ones. Loosely coupled as a design paradigm is harder to design and maintain for the programmer and in some cases has a performance impact, but a lot nicer for the admin and feels ‘cleaner’ to me, at least.