Rolf Kalbermatter

I personally find 2009 a rather steep step to go to. I still have projects that are maintained in 7.1.1 and I don't like to go through hoops to backconvert the code after each modification. I can look into the directory layout you mention. Can you point me to a document that describes the specifics and the exact problems this is supposed to solve? PortIO is as far as I'm concerned EOL. I don't plan to do any maintenance on that. It solves a problem that should be not even considered as a solution in modern OSes, and uses technology that is very unportable to other LabVIEW platforms, including 64 Bit Windows.

The recommended way to do what you want to do, without even having to issue VI server calls to open and size the window is to simply select under Windows Appearance in the VI settings the Dialog option. This will change various specific settings, such as Show FP when called and close afterward, modal state, disable scroll bars and a few other things. Especially under Windows, some of these properties are exclusive, meaning that if you enable or disable one of them you also disable or enable something else automatically, and LabVIEW can't even do anything about it. You still can execute code to size and place the dialog if you need to, but should try to minimize the number of programmatic changes to window style modifications as much as possible, as they can unset settings you made in the configuration implicitly.

This is a library implemented in C, that claims to implement the ONC/RPC protocol. It's old but fully based on the original Sun specs. This is a C# implementation and this and this are in Java.

You could save the cmd intermediate process creation altogether by directly piping into the (Mercurial) command line tool. And if you use the OpenG Pipe functions you could potentially even use the same single mercurial command line instance to issue many commands after each other through a pipe to the stdin and receive any response through another pipe from stdout. And your hunch that process creation is quite an expensive task under Windows is quite right. And doing this through CMD really doubles that. But unless you need to also access Windows shell features, such as its build in commands, or locating an unqualified executable name in one of the PATH directories, it should be usually not a problem to directly instantiate the target command line app, by simply issuing its fully qualified exe name as first parameter, leaving out the cmd \c step completely.

Not really. If you compare the typestring of an ActiveX refnum with another typestring of a ActiveX refnum it only is equal if both UIDs are the same. The class GUID is basically the whole class and the interface GUID is the actual interface implementation. If only the class GUID is the same, then it is not the same refnum type, but a different one (with usually different properties and methods).

Thanks for pointing this out. And no I haven't run the ZLIB library on every possible target that is out there. For several good reasons: 1) I don't have all that hardware available. 2) I do have a normal daytime job to earn my living 3) LVZLIB already is targeted at Windows 32 Bit, MacOS Classic, MacOS X 32 Bit (with some issues related to long path names), Linux, Pharlap ETS, and VxWorks and I'm working on Windows 64 Bit support too. Testing the library myself on all of these systems with many different scenarios is simply not an option. What I did in case of the RT targets, was simply to assume that the ETS Pharlap system should work with the same code as the Windows system. In the case of the VxWorks system I simply compiled the according .out file and asked people to test it, which it of course didn't to start with. Thanks to a very helpful engineer at NI who had access to the (rather expensive) integrated development system for VxWorks we could debug the issues, which required actually some significant changes to the entire source code framework to make it work for VxWorks. As to the path handling: Can you positively confirm that your change will work without issues on all the aformentioned targets? If someone can confirm this to me, it would be fairly easy to make the necessary changes to the library, possibly at a place that is actually less performance intensive, such as in the actual shared library code itself. Specifically the change to the path separator should be handled in "ZLIB Common Path to Specific Path.vi" instead. It also takes care of stripping the path from any trailing seperator. So the real fix is to simply use this VI. The VI in the SVN repository does this already and I changed that in April of this year, but for some reasons, your library doesn't seem to use that VI. I'll check what the OpenG library contains and if there is indeed some problem with having the latest source code in the package. EDIT: Ok I checked. 4.0.0-2 seems to be based on the old 2.5.1 source code and doesn't contain the fix to treat the Pharlap platform as Windows platform in the "ZLIB Common Path to Specific Path.vi". But the orginal code contains definitely the "ZLIB Common Path to Specific Path.vi" in the "ZLIB Extract All Files To Dir.vi" and the only thing needed to make it work for Pharlap platforms is to add the Pharlap enumeration to the case structure inside "ZLIB Common Path to Specific Path.vi" that handles Windows 3.1 and Windows 95/NT enumeration already. No need to handle directories and files differently as the LabVIEW Build Path primitive is smart enough to work for both correctly.

The code as posted in the diagram won't work at all. You can not emulate an embedded fixed size array in a cluster with a LabVIEW variable sized array at all. Instead you have to use a cluster which contains the same amount of elements of the same datatype, to match the fixed size array. So a GUID is really a cluster of type { uint32,uint16,uint16, {uint8,uint8,uint8,uint8,uint8,uint8,uint8,uint8}}

This is a smart implementation but I personally would feel a little concerned about creating a potentially large XML string to get such an information. The solution from the original poster had one big problem that it only really checked for the refnum to be ANY ActiveX refnum. It should have gone further to not only compare two elements from the typestring but in fact 23 (possibly even 27 but I'm not sure those additional 4 words provide any meaningful information). Basically the ActiveX specific typestring description contains a 0x3110, 0x0, 0x4, <16 bytes for the ActiveX Class GUID>, 0x0, 0x1, <16 bytes for the Interface GUID>, and then some other stuff (usually 0x0, 0x1, 0x0, 0x0). It's quite possible that the constant numbers could change with different ActiveX refnums, but my own testing seemed to indicate that they stay the same for several different ActiveX refnums, and quite likely are really the same for the same ActiveX type. To be really right the higher significant byte of the 2nd value of the full typestring should be masked out, as it contains LabVIEW private flags about the control the wire comes from.

That's not scripting but an intentional feature when properties were introduced. There isn't much else you can do on a running VI if it's not done in a control as data change.

I'm not sure how this stuff is implemented, but could it be simply so that the according license file is added as a resource to the executable? In that case it should be possible to hack the resulting LabVIEW executable to include this resource in its resource directory. Finding out the resource type and ID would then be the only challenge left to do.

If you happen to include the VISA runtime installer into the application installer you have to make sure to also add the NI-Measurement & Automation Explorer in the Additional Installs settings. DAQmx allows to select several different Install Types with most of them including MAX. VISA runtime only contains the runtime but at least in newer LabVIEW versions you can select MAX as an extra component.

There is the hardware limitation for sure. A device oriented USB connector should be a USB-B connector not an USB-A connector. I haven't seen a single computer hardware with USB-B connectors so far. Electrically there is not really any difference but the software stack is again different. I'm pretty sure that it would be possible to write a USB device stack for XP but that involves going into kernel mode. Maybe, just maybe, it could be possible to emulate the device stack in user space on top of a library like libUSB or the native Windows USB device driver API, but that only would alleviate the device driver debugging issue, not the whole trouble of implementing a valid USB device stack.

Your reasoning mixes again two rather unrelated things. That of hacking password protected VIs and that of hacking the LabVIEW license. For both you do need to to dig into disassembly if you don't want to go the brute force attack through GPU path, but they are not directly related to each other. I haven't looked at the details for some time, but from what I saw earlier the license generators you could find were always tied to very specific LabVIEW versions. I think the license technic hasn't changed since about LabVIEW 7.1 so it might be possible to generate a key generator that works across versions, but I don't know. I'm not sure if there is a single person who knows how to open password protected VIs in all possible LabVIEW versions, but I'm certain there exist people who can open password protected VIs in certain versions of LabVIEW. And they don't work for NI, as NI has of course the ability to work on the source code directly to circumvent such protection. This means, don't trust your super secret 5 million dollar idea to password secured VIs but also don't expect or require NI to provide such a possibility. It is technically simply not feasable to create a really secure protection without at the same time throwing away the advantage of not having to remove the diagram and making a VI only readable in the specific version and platform it was created in.

It's a violation of the license agreement indeed, though I doubt a hacker feels much bothered by that . The other issue is that you need to do disassemble and that is not trivial. It is made extra hard by the sheer size of the LabVIEW executable nowadays. Even a very good disassembler takes a few hours to get a raw disassembly for such a huge executable. And then you can sift through million lines of assembly code to find the places where the MD5 hash is checked. And looking at assembly for even a 100k DLL is already a rather boring job. The fact that every half year a new executable is released makes the task even more hopeless. So while I'm sure there exist hackers who have hacked one or two versions of LabVIEW to that extend they really won't keep on doing that over the years as the gain of this is minimal. There is very little you can really see from most password protected VIs. Bragging rights don't apply because if someone does that, he might get a cease and desist letter or even worse, signed by the legal department of NI. I have at some point looked at the possibility to simply modify the VI and that seemed just as hopeless. Especially with VI libraries involved, which contain also a password whose hash is even out in the clear in the library XML code. And those passwords even seem to be interwoven with each other. As to the licensing. I believe there exist Key generators to fake-license LabVIEW installations. Never mind that most of those key generators have also some stealth load inside, that packs a few viruses and/or troyans on every computer they are executed on. After all why should a hacker who doesn't respect intellectual property respect someones privacy?

In order to deal with LabVIEW Variants on the C side of the fence you need an API that exists but is undocumented so far for people not working at NI. LabVIEW Variants are really C++ type objects so with just flattening or whatever you won't get far. And the way to pass variants to the Call Library Node is not as Interface To Data but simply as LabVIEW data. So any of the other three options though it won't really make any difference which you chose as they don't apply to data other than arrays or handles.

Where does the licensing scheme even remotely touch password security of VIs? Anything license related is really handled in the LabVIEW kernel itself so not sure what the ability to unlock a password protected VI would do there. Following is not directed at you Shaun but at anyone being high in the arms about the insufficient protection password protected VIs give them to protect their oh so precious IP: Password protection of diagrams is not meant to protect your IP. There exists only one really secure way to protect your IP, and that is to put it in a heavy steel safe, destroy all copies of your idea and dump the safe in the North Pacific above the Mariana Trench. Save of some alian race with super high tech, nobody will be able to get at those secrets. Chances are however high that someone else has already developed the same idea independently and will go to market with it and earn some money with it. Another slightly less secure means is to hire a whole army of lawyers who will involve anybody into a legal battle who might even just appearing to try to steal that IP, so that they can fight for the rest of their life, robbing them of any time to invest into monetizing the stolen idea. Both of them are highly unpractical and costly! Get over it and accept that password protection of diagrams is only to keep out the nosy. If you do need to protect your IP don't distribute the source at all! Bite the bullet and remove at least the diagram. Yes it's inconvenient as such VIs can only be loaded into the LabVIEW version in which it was created and also only on that platform but anything else means LabVIEW has to be able to get at the diagram somehow without knowing the password (or worse yet store the password in the VI somehow too) and that also means that anybody with enough determination will be able to circumvent any kind of protection the LabVIEW developers can come up with to prevent others than LabVIEW itself to get at that diagram. I think the best long term protection in that respect is actually the semi annual release cycle of LabVIEW as it obsoletes any of the more promising hacking solutions each time.

I have used in the past HelpMaker from vizacc.com. It used to be a free tool but there was some hickup in who is going to maintain it some time ago. Not sure about the current state, it got confusing and I haven't used the tool in a while.

I'm not sure this is turned off by default, but I don't like autoinserted feedback nodes at all. Yes they are equivalent to shift registers, (since about 8.5 even in performance) but I prefer the more familiar shift register added explicitedly by myself than an automagic feedback node that is in my case in 99% not what I want.

Occurrences work a bit more complicated. I have to admit that my memory is a little foggy about the exact details of this, as it has been several years that I struggled with this for a rather complicated infrastructure, involving use of occurrences also in external C code. But from what I remember, once an occurrence has triggered it is in the set state (to use a more common concept of ResetableEvent as analogy). When a WoO executes for the first time it looks at the state and when ignore previous is true it will USUALLY wait even when the occurence is currently in the triggered state. When it is false it will just continue when the occurrence is in the triggered state. In any case when WoO returns without timeout it will reset the state of the occurrence for this instance of WoO only. Next time around this WoO will use its local state to detect previous triggers when ignore previous is false. Other WoO instances will not influence the behaviour of this WoO in respect to detecting previous triggers. But a specific WoO can only wait once on a trigger eventhough you may have ignore previous set to false. What I encountered sometimes was that the occurrence could get triggered the first round around even when ignore previous was true AND the trigger event had clearly occurred before the wait executed. My solution was to use the occurence as an indication that something might have happened and when WoO returned without timeout to actually check for the data to have arrived and if it didn't so far treat it as timeout anyhow, usually looping once more for an event. This was back in LabVIEW 6 or 7 days and I have since always used occurrence in a way that was tolerant to this behavior. At first I considered it a bug of the occurrence but some discussions let me believe that it was an artifact of concurrent programming that can't be completely avoided and use of this should always be prepared for this possibility. NI might have changed something in the occurrence handling since and it may not behave exactly that way anymore, but I wouldn't really notice as my implementation is tolerant to the old behavior but of course won't break on an improved behavior of the occurrence. As to a case where occurrences have an advantage over the other asynchronous objects in LabVIEW: If you want to be able to trigger an event from external C code the only native LabVIEW objects that are to my knownledge available for this are Occurrences since LabVIEW 3 or 4 and User Events since LabVIEW 7.1. None of this is well documented but there are for both semi offical NI examples floating around. Wait on Occurrence had that as long as I can remember. (But my long term memory is sometimes a bit fuzzy so it may not have been there in LabVIEW 3. It's definitely there as far back as LabVIEW 5.1, I just checked. ) Using (undocumented) LabVIEW manager calls, one can create dynamic occurrence refnums. I have done so in the past for a data logging application, giving every single channel tag its own occurrence so clients could wait on value changes easily. Worked like a charm even for several 100 channels. All the LabVIEW refnums created (except those created by the LabVIEW manager calls directly unless you use some other manager calls to register those refnums for automatic cleanup) are suspectible to automatic cleanup on termination of the hierarchy that created them. So they do get cleaned up eventually. Static refnums vs. dynamic refnums has always pros and cons on both sides. Try to execute Create Occurrence in a loop to create several occurrences for a varying number of objects. It won't work as expected. So while dynamic refnums do require extra care from a programmer to properly cleanup after use, they also offer much more flexibility. For the same reasons you could vote that string constants should be static to avoid a LabVIEW user creating memory hogs by wiring it to an autoindexing loop boundary of an infinite loop. But that would possibly render LabVIEW even turing incomplete as you could not deal with a lot of common situations anymore. Yes notifiers and occurrences are similar but a notifier can have a data item attached to it, while an occurrence only carries the notification event itself.

On a sidenote on this. I just noticed that the luaview mailinglist at luaforge was shutdown as part of the downsizing of that site to a mostly static project directory. Do any people here have recommendations for a mailinglist provider, that we could use for a replacement? Until we have something else in place as a public mailing list the email addresses luaview-info(at)citengineering.com and luaview-bug(at)citeengineering.com can serve as an intermediate solution, but I would prefer to have a public accessible mailing list for the longer run. Running our own forum solution is unfortunately a to heavy-weight solution for such a project .

Occurrences are the underlaying functionality of all LabVIEW asynchronous operations. However they have a few limitations in itself. 1) They don't allow for any data to be associated to them 2) They have somewhat confusing semantics 3) You can get a triggered occurrence from set occurrence invocations that happened before the wait occurrence was called even when ignore previous is true. This can be worked around easily by checking for the actual event in some other ways and reentering a wait if the event wasn't really true, but one needs to be aware of it.

I don't think a wire stores any data in LabVIEW. However you may want to look into custom probes. They basically do what you want, though you have to place them manually (well maybe scripting supports them too :-) )

You didn't happen to go from one platform to another? Remember Windows 32 bit and Windows 64 bit are completely different platforms when compiled code is concerned and CINs are simply compiled object code. Change between Mac, Windows, Linux and VxWorks are anyhow different platforms. As long as you stay in the same platform, CINs should still load fine in LabVIEW. However I don't beleive CIN tools have been ported to Win 64 Bit so don't expect to be able to create CINs for that platform. To port a CIN you would anyhow need the source code as you need to recompile it. Even if they wanted they couldn't. The actual CIN is just as different as a DLL for different platforms. There exists no good translation to convert a 32 bit DLL to a 64 bit DLL, that I would know of. The solution is to take the source code and recompile. Without source code it's a though cookie.

It's a bug in the sense of a user error. It's not really a bug in LabVIEW itself as it does perfectly right what it is supposed to do.

Yes I do happen to know about LuaVIEW and its future. We haven't yet defined an exact timeframe of when and what things will happen, but expect LuaVIEW to be maintained and even improved in the future. A few things in the pipeline though no promises they will all be released: - Fix some minor errors in newer LabVIEW versions with the unit tests - Make the LuaVIEW core a shared library instead of a CIN - Provide direct VISA and .Net interfaces in LuaVIEW from a script - Make it's distribution VIPM compatible - Get it Lua 5.1 compatible - Add additional targets (x86 Mac, x64 Mac, x64 Windows, possibly cRIO VxWorks)