On 04/04/2016 2:34 AM, Vladimir Panteleev wrote:
On Sunday, 3 April 2016 at 14:19:17 UTC, rikki cattermole wrote:
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!
Have you actually tried doing this in practice and getting it to work?
Even with correct function signatures, you'd need more than just the
types to correctly marshall the data between processes. RPC is generally
done with a subset of types with well-defined serializations.
How would you even get GetProcAddress hooking working in this scenario?
You wouldn't even know the number of arguments, much less their types!
LabVIEW is the one that calls the functions. You declare the signature
there. Nothing fancy pretty much limited to c here.
From what I've ready anyway.
So hooking GetProcAddress just tells LabVIEW where to find the function,
not much beyond that.
