Calling a 64 bit DLL from LabVIEW 8.0

[Raistlin]

I compiled a C DLL usign the x64 compiler of Visual Studio .NET 2005, but do not succeed in calling it with the 'call library node' of LabVIEW (version 8.0), on the same 64 bit machine. The message I get is the following :

LabVIEW: Some system capacity necessary for operation is not enabled.
The file '*.dll' is not a valid LabVIEW file.

I know LabVIEW is still 32 bit, but is not possible to call this type of DLL ? I also have the remaining problem that my pointers are 64 bit inside C, and 32 bit inside LabVIEW. Since arrays have to be passed between both that poses another challenge. But this is a problem for later.

Message Edited by Raistlin on 04-10-2006 02:52 AM

[pauldavey]

Sorry that I can't be of much use to you, but I do know that Labview 8 supports 64bit integers now, if that helps.

[rolfk]

---

@Raistlin wrote:
I compiled a C DLL usign the x64 compiler of Visual Studio .NET 2005, but do not succeed in calling it with the 'call library node' of LabVIEW (version 8.0), on the same 64 bit machine. The message I get is the following :

LabVIEW: Some system capacity necessary for operation is not enabled.
The file '*.dll' is not a valid LabVIEW file.

I know LabVIEW is still 32 bit, but is not possible to call this type of DLL ? I also have the remaining problem that my pointers are 64 bit inside C, and 32 bit inside LabVIEW. Since arrays have to be passed between both that poses another challenge. But this is a problem for later.

Message Edited by Raistlin on 04-10-2006 02:52 AM

---

LabVIEW is a 32bit application and runs in the 32bit Windows subsystem when you install it on a 64bit Windows OS. As such it can't load or otherwise use any 64bit DLLs.
And no the problem about 32bit and 64bit pointers is just another very important issue and there is no later here. Supposedly you could create a 32bit <-> 64bit thinking DLL that translates the whole environment between the LabVIEW 32bit one and the DLL 64bit one (similar to what you had to do in old Windows 3.1 days to interface the 16bit DLLs to the 32bit LabVIEW system), but I have no idea if normal Visual C would even support creating such thunking DLLs or if you would need to dig deep into assembly too.

So basically there is no go about what you want to do. The best solution would be to recompile your DLL as a 32bit DLL and load that into LabVIEW. If that is no option you would have to wait for LabVIEW 64bit which there has been no date nor version specified as to when it will be available. LabVIEW 9.0 may be a good target for that but there will be first LabVIEW 8.1 released sometimes this or next year.
I personally expect the guys from LabVIEW R&D to have to solve some very hard to crack nuts in that transition not to mention that LabVIEW without the according DAQ, VISA and other libraries is basically useless for most users.

Rolf Kalbermatter

Message Edited by rolfk on 04-10-2006 11:46 AM

[Raistlin]

Thank you for this information. It does make sense, and maybe I was a little bit too optimistic. We currently have a full 32 bit software program, and it would have been nice to port some functionalities to 64 bit, since memory is quite an important limitation (think 3D, think 2048 x 2048 x 200 and beyond 🙂 ). We are more and more inclined to porting everything to a full C++ environment, maybe it might finally come to that.

Message Edited by Raistlin on 04-10-2006 06:55 AM

[Lycangeek]

Unlike the 16 to 32-bit transition, there isn't any support for thunking layers when dealing with the 64-bit world. Microsoft provides something called WoW (Windows on Windows), which emulates a 32-bit system on the 64-bit machine, and that is how LabVIEW can run on 64-bit. The only way to call a 64-bit DLL is to call it via a remoting call (such as DCOM), which is supported by Microsoft.

A point to consider is that even if LV runs in 32-bit mode, you still can have an advantage in the 64-bit world. The first memory problem people tend to run into on 32-bit is that the user-kernel boundary is at 2GB. This means that half of your address space is reserved for the kernel (you can change it to 3GB/1GB, but that puts a lot of pressure on the kernel and can cause problems by itself). In other words, even if you have 4GB of RAM in the system, you only have 2GB of memory address to play with for LabVIEW.

However, in a 64-bit world, a WoW program gets the full 4GB of address space to play with (the kernel space being "hidden"). Thus LabVIEW and your DLLs could allocate much larger blocks of memory than in 32-bit. Add in the fact that you can put in a lot more RAM to keep things running fast, and you have a nice solution.

A word of warning - a 64-bit system REQUIRES that the drivers are 64-bit. There is no emulation for 32-bit drivers. Thus make sure that all the drivers you need (NI hardware, your video card, ethernet card, etc) have 64-bit drivers before you switch.

[Raistlin]

Luckily this software does not have anything to do with hardware. It has evolved from a complete LabVIEW based program, but since it depends heavily on fast memory operations with huge amounts of memory only the GUI remains in LabVIEW. At the moment some users run it on x64 systems, but as one of them let us know today, they do encounter some "Memory is full" messages with certain data sets. And then there hands our tied. So a full C++ conversion might be upcoming, although I dread the amount of work that is waiting for us.  But it's all a matter of patience.

LabVIEW will off course remain our preferred development environment for all our hardware controls, it's also a matter of using the right tools for the right applications.

[Gates]

So is it correct that if I want to switch to 64 bit programming, I can better forget Labview?

[Raistlin]

I think you can put it like that. Workarounds are always limited since LabVIEW itself remains 32 bit. I am wondering if there's a roadmap for the 64 bit version, but I guess this might be something for the 'not-so-near' future.