Summary:

A personal note to the community

First off I would like to extend my thanks for the ones out there that provided moral support for my (controversial) actions here. I realize that my actions haven't been completely selfless, but I really wanted to document most of what I was able to figure out so that I didn't just release some source code. I have been extremely surprised that nobody else found out that ;DNI_IntToEnum.vi was unlocked, with adequate documentation provided inside of it. Perhaps it is because not many people purchased the addon? Maybe nobody thought to give it a try? Process of discovery I first discovered this by playing around with the State Machine addon and using it to generate code. I noticed the new "primitive" ;DNI_IntToEnum.vi and I was immediately fascinated. Finally a way to provide an ENUM value from an integer (type cast doesn't work, I don't think) in a nice packaged little...primitive? But wait, primitives aren't .vi files (as far as I know). I also wondered why this wasn't a part of the normal libraries. I first discovered that it had some oddities when I sent a copy of it to my co-worker, and when he ran it on his machine it retained some information (the enum type, I think) after it had been disconnected! It seemed to retain the enum type on the output long after it had been disconnected, and then I opened it up by itself. Now THAT was something new. A ton of weird inputs and outputs. Same icon, but the Input Parameters and the Return Parameters all seemed weird and irrelevant to the whole process. I then found out through some easy manipulation that the file required the ";D" prefix to work correctly. Is this a joke (winking smile) or does it represent something specific? I then noticed that a lot of internal events weren't used, so I populated the state machine with the extent of the cases provided in what. I also added a few globals to see when the events specifically occurred. Over the course of a month or so, I had exhausted my ability to work with XNodes, since I had limited access to scripting library items. My next step was to investigate the entire scripting ability built into LabVIEW. The online message boards weren't much help at the time, with a few primitives and methods exposed here and there (this was prior to my knowledge of SuperPrivateScriptingFeatureVisible and SuperSecretPrivateSpecialStuff, which had, at the time, not been exposed on the LAVA group). I had an idea of what my goal was (;DAHR_MergeErrors.vi), but I had no way to generate the internal code in the PropType event. Specifically, I needed a Refnum to several things that I needed to create using the New VI Object primitive, such as a For Loop, Build Array, Numeric Constant, and others. Well, I realized that I had a nifty little tool that could create anything I needed! XNodes can change their outputs and inputs based upon the type descriptor of each terminal in termSpecs! I quickly made an XNode that accessed a global variable for the type descriptor that I wished to generate. I researched type descriptors until I found the right range of objects that I wanted (refnums), and then I selected Create Constant from the terminal. Pop! Here was a refnum to a refnum! I made it into a scripted macro and generated all the refnums I needed to access the New VI Object primitive properly. Suddenly, I was active in the scripting world, and my only key in the door was one little XNode that was left unlocked! Now, of course, if you set SuperPrivateScriptingFeatureVisible=True in LabVIEW.ini then you have access to all of these refnums. Not to mention various properties/methods that I managed to generate (by the way, has anyone figured out how to set correct parameters to VI.GenerateCCode? That's a funny one...) manually from some LAVA example code prior to this ini setting. Future actions I'm considering sitting down and documenting what I have learned from experimentation with various hidden Properties and Methods (a lot of the internal documentation is done well, but some of these are actually quite useful in development, and could be documented better), or perhaps the LabVIEW ini settings I have found (which isn't many per se), or what I have learned from App.CallInternalCommand. Before the whole system was exposed, there was a lot more discussion on these topics (LAVA). Now it seems everyone is a lot more silent on these topics, but available and willing to address specific topics. I know now is the point a lot of you are clicking on my email and sending me a link to some website that documents all this stuff and puts me to shame. I'm sure I will learn a lot from the community after releasing this information, and hopefully the happy people will exceed the unhappy people. Legalities I want to stress the following: I only worked with unlocked, available code and what features I have explained here. I don't think anything I did could be construed as reverse-engineering (just understanding provided code functionality). I am not asking for money or anything like that, and I am not releasing any code that could not have been accessed otherwise. My reason for not providing the source code to my VIs is that NI could see my code as just a modified version of the code provided in the State Machine toolkit, which would be essentially leaking purchased code for free. I stripped the code from the released VIs because I was afraid that there might be a way hidden deep in the scripting that would allow users to unlock VIs (and be accessed only by the creme-de-la-creme of LabVIEW, which is everyone at NI). That scared me into thinking that NI could unlock my VI and see my source code, and then construe it as me leaking purchased source code. I want to make my actions as legal as possible in the very shady politics of software development, which become even more gray in the world of LabVIEW. Would screenshots of source code be legal to post on the internet? When I release code that is created easily by me because I know how it works, is this legal? Is my documentation of the process legal? I'm not making a profit, and this is something that can be sent word-of-mouth, so I see what I have done as public domain for release. After all, you *do* have to purchase LabVIEW for any of this to be helpful in the first place. NI's only problem will be when they want to make money for something that is already available. Scary. Controversy I would like to outline the controversy I have seen on this entire scenario for the LabVIEW community. I found something that was unlocked (and I'm surprised I haven't seen anyone else discuss it): ;DNI_IntToEnum.vi Express Nodes --> XNodes (used in Storage VIs) are a member of the controversial LabVIEW VI Scripting abilities. These abilities have not been "formally" released by NI because of (a) lack of documentation, (b) lack of stability, (c) prototypical status, (d) limited helpfulness in developing VIs in the first place, (e) difficulty and complexity of use, (f) plans to release said ability in formal status in LabVIEW 8.0. My guess is that this is one of the many reasons LV8 is taking so long to release. My "shady" actions (my own words). I would like to stress that over my entire development and discovery of LabVIEW scripting et al, I have never had malicious intent and I have never released any code that had potential to harm or otherwise affect negatively anyone in any way. I only released VIs that demonstrated various abilities of XNodes, and I wanted to stress that I had no idea how stable the whole XNode system was, since it was completely undocumented in terms of being a part of the LabVIEW system. I hate having to specify this, but I fear worst case scenarios where someone is working on a large project, runs one of my XNode VIs, and then the system crashes when they try to compile it as a part of the project. I figure scaring everyone into being careful before using this stuff is a lot safer for me when something goes wrong. It is NEVER my intention for anything bad to happen with this. My only point of claim is to release what I know on all of this, not some of NI's source code right off the bat. Is this information 'supposed' to be public? I would like to point out that NI released LabVIEW with these abilities inherent, and I merely help to expose these abilities. You're not downloading a patch to add the functionality in LabVIEW, you're not hacking LabVIEW.exe, you're not running code that was created with a hex editor. All this stuff was figured out by, well, using LabVIEW. The controversy lies in some of the (negative) feedback I got on this topic. I have people angry with me: That don't want scripting to be publicly available: ...Because NI will never let us use it again! (This was a somewhat common concern, especially with LV8 in the works) ...Because it will destroy my system! ...Because it's not fully documented! ...Because it's going to be a purchasable addon! That wish I had released my information earlier That don't like my course of action through this I suppose the one thing I could have said earlier is: ;DNI_IntToEnum.vi! I worked pretty hard to get to this point, and I want the community to benefit from this, and I apologize for taking my time on this. Schoolwork remains my excuse for not getting around to this topic in a more timely manner. Will NI be angry? From what I've seen, NI has seen fit to release Beta code in a Final product. "...to share this technology is to break the licensing and/or Nondisclosure agreements" apparently. I sincerely hope they don't try to burn me at the stake for all of this. - Adam Rofer Email me your opinions or comments. Be nice! :) Thanks to... LAVA Forums for providing me with the basework to work with and discover how XNodes work Stephen Mercer for his objective assistance in understanding what I was working with Unnamed people who helped me clarify what I was working with Anyone who emailed me supporting my actions when I was initially "shouted down" Apologies to... The community for not making this available sooner NI for exposing as much as I can LAVA for not posting this on their forums first, instead opting for a bundled info package :)