Hi,
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).
Best,
Sascha
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
