celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sascha Zelzer <s.zel...@dkfz-heidelberg.de>
Subject Re: framework use some unix's function, not apr
Date Mon, 26 Nov 2012 08:20:49 GMT

As I understood it, your referenced link is about sharing module handles 
between different processes.

I am not a Windows DLL expert but I think the following is true (maybe 
there are some tricks on the Windows platform, but they would definitely 
be non-standard):

Vaguely speaking, the Windows linker resolves symbols at link-time, 
contrary to the default behaviour of the ELF linker, resolving symbols 
lazily at runtime. Therefore, the concept of a symbol search path makes 
not much sense on Windows (except for the search path defined by the 
link-time dependencies). Consequently, dynamically loaded libraries on 
Windows do not affect symbol resolution of subsequently loaded libraries 
so their symbols are never "global". RTLD_GLOBAL on POSIX systems adds 
the symbols of the loaded library to the global search path, hence they 
can be used by the dynamic linker to resolve symbols of subsequently 
loaded libraries. There is no such "global symbol search path" on 
Windows (AFAIK).


On 11/26/2012 08:50 AM, Alexander Broekhuis wrote:
> Simple answer: I don't know.
> Little more detail: On [1] something is mentioned about loading not being
> global, though the text doesn't mention wether symbols get added to the
> running process or not.. So this is something that needs testing.
> As far as I can tell, if windows doesn't support local loading Celix
> probably still works, but having multiple bundles providing the same
> methods doesn't (for example multiple versions of the same service).
> "Module handles are not global or inheritable. A call to *LoadLibrary* by
> one process does not produce a handle that another process can use — for
> example, in calling
> *GetProcAddress*<http://msdn.microsoft.com/en-us/library/windows/desktop/ms683212(v=vs.85).aspx>.
> The other process must make its own call to *LoadLibrary* for the module
> before calling *GetProcAddress*."
> [1]:
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).aspx

View raw message