Is it possible to load in a dynamic library in D, and have the library you just loaded call your own functions? Imagine having a plugin loader and the plugins call methods like 'addButton()' from the host application.

Am 05.02.2014 14:21, schrieb Jeroen Bollen:
> Is it possible to load in a dynamic library in D, and have the library
> you just loaded call your own functions? Imagine having a plugin loader
> and the plugins call methods like 'addButton()' from the host application.

Yes, thats what core.runtime.loadLibrary is for.
http://dlang.org/phobos/core_runtime.html#.Runtime.loadLibrary

You can also always fall back to operating system functions like, LoadLibrary and GetProcAddress for windows.

Kind Regards
Benjamin Thaut

On Wednesday, 5 February 2014 at 13:52:10 UTC, Benjamin Thaut wrote:
> Am 05.02.2014 14:21, schrieb Jeroen Bollen:
>> Is it possible to load in a dynamic library in D, and have the library
>> you just loaded call your own functions? Imagine having a plugin loader
>> and the plugins call methods like 'addButton()' from the host application.
>
> Yes, thats what core.runtime.loadLibrary is for.
> http://dlang.org/phobos/core_runtime.html#.Runtime.loadLibrary
>
> You can also always fall back to operating system functions like, LoadLibrary and GetProcAddress for windows.
>
> Kind Regards
> Benjamin Thaut

How exactly does that work 2 ways? Can I just define the functions and not implement them in the library?

Am 05.02.2014 16:36, schrieb Jeroen Bollen:
> On Wednesday, 5 February 2014 at 13:52:10 UTC, Benjamin Thaut wrote:
>> Am 05.02.2014 14:21, schrieb Jeroen Bollen:
>>> Is it possible to load in a dynamic library in D, and have the library
>>> you just loaded call your own functions? Imagine having a plugin loader
>>> and the plugins call methods like 'addButton()' from the host
>>> application.
>>
>> Yes, thats what core.runtime.loadLibrary is for.
>> http://dlang.org/phobos/core_runtime.html#.Runtime.loadLibrary
>>
>> You can also always fall back to operating system functions like,
>> LoadLibrary and GetProcAddress for windows.
>>
>> Kind Regards
>> Benjamin Thaut
>
> How exactly does that work 2 ways? Can I just define the functions and
> not implement them in the library?

You don't define functions, just function pointers. You could also do it oop style:

// The loader
import core.sys.windows.windows;

interface IPlugin
{
  void pluginMethod1();
  void pluginMethod2();
}

// function pointer definition for the entry function
extern(C) alias IPlugin function() pluginEntry;

IPlugin loadPlugin(const(char)[] path)
{
  auto handle = cast(HMODULE)runtime.loadLibrary(path);
  //use dlsym on linux
  auto entry = cast(pluginEntry)GetProcAddress(handle, "pluginEntry".ptr);
  return entry(); // get the plugin interface
}


// The plugin
interface IPlugin
{
  void pluginMethod1();
  void pluginMethod2();
}

class PluginImpl : IPlugin
{
  override void pluginMethod1() { ... }
  override void pluginMethod2() { ... }
}

export extern(C) IPlugin pluginEntry()
{
  return new PluginImpl();
}

This however will have issues on windows, because the runtime is not shared. On Linux it should work just fine if you remember to link against the shared runtime.

You might also want to watch this talk from D-conf 2013:
http://dconf.org/2013/talks/nowak.html

Kind Regards
Benjamin Thaut

On Wednesday, 5 February 2014 at 16:27:10 UTC, Benjamin Thaut wrote:
> Am 05.02.2014 16:36, schrieb Jeroen Bollen:
>> On Wednesday, 5 February 2014 at 13:52:10 UTC, Benjamin Thaut wrote:
>>> Am 05.02.2014 14:21, schrieb Jeroen Bollen:
>>>> Is it possible to load in a dynamic library in D, and have the library
>>>> you just loaded call your own functions? Imagine having a plugin loader
>>>> and the plugins call methods like 'addButton()' from the host
>>>> application.
>>>
>>> Yes, thats what core.runtime.loadLibrary is for.
>>> http://dlang.org/phobos/core_runtime.html#.Runtime.loadLibrary
>>>
>>> You can also always fall back to operating system functions like,
>>> LoadLibrary and GetProcAddress for windows.
>>>
>>> Kind Regards
>>> Benjamin Thaut
>>
>> How exactly does that work 2 ways? Can I just define the functions and
>> not implement them in the library?
>
> You don't define functions, just function pointers. You could also do it oop style:
>
> // The loader
> import core.sys.windows.windows;
>
> interface IPlugin
> {
>   void pluginMethod1();
>   void pluginMethod2();
> }
>
> // function pointer definition for the entry function
> extern(C) alias IPlugin function() pluginEntry;
>
> IPlugin loadPlugin(const(char)[] path)
> {
>   auto handle = cast(HMODULE)runtime.loadLibrary(path);
>   //use dlsym on linux
>   auto entry = cast(pluginEntry)GetProcAddress(handle, "pluginEntry".ptr);
>   return entry(); // get the plugin interface
> }
>
>
> // The plugin
> interface IPlugin
> {
>   void pluginMethod1();
>   void pluginMethod2();
> }
>
> class PluginImpl : IPlugin
> {
>   override void pluginMethod1() { ... }
>   override void pluginMethod2() { ... }
> }
>
> export extern(C) IPlugin pluginEntry()
> {
>   return new PluginImpl();
> }
>
> This however will have issues on windows, because the runtime is not shared. On Linux it should work just fine if you remember to link against the shared runtime.
>
> You might also want to watch this talk from D-conf 2013:
> http://dconf.org/2013/talks/nowak.html
>
> Kind Regards
> Benjamin Thaut

I think Jeroen is asking for the opposite of this as library will call host's functions.

Am 05.02.2014 18:09, schrieb tcak:
>
> I think Jeroen is asking for the opposite of this as library will call
> host's functions.

Well for that you can just pass function pointers / interfaces into the library from the host.

Kind Regards
Benjamin Thaut

On Wednesday, 5 February 2014 at 16:27:10 UTC, Benjamin Thaut wrote:
> Am 05.02.2014 16:36, schrieb Jeroen Bollen:
>> On Wednesday, 5 February 2014 at 13:52:10 UTC, Benjamin Thaut wrote:
>>> Am 05.02.2014 14:21, schrieb Jeroen Bollen:
>>>> Is it possible to load in a dynamic library in D, and have the library
>>>> you just loaded call your own functions? Imagine having a plugin loader
>>>> and the plugins call methods like 'addButton()' from the host
>>>> application.
>>>
>>> Yes, thats what core.runtime.loadLibrary is for.
>>> http://dlang.org/phobos/core_runtime.html#.Runtime.loadLibrary
>>>
>>> You can also always fall back to operating system functions like,
>>> LoadLibrary and GetProcAddress for windows.
>>>
>>> Kind Regards
>>> Benjamin Thaut
>>
>> How exactly does that work 2 ways? Can I just define the functions and
>> not implement them in the library?
>
> You don't define functions, just function pointers. You could also do it oop style:
>
> // The loader
> import core.sys.windows.windows;
>
> interface IPlugin
> {
>   void pluginMethod1();
>   void pluginMethod2();
> }
>
> // function pointer definition for the entry function
> extern(C) alias IPlugin function() pluginEntry;
>
> IPlugin loadPlugin(const(char)[] path)
> {
>   auto handle = cast(HMODULE)runtime.loadLibrary(path);
>   //use dlsym on linux
>   auto entry = cast(pluginEntry)GetProcAddress(handle, "pluginEntry".ptr);
>   return entry(); // get the plugin interface
> }
>
>
> // The plugin
> interface IPlugin
> {
>   void pluginMethod1();
>   void pluginMethod2();
> }
>
> class PluginImpl : IPlugin
> {
>   override void pluginMethod1() { ... }
>   override void pluginMethod2() { ... }
> }
>
> export extern(C) IPlugin pluginEntry()
> {
>   return new PluginImpl();
> }
>
> This however will have issues on windows, because the runtime is not shared. On Linux it should work just fine if you remember to link against the shared runtime.
>
> You might also want to watch this talk from D-conf 2013:
> http://dconf.org/2013/talks/nowak.html
>
> Kind Regards
> Benjamin Thaut

That example seems to only let the loader call the plugin, and not the other way around.

Am 05.02.2014 18:33, schrieb Jeroen Bollen:
> On Wednesday, 5 February 2014 at 16:27:10 UTC, Benjamin Thaut wrote:
>> Am 05.02.2014 16:36, schrieb Jeroen Bollen:
>>> On Wednesday, 5 February 2014 at 13:52:10 UTC, Benjamin Thaut wrote:
>>>> Am 05.02.2014 14:21, schrieb Jeroen Bollen:
>>>>> Is it possible to load in a dynamic library in D, and have the library
>>>>> you just loaded call your own functions? Imagine having a plugin
>>>>> loader
>>>>> and the plugins call methods like 'addButton()' from the host
>>>>> application.
>>>>
>>>> Yes, thats what core.runtime.loadLibrary is for.
>>>> http://dlang.org/phobos/core_runtime.html#.Runtime.loadLibrary
>>>>
>>>> You can also always fall back to operating system functions like,
>>>> LoadLibrary and GetProcAddress for windows.
>>>>
>>>> Kind Regards
>>>> Benjamin Thaut
>>>
>>> How exactly does that work 2 ways? Can I just define the functions and
>>> not implement them in the library?
>>
>> You don't define functions, just function pointers. You could also do
>> it oop style:
>>
>> // The loader
>> import core.sys.windows.windows;
>>
>> interface IPlugin
>> {
>>   void pluginMethod1();
>>   void pluginMethod2();
>> }
>>
>> // function pointer definition for the entry function
>> extern(C) alias IPlugin function() pluginEntry;
>>
>> IPlugin loadPlugin(const(char)[] path)
>> {
>>   auto handle = cast(HMODULE)runtime.loadLibrary(path);
>>   //use dlsym on linux
>>   auto entry = cast(pluginEntry)GetProcAddress(handle,
>> "pluginEntry".ptr);
>>   return entry(); // get the plugin interface
>> }
>>
>>
>> // The plugin
>> interface IPlugin
>> {
>>   void pluginMethod1();
>>   void pluginMethod2();
>> }
>>
>> class PluginImpl : IPlugin
>> {
>>   override void pluginMethod1() { ... }
>>   override void pluginMethod2() { ... }
>> }
>>
>> export extern(C) IPlugin pluginEntry()
>> {
>>   return new PluginImpl();
>> }
>>
>> This however will have issues on windows, because the runtime is not
>> shared. On Linux it should work just fine if you remember to link
>> against the shared runtime.
>>
>> You might also want to watch this talk from D-conf 2013:
>> http://dconf.org/2013/talks/nowak.html
>>
>> Kind Regards
>> Benjamin Thaut
>
> That example seems to only let the loader call the plugin, and not the
> other way around.

Well as I already said, for the other way around just pass function-pointers / interfaces to the plugin as soon as you established the one-way connection.

On Wednesday, 5 February 2014 at 17:39:34 UTC, Benjamin Thaut wrote:
> Am 05.02.2014 18:33, schrieb Jeroen Bollen:
>> On Wednesday, 5 February 2014 at 16:27:10 UTC, Benjamin Thaut wrote:
>>> Am 05.02.2014 16:36, schrieb Jeroen Bollen:
>>>> On Wednesday, 5 February 2014 at 13:52:10 UTC, Benjamin Thaut wrote:
>>>>> Am 05.02.2014 14:21, schrieb Jeroen Bollen:
>>>>>> Is it possible to load in a dynamic library in D, and have the library
>>>>>> you just loaded call your own functions? Imagine having a plugin
>>>>>> loader
>>>>>> and the plugins call methods like 'addButton()' from the host
>>>>>> application.
>>>>>
>>>>> Yes, thats what core.runtime.loadLibrary is for.
>>>>> http://dlang.org/phobos/core_runtime.html#.Runtime.loadLibrary
>>>>>
>>>>> You can also always fall back to operating system functions like,
>>>>> LoadLibrary and GetProcAddress for windows.
>>>>>
>>>>> Kind Regards
>>>>> Benjamin Thaut
>>>>
>>>> How exactly does that work 2 ways? Can I just define the functions and
>>>> not implement them in the library?
>>>
>>> You don't define functions, just function pointers. You could also do
>>> it oop style:
>>>
>>> // The loader
>>> import core.sys.windows.windows;
>>>
>>> interface IPlugin
>>> {
>>>  void pluginMethod1();
>>>  void pluginMethod2();
>>> }
>>>
>>> // function pointer definition for the entry function
>>> extern(C) alias IPlugin function() pluginEntry;
>>>
>>> IPlugin loadPlugin(const(char)[] path)
>>> {
>>>  auto handle = cast(HMODULE)runtime.loadLibrary(path);
>>>  //use dlsym on linux
>>>  auto entry = cast(pluginEntry)GetProcAddress(handle,
>>> "pluginEntry".ptr);
>>>  return entry(); // get the plugin interface
>>> }
>>>
>>>
>>> // The plugin
>>> interface IPlugin
>>> {
>>>  void pluginMethod1();
>>>  void pluginMethod2();
>>> }
>>>
>>> class PluginImpl : IPlugin
>>> {
>>>  override void pluginMethod1() { ... }
>>>  override void pluginMethod2() { ... }
>>> }
>>>
>>> export extern(C) IPlugin pluginEntry()
>>> {
>>>  return new PluginImpl();
>>> }
>>>
>>> This however will have issues on windows, because the runtime is not
>>> shared. On Linux it should work just fine if you remember to link
>>> against the shared runtime.
>>>
>>> You might also want to watch this talk from D-conf 2013:
>>> http://dconf.org/2013/talks/nowak.html
>>>
>>> Kind Regards
>>> Benjamin Thaut
>>
>> That example seems to only let the loader call the plugin, and not the
>> other way around.
>
> Well as I already said, for the other way around just pass function-pointers / interfaces to the plugin as soon as you established the one-way connection.

Ah so like an initialize function taking a set of arguments representing functions and classes?

How exactly would that work for classes?