State of windows DLL support

[rikki cattermole via Digitalmars-d-learn]

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.