list VIs inside 2010 executable

[X.]

Bjorn, it doesn't work in LV 2010 anymore, as discussed previously in the thread... Or does it?

[Norbert_B]

No, it does not work anymore with LV 2010. You stated, that "This change IS an annoyance!", but this is a personal view.

In general, i welcome this change since it is about security. I don't want to go into detail, but i have to ensure you, that it was about time for NI to tighten security for compiled, executable code (so true for DLLs as well). Otherwise, abuse from your 'Intellectual Properties' (meaning: your developed code) is possible.

Norbert

[rolfk]

Sorry but security by obscurity is simply no security. Those people that are so afraid of their IP in a compiled app really have to wake up. There is always a way to get at the compiled code, even much easier in a standard DLL than in a LabVIEW executable. It's just a fact and one has to live with that. Trying to claim it is different is only creating false security.

[Norbert_B]

Rolf,

sure, if someone WANTS to get access to code, he still will.. that's an old issue, for all kind of software.

Still, it was too easy, and in addition i found using "List Folder" to browse content of an EXE or DLL always weird and i did not understand why this should be possible/necessary. I think that the way 2010 works is appropriate for most cases and it never should have been any other.

But i understand that people, (ab)using the previous possible way are now frustrated because of this....

just my 5 cents,

Norbert

[rolfk]

The ability to list the contents of a LabVIEW exe with List Folder function was most likely not intentional. It was just a byproduct of the combination of the facts that LabVIEW treated LLBs as a directory in its file manager code and that executables were really just an LLB in disguise, and that LabVIEW used these facts internally to load the application from that LLB.

What I do get worked up over, are the few people screaming mordio because there is a possibility to look at the VI hierarchy in an executable, because their precious IP is at danger. If the IP is at danger by the pure fact that one can see what VIs are inside an executable, then that IP really can't be that great to begin with. And putting it in C code and compiling it into a DLL or executable makes it actually much easier to reverse engineer not just the function names but the actual code itself. But some people will always insist on living in their dream world.

It's not as easy to get at the VI names in 2010 but it is far from impossible

[BYeske]

I have spent most of the day doing exactly what was in this thread.

I am new to OOP and I am attempting to implement it in a new program I am developing.  I am using the factory pattern and was trying to dynamically load classes based on a directory structure that I developed.  I was thinking that as I developed new classes and put them in certain folders that the main program would be able to list all the folders and all the classes in each folder and populate a ring Control.  The caption of the ring control would be the Folder and the names inside the ring would be the class names.

For example, I am using the Hardware Abstraction concept in my program, and each ring control would be a type of hardware and each name inside the ring (or class) would be a specific model of that hardware.  I thought it would be nice to have the main program automatically populate out the ring controls based on the classes I had developed.

Well I ran into the problem of hey, I cannot do a list folder on files inside the runtime executable.  I searched out how I could do this and came up empty.  I found the OpenG 2009 ZIP solution and implemented it, only to have it fail on the 2011 Labview version that I was using.

So now I am simply staticly having a array of paths to where all my dynamically called classes reside.  Does anyone know of a good solution to this type of problem?  One way that I could get around this problem is what was mentioned above:  Generate an array of paths to where all the dynamically called classes reside at build time and save that array as a constant in the program and work with that.   Also, could using an .ini file with the paths stored in it work?  I would have to include the .ini file with the executable if I did this though.

This works for Classes that are included in the built executable.

If you want to add classes later to a built executable, this is an entirely different problem.  For this problem, what would you do?  Build the dynamically called classes in a source distribution and have the program search this add on package or plugin?  Any comments or good articles on how to do this?

Is this what I want?  https://decibel.ni.com/content/groups/large-labview-application-development/blog/2011/05/08/an-appro...

[rolfk]

You seem to have come up with the possible solutions already. Either store your hierarchy externally to the executable and list it from there, or populate some control or ini file with the contents of your executable at build time.

However as the original author of the OpenG ZIP Library I would be interested to know what failed in LabVIEW 2011. To my knowledge this still should work in 2011 as they did before. (Unless you also made a move to 64 bit LabVIEW which at the moment is not yet supported as the shared library that implements the ZIP Tools funcionality needs to be recompiled for that and I haven't really got around to install a complete 64 bit compiler and debugger toolchain yet).

[BYeske]

The OpenG zip Library didn't fail,  I'm sure it works as intended on zip files,  What I was saying was that since the .exe can no longer be treated as a zip file, in LV2011, I could not get the Vi's names as you could in LV2009.

[rolfk]

---

@BYeske wrote:

The OpenG zip Library didn't fail,  I'm sure it works as intended on zip files,  What I was saying was that since the .exe can no longer be treated as a zip file, in LV2011, I could not get the Vi's names as you could in LV2009.

---

Ohhh I see. Well it is still a compressed archive, but I believe they changed the ZIP file marker in the beginning. Almost all ZIP file libraries check the file for an occurrence of the character sequence PK and try to read the archive directory  relative to that. When I looked at it briefly they seemed to have changed the PK prefix but otherwise it still looked like a ZIP file. This was however a very brief check so there might be more to it.

[M_Berggren]

Hi all

The scenario that monzue is describing above is more or less exactly the situation that I am facing. My application were initially developed in LV8.5 without an object oriented design. I included the basic hardware simulator in the executable (using "Always include" in the build) and distributed the other plugin drivers as llb:s. Each plugin (including the simulator) came with a description file pointing out the different VI:s to load. This worked fine until I started using LVOOP and had to disable the "Use 8.x file layout" option. Now I have to specify the VI:s (for the simulator) with the internal path within the executable, which I don't know, and that might change if the executable is built on different machine with a different project root path.

So, I know the name of the VI but need to find the complete path within the executable.

Is there any solution to the listing problem discussed in this thread or is there any other way to find the VI?

Best regards

Michael