Thanks David, Rolf, and Greg for all the input on this rather esoteric
topic. I still have issues regarding this topic, but I don't know
that I can formulate them into pointed questions. In any case, the
dll calls work, and that's what matters in the end.
What I DO know is that - thanks to you g
>You pointed out that depending on which calling
>convention you use, either the function or the calling
>code pops parameters off the stack. Which convention
>does which, and does one method inherently involve
> less overhead than the other?
With cdecl the caller is responsible to adjust the sta
Thanks, David,
You've answered my question. If you don't mind carrying on this
discussion just a little further, though, you've brought up one more
question...
You pointed out that depending on which calling convention you use,
either the function or the calling code pops parameters off the stac
I'm not sure what you mean with "before being concatenated with the
rest of the pointer".
An x86 machine is little endian. So the CPU expects the bytes to be
in reverse order. If a function in your dll expects an int32, it will
want the bytes in reverse order.
So, when LabVIEW makes calls to na
In building pointers to be passed to certain dll calls, I have noticed
that I need to pay attention to some peculiar details if I want the
functions to execute properly. Namely, numeric types must have their
bytes reversed from the way in which LabVIEW orders them
(least-significant last) before b
