Ant: Re: Ant: Re: Ant: Re: Ant: Re: Ant: Re: [Gtk-sharp-list] gtk-sharp.dll not working on linux because it references win32 dll's

[Jonathan Pryor]

On Thu, 2005-07-21 at 20:42 +0200, Jost Boekemeier wrote:
> Hi,
> 
> > Because that's one of the *fundamental*
> > underpinnings of .NET. 
> 
> Pardon?  *Every* such system, be it elf, java, ... has
> the concept of a "most recent" or "default" version.

Thank you for completely missing the point of the example in my last
message.  Obviously I wasn't clear enough.

So, some historical perspective: 

 1. User installs AppA, which depends on MFC.DLL, and installs this 
    into C:\Windows.

 2. User installs AppB, which installs a different version of MFC.DLL
    into C:\Windows.

 3. User tries to run AppA.  AppA aborts.  User is not happy.

 4. User uninstalls AppB.  AppB's uninstall program is broken, and 
    doesn't revert MFC.DLL.  AppA still aborts.  (There are perfectly 
    valid reasons to not revert MFC.DLL as well, since Win32 .DLLs 
    contain a version number and AppB's .DLL may be more recent.
    That doesn't keep AppA from breaking, though.)

 5. User is forced to re-install the entire OS in order to get a sane
    version of MFC.DLL (though the user doesn't actually understand 
    this, they just believe that Windows is flaky-as-sin and requires
    these period re-installs...)

Welcome to "DLL Hell."   This is what happens when *real* library
versioning is not present.  This is what .NET tries to fix.

And this is precisely what you want to do.

You're WRONG.  WRONG WRONG WRONG WRONG WRONG.

Did I mention that you're WRONG?

It's because of this that Microsoft started putting version numbers into
library names -- see MFC42.DLL.  However, maintaining backward
compatibility is difficult, so they eventually reached the point where
MFC42.DLL's API was stable, but MFC42d.dll (the debug version) wasn't,
so if you had a broken app that depended on the debug version, an
upgrade would, again, break the app.

Suffice it to say, Win32 DOES NOT provide a decent versioning system.

Neither, for that matter, does Java.  You either need to modify
CLASSPATH to get the right version, or rely on the end-user to install
jar files into the right place, and if they install stuff into the boot
classpath that has a different API...  Oops, you're dead.  Thank you for
playing.

Of the formats you listed, only ELF supports proper versioning, which is
why you can have *parallel* installs of libc.so.6, libc.so.5, etc., and
you can have different major versions of the "same" library installed
and things Just Work.  You can even have several different major+minor
versions installed, and through judicious use of symbolic links the most
recent version -- within a major release -- will be used when an
application loads.

The only problem with ELF approach is that it requires a unique base
name, and thus doesn't handle file name conflicts at all.

.NET requires a base name, version, and public key token.  The public
key token allows multiple different companies to ship assemblies with
the same base name and allow things to Just Work.

Be nice to your users, and don't use partial assembly names.  It's for
your own good and their happiness.

> The user doesn't care for all this, he/she wants to
> open the library that is installed on the system.

And this is where you need to firmly define who your user is.

The end user doesn't care about libraries, they care about
*applications*.  If the app breaks, they're not happy.

Developers can put up with a little grief to ensure that the end users
are happy.  This means LEARNING ABOUT PROPER VERSIONING AND DOING THE
RIGHT THING.

So which user are you talking about?  The end-user?  Or the developer?

 - Jon