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!
