[Info-vax] Shared Objects And DLL Hell

[Stephen Hoffman]

On 2016-06-30 22:47:26 +0000, lawrencedo99 at gmail.com said:

> 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.

OpenVMS application development tools and practices are not exactly 
bleeding edge.  VAX C has been deprecated for longer than Windows 95 
has been available and various folks still haven't reviewed and 
reworked their application code for compatibility ANSI/ISO C, after all.

As for Microsoft?   Learning from the ideas and implementations of 
others does not mean reimplementing bugs, limitations, misfeatures or 
errata.   Best to learn and improve and avoid.

>> 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...

Badly.  Manually.  Rdb has a command procedure used to set the Rdb 
version, and that's about the most reasonable approach presently in 
use.  Entirely unintegrated, of course.

>> 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.

False.

> The whole business with virtualization and containerization and all the 
> rest is mainly because you cannot trust proprietary software to play 
> nice.

Nor can open source be particularly trusted.   Either the specific wad 
of code, or the package in general.   This is why sandboxes are part of 
most any container strategy, and part of app stacking.   To isolate 
damage and bugs that can be latent whether intentionally or otherwise, 
and to (try to) isolate dependencies for that matter.

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

OpenVMS does not have that mechanism for anything past PCSI and 
VMSINSTAL kits, and the closest analog is CDSA.  That's long been 
deprecated, too.  Whether those existing checks are reliable is not 
something I'm willing to affirm; not without reviewing details of the 
implementation.



-- 
Pure Personal Opinion | HoffmanLabs LLC