Issue with accessing 32 Bit DLL in 64 Bit LabvIEW

[ManasaM]

Hi All,

I am working on image sensor testing.

Here we will grab the image and send the image path for post processing, post processing will be done by the Vis which calls 32 bit DLL.

we are using 64 bit LabVIEW.

Problem Statement:

We have to call 32 bit application from the 64 bit LabVIEW in the same computer, I have got the suggestion saying if we use shared variable it is achievable but its over the network from different computer but i want use in the same computer. 

The test flow will be like

Power up the device using 64 bit LV

Run Pattern using 64 bit LV

Grab image using 64 bit LV

Call and 32 bit LV and send image paths

Get post processed data from the 32 bit LabVIEW and publish using 64 bit LV

Please suggest me how we can achieve it?

Best Regards

Manasa M

[Bob_Schor]

Are you dealing with very large arrays that require 64-bit LabVIEW?  If not, you will greatly simplify your task by sticking with 32-bit LabVIEW throughout.

Bob Schor

[ManasaM]

Thanks for the reply.

For now we are not dealing with the large array but may be in future we may need to deal with large arrays. 

I have checked one suggestion in the NI site 

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PA7SSAW

"Alternatively, you can load the DLL in a 32-bit LabVIEW VI or EXE and communicate between 64-bit LabVIEW and 32-bit LabVIEW using Shared Variables or other networking technologies"

Few Clarification I need on this:

1. Can we use shared variable between 32 bit LabVIEW and 64 Bit LabVIEW in the same computer?

2. Develop wrapper VIs call 32 Bit DLL and Make a DLL out of it and Calling in 64 bit LabVIEW ? Will it works?

Best Regards

Manasa M 

[GerdW]

Hi Manasa,

1. Yes, you can use network communication (which is used by shared variables) between any EXE on your computer…

2. Don't know. Maybe this MSDN entry is more clear on this topic…

[wiebe@CARYA]

AFAIK, Calling a 32 bit dll in a 64 bit exe (LabVIEW or other) or vice versa is just not possible. There might be techniques (that I don't know of) that work around this, but in general it's just not possible. At best, the workaround will complicate things a lot. The solution with a 2nd application used as "server" will probably be far less complicated.

Obviously, a new build of the dll will solve the problem as well, but that might not be possible.

[mud_light]

One option would be to write a wrapper DLL in C that makes calls to the 32-bit DLL.  Compile YOUR DLL for 64-bit operation.  LabVIEW's none the wiser.

Had to do this a while back integrating some very legacy 3rd party code with a new 64-bit application.

[wiebe@CARYA]

---

@mud_light wrote:

One option would be to write a wrapper DLL in C that makes calls to the 32-bit DLL.  

---

I think that's only possible when you go through COM right? Because a plain C dll compiled to 64-bit would not be able to load a 32-bit dll.

You could give this wrapper tool a go... I'd be interested in the result. There is a free "almost full functional" trail. The price €500-€600 is a bit steep for a tool, but making the wrapper yourself could take days\weeks depending on the number of functions... You need to provide a header file of the original.

[mud_light]

Yeah, its hacky.

[rolfk]

---

@mud_light wrote:

One option would be to write a wrapper DLL in C that makes calls to the 32-bit DLL.  Compile YOUR DLL for 64-bit operation.  LabVIEW's none the wiser.

---

Except with the aforementioned wrapper tool this is not an option. A 32 bit DLL can not be loaded into a 64 bit process and vice versa. Microsoft specifically avoided this trouble maker since they probably learned a lot when going from Windows 3.1 to Windows 95 and tried to do just that there, where you could sort of load 16 bit DLLs into a 32 bit process through something called thunking. This was cumbersome, and required more often than not assembly code programming and it was VERY error prone. Basically it seemed probably like a good idea at first but turned out to be such a trouble maker that there were very few real situations that used this. It was much easier to continue to keep everything including the main process as a 16 bit application and live with the limitations that were caused by this, than trying to get this mixed system working.

The wrapper tool basically creates a COM stub and proxy and then a wrapper DLL to convert the COM proxy back into a DLL calling interface. The COM stub is running in the target process as a sort daemon that hooks itself into the Windows message queue of the target process. The proxy is running inside the calling process and also hooks itself into the Windows message queue of the calling process. The COM stub and proxy communicate through RPC (remote procedure call) either over pipes (local) or TCP/IP (when stub and proxy are on different (virtual) machines) between each other. It's an ingenious system, that sometimes works but easily can break apart. If one of the two processes stops or pauses to service the Windows message queue for whatever reason the COM proxy/stub communication is paused too. It's also a speed limitation as everything has to be serialized (marshalled) through this communication channel.

And for anything but trivial DLLs it is also necessary to do extra hand holding to help the wrapper tool to do the right thing. C headers are notoriously inadequate to describe the entire calling interface of a function if there is anything in the parameters list that is not a scalar basic datatype. This includes any form of pointers such as arrays and strings, or even scalar parameter values passed as reference (and goes totally awry for function pointers). Such things either have to be documented in the accompanying documentation for that DLL, or guessed by the programmer when using such DLL functions. And in either case tried out, tested and again tested.