LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Converting 32 bit dll into 64 bit

Solved!
Go to solution

Alright I've been struggling with this for a while, and I know there's a lot of answer out there saying that you need to use the source code but I don't have that.  What I do have is the dll, a .lib file, and the .h file.  I was wondering if there was any way to use these to recompile the dll from 32 bit to 64 bit?  I also see that the header file has this

 

#ifdef _WIN32
#define IDS_DLL __declspec(dllexport)
#elif defined(UNIX)
#define IDS_DLL
#else
#define IDS_DLL __declspec(dllimport)
#endif

 

Which seems to be trying to set up use for both 32 bit and 64 bit, however the dll is only in 32 bit.  Is there any way to access it in 64 bit labview?

0 Kudos
Message 1 of 6
(14,293 Views)
Solution
Accepted by topic author EthanHenry

@EthanHenry wrote:

 

 

Which seems to be trying to set up use for both 32 bit and 64 bit, however the dll is only in 32 bit.  Is there any way to access it in 64 bit labview?


No, there is no 32-bit 64-bit magic in there. And it is preprocessor statements, so what the compiler does before it actually compiles the source code into the final binary object. It has no influence whatsoever on how you can call the resulting DLL.

 

This particular preprocessor magic defines some label depending on if the source code is compiled for Windows or Unix. And the _WIN32 define is true for both 32-bit and 64-bit compilation but that is totally irrelevant for your problem.

 

If you have a 32-bit DLL you need a 32-bit application to call it. Unless you are so proficient in assembly programming that you could rewrite parts of Windows in it, there is simply no way around that! Niente, Non, Nothing!

 

You have 3 options (in order of effort) and nothing else:

 

1) Use 32-bit LabVIEW for your entire application.

2) Use 32-bit LabVIEW to interface to that DLL and then use some IAC (Interapplication Communication) such as Network Streams, TCP/IP connections or similar to talk with that 32-bit application from your main 64-bit application

3) Get someone with the source code for that DLL to recompile it for 64-bit. Note that this may not be as simple as throw the Compile switch and be done. The code may make many assumptions about being executed in 32-bit that will not compile or crash at runtime if compiled for 64-bit without careful code review.

 

Rolf Kalbermatter
My Blog
Message 2 of 6
(14,243 Views)

Out of curiosity: why wouldn't you be able to call a 32 bit DLL on a 64 bit LabVIEW, given you pass 32 bit variables? Vice versa doesn't work, that's clear. 

Windows is 64 bit, but most apps are 32. I suppose, 32 bit applications usually call 32 bit DLLs of which the system DLL must be in Windows as well. So Windows has supposedly many DLLs in 32 bit and 64 bit. Does that mean the 64 bit apps would never call 32 bit or even 16 bit DLLs? Why not? 

0 Kudos
Message 3 of 6
(14,240 Views)

@MaSta wrote:

Out of curiosity: why wouldn't you be able to call a 32 bit DLL on a 64 bit LabVIEW, given you pass 32 bit variables? Vice versa doesn't work, that's clear. 


You simply can't. It is not just about pointers being different. The entire CPU needs to change into a different mode for 64-bit code to work than for 32-bit code.

Windows maintains a complete 32-bit copy of system DLLs (located in the SysWOW64 folder to use for 32-bit applications) and will load any request for a system DLL from there for 32-bit applications, even if the application tries to explicitly load from the System folder instead. These 32-bit versions do all kind of assembly trickery to forward calls to the 64-bit version of the real system DLL whenever that is needed.

 

Microsoft chose to NOT make these 32-bit to/from 64-bit thunking layer available to user applications since it is a pitta to maintain and use. Chances that people trying to use this would mess up really good, is simply way to big and if you mess things up on this level a simple OS crash could be the least of your troubles.

Rolf Kalbermatter
My Blog
0 Kudos
Message 4 of 6
(14,221 Views)

Rolf if right (as usual).  I presented on Network Streams a while ago.  In it I mentioned the limitations of the 32 and 64 bit DLL calling.  I posted the code and demo here where you have a 32 bit application doing the work, and then some communication method to the 64 bit.

 

Automotive communications often rely on a Seed/Key DLL that is provided for unlocking functionality of ECUs.  This DLL is a Windows 32 bit DLL, and is restricted on the platform it can be called from.  So in the ECUMC toolkit NI provides an example called Remote Seedkey which uses TCP to ask another system (or application) to perform the unlock.

Message 5 of 6
(14,200 Views)

You know, I had a feeling that was the case, but I was hoping in my heart of hearts that there was some workaround.  Thanks for the clarifier, and I didn't actually know that Win32 handles both 32 and 64 bit (learn something new everyday!).  I finally got in contact with the distributor who gave me the next best thing, so it worked out in the end.  Thanks y'all, happy coding!

0 Kudos
Message 6 of 6
(14,190 Views)