LabVIEW
Working with 32bit and 64 bit in the same project
I believe that if you double-click on a LabVIEW file (e.g., vi, ctl, lvproj, etc.), it opens with the last version of LabVIEW that you used. Open the version of LabVIEW that you want to use first, then open the file.
A 32-bit DLL can NOT be loaded in a 64-bit applciation. That applies to LabVIEW as well, so your code trying to access the 32-bit DLL will need to be in a project that is loaded into 32-bit LabVIEW, or you get all kinds of broken arrows.
@rolfk wrote:
A 32-bit DLL can NOT be loaded in a 64-bit applciation. That applies to LabVIEW as well, so your code trying to access the 32-bit DLL will need to be in a project that is loaded into 32-bit LabVIEW, or you get all kinds of broken arrows.
I've seen that, given both 32 and 64 bit versions of the dll were properly installed, LabVIEW will find the appropriate one, depending on bitness.
@billko wrote:
@rolfk wrote:
A 32-bit DLL can NOT be loaded in a 64-bit applciation. That applies to LabVIEW as well, so your code trying to access the 32-bit DLL will need to be in a project that is loaded into 32-bit LabVIEW, or you get all kinds of broken arrows.
I've seen that, given both 32 and 64 bit versions of the dll were properly installed, LabVIEW will find the appropriate one, depending on bitness.
Of course, but that is not how I understood the request of the OP. The Call Library Node is quite involved and some of the things are a bit under the hood although in principle documented.
When you only have a DLL name without path, LabVIEW will simply pass that to Windows and Windows will search in the default locations for that DLL. Among them is the System directory according to the bitness of the calling application, System32 if you execute in 64-bit LabVIEW, SysWOW64 if you execute in 32-bit LabVIEW. So if you have the according DLL in the correct System directory all is well.
If you define a full absolute path, LabVIEW will simply pass that to Windows and that better is the right bitness or Windows will fail the load and LabVIEW simply gives you a broken arrow or error.
There are a few special wildcards that you can also use in the DLL name which LabVIEW will first substitute before passing the path or name to Windows.
name.* LabVIEW will replace the wildcard with the file ending for the current platform, dll on Windows.
name*.dll LabVIEW will replace the wildcard with 64 when running in 64-bit and 32 otherwise.
name**.dll LabVIEW will replace the double wildcard with _64 when running in 64-bit and nothing otherwise.
The wildcard for the latter two cases can be placed anywhere in the name before the dot to indicate the name ending. So "name*shared.dll" will result in "name32shared.dll" in 32-bit LabVIEW. This can be handy if you do not want to place a DLL into the system directory but rather want to keep it in the VI library directory. This way you can place both the 32-bit and 64-bit in the same directory and LabVIEW will simply use the one that is appropriate.
@rolfk wrote:There are a few special wildcards that you can also use in the DLL name which LabVIEW will first substitute before passing the path or name to Windows.
name.* LabVIEW will replace the wildcard with the file ending for the current platform, dll on Windows.
name*.dll LabVIEW will replace the wildcard with 64 when running in 64-bit and 32 otherwise.
name**.dll LabVIEW will replace the double wildcard with _64 when running in 64-bit and nothing otherwise.
TIL, thanks Rolf. Ever considered writing a nuggets series?
Actually there have been a few topics coming up recently and I'm in the process of writing something up for my own blog pages.
