Rolf Kalbermatter

Not sure what you mean exactly. In terms of LabVIEW there are not many variations possible: Windows 16-bit: __pascal + __cdecl Windows 32-bit: __stdcall + __cdecl Windows 64-bit: __fastcall, 4 registers for first 4 parameters (shadowed on the stack) + remaining on stack Everything else uses whatever is the the system default calling convention (not sure about Mac 68k here). So basically only Windows 16-bit and 32-bit let you choose between 2 calling conventions, everything else was whatever is the platform default for them, usually either __cdecl or something with a number of registers and the remainder on the stack on RISC like CPUs such as Sparc, PPC, PA Risc and ARM. As to compiler supporting various calling conventions, gcc is probably the most varied. You can get into pretty involved things there depending on platform and version. MSVC also knows a few more than what is mentioned above, but they either apply to kernel driver programming or C++ programming.

Depends what compiler you use. Some are more difficult to force into compliance with your preferences than others.😁 All my DLLs are always cdecl or whatever the preferred calling convention is (Windows 64-bit abandoned with cdecl in favor of fastcall, and trying to force a compiler to do cdecl there, while possible in some compilers, is pretty much doomed for anyone else who is going to have to use that DLL). For Windows APIs however you can't choose, that decision has been made by Microsoft when defining the API. For user DLLs I don't see why anyone ever would have decided to go by stdcall, unless they use a programming environment that could not deal with cdecl.

I consider it ill advised since that name decoration is simply a Microsoft convention. Other compilers did in the past not create such names when linking a DLL. So as summary: 1) It's not mandated by Microsoft that a stdcall function should be decorated like that, but simply a convention by their linker. It's also not mandated that a non-stdcall function can't be named that way. 2) So it is not a mechanism to reliably avoid Call Library Node misconfiguration. 3) More importantly, it makes it impossible to call a function that was intentionally named that way but compiled as cdecl. Why would someone create such a function? Well, I have no idea even if you beat me, but obviously someone did, otherwise NI would not have removed that anti-foot-shooter hack.

There are posts on the NI forum about this, the earliest probably around 2012 or 2013 and I was involved in finding the issue. It's not so difficult when you look at a Call Library Node for a Windows API that crashes and then see that it is configured cdecl as there are virtually no Windows APIs with that calling convention except when they have a variable number of parameters as that can not be done in stdcall where the function itself adjusts the stack just before returning. Why would someone "fix" an anti foot shooting protection? Most likely because there was an important customer wanting to call a DLL that used that naming decoration for whatever strange reason, while it was explicitly compiled to use cdecl, and threatened to sue the poor support person taking their call and sending an assassin squad to the NI head quarter. 😁 And in all honestly it is an ill advised protection that should not be there. What is less nice is that this functionality was simply removed without some mutation code path when upgrading pre 2011 VIs with a Call Library Node to 2011 or later. Yes there are complications, the correction was apparently done at recompilation time by actually verifying the exported name (the Call Library Node doesn't require to enter the decorated name but does the according matching to the real exported function at that moment) so if the VI was loaded in a newer version with the DLL missing, it would be impossible to properly mutate the code, but it would have been at least possible to try to mutate the VI during loading into the new version if the original was older than 2011. As it is that ship has long sailed already and it is a moot point to argue about now.

Just one wild guess that recently bit me in another library. Does the SQLLite API in the Windows DLL use stdcall calling convention? Until LabVIEW 2011, LabVIEW had a "helpful" feature to second guess your choice of that calling convention in the Call Library Node if the exported function had the appendix @xx with xx indicating the number of bytes passed on the stack for the parameters. The calling convention was silently "corrected" to stdcall even if you had cdecl in the configuration. Once you move to LabVIEW 2011 or later, this suddenly crashes as that silent correction was removed without any warning. The correct way when such a feature gets removed would have of course been to mutate the VI when converted from a pre 2011 version to 2011 or later. However the person removing that paternalizing feature did not think about adding an according mutation code path in the InstrumentLoad() function. The thing bit me because I was developing code in LabVIEW 8.6 and had been also testing it in LabVIEW 2020 64-bit to be sure, wrongly assuming I had been accounting for a fairly large range of LabVIEW versions and platforms. Since LabVIEW 64-bit does not have any calling convention to choose from it did not expose that misconfiguration and someone else loading it into a newer LabVIEW 32-bit version found out the hard way that I had messed up. Never mind, I see it is 2025 64-bit LabVIEW so there is no calling convention to get wrong.

It is not that LabVIEW MAY unregister the reference, but that it WILL unregister the reference as soon as the top level VI in whose hierarchy the reference was created goes idle. This is by design and the only way to prevent that is to either keep that hierarchy active until any other user of that refnum has finished or delegate creating of the refnum to the place where it is needed, for instance through a LV2 style global maintaining the reference in a shift register and when being called for the first time it will create the refnum if the shift register contains an invalid refnum. True Actor Framework design kind of mandates that all refnums are created in the context of where they are used not some other global instance that may or may not keep running for the time some Actor is using the refnum.

Thanks for the feedback. Will try to check what the problem with VIPM 2026 might be. As to commercial information I saw that you have sent an email to info (at) citengineering.nl and will make sure that the person in question will respond to that.

Can you tell me more about what the problem is with VIPM? Which VIPM version is that? And what error if any do you get?

Thanks for your feedback. I'm not the legal owner of Lua for LabVIEW, only the maintainer. It is unfortunately not my decision how it is distributed/sold. But even if it was, I don't think I would actually open source it. But I would probably make it free.

I tried hard to ignore your poisonous whisperings but eventually succumbed to it. 🤫

Hey, I didn't talk about code! This was about advertisement and commerce. (And my lost privilege, which indeed hurts my sensitive soul a little 😁. It's soul crushing to read an old post of myself and discover typos in it.)

Are you seriously expecting anyone to install a random executable on their system from an unknown publisher, provided by an anonymous person on the web, where one can't even get a proper link in Google to the actual company page? Sorry, but anyone doing that should not be allowed near 5m of a computer system!

F*ck! 😁 And I lost my privilege of being allowed to edit posts indefinitely some years ago for unexplained reason. Ohh well! Not sure I care at this point very much. I just suck at commercial promotional stuff and am admitting it.

It's still maintained and sold, although not actively marketed. https://luaforlabview.com/

Not starting but want to try to do a cRIO variant of a few things such as the OpenG ZIP library, Lua for LabVIEW, and especially my OPC UA Toolkit.