Are we able to create DLLs easily enough in D now? Do we still need to tell our D DLLs to share their GCs with the calling EXE? And is the wiki page fully up to date on the matter? If not where can we find the up to date information? Or should we be using core.runtime.Runtime.loadLibrary()?

Sorry for the barrage of questions, I hope you guys are able to answer some of them. Many thanks in advance

On Saturday, 26 July 2014 at 07:53:54 UTC, Matt wrote:
> Are we able to create DLLs easily enough in D now? Do we still need to tell our D DLLs to share their GCs with the calling EXE? And is the wiki page fully up to date on the matter? If not where can we find the up to date information? Or should we be using core.runtime.Runtime.loadLibrary()?

I think so, though the page is still 32-bit/Optlink centric.
http://wiki.dlang.org/Win32_DLLs_in_D

Just created a Win64 dll the other day:
https://github.com/Trass3r/hooksample

But haven't investigated GC/runtime sharing.

Am 26.07.2014 09:53, schrieb Matt:
> Are we able to create DLLs easily enough in D now? Do we still need to
> tell our D DLLs to share their GCs with the calling EXE? And is the wiki
> page fully up to date on the matter? If not where can we find the up to
> date information? Or should we be using core.runtime.Runtime.loadLibrary()?
>
> Sorry for the barrage of questions, I hope you guys are able to answer
> some of them. Many thanks in advance

Dll support on windows is still limited to global functions only. If you try anything else it will break.  E.g. exporting classes. I don't recommend using DLLs in their current state unless you are ok with having a C interface for your DLL. See http://wiki.dlang.org/DIP45 for what has to be done to make DLLs actually usable on windows.