Using shared libraries for external scripts, looking for advice (windows)

[Guillaume Piolat via Digitalmars-d-learn]

On Monday, 15 August 2016 at 08:45:07 UTC, Tofu Ninja wrote:
> So this is kind of an open ended question, just looking for 
> advice on doing it in general, if it's possible, and doing it 
> specifically in D on windows. I am not super familiar with how 
> shared libraries work so I had some questions.
>
> I would like to attempt to use D to write scripts for a game 
> engine I am working on. The goal is to have the ability to 
> externalize the code that is specific to an individual game or 
> level instead of just compiling it all into the engine it self. 
> I want to be able to treat them as resources similar to other 
> asset files such as images or models. A secondary goal is to be 
> able to reload them at runtime for iteration.


There is another way, you can use a scripting language and "plug" 
things you want to use there.

For example with scheme-d: 
https://github.com/p0nce/scheme-d/blob/master/examples/repl/repl.d (however: don't use schemed, it's crap)

> So with that in mind, my general plan was to compile them into 
> dll's and load them at runtime. My understanding is that to 
> make it work, each dll will need to have an entry point that 
> registers its data with the rest of the engine but I am unclear 
> of some of the details or even if it is possible.

You can export any function you want with the signature you want. 
But usually a C FFI is used with only pointers and plain structs.

Each DLL will have its own D runtime and GC.

You can use the recommended snippets for DllMain: 
https://wiki.dlang.org/Win32_DLLs_in_D

> I am unsure of how to give the library access to the rest of 
> the engine. For instance, I have some global data in the 
> engine. How do I go about making sure the dlls have access to 
> that data, is there a way to make sure the dll will share the 
> memory space as the rest of the program,

The DLL will always share the memory space of the rest of the 
host program.


> or will I need to explicitly pass that data into the dll to 
> give it access.

Yes because it's bad manner anyway for the DLL to access data in 
any way other than through exported functions.


> Also I am unsure of how to go about keeping the engine code out 
> of the dll. I would like to keep the dll as small as possible. 
> If the dll accesses anything from the engine, how do I keep the 
> engine code out of the dll?

If it's all D, you can perhaps pass interfaces around.


> Idealy I would also like to keep phobos out of the dll as well. 
> If the dlls get too big then it will probably not be useable.

Then you can make a runtime-less DLL, remove the stuff in 
DllMain, but this won't be fun everyday.