Re: Symlinks from Tools to Applications

[Christopher Armstrong]

Hi

Looks like a flurry of activity on the list overnight...

DLL Hell (the commonly used name for this versioning nightmare) has been 
approached by several solutions over the years, none of which quite 
solve the problem. I think Microsoft's current solution is to use 
manifest files, which are a description of the DLL and a version number. 
Applications have a manifest file as well, specifying the versions they 
are linked against. Windows then maintains multiple copies of a DLL 
based on this information, although this feature is only available on 
Windows XP upwards (not Win2K).
COM never had interface versioning, instead relying on interfaces with 
different names e.g. ITypeLibInfo, ITypeLibInfo2, ITypeLibInfo3 to allow 
adding features to a interface (which gives me yet another idea).

And from what I can recall, the DLL Hell issue traditionally relates to 
putting DLLs in the users %WINDOWS%\SYSTEM32 directory, which is now no 
longer recommended by Microsoft, and I strongly advise against us doing so.

There is also the issues of bundles linking against different versions 
of gnustep-base/gnustep-gui as compared to the application they are 
running in...if these DLLs have different "INTERFACE_VERSION"s as you 
specified earlier, both versioned DLLs get loaded into the application 
and muck up the runtime. I used to have this problem before we switched 
to the gnustep-base.dll/gnustep-gui.dll naming. If we are to use 
INTERFACE_VERSION, we need to make sure that these change no more than 
necessary i.e. once we get to version 1.0, we maintain these interfaces 
as a separate version of GNUstep, whilst developing under a 1.2 or 1.1 
or whatever.

Ideally, interfaces only change in development versions of libraries, in 
which case we instruct users to recompile *everything* every time they 
check out from SVN, and stable release versions maintain their 
interfaces across the entire major version number. From what I can see, 
this is current GNUstep policy, so that using INTERFACE_VERSION is not a 
problem.

Which leads me to my other idea...COM registers every class/interface in 
the registry with a pointer to the location of the DLL. If we were to 
modify the runtime, would it be possible for it to locate classes at 
runtime by looking them up in the registry, instead of explicitly 
linking against its DLL? Or is this just fanciful thinking?

Regards
Chris

Nicola Pero wrote:
> > The idea of having the gnustep runtime distributions in their own  
> > subdirectories avoids all this conflict ...
> >     
>
> Btw, I'm not necessarily opposed to this ...
>
> ... I just want the stuff to have decent versioning built-in. :-)
>
> No matter what we solution we choose, decent versioning built-in will make
> things easier, particularly on Windows where -- according to reports
> on the web -- non-existing DLL versioning is constantly causing horrible 
> problems to end-users. ;-)
>