Scripting and Rusty Nails History

[hooovahh]

In the LabVIEW community a phrase that has been used to describe undocumented, or incomplete features of LabVIEW has at times been called Rusty Nails.  In searching LAVA it appear this is never explained and so this post is intended to give a brief history with as many details as I know having not been active when this all took place.

The earliest reference to "Rusty Nails" found online (thanks to AQ) is by Greg McKaskle of NI in 1999.  Someone was asking about all the undocumented INI settings that could be found, and how some weren't exposed to the Tools >> Options dialog.  Greg's reply was this:

Quote

As mentioned, most of these configuration options are available from within the Preference dialog. There are also configuration options that aren't in that list because they are needed so early in LV's launch that the resources aren't open yet; so this isn't the complete list. The options that aren't in the preferences dialog are generally considered to be not useful or even harmful. They are sometimes there to allow us a backdoor or a workaround for when we change a behavior. They are also used to turn on obscure development features that we, the LV developers, use to make or debug LV. These obscure features are typically kind of like the attic or basement of a house, not finished out, not very interesting, and potentially harmful.

We have never tried to hide any of these strings, and I don't believe you will gain any benefit from trying out various combinations of the settings. If you ask technical support what a setting is, they will likely tell you that they have no idea. They are telling you the truth. I don't even know what some of them do without checking the code. Others, such as exoticcontrols, no longer do anything. It was once used to show a control palette submenu that contained controls that were still in work and not ready for prime-time. They were experiments, unsupported features, and guaranteed to crash if you did much with them. Just the sort of thing that we need for development, but not useful to even advanced LV users unless they have a death-wish.

If you experiment with the .ini file and you crash mysteriously losing hours of work, I'd suggest putting the file back to the way LV left it. Don't ask tech support to fix it or complain that the LV attic has rusty nails and splinters.

As for whether or not Resedit is wonderful, I personally prefer Resorcerer, but that is a different story. It is a low level tool that in the right hands is useful, in the wrong hands, well, its in the wrong hands. For the person that likes taking a multimeter and a soldering iron to computers and household appliances, its exactly what you always wanted. If you start monkeying with things in the resources or the .ini file, use common sense and do it on a copy or you will just end up reinstalling LV.

Once the fun and experimentation is over with, I think you will agree that the useful options, with very few exceptions are in the Preference dialog.

Back in the LabVIEW 5.x and 6.x era there was a new emerging technology that was LabVIEW Scripting.  NI had created scripting for their own purposes but the community saw it and wanted to be able to automate editing, or creating LabVIEW code.  With the help from Jim Kring and others, the basic tools for enabling scripting in LabVIEW were available.  The story of how this came about is worth a post of its own, but the summary is that NI shipped a VI that didn't have a password on the block diagram, which allowed for the creation of any object, given an ID.  Using a for loop, you could easily create every object in LabVIEW, including objects which facilitate in creating and manipulating code. Discussing scripting often leads into discussing other INI keys which enable private functions like the well known SuperSecretPrivateSpecialStuff.  It is possible this is one of the keys Greg was referring to.  Other INI keys from 5.x can be found here.

After these discoveries the NI forums started getting users asking about scripting, and private functions.  Users were looking for help, and documentation but NI wasn't ready for this knowledge to be public and so they started deleting all posts related to private, and scripting functionality.  Some of the motivation for the creation of LAVAG came about by a desire to have an independent place to discuss the LabVIEW topics that NI didn't want to have on the public forums, potentially adding to the number of support calls, and confusing new users with advanced topics that were undocumented or incomplete.

After LAVA's creation a subforum section was labeled Rusty Nails, and intended to be a place to discuss Scripting, ExternalNodes, XNodes, Private methods, and general LabVIEW hackery.  Over the years several private functions have been made public, and scripting has become an official feature shipping with LabVIEW.  Because of this the Rusty Nails and XNodes subforums were combined into what is now the VI Scripting section.  Even over on the official NI forums, discussions about private functionality and XNodes has been relaxed since those early days.  Asking for private methods and getting unofficial help is something users, and sometimes NI employees will participate in, without the heavy censorship seen earlier.  And topics of scripting are encouraged now that the feature has been official since LabVIEW 8.6.

If you have anything you'd like me to add regarding scripting's history feel free to reply and I can add it.  And if I got any of the details wrong let me know.  Again I wasn't around when this all took place and I've just tried putting down the details I've heard from other developers.

[styrum]

Well, you are missing some important details in "The story of how this came about". So maybe indeed "it is worth a post of its own". It was LabVIEW 7.0 where they forgot to put a password on one of the VIs shipped with LabVIEW. And that VI had some node(s) on its block diagram including, I think, the BD reference property for the VI class. The community indeed got excited. But what did NI do? They tried to hide everything again in LabVIEW 7.1! I made a joke then that "our mother" NI must had had a PMS so she put the most interesting toys on a top shelf. So I made a"ladder" for us, kids, to get to them again and called it

hviewlabs was me then, because that was a name of my company I used to sell my LabHSM Toolkit, an actor framework with actors controlled by hierarchical state machines (statecharts), long before the Statechart toolkit by NI, "THE Actor Framework", DQMH, and even before LVOOP.

After PJM_Labview has published his private class generator http://forums.lavag.org/index.php?showtopic=307&hl=# and class hierarchies http://forums.lavag.org/index.php?showtopic=2161# and http://forums.lavag.org/index.php?showtopic=314&hl=hierarchy# (neither topic is available anymore) it became clear how to get access to private classes, properties and methods. However, it wasn't convenient enough. My PMS Assistant made it really easy. It gave back the access to those features to a much wider community of LabVIEW enthusiasts

As you can see from the PMS topic discussion, by that time brian175 already had made his DataAct Class Browser. And he got really excited about the possibility not only browse but also to actually create objects, property and method nodes with the properties and method NI didn't want the users to see.

 

By April of the same 2006 he figured out object creation too and incorporated the capabilities of PMS Assistant into DataAct Class Browser.

At that point, I guess, NI decided that "the cat is out of the bag" and there is no point to resist. Nevertheless even after VI Scripting was made released by NI some classes, and even some properties and methods of public classes remain hidden even in LabVIEW 2024.

I wonder why DataAct Class Browser is no longer available (as of January 2025) as well as original findings by PJM_Labview even here, on LavaG. Did NI "politely asked" admins to remove all that and just forgot about my PMS Assistant?

[Rolf Kalbermatter]

On 1/23/2025 at 9:52 PM, styrum said:

I wonder why DataAct Class Browser is no longer available (as of January 2025) as well as original findings by PJM_Labview even here, on LavaG. Did NI "politely asked" admins to remove all that and just forgot about my PMS Assistant?

Not likely. I think the Administrators always resisted such requests unless there was a real legal matter involved. But LavaG had several nervous breakdowns over the years, either because a harddisk crashed or forum software somehow got in a fit. It was always restored as well as possible, but at at least one of those incidents a lot got lost. Some of that was consequently restored from archives other people had maintained from their push notifications from this website, but quite a bit got lost then.

You can still see some old posts where the whole text is underscored and links for as far as they are present point into nirvana. These are supposedly not well restored posts and by now of at best historical value, so hard to justify to try to clean up.

Edited January 25 by Rolf Kalbermatter

[hooovahh]

On 1/25/2025 at 7:57 AM, Rolf Kalbermatter said:

Not likely. I think the Administrators always resisted such requests unless there was a real legal matter involved. But LavaG had several nervous breakdowns over the years, either because a harddisk crashed or forum software somehow got in a fit. It was always restored as well as possible, but at at least one of those incidents a lot got lost. Some of that was consequently restored from archives other people had maintained from their push notifications from this website, but quite a bit got lost then.

This is pretty accurate. I know one ex-coworker in particular had an RSS feed push to his Outlook every post on LAVA.  When LAVA had a major crash his Outlook was used to restore as much content as was possible.  As for the content moderation, we try to self police our selves, enough to not get on NI's bad side.  I have very rarely ever needed to intervein.  One time I had to ask one user, to tread carefully on the topic they were sharing, but I did not delete any content or post.  Thanks for the additional history. Jim has mentioned this story to me in the past but I didn't remember the details.  I believe there was a meeting with NI where they were insisting that the scripting code wouldn't be made public, and someone called their bluff basically stating the tools for scripting are already being made by the community, and that if these were good enough for NI to use, we should also have access to them.

[crossrulz]

Another part of this history: JKI forced NI's hand to release scripting (officially supported and open for everybody to use) with their Right-Click Framework. This is how I discovered scripting. I think I even wrote one or two plugins for myself. Then something happened in LabVIEW 2011 or 2012 that broke it. I asked Michael Aivalotis about it and that's how I found out this part of the story. JKI had no intention of fixing the issue because their mission was accomplished.

 

[styrum]

Oh, so is It now JKI who "forced NI's hand to release scripting"?! Isn't that too much of a credit for him/them considering when he released his framework relative to the previous community efforts mentioned above? Maybe it became "the last nail into the coffin" of the "VI Scripting is for NI use only", but definitely not the only and not the "thickest and longest" one.

Edited February 4 by styrum

[Rolf Kalbermatter]

37 minutes ago, styrum said:

Oh, so is It now JKI who "forced NI's hand to release scripting"?! Isn't that too much of a credit for him/them considering when he released his framework relative to the previous community efforts? Maybe it became "the last nail into the coffin" of the "VI Scripting is for NI use only", but definitely not the only and not the "thickest and longest" one.

Well, there are two aspects. The first is the technical one from hackers diving into the software and unhiding things that NI felt were not ready for prime time, to complicated for simple users, or possibly also to powerful. The main reason definitely always is however: if we release that, we have to spend a lot more effort to make it a finished feature (a feature for internal use where you can tell your users: "sorry that was not meant to be used in the way you just tried") is maybe 10 - 20% of development time than the finished feature for public use. There is also support required. That costs money in terms of substantial extra development, end user quality documentation (a simple notepad file doesn't cut it), maintenance and fixing things if something does not match the documented behaviour. And yes I'm aware they don't always fix bugs immediately (or ever) but the premise is, that releasing a feature causes a lot of additional costs and obligations, if you want to or not.

The other aspect is, if someone who is an active partner and has active contacts with various people at NI, he is infinitely more likely to be able to influence decisions at NI than the greatest hacker doing his thing in his attic and never talking with anyone from NI. In that sense it is very likely that Jim having talked with a few people at NI has done a lot more to make NI release this feature eventually, than 20 hackers throwing every single "secret" about this feature on the street. In that sense the term "forcing NI's hands" is maybe a bit inaccurate. He didn't force them, but led them to see the light! Not out of pure selfless love, but to be able to officially use that feature for himself.

The according Right-Click framework was a proof of concept to see how this feature can be used and mainly an example to other users how it can be used, and indeed once it worked it had fulfilled its purpose. That it was not maintained afterwards is not specifically JKI's fault. It is open source, so anyone could have picked up the baton, if they felt it was so valuable for them.

The problem with many libraries is actually, if they are not open source and free, many complain about that, if it is open source and/or free, they still expect full support for it! In that sense I have seen a nice little remark recently:

 

Edited February 4 by Rolf Kalbermatter