Shared libraries/DLLs

[Unknown W. Brackets]

I'm not wanting to have to do that from the DLL.

Here's a practical example:

void plugin_function ()
{
	if (ask_host_for_something() != 42)
		tell_host_about_error("Oh no!");
}

I suppose you're suggesting I could either use GetModuleHandle(NULL) by 
passing it to the plugin, or from within the plugin (unclear but at 
least it makes this doable, though annoying.)  However, even then, .so 
files are simpler - it sets up the symbols for me.  I don't have to 
GetProcAddress any of them.

-[Unknown]


Neal Alexander wrote:
> Jarrett Billingsley wrote:
>> "Unknown W. Brackets" <unknown at simplemachines.org> wrote in message 
>> news:fo0p7c$1tbq$1 at digitalmars.com...
>>> Okay.
>>>
>>> Example "plugin" example.d:
>>>
>>> ---
>>> module example;
>>>
>>> extern (C)
>>> export int foo();
>>
>> Ohhh, _there_ it is; I think this bit got cut out of the original post :)
>>
>>> I don't have the Linux loader in front of me but it's almost exactly 
>>> the same and works just fine (LoadLibraryA => dlopen, GetProcAddress 
>>> => dlsym, FreeLibrary => dlclose, with some dlerror logic in there.)  
>>> But as stated, it appears that there's really no "reverse linking" of 
>>> DLLs.
>>
>> As in having DLLs link to symbols exported from the app?  Right, it's 
>> not possible without some hackery.  I'm not sure how to do it but 
>> apparently it can be done.  I think there are restrictions on it, though.
>>
>> DLLs really *are* an awful approximation of SOs :(
>>
> 
> Ive never had problems resolving an .exe's exported symbols at runtime. 
> Dunno why it would be an issue doing it from inside a DLL.
> 
> x = GetModuleHandle(NULL); // handle to image that created the process
> GetProcAddress(x, "foo_"); // or "foo" depending how the compiler 
> generates C symbols