[Info-vax] Shared Objects And DLL Hell

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Thu Jun 30 11:07:18 EDT 2016


On 2016-06-30 06:06:08 +0000, lawrencedo99 at gmail.com said:

> I saw some discussion elsewhere on why Microsoft Windows is prone to 
> “DLL Hell”, and whether Linux had a similar problem.

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.

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.  DECwindows did this 
with version-numbered naming ~twenty years ago, and — for an entire 
package — Oracle Rdb has one of the best multi-version implementation 
available on OpenVMS.

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 — is FOOSHARE010.EXE 
really FOO V1.0, or is that something else that only seems to be FOO 
V1.0?  OpenVMS has no concept of signed executable images, much less 
signed component objects, and the structures intended for parts of that 
work including installation verification (VMSKITBLD.XML, etc) were 
never finished.


-- 
Pure Personal Opinion | HoffmanLabs LLC 




More information about the Info-vax mailing list