How to get list of dymanic VIs included in an executable?

[george seifert]

With the development system I can get a list of dymanic VIs (they start with a unique string) by using List Folder VI. These VIs are displayed to the user.

When I built the executable I put all the dynamic VIs in the Always Included box on the Source Files tab. So now I assume they should be contained within the exe. How do I get a list of the dymanic VIs from the executable?

George

[Olivier Jourdan]

Hello,

Have you try to use "All VIs In Memory" application property ?

[george seifert]

Hello,

Have you try to use "All VIs In Memory" application property ?

No, but since they're dynamic VIs I don't think they'd be in memory.

[Olivier Jourdan]

I don't think they'd be in memory.

If they are include in the EXE, I think they are in memory when the EXE is loaded. Try and let me know.

[crelf]

Hmm - maybe list the VIs included in the exe, and then compare the list with the all VIs in memory - those not listed are dynamic? I can see how there would be exceptions though. Or maybe you could open each VI in the exe and get it's caller - those without callers are dynamic? No, because you'd be the caller. Requires more thought I think...

[jdunham]

If they are include in the EXE, I think they are in memory when the EXE is loaded. Try and let me know.

That is almost surely wrong. When the EXE loads and executes, the startup VIs load and run, and that's it. There is no mechanism for dynamic VIs to be loaded unless you write code to load them.

George, by nature it should be hard to browse the EXE for VIs. It used to be really easy, since it was just an LLB, but finally NI tightened the security. No offense intended, but I don't want you or anyone else looking into our executables and harvesting the names of our proprietary routines. But if it's your code, you have some options. You can drop all of your dynamic VIs into "Dynamic VI Container.vi", and include that as the only Dynamic VI in your project. Then code running in your EXE could load it and get its callees from its VI reference.

If that's too ugly and/or slow, you could mantain a list of those VIs (you could actually get that from the lvproj build specs with property nodes, but it might be easier to just maintain your own list). Store the list as a default value of a simple subvi and build that into your EXE.

[crelf]

George, by nature it should be hard to browse the EXE for VIs. It used to be really easy, since it was just an LLB, but finally NI tightened the security.

Ugh, I'd forgotten about that. Sorry - my method(s) won't work

[george seifert]

That is almost surely wrong. When the EXE loads and executes, the startup VIs load and run, and that's it. There is no mechanism for dynamic VIs to be loaded unless you write code to load them.

George, by nature it should be hard to browse the EXE for VIs. It used to be really easy, since it was just an LLB, but finally NI tightened the security. No offense intended, but I don't want you or anyone else looking into our executables and harvesting the names of our proprietary routines. But if it's your code, you have some options. You can drop all of your dynamic VIs into "Dynamic VI Container.vi", and include that as the only Dynamic VI in your project. Then code running in your EXE could load it and get its callees from its VI reference.

If that's too ugly and/or slow, you could mantain a list of those VIs (you could actually get that from the lvproj build specs with property nodes, but it might be easier to just maintain your own list). Store the list as a default value of a simple subvi and build that into your EXE.

Yes, it's definitely wrong. I tried it. What did work was this (although it isn't as elegant as I'd like):

1. All dynamic VIs are put in the Always Included box on the Source Files tab.

2. On the Source File Settings tab I set the Destination for each of the dynamic VIs as Support Directory. This loads each of the dynamic VIs to the support directory. I guess this would be a problem if you wanted to keep all you VIs secret, but all my stuff is in-house.

3. Getting a reference to the dynamic VIs requires some different code for the run time system vs the development system.

George

[jzoller]

You can also parse them out of the executable, since they're stored amongst the binary in clear (if messy) text.

Joe Z.

[Olivier Jourdan]

That is almost surely wrong. When the EXE loads and executes, the startup VIs load and run, and that's it. There is no mechanism for dynamic VIs to be loaded unless you write code to load them.

You are right, I've never test this because I use an another way to load dynamic VIs.

If you use Static VI Reference (see attachment) :

- You don't have to add explicitly your dynamic VI in your build specification

- You can rename your dynamic VI worriless

- Your dynamic VI is hidden from end-users

- code is the same in development or runtime

As far as I've understood the question, I think this can fit with the issue.

Regards,

[jdunham]

You are right, I've never test this because I use an another way to load dynamic VIs.

If you use Static VI Reference (see attachment) :

- You don't have to add explicitly your dynamic VI in your build specification

- You can rename your dynamic VI worriless

- Your dynamic VI is hidden from end-users

- code is the same in development or runtime

As far as I've understood the question, I think this can fit with the issue.

Regards,

Yes, if you can use static VI refs, that is far easier than any other method. You only need to load stuff by name if it's important to take it in and out of memory under programmatic control.