www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is there a way to do 2-way linking?

reply "Jeroen Bollen" <jbinero gmail.com> writes:
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.
Feb 05 2014
next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
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
Feb 05 2014
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
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
Feb 05 2014
next sibling parent Benjamin Thaut <code benjamin-thaut.de> writes:
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
Feb 05 2014
prev sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
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.
Feb 05 2014
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 05.02.2014 18:41, schrieb Jeroen Bollen:
 How exactly would that work for classes?

Once again, make an interface for all methods you want to be available. interface IExposed { void method1(); void method2(); } then pass that interface to the plugin. Because all interface methods are virtual function calls, the plugin does not have to know the location of these methods at link time.
Feb 05 2014
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 05.02.2014 18:51, schrieb Benjamin Thaut:
 Am 05.02.2014 18:41, schrieb Jeroen Bollen:
 How exactly would that work for classes?

Once again, make an interface for all methods you want to be available. interface IExposed { void method1(); void method2(); } then pass that interface to the plugin. Because all interface methods are virtual function calls, the plugin does not have to know the location of these methods at link time.

If you need real world code: https://github.com/Ingrater/Spacecraft/blob/physics/game/sources/physics/dllmain.d The "InitPlugin" function establishes the two way communication. You can find the loader here: https://github.com/Ingrater/thBase/blob/master/src/thBase/plugin.d#L265 Kind Regards Benjamin Thaut
Feb 05 2014
parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 05.02.2014 19:11, schrieb Jeroen Bollen:
 On Wednesday, 5 February 2014 at 17:59:38 UTC, Benjamin Thaut wrote:
 Am 05.02.2014 18:51, schrieb Benjamin Thaut:
 Am 05.02.2014 18:41, schrieb Jeroen Bollen:
 How exactly would that work for classes?

Once again, make an interface for all methods you want to be available. interface IExposed { void method1(); void method2(); } then pass that interface to the plugin. Because all interface methods are virtual function calls, the plugin does not have to know the location of these methods at link time.

If you need real world code: https://github.com/Ingrater/Spacecraft/blob/physics/game/sources/physics/dllmain.d The "InitPlugin" function establishes the two way communication. You can find the loader here: https://github.com/Ingrater/thBase/blob/master/src/thBase/plugin.d#L265 Kind Regards Benjamin Thaut

But what if I want to define a class loader side and implement it library side? I guess I'll have to write 'getInstance' methods?

You always have to put the class defintion and implementation into the same executable / library. You can however define a interface and query the actual implementation from the library. So basically it would come down to a getInstance method or factory method.
Feb 05 2014
prev sibling next sibling parent "Jeroen Bollen" <jbinero gmail.com> writes:
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?
Feb 05 2014
prev sibling next sibling parent "tcak" <tcak pcak.com> writes:
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.
Feb 05 2014
prev sibling next sibling parent "Jeroen Bollen" <jbinero gmail.com> writes:
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.
Feb 05 2014
prev sibling next sibling parent "Jeroen Bollen" <jbinero gmail.com> writes:
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?
Feb 05 2014
prev sibling next sibling parent "Jeroen Bollen" <jbinero gmail.com> writes:
How exactly would that work for classes?
Feb 05 2014
prev sibling parent "Jeroen Bollen" <jbinero gmail.com> writes:
On Wednesday, 5 February 2014 at 17:59:38 UTC, Benjamin Thaut 
wrote:
 Am 05.02.2014 18:51, schrieb Benjamin Thaut:
 Am 05.02.2014 18:41, schrieb Jeroen Bollen:
 How exactly would that work for classes?

Once again, make an interface for all methods you want to be available. interface IExposed { void method1(); void method2(); } then pass that interface to the plugin. Because all interface methods are virtual function calls, the plugin does not have to know the location of these methods at link time.

If you need real world code: https://github.com/Ingrater/Spacecraft/blob/physics/game/sources/physics/dllmain.d The "InitPlugin" function establishes the two way communication. You can find the loader here: https://github.com/Ingrater/thBase/blob/master/src/thBase/plugin.d#L265 Kind Regards Benjamin Thaut

But what if I want to define a class loader side and implement it library side? I guess I'll have to write 'getInstance' methods?
Feb 05 2014