I have labview 2009 sp1 64 bit on a 64 bit machine with windows vista64 bit. I am using the import shared library wizard on a 64 bit dll with provided header file.
I noticed that the header file shows some functions as passing void*. When the wizard generates the call library nodes and the vi terminals it makes them U32. Perhaps I am missing something here but on a 64 bit machine shouldn't these be U64? I feel that if the 64 bit dll attempts to return a pointer that points to address higher than the 32 bit limit I could get into some real trouble here.
Is this an NI over sight or my misunderstanding?
Solved! Go to Solution.
Hi James G,
This is Paul, the applications engineer at National Instruments who will be helping you. So I think there is a bit of a misunderstanding here with what's going on. The type of machine you're on, whether it's 32 or 64 bit, has no bearing on the data type requirements that should be passed. For example, a 32 bit machine could process a U128. Let me know if you have any other questions.
Hi James G,
This is Saverio, not an applications engineer at National Instruments who will be helping you on this public forum.
To answer your question, the Import Shared Library Wizard uses U32 for void*. This is actually documented. This does not mean that you can't change the data type after the wrapper VI is created. In fact, you should.
Is it an NI oversight? Yup.
The type of machine you're on, whether it's 32 or 64 bit, has no bearing on the data type requirements that should be passed.
Really? So in other words, 64-bit code will work on 32-bit machines? And exactly when did this magic get created?
Hi smercurio_fc and James G,
Sorry that I wasn't clear enough in my first post. All I was saying was that input data type/representation is not related to the machine architecture, whether it is 32 or 64 bit. Regardless of the architecture a dll can have a 64 bit input. Admittedly, on a 32 bit machine this would have performance implications but there is no reason why you can't do it. Sorry for the misunderstanding and thank you for clarifying that.
As of LabVIEW 8.6 (or was it 2009? I can't remember for sure) we have a "pointer-sized integer" option for call library node parameters. If the import wizard is trying to wire an integer to a void* parameter set to pass by value then it should be setting the type of the parameter to pointer-sized and make the wire/control itself a 64-bit integer (on all platforms). This is a limitation in our 64-bit support because the import wizard predates that option (and our 64-bit version of LabVIEW). I will file a bug report for it.
Yes Smercurio_fc I could change it by hand, but the reason I was using the import wizard is because the dlls I am importing have literally hundreds of functions in them passing these pointer around, so if I have to change stuff by hand...well I'd just rather not. Thank you for pointing out that it is documented that pointers are assigned to U32.
Adam Kemp, I am aware of the pointer sized integer and was a bit surprised when the import wizard did not take advantage of them. Thank you for filing a bug report on this. I am really amazed that no one has already run into this. The import wizard is generally quite awesome and I have used it with great success in the past.
Simple Workaround: if you have an otherwise unused data type like I8 to spare, just replace all VOID* parameters in your DLL's header file with INT8. Then, run the shared library import wizard, let it create all the desired VIs and afterwards, run attached scripting VI on the newly created folder.
It will use scripting to find all I8 controls inside the VIs, change them to U64 and re-save the VIs.
That is a nice simple workaround. I am upset that I did not think of that myself.
Thank you for this.