State of windows DLL support

Vladimir Panteleev via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Sun Apr 3 06:59:29 PDT 2016


On Sunday, 3 April 2016 at 13:50:20 UTC, rikki cattermole wrote:
> On 04/04/2016 12:55 AM, Nicholas Wilson wrote:
>> On Sunday, 3 April 2016 at 12:20:33 UTC, rikki cattermole 
>> wrote:
>>> I'm just guessing context here.
>>
>> Oh. Needed functionality is in DLL. Need it in LV. Can't / 
>> don't know
>> how to in LV. setting up a server for that functionality in D 
>> ( I/O to
>> some power inverters DAQ ). set up a pipe /local host server 
>> to transfer
>> data to LV.
>
> Okay now I'm more awake, lets see what we can do.
>
> The problem you're hitting is there is no real load/unload 
> hooks by the looks of things.
>
> Okay assuming DllMain is in fact being called correctly, you 
> can initialize and unload D's runtime.
> So you can build reloadable platform fairly easily there.
>
> http://www.ni.com/white-paper/3056/en/
>
> You'll need to test that you can in fact fully load/unload D's 
> runtime more than once.
> Unfortunately I don't think you can modify LabVIEW from D side.
>
> I've done a bit of reading on how to make it so GetProcAddress 
> returns whatever you want (runtime adding of symbols).
> Simply put, do-able!
>
> Example code: 
> http://www.codeproject.com/script/Articles/ViewDownloads.aspx?aid=116253

I must be missing some context because I have no idea how this 
post (especially the last link) is an answer to the OP's question.

Nicholas, the answer to your original question (how well DLLs 
work with D) depends on the exact situation, namely:

1. If the .exe is non-D and you want to write a D DLL, you should 
not encounter any problems. I assume you will use a C API to 
communicate. The D DLL will have its own self-contained D runtime 
and manage its own memory. The only main thing you have to be 
careful of is when passing the only reference to a GC-allocated 
block of memory to the main program: the D GC can't know whether 
the main program still holds a reference to it, and may free it 
under the main program's nose. The API should specify the exact 
lifetime of objects passed indirectly; if in doubt, copy them to 
unmanaged (core.stdc.stdlib.malloc'd) memory.

2. If the main program is in D and you want to use a C DLL, then 
it is no different to how D already uses the Windows API runtime 
or any other C library. You will need to find, create or convert 
an import library in order to link against the C DLL. The same 
warning about memory and lifetime as above applies.

3. If you want to write D DLLs to use in D programs, you have two 
situations, depending on whether you want the D runtime to be 
shared. You could restrict the program to a C API with 
well-specified lifetimes, taking care of the same issues as 
above. It might also be possible to share the D runtime between 
the D EXE and DLL, so that there is one GC which knows when 
objects are reachable by either the EXE or DLLs, but I don't know 
what's the current state of that on Windows.


More information about the Digitalmars-d-learn mailing list