On Sunday, 3 April 2016 at 15:32:00 UTC, rikki cattermole wrote:
> On 04/04/2016 2:34 AM, Vladimir Panteleev wrote:
>> [...]
>
> 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.

I still have no idea how all this can possibly make any sense or work at all, possibly because I don't know what LabVIEW is.

On Sunday, 3 April 2016 at 13:59:29 UTC, Vladimir Panteleev wrote:
> 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.

thanks. In theory all the DLL will do is talk to a device driver that talks to the power inverters, so just copying the useful data should work, possibly freeing the old data.
I'm not quite sure how easy output will be but oh well.

On Sunday, 3 April 2016 at 15:34:33 UTC, Vladimir Panteleev wrote:
> On Sunday, 3 April 2016 at 15:32:00 UTC, rikki cattermole wrote:
>> On 04/04/2016 2:34 AM, Vladimir Panteleev wrote:
>>> [...]
>>
>> 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.
>
> I still have no idea how all this can possibly make any sense or work at all, possibly because I don't know what LabVIEW is.

Ah, ignorance is bliss my friend. A graphical programming environment, enough said. Their libraries are good i'll give them that, but the interface is tedious beyond comparison. Also it's not text,so you can't diff it, which implies you can use any version control.

On Sunday, 3 April 2016 at 14:34:07 UTC, Vladimir Panteleev wrote:
> On Sunday, 3 April 2016 at 14:19:17 UTC, rikki cattermole wrote:
>> [...]
>
> 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!

Hence why i wanted to do it in separate processes communicating via a (whatever the windows version is of a) pipe or on localhost