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
_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
