State of windows DLL support

rikki cattermole via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Sun Apr 3 07:19:17 PDT 2016


On 04/04/2016 1:59 AM, Vladimir Panteleev wrote:
> 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.

The link is there as a backup plan. I made the assumption that it may 
not be possible to have more than one D shared lib loaded during the 
lifetime.
The idea is simple. Have a D shared lib that acts as a dynamic dispatch 
to the appropriate child process who will route the call to the function 
in question.
The hooking into GetProcAddress allows having symbols that are not 
exported by the shared library that was loaded.

Anyway, at worse this architecture would allow quite fast reloading!


More information about the Digitalmars-d-learn mailing list