Re: Symlinks from Tools to Applications

[Richard Frith-Macdonald]

On 9 Mar 2007, at 07:40, Christopher Armstrong wrote:

> > The process of location of the shared runtime installation could be a
> > little more complex ... we might have multiple copies of the shared
> > runtime installed.  But a registry key can have multiple values set,
> > so the application installers could check for that, and if multiple
> > copies of the runtime are installed, offer the user a choice of which
> > runtime to use.  This could also support versioning ... we could have
> > different runtime versions installed and application installers could
> > associate the applications with the appropriate version.
>
> Most developers would want to make these decisions themselves  
> instead of
> leaving it to users. In that case, it should be possible for  
> application
> developers to force a particular major version number for
> libraries/frameworks for use with their application.

I think you misunderstand me ...
When an application is built/packaged, it *must* of course be done  
against a particular version of the libraries ... so it *requires*  
that version of the libraries in order to run.
Therefore, when the application installer installs the application,  
it *must* make that application use the version of the runtime that  
the application was built for ... this is not a case of the developer  
or the user making a decision (except in as much as the developer  
made the app package using a particular version of gnustep, and the  
user downloaded a particular version of the app package).
I was only suggesting that a user could choose the runtime where  
multiple copies of the same version are installed (assuming we permit  
that).


> > The biggest problem is what happens to apps if the runtime is deleted
> > or moved (a clean uninstall should not be a problem as we could have
> > the uninstaller check for apps using the runtime and warn and give
> > the user a choice of actions).  The best we could do in this case
> > would seem to be to use the approach you outline of having an
> > executable check for the existence of the runtime before loading the
> > main app, and display a useful error message if it is not found
> > (possibly even search the disk to see if it can find where the
> > runtime has been moved to).  Perhaps that's just too complex to be
> > worth bothering with though.
>
> The reason I proposed this was to overcome the limitation of  
> needing an
> application's dll's to be in the search path when the application is
> loaded.

Yes ... but the standard windows mechanism for doing this is to use  
the registry ... (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows 
\CurrentVersion\App Paths) which solves the problem of automatically  
locating the dlls efficiently and simply.  Using a non-standard  
mechanism has its own advantages (assuming someone writes all the  
code to do good things like search for and if not found, nicely alert  
the user that the runtime has been removed).  I'd try the simple,  
standard mechanism before resorting to writing a more complex  
mechanism from scratch.