Re: Symlinks from Tools to Applications

[Christopher Armstrong]

Hi

Nicola Pero wrote:
> > 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...
> >     
>
> Very good point ... I hadn't thought of that. :-(
>
> On other platforms this is not so much of an issue just because bundles 
> don't need to be explicitly linked to all libraries ... but on Windows they do :-/
>
> Is there a way to avoid linking bundles to all libraries on Windows ?
>   
Not that I'm aware of. It doesn't actually link it to a particular 
library, just the file name. From past experience, you can usually just 
drop in another DLL with the same name. As long as all the exports are 
the same, this never is really much of a problem (obviously interface 
breakage is possible, but we wouldn't allow this).
> Else, there is some more thinking to do here to make for a smoother user
> experience. :-/
>   
Perhaps we should emphasize the usage of frameworks in these scenarios, 
instead of using libraries. They have versioning built into their 
design, so we really should take advantage of them, even if they don't 
map properly to a GNUstep environment. We really should modify the 
openapp/opentool script so that it puts the paths to a framework version 
into the "PATH" variable on windows and "LD_LIBRARY_PATH" on unix on 
startup (has this already been done?) Then, as Richard has suggested, 
use the AppPath registry setting to the directories we need (in this 
case, the framework directories). In all cases, the name of the .dll 
file stays the same whilst the dll itself changes every time the 
programme is run.

Otherwise, your idea of using the INTERFACE_VERSION stuff is probably 
more appropriate, as we should just "hope" that a bundle or library uses 
the same version as the application thats linking against it. Perhaps 
better protection against this can be put into the Objective-C runtime? 
This appears to be where most of the problem starts.

There is also a technique on Windows known as "Delayed-DLL Loading", 
where the dll is loaded until the first time one of its symbols is 
referenced in the programme. Code is emitted by the compiler that causes 
LoadLibrary/GetProcAddress to be called upon this happening. Maybe we 
should consider bugging the mingw people into writing something like 
this, or developing it ourselves.
> > 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?
> >     
>
> It's an interesting idea ;-)
>
> I'm not sure it would really work because most libraries/bundles/etc contain
> a lot of C code as well as ObjC classes.  So even if we managed to hack the
> runtime to look up classes in the registry, C stuff would still need to be
> loaded via DLLs, and versioning problems wouldn't go away :-
Good point...perhaps we could use a thunking technique for these? 
Something like a code stub that tries to find the address of the 
function at runtime and does a jmp to its address? Not pretty, but again 
another potential (part) of the solution.

Regards
Chris