Converting 32 bit dll to 64 bit masm

[old_man]

I am having a problem with trying to use a 32 bit dll with LabView 2010 64 bit.  I don't find a work around other than converting the dll to 64 bit.  Any info?

I have the source for the dll but it is done in assembly.  Any pointers on changing it over to 64 bit?  I've done 32 bit several years ago, but never 64 bit.

I was originally told to load LabView 32 bit on the Windows 7 system and everything would be fine.  It was buggy and but it would load the dlls and they worked most of the time.  That was the problem.  I converted over to 64 bit LabView and now the dll's won't load at all.

[rolfk]

---

@old_man wrote:

I am having a problem with trying to use a 32 bit dll with LabView 2010 64 bit.  I don't find a work around other than converting the dll to 64 bit.  Any info?

I have the source for the dll but it is done in assembly.  Any pointers on changing it over to 64 bit?  I've done 32 bit several years ago, but never 64 bit.

I was originally told to load LabView 32 bit on the Windows 7 system and everything would be fine.  It was buggy and but it would load the dlls and they worked most of the time.  That was the problem.  I converted over to 64 bit LabView and now the dll's won't load at all.

---

You summed it up! LabVIEW 64 bit requires 64 Bit DLLs. So it's either going back to LabVIEW 32 Bit or converting the DLL. Considering that the DLL contains assembly code, I would discount the porting of the DLL as a feasable solution, unless you can spend quite a lot of time on this and even more on the debugging.

You don't mention what was buggy, but LabVIEW 2010 32 bit works fine for me on Windows 7. Interfacing DLLs is a tricky thing of course, you need to have everything right, from the setup of the Call Library Node, to the correct allocation of buffers for array and string paramaters of the DLL functions, and of course the DLL itself. If you have a VERY good understanding of C programming you can go about it in this way:

1) Debug the DLL VERY throughly in several C test programs to make sure the DLL itself is not causing the trouble.

2) Configure the Call Library Nodes and check and double check the parameters to be of correct type and reference (pass by value or reference), C array and string pointers, etc.

3) Make sure that on any output buffer (string or array to receive data from the DLL function) you do allocate the necessary buffer size in LabVIEW before calling the function. This often gets forgotten even by seasoned C programmers (who would never pass an unmalloced buffer to such a function in a C program) because LabVIEW does all the memory management in the rest of the program for them. But for the Call Library Node it can't even start to guess how much memory the function would need so it doesn't try either and relies on the programmer to tell it that, either in the Call Library Node configuration through the minimal size parameter, or on the diagram by explicitedly allocating those buffers for instance through an Initialize Array node.

All of these points can create very strange trouble if not done right. Strange in that it can seem to work fine until you try to close the application or LabVIEW, or there is full moon, or you build the application or ship it to the other side of the world. Problems can be crashes, exception dialogs, strange results in the calculated values, etc.

So debug, debug, debug, instead of changing various components on a random way, that will give you more trouble such as trying to go 64 Bit on an assembly code DLL.

If you don't have a good understanding of C, then have someone who does do the above mentioned 3 steps

[old_man]

I have been programming with dll's for decades.  I understand them very will as I wrote instrument drivers, even for NI, under contract.  I have taken the configuration back to the simplest form possible, namely an older XP machine and 32 bit Labview.  I still see the problem.

As it turns out the relay control board seems to "step" on the voltmeter when the very first function is called, namely the 'Find Devices' call.  It appears that the dll is somehow screwing up the voltmeter when it queries all the items on the bus.  None of the subsequent calls to the relay board cause any problems.  I am deconstructing the dll at the moment to see if I can figure out what is causing it.   I have been thinking of talking directly to the usb using LabView and doing raw commands instead of using the dll.

[smercurio_fc]

Yet another start of the same thread: http://forums.ni.com/t5/LabVIEW/Using-LabView-32-on-a-64-bit-machine/m-p/1573916

Starting new threads on the same subject makes it more difficult to help since people don't know what's already been discussed and suggested. Please help us help you by sticking to the discussion in one place. Thank you.