12 replies to this topic

[flarn2006]

Exactly what library is this calling? I found it in one of the VI's that comes with LabVIEW.

[rolfk]

Exactly what library is this calling? I found it in one of the VI's that comes with LabVIEW.

What the name says: LabVIEW. Basically LabVIEW exports a lot of so called manager functions that can be called from C code, such as when you write a DLL (or shared library on non Windows systems). A lot of those manager functions are described in the External Code Reference Manual which comes as part of the help files in your LabVIEW installation. The LabVIEW library name is a special keyword, that tells the Call Library Node to link to whatever the current LabVIEW execution kernel is (LabVIEW.exe in the IDE, lvrt.dll in a built app). Note the case of the letters, which needs to match exactly with the official spelling.

And before you ask, LabVIEW exports more functions than are described in the manual such as the one you found. Some are used internally by LabVIEW VIs but they are usually password protected. Sometimes one slips through the cracks. Most of those undocumented functions make no sense to be called outside of a very specific context, and some are rather harmful if not called in a very specific way. A lot of them are really only exported so that LabVIEW can itself use them as a sort callback and they make not really any sense to be called from a VI diagram.

[Aristos Queue]

It's no different than calling any other DLL. It calls into labview.exe in the dev environment and into lvrt.dll in the runtime engine. We could have made it always call lvrt.dll, but that would effectively make two copies of the DLL in memory. For the record, the reason that we export functions is so that we can expose VIs that call those functions, so pretty much all of those functions are exposed as VIs already in the palettes. Those that are not exposed as single VIs are part of other VIs. Calling things like MoveBlock directly are particularly dangerous since they arbitrarily overwrite memory.

[flarn2006]

Oh, okay. In case you're wondering, it was in a password-protected VI, so that makes sense. Hmilch's VI Explorer is awesome.

[rolfk]

Oh, okay. In case you're wondering, it was in a password-protected VI, so that makes sense. Hmilch's VI Explorer is awesome.

Is it? And what did you learn from this awesome look behind the curtains? Yes there is a function you can use to translate an error code into an error string. But the VI that you looked at does that already for you without the need to bother about correct calling convention, parameter type setup and a few other nasty C details. Not sure I see the awesomeness here, other than the desire to feed your own curiosity and find more ways to shoot in your foot.

[hooovahh]

Is it? And what did you learn from this awesome look behind the curtains? Yes there is a function you can use to translate an error code into an error string. But the VI that you looked at does that already for you without the need to bother about correct calling convention, parameter type setup and a few other nasty C details. Not sure I see the awesomeness here, other than the desire to feed your own curiosity and find more ways to shoot in your foot.

Just let him have his fun. It lets him feel like a leet haxor.

But seriously NI doesn't appear to have any thing to hide in those VIs, as demonstrated by this here.

[asbo]

For the record, the reason that we export functions is so that we can expose VIs that call those functions, so pretty much all of those functions are exposed as VIs already in the palettes. Those that are not exposed as single VIs are part of other VIs. Calling things like MoveBlock directly are particularly dangerous since they arbitrarily overwrite memory.

I'm curious (and maybe this is becoming OT) why VIs such as that which don't have much/any logic on the BD were just exposed as "native" nodes - no block diagram to even try to look at. Is there are a lot of overhead in nodes like that?

[rolfk]

I'm curious (and maybe this is becoming OT) why VIs such as that which don't have much/any logic on the BD were just exposed as "native" nodes - no block diagram to even try to look at. Is there are a lot of overhead in nodes like that?

I'm not sure what you are asking here. Do you want to know why NI didn't make a yellow node of this function? If that is your question I can think of a few reasons.
It's much easier to add an "undocumented" VI in vi.lib calling back into LabVIEW than adding a new node to LabVIEW. A new node needs an icon, help and several more resources embedded in the executable. That is a lot of work in terms of extra work, testing and verifying. A VI is added easily to vi.lib, can be adapted, tested, modified and documented by non LabVIEW core developers, and if the need should arise and it didn't get documented in the meantime, changed, removed and whatever else. Adding a private export of a C function only requires the expertise of the LabVIEW core developer who works on that code, not the expertise of several people working on various parts of the whole LabVIEW core.

A developer of a new tool in LabVIEW finding to need access to a specific internal data structure can either file a new proposal to add an (undocumented) node, and wait until the powers to be have decided that this is a good idea, developer resources have been assigned to work on that, and testing and documentation has had their say, or simply add that export to the exported LabVIEW functions, create a private VI to access it and be done. Sure such functionality might be an interesting candidate to turn into a node at some point, but chances are that nobody will look back once it's done and working.

So it's a shortcut to add functionality to LabVIEW that a new tool might require, without having to go through a hole bunch of modifications of the LabVIEW core itself. Since the password protection is now seriously broken and can't be used to prevent people to go into such VIs to shoot their own foot, they probably will change policies in the future and move a lot more into the direction of new (possibly undocumented) nodes, to expose such functionality. Undocumented, because once a function has been documented it can't really be removed anymore or even just modified, without a lot of hassle.

[Mr Mike]

Is there are a lot of overhead in nodes like that?

Yes. A new VI takes a few minutes to develop. A new node takes a few days at a bare minimum for the simplest node: type propogation, compiling, marking which inputs are in place to others, adding documentation, potentially marking which versions it's available in, enumerating each of the terminals, potentially adding properties and methods, maybe making it support different types (do you have any idea how many numeric nodes support clusters of numerics?), building the intermediate representation for the compiler, building the compiler code for it, etc. Plus all the time it takes to actually compile LabVIEW. Plus time to check for type-safety bugs (e.g. dereferencing null), save for previous, etc. LabVIEW takes care of all of these things for VIs.

We have a document for creating new primitive functions that is 12 pages long because there are so many different things you need to worry about. Creating nodes (which are more complex than primitives) is much harder.

[asbo]

Thanks for the replies, rolfk and Mr Mike. Had I thought it through a little more, that'd have been obvious. I'm glad to hear that the application process for nodes is thorough, at least. The VI approach, while less controlled, does make more sense in these instances.

[flarn2006]

Yes. A new VI takes a few minutes to develop. A new node takes a few days at a bare minimum for the simplest node: type propogation, compiling, marking which inputs are in place to others, adding documentation, potentially marking which versions it's available in, enumerating each of the terminals, potentially adding properties and methods, maybe making it support different types (do you have any idea how many numeric nodes support clusters of numerics?), building the intermediate representation for the compiler, building the compiler code for it, etc. Plus all the time it takes to actually compile LabVIEW. Plus time to check for type-safety bugs (e.g. dereferencing null), save for previous, etc. LabVIEW takes care of all of these things for VIs.

We have a document for creating new primitive functions that is 12 pages long because there are so many different things you need to worry about. Creating nodes (which are more complex than primitives) is much harder.

I'm curious about that document. Any chance I (and the rest of the community, of course) can see it?

Also, hooovahh, I saw your post, and I don't feel like a "leet haxor" just because of something small like that. Don't jump to conclusions.

[rolfk]

I'm curious about that document. Any chance I (and the rest of the community, of course) can see it?

I can't speak for NI and don't know that document, but I'm 99.99% sure that it has a big watermark across the front page, stating:

"Company Confidential".

Quite possibly this watermark is repeated on every single page. Besides of that it would be of no significant use to us LabVIEW users, as it refers among other things, to various places in the LabVIEW C++ source code, where specific provisions need to be added for the new node, the internal daily unit test framework run that needs to be enhanced to test the new node, the fact that the documentation department needs to be informed about writing a new help section for this node, and probably a few other things, that leave everyone not working in the LabVIEW team flabbergasted. And that document most likely isn't the most popular bedtime lecture of any LabVIEW development team member either.

In other words, if you want to see this document you will need to apply with NI as LabVIEW developer and hope to be accepted.

[Mr Mike]

I'm curious about that document. Any chance I (and the rest of the community, of course) can see it?

No. There is no chance at all that we'll release that. I will tell you that it's titled Primitives for Dummies and has at least a dozen pages.

I can't speak for NI and don't know that document, but I'm 99.99% sure that it has a big watermark across the front page, stating:

"Company Confidential".

Quite possibly this watermark is repeated on every single page. Besides of that it would be of no significant use to us LabVIEW users, as it refers among other things, to various places in the LabVIEW C++ source code, where specific provisions need to be added for the new node, the internal daily unit test framework run that needs to be enhanced to test the new node, the fact that the documentation department needs to be informed about writing a new help section for this node, and probably a few other things, that leave everyone not working in the LabVIEW team flabbergasted. And that document most likely isn't the most popular bedtime lecture of any LabVIEW development team member either.

In other words, if you want to see this document you will need to apply with NI as LabVIEW developer and hope to be accepted.

The only part you're wrong about is the watermark on every page. I should point out that the document starts with "Tremble young seeker for thou art entering a secret chamber in the LabVIEW shop of horrors."

I don't have much more to say about this except that we keep parts of LabVIEW private because they are not ready for use by the general public or even experimenters. If you want to experiment, I suggest you check out NI Labs. I think it's great that you want to experiment, but there are a lot of Bad Things™ that can happen. You can corrupt VIs and not get them back. Or the corruption may have no effect for a long time and then suddenly things start to break in unexpected ways. I'm not telling you to protect you or because I feel NI is threatened; I'm telling you because there's the potential to break things for you, and other people if you release tools that use unstable, unreleased features.