[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