How to compile code in 64-bit that calls a 32-bit SubVI?

[sshon]

Through this forum, I've found out how to call a subVI that uses 32-bit libraries from a 64-bit environment by opening an application reference to an already running 32-bit environment:

This however falls apart when I attempted to make an executable. Can somebody please advise me on how I would do that?

[Mark_Yedinak]

Do you have both the 32 and 64 bit runtime engines installed on the PC which will be running the executable? Di you include the VI that is being called with your executable? Is your path to the VI correct?

[sshon]

Hello Mark. Yes, I have both runtime engines installed.

I'm too much of a novice in building executables to not even know what I may be missing... Since the subVI calls 32-bit libraries, it wouldn't compile in 64-bit when I included it, so I've  tried compiling it separately in 32-bit, and placed it at the same path as the 64-bit exe (as the uncompiled vi's are relative to each other). That didn't work. I thought maybe I need to explicitly state the port number in the subVI's ini after a bit more searching, so I did that; that wasn't the solution...

[tst]

The first function in your code is Open Application Reference. It opens a reference to an already running application which is listening on port 3364. This means you need to have a 32 bit application already running which has VI server configured to listen at that port. I'm assuming you don't and that you're getting an error there, but you didn't provide details about how it "falls apart". I would suggest you have some type of error handling so you can understand what's going on (The easiest in terms of amount of code is to place some error indicators).

The easiest way to make this work is probably the following:

1. Build a 32 bit EXE. Have the VI you want to run included in that build and loaded (for example, just place it inside the main VI in a part of the code that doesn't run). This EXE can probably just have a main VI with an event structure that does nothing until you close the application.
2. Configure that EXE to have VI server enabled and listening on port X (this is in the INI file for the EXE and you should find the relevant lines with a search (maybe "VI server executable INI")).
3. Run that EXE and make sure it stays running. This is required for the open function to work.
4. When opening the reference to the VI, don't use a relative path. Use a string constant. If the VI is already loaded in the EXE, the function will simply use that VI. If you start using relative or absolute paths, that makes it more complicated.

All of this is not particularly elegant and there might be cleaner ways to do this, but this is probably the simplest to get it to work the way you have it now. Once you have it working, you can think about cleaning it up (minimizing or hiding the second EXE, passing a message to it from the main EXE to make it close, running it from the main EXE, etc.).

[sshon]

Hi tst. Thanks for responding.

When I said it "fell part", there actually wasn't any error. It just didn't do anything as though the subVI was a blank.

Following your advice, I built a 32-bit exe with the subVI in the true case of a case structure that is always false, within the timeout event of an event structure, within a while loop. I've added the following lines to the associated ini after a search:

server.tcp.enabled=True
server.tcp.access="+*"
server.tcp.port=3364
server.tcp.acl="290000000A000000010000001D00000003000000010000002A10000000030000000000010000000000"
server.vi.access=""

I've also changed the reference from a path to a string.

Unfortunately it's still behaving as though the subVI isn't there. Can you tell me what else I'm missing? With the change from path to string when opening the reference in the main VI, if I run both the new VI from which the 32-bit EXE is built in the 32-bit environment and the main VI in 64-bit, there is now an error saying that the subVI is not in memory.

[Intaris]

Does the sub-VI have compiled code separation set?

[sshon]

Did you mean the option to "separate compiled code from source file"? Yes, it did; though, unchecking that option resulted in the same error message when the "loading" VI and main VI were run in their respective 32/64-bit environments.

[Intaris]

The application instance you are opening the 32-bit VI in, is it an EXE or the LabVIEW IDE?

If it's an EXE, then you're going to need to remove the flag for separating the compiled code. Without the 32-bit compiled code, the 32-bit EXE will not know what to do with it, it will not receive executable code.

You will need to find a way to get the 32-bit compiled code in the VI to stay as 32-bit when compiling your 64-bit EXE. This is probably best done by having it external to the EXE itself, I have no experience of how to tell a 64-bit application build process to leave any given VI as a 32-bit VI. But if you have the compiled code separated, there's no actual executable code within the VI, so without having the IDE to create that, it will never work.

[tst]

---

@sshon wrote:

Hi tst. Thanks for responding.

Following your advice, I built a 32-bit exe with the subVI in the true case of a case structure that is always false, ...there is now an error saying that the subVI is not in memory.

---

If it's wired to a false constant, it's probably optimized out of the build. Try just putting it in the timeout event or create a static VI reference to it. You can also define it as always included, but then it won't be loaded automatically and the open by name won't work.

Note that once the VI is statically included in the build, it has the compiled code in it by default, so it's unlikely you would have to deal with that.

To understand the process, you are opening a reference to the running 32 bit EXE, then you use that reference to open a reference to a VI running in that process and then you call that VI. My understanding is that the call is executed in the remote app and that's why it can be in a different version of LV

[sshon]

I think I understand the process, but I can't seem to manage to get the subVI to load. I've tried putting it in the timeout event, and tried doing an "open VI reference" to it outside of the while loop... I get the same result as before: when running as EXE there was no error but it was as though the subVI was absent; when running in their respective environments there's an error saying the subVI is not in memory.

Thanks for all the help so far, but I think I may need to rethink the architecture since I can't seem to get this working...