LabVIEW
Converting 32 bit dll into 64 bit
Solved!
@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.
@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 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.
