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