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

Jeroen Bollen (4/4) Feb 05 2014 Is it possible to load in a dynamic library in D, and have the

Benjamin Thaut (7/10) Feb 05 2014 Yes, thats what core.runtime.loadLibrary is for.

Jeroen Bollen (4/17) Feb 05 2014 How exactly does that work 2 ways? Can I just define the

Benjamin Thaut (41/58) Feb 05 2014 You don't define functions, just function pointers. You could also do it...

tcak (4/69) Feb 05 2014 I think Jeroen is asking for the opposite of this as library will

Benjamin Thaut (5/7) Feb 05 2014 Well for that you can just pass function pointers / interfaces into the

Jeroen Bollen (4/69) Feb 05 2014 That example seems to only let the loader call the plugin, and

Benjamin Thaut (4/80) Feb 05 2014 Well as I already said, for the other way around just pass

Jeroen Bollen (4/96) Feb 05 2014 Ah so like an initialize function taking a set of arguments

Jeroen Bollen (1/1) Feb 05 2014 How exactly would that work for classes?

Benjamin Thaut (10/11) Feb 05 2014 Once again, make an interface for all methods you want to be available.

Benjamin Thaut (8/19) Feb 05 2014 If you need real world code:

Jeroen Bollen (4/29) Feb 05 2014 But what if I want to define a class loader side and implement it

Benjamin Thaut (5/34) Feb 05 2014 You always have to put the class defintion and implementation into the

"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

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.


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

Kind Regards
Benjamin Thaut

Feb 05 2014

"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.


 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

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.


 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

"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.


 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

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

"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.


 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

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.


 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

"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.


 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

"Jeroen Bollen" <jbinero gmail.com> writes:

How exactly would that work for classes?

Feb 05 2014

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

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

"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

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

D Programming

C/C++ Programming

Other

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