[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Symlinks from Tools to Applications

From: Christopher Armstrong
Subject: Re: Symlinks from Tools to Applications
Date: Sat, 10 Mar 2007 12:07:03 +1100
User-agent: Thunderbird (Windows/20070221)


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]