[Mono-devel-list] Proposal: Library Loading

[Ferdinand Prantl]

Hallo Jordi and Jon, 

> From: Jordi Mas [mailto:jordi at ximian.com] 
> On dc, 2004-04-14 at 03:25, Jonathan Pryor wrote:
> > On Tue, 2004-04-13 at 21:07, Vladimir Vukicevic wrote:
> > > On Tue, 2004-04-13 at 17:52, Jonathan Pryor wrote:
> > > 
> > > > 1.  What happens if there are multiple major versions 
> of libfoo.so
> > > >     installed: libfoo.so.1 and libfoo.so.2?  Which gets 
> loaded?  At
> > > >     present, whichever libfoo-devel package was 
> installed, which may be
> > > >     ABI-incompatible with what the assembly was written 
> against.  Oops.
> > > 
> > > What happens if I have one assembly that needs libfoo.so.1, and 
> > > another that wants libfoo.so.2?
> > 
> > Then we're screwed. :-)
> > 
> > On the plus side, this can't happen on Windows since 
> Windows doesn't 
> > support versioned libraries...
> 
> Hello Jon,
> 
> Just to mention that there is an optional VERSION resource that any
> win32 binary can contain, in fact many do have a VERSION resource.

[snip]

Actually, the VERSION resource can be used only passively, one can read it
and behave some way (rewrite a file or not). There is no support for it in
the OS dll loader. With lack of symbolic and hard links on windows it is not
alone usable to introduce a library versioning system. Hard links are
supported on NTFS 5 and higher, but similar library versioning concept from
un*xes is not used, from the historical reason. (There is posibility to use
implement a system locally in an application, which will dynamically load a
dll, test its version and then go to another one as described somewhere, but
then we'd have .NET :-)

Microsoft introduced dll versionning for WIndows 2000 and higher, which
brings a library versioning system controlled by the OS configuration,
something like .NET, also with a new API methods, but it is used probly by
Microsoft themselves (try to peek into WinSxS) ...

The native library versioning concepts are very different on both platforms
and that is why I like more the non-intrusive solution with conf.d than the
new attribute for DllImport. Im nakes the versioning also externally
configurable without recompiling or somehow modifying the assembly. The
attribute "version" can be optional and even then used only if the platform
supports it (if not, maybe warn about it, or check the version at least, if
possible).

Ferda