Is there a fast way to convert a lot of CLN from 32 bit to 64 bit

[James_G1]

I have a lot of call library nodes that take U32 as pointer parameters in and U32 as pointer parameters out.  They talk to a 4 different 32 bit dlls.  The paths are hard coded.  I now have a 64 bit dll.  Is there some way to quickly update this legacy code I have to handle the new larger pointers. 

My first thought was if I could look in the binary files and quickly change it there.  I have actually been able to do a search on the binary files and replace all references to mydll32.dll with mydll64.dll.  This worked because it was stored in the file as ASCII.  The rest of the binary file is nearly undecipherable.  I know its a binary file its supposed to be undecipherable.  I tried making a very simple file with a U32 output saved it then changed it to a U64 output and saved it.  Well to my surprise the binary changed in many places???  (I was hoping like only one or two maybe 10)

Is there a legitimate way to do this?  Is there a hacked way to do this?

[rolfk]

---

@James G wrote:

I have a lot of call library nodes that take U32 as pointer parameters in and U32 as pointer parameters out.  They talk to a 4 different 32 bit dlls.  The paths are hard coded.  I now have a 64 bit dll.  Is there some way to quickly update this legacy code I have to handle the new larger pointers. 

My first thought was if I could look in the binary files and quickly change it there.  I have actually been able to do a search on the binary files and replace all references to mydll32.dll with mydll64.dll.  This worked because it was stored in the file as ASCII.  The rest of the binary file is nearly undecipherable.  I know its a binary file its supposed to be undecipherable.  I tried making a very simple file with a U32 output saved it then changed it to a U64 output and saved it.  Well to my surprise the binary changed in many places???  (I was hoping like only one or two maybe 10)

Is there a legitimate way to do this?  Is there a hacked way to do this?

---

The LabVIEW VI structure is fully binary. There REALLY is no way to do what you want by editing the file directly. You were lucky that the DLL names were the same length, otherwise you would have destroyed the binary structure of your VI file by editing the DLL names.

You could try to look into the LabVIEW scripting API. But there are several caveats.

1) Not the entire LabVIEW object model and all its possible operations is exposed through that interface. It is quite possible that you end up missing a crucial property or method to change the datatype of a specific Call Library Node parameter or something like that.

2) Developing programs using LabVIEW Scripting is definitely not for the faint hearted. Documentation is scarce, the interface is more than huge and the programming methodology sometimes a bit strange. It is LabVIEW advanced programming on steroids.

Taken all this into account there are only two reasons why I would even consider doing this particular task in that way:

1) There is virtually an unlimited amount of code that needs to be converted.

2) and the fun factor to come up with this.

It will certainly take more time to go that route than going through all VIs and do it the manual way unless point 1) above applies. 🙂

Also you are not done by changing the CLN parameter type only. You need to change any control that passes these values along to other VIs to be of 64 bit type too otherwise you will loose the pointer on 64 bit platforms when it goes through a control.

[DFGray]

We have done this sort of thing internally at National Instruments many times.  Using the scripting interface is your best bet for automating it.  With the caveat that I have been using scripting for almost a decade, I will say this is a fairly straightforward scripting problem.  The real issue, as Rolf states, is that you need to accurately identify everything that needs to change.  For example, in one instance I handled, the function names from a C++ 64-bit DLL were not mangled, while they were mangled for the 32-bit DLL.  This required changing not only the DLL path, but the names of the functions as well.  You also must deal with 64/32 bit pointer issues.  But that usually requires more extensive code modification.  It may or may not be worth automating, depending on how much you need to change and how many functions need the change.

Let us know if you need more help.  This has been a rather general post.