[Info-vax] Shared Objects And DLL Hell

[lawrencedo99 at gmail.com]

On Friday, July 1, 2016 at 3:07:20 AM UTC+12, Stephen Hoffman wrote:

> DLL Hell is a solved problem.  Has been for many years.   Apps are 
> adopting the available solutions, too.  Slowly.
> 
> Have a look at .NET, and with the way that applications now deploy with 
> the expected frameworks, and with how applications are increasingly 
> bundled together and don't need to splatter their giblets around a 
> system.  Or how the applications are prohibited from that.

Windows Dotnet has been around since about 2001, hasn’t it? So “slowly” is a bit of an understatement.

The idea of collecting all your dependencies together into “assemblies”, so that different apps can have different versions of the same dependency, sounds fine in theory, it seems to work less well in practice. For example, later versions of Dotnet are supposed to be backward-compatible with earlier versions, yet you often end up with systems where there are multiple versions installed side-by-side.

Then there’s the question of Microsoft’s commitment to Dotnet. It got distracted by Silverlight at one point, then this WinRT thing. Currently it is pushing “Universal Windows Platform”, but already there are questions about how “Universal” this is going to be, with limitations being imposed on the XBox version (no games!) and the terminal condition of Windows Phone.

> Dealing with incompatible versions through version-numbered shareable 
> image filenames or the occasional version-numbered object library is 
> common on most platforms, including on OpenVMS.

How does VMS deal with it? I trust it doesn’t use file version numbers...

> Where this naming gets in trouble is now further along, around 
> deploying applications and later with cleaning up any added 
> dependencies, and with more subtle issues such as code signing and with 
> ensuring that packages can't hijack each other ...

You don’t have that problem with open-source software, only with proprietary packages. The whole business with virtualization and containerization and all the rest is mainly because you cannot trust proprietary software to play nice.

Most Linux distros (even Android) have the concept of signing packages, rather than individual executables.