Rolf Kalbermatter

I'm not sure but I don't think there is a good way. It may be possible in theory to use the Picture Control to display a PICC formated data stream and with lots of wizardry I'm sure it would be possible to store the PICC as a resource inside the VI itself and reference it from there but that would require so many hacks in the VI data itself that I would consider that a major work even for someone who has access to the complete VI data format specification. The OS clipboard likely won't work since it does not know about this type of format. Yes you can copy picc's between different LabVIEW objects over the clibboard and that is an interesting way to customize controls, but this is because LabVIEW maintains internally its own clipboard which knows about all kinds of internal formats including LabVIEW diagrams, paths, controls, and also PICCs, etc. but it does not transport those formats to the external clipboard and back but instead translates them to a format that the external clipboard officially supports, such as a bitmap when you copy a diagram and then try to paste that in another application including a different LabVIEW process. While on Windows the supported external vector image formats are WMF/EMF, on the Mac it used to be PICT which actually worked quite a bit better than WMF/EMF back then. Why not still use the PICC format? The code is there already, the internal control editor too (eventhough it badly needs some love). Adding another format like SVG may seem like a nice choice, but LabVIEW does not know about it so far, so it would have to be added, and it would not just be an importer/exporter but just about anything where PICC resources are used would have to be touched seriously. So basically anything in the frontpanel. Maybe if they decide to overhaul the control editor and make it a fully featured editor again, they would consider adding a new intermediate format like SVG but not vice versa. I also believe that much of the silver controls was simply done by using the control editor to create new custom controls, but I haven't looked at them yet. Still using classic controls everywhere for internal frontpanels and the system style for user interfaces almost exclusively. I feel the everchanging cry for newer, fancier, simpler, crazier, whatever controls is mostly hysteric. Whatever MS declares as the newest hit, people seem to want to have it, even if it hurts in the eyes.

Where would you want to take such a picc? This format was created by the LabVIEW developers for LabVIEW and outside of the LabVIEW development group exist no editors or such who can create this format. I used to use WMF images in the past. But most WMF editors out there where abominable to say the least, and created images that produced rather different results depending on Windows version and viewer used. WMF supposedly is a little better but also a somewhat niche format that most Microsoft applications do support but don't advertize, and only very few other applications claim to support but with varying results. I had some interesting results by using Powerpoint to create the graphics. However eventhough LabVIEW has some support for importing WMF/EMF from the clipboard, it can be tricky to convince Windows/LabVIEW to take this format rather than have Windows advertize an intermediate Bitmap version of the WMF/EMF file, which will cause LabVIEW to use that instead. However I can not comment on how this would work in recent versions as my experiments with this date from LabVIEW 3 and 4 times. I'm pretty sure that this functionality did not receive any face lift since at least LabVIEW 5 because it is in fact an almost never used feature by anyone and NI doesn't spend resources on unused features. And it just as much could have bitrotted over the years, and not work anymore or even be removed entirely.

Most likely because this was not humorously meant but purely logical.

As pointed out by others already, your car analogy has many flaws. For one you can't copyright a colour and even less so the right to change the colour of something. Copyright is about the right to copy something considered a creation in some form or the other. Except the design style, logo and such things there is little that could be copyrighted about a car. Patents is an entirely different thing again but even that is about copying something considered technical art in some form. Both do not apply to the fact if you can paint your car or not. A manufacturer could declare your warranty void or you could loose the right to do liability claims against the manufacturer, if he can make it reasonable believable that your paint job has caused the defect you seek warranty for, or the accidents you claim liabilities but nothing else. Software is an entire different beast. Most licenses, even open source, don't grant you ownership of the software, only a right to use it. It could be considered absurd, but then what ownership would you get? Can someone own bits and bytes, or the letters in a book? Do you own the letters in a book or rather just the paper of the book the letters are printed on? Are you allowed to destroy the book? Yes of course and so are you allowed to destroy the copy of the software on your harddisk or even the harddisk itself, as that is a material good you own. But you do not own the particular assembly of bits and bytes that makes up the software. For one thing because ownership means usually exclusivity but how can you own those bits and bytes exclusively? All material things can only be owned once at any particular time. A particular software exists unlimited times, so the classical property rules are very difficult to apply here. That is why all legal systems have rather adopted the copyright for distributed software than the property right, since many provisions of the property right simply do not apply to software programs at all. If it is a good choice I'm not sure, but adopting property rights instead would certainly not solve those problems but simply create others and possibly a lot more. As you get older you might find out that anything tends to have quantum mechanic inner workings, especially things that appear logically bipolar in nature. What is good and bad may seem very clear for simple minds, but if you go deeper you will find out that the decision about that is very relative and only really is made by the observer, but definitely not an universal police force called God.

Legally you are totally wrong. Nowhere in the license agreement does it say anything about "for profit". Also you may not do it for profit, others using the information you dissect to the public will! In some legislations NI could loose the right to seek payment of damages through the legal path if they don't go after all such activities, independent if it is for profit or not. How many bad guys get away nowadays pointing with their finger: "But he did it first and never got punished, so why should I be!" And the legal system in some places agrees with that logic. Depending on where you live, you may be indeed fairly clear, both because of legal laws in your place as well as being far out of reach of lawyers NI is willing to pay. However you may want to travel at some point and such activity could be a serious liability then. And using an alias in a forum like this is certainly no reliable way to hide your real life identity.

Could be the path glyph. Also they are not bitmaps but vector graphics. The LabVIEW picc format resembles the Macintosh PICT format in many things, but has a somewhat different binary data format.

I haven't really used .Net so far, other than converting some .Net code to Java! And creating a .Net binary module for LuaVIEW for a client in order that they could interface to .Net drivers from within our test application. But specially that last one forced me to learn more about .Net than I ever cared to know. Anyhow I rather write a standard C shared library from scratch than integrating .Net into LabVIEW applications myself.

What's so special about those pics? If you haven't noticed, they resemble many standard LabVIEW control components, just in a special colour scheme. Ever heard of blue screen stamping and such? Would seem quite logical to use specific colours to identify various parts of a control, such as background and foreground area!

.Net assemblies should not be placed in the system32 folder. The .Net loader will not pick them up from there. Instead they need to be placed in the GAC (Global Assembly Cache) or in the directory where the executable of the calling process is located. In the case of LabVIEW development environment, the better place is the actual project directory as LabVIEW registers that as well with .Net when loading a .Net assembly from within a project context. But if possible .Net assemblies should be installed into the GAC by an installer.

I wouldn't say I prefer it, but I have some fond memories off working on Valid and later Sun Sparc stations using a graphics editor called ged. This was used to design electronic schematics both for PCB and ASIC design. The displays were phosphor screens and had a very similar look. No draggable windows, but a fixed mouse controllable drawing area and a command line entry that allowed to edit the graphic design magnitudes quicker than any menu oriented interface. In fact QuickDrop goes quite a bit in that direction and as some people at NI expertly demonstrated really can be a big improvement in editing speed of diagrams. There was a text script configurable button menu bar on one side of the screen to help use the less common commands, but common operations were much quicker by typing them on the keyboard than trying to find the command in the fixed menu bar and even more quick in comparison to a navigable hierarchical main or even pop-up menu.

NI has in the 15 years or so that the password protection existed, revisited their semi-official response several times. Officially they never publicly committed to helping recover VIs with lost passwords. Unofficially they did make some efforts to help well known customers recover their own VIs, if they could proof reasonably well that it was actually their VI. As that could get easily into a legal and administrative nightmare, they seem to have more than once issued an ukas internally to stop providing this service altogether yet it seems to have surfaced every now and then again, if a customer knew the right person to contact. Supposedly that would be someone rather high in the command chain of NI management. It's not a bad advice at all! Removing diagrams is just about the worst you can do for distributing VIs. If you are not careful and keep several copies of your source code you can end up VERY easily with no source code at all. That I would consider worse than having the source code exposed to some unscrupulous people no matter how precious that source code is. If the source code is not important enough to warrant a %$#$%$#%#$%#$% comment when you notice that it is gone, you certainly wouldn't worry about someone "stealing" that source code, and if it is a multibillion dollar IP, then good riddance if you loose it! Also distributing VIs without source code requires you to provide one copy of the VIs for every (minor) LabVIEW version and platform you want to support. That is just about one of the bigger nightmares to happen in terms of maintenance and support.

I think that is what Ton meant, he just didn't use shell script variable names. And it is probably very much Windows AND VIPM version dependent. Mine is for instance in C:AppDataJKIVIPMdatabases (Windows 7) which would be equivalent to %COMMONAPPDATA%JKIVIPMdatabases. C:UsersAll Users actually shouldn't exist on a clean Windows 7 install, as that is normally called C:UsersPublic instead, but maybe you upgraded Windows 7 from a Windows XP installation?

The way I did this in the past is enumerating the entire contents of the diagram recursively, place everything into a selection, copy it to the clipboard, then pasting it from there into the new VI. Quite involved, and very easy to forget something, so if you do not need this to work with ancient LabVIEW versions, I would look for the Inline method, Darin mentions. Sorry I wouldn't know where it is as I haven't used that so far, but I assume it would be only in recent versions.

- Move is as the name says not meant to copy code around for one thing. - Also you make the mistake to try to copy a TopLevelDiagram into another TopLevelDiagram. For one thing a diagram can NOT contain a diagram but instead is an internal property of some other object, such as a VI or a loop, case or sequence structure. - Please also notice that there is in fact a difference between a TopLevelDiagram and a Diagram(Section) you can for instance get from a loop or for every case in a case structure. They are similar but not the same, since they are owned by two very different objects, as VIs existed before there was a proper object hierarchy in LabVIEW. For another thing I would believe it is there to move nodes around to another part of the same VI, not copy it to an entirely different VI. Clarification: objects existed in LabVIEW from at least version 2.0 internally and were used extensively despite LabVIEW having been programmed in standard C exclusively back then (all the C++ compilers back then were not up to the task of compiling a code base like LabVIEW without bugs and horrible performance of the resulting executable), but that object hierarchy was not exposed anywhere, and was not fully formalized, as C has no means to enforce any object hierarchy formalization and all had to be done by hand and agreement between developers. The first versions of VI Server around LabVIEW 4.0 only allowed access on VI level, and only around 5.0 was the VI server interface to the object hierarchy of frontpanel objects added and around 6.0 extended with what we know as scripting interface now.

It truely depends how good the cake is. If it is delicious I might also go for seconds. And I didn't mean variants to be the same as varargs, but it's the closest you can get to in LabVIEW. Unless of course you use LabVIEW objects as Vi conpane parameters, then you can truely put anything in the parameter, never mind that you might have to design a class hierarchy and accompanying code that makes Variant handling look trivial! As to typesafety I mostly consider it very beneficial. Sometimes it can be a bit hindering, but overall it is a real life saver for me. Maybe that is also because if I think I will need some truely horrible ways to be able to shoot in my foot, I usually go and write C code instead!

Not really. It also is in answer to some of your points, although yes it clearly is targeting also and even more so the points flarn makes. While it is unlikely that you will get into legal problems if you look at a VI diagram that was not intended for you to look at and if you only use that knowledge internally, without redistributing what you learn from it, it is still not legal to break the password at all. Forcing the door of a house is illegal independent if you want to steal something or just nose around for your curiosity (or find out what has been done wrong there in order to not make the same mistakes in your own house). If you or anyone else doesn't like the password protection of a VI, you should not download it or ask for a refund if you bought it, and cease using the VI and any accompanying software altogether, not breaking into it to use it anyways in the way you like.

I didn't mention PHP, but instead Lua. Lua is not interpreted but compiled into byte code, just like .Net, Python and others. I don't think it makes that much difference if a language is interpreted, compiled or byte coded, in terms of vararg implementation. Some have a more elegant way of defining it, some implement it in a truely hackish way (most vararg implementations in C used to rely in fact on some low level compiler features that went as far as inline assembly) and some chose to not support it to not give the user another way to shoot themselves in their foot. The most close vararg analogy in LabVIEW would be Variants. Ohh you say that it is a pain to implement and maintain such an interface? But so are all vararg type interfaces! In terms of typesafety, stack boundery handling and all that, you can't have the cake and eat it too!

Logically putting a password on a diagram is not that different than locking your house door. Can a locked door be forced open? Yes of course! Would you consider it rightful to do so? Probably not! Never mind that you would probably even find it very unfriendly if a stranger enters your house when you forgot to lock the door. The diagram of a VI is not your property, in fact it never can be (except maybe in some banana republic) unless you created it yourself or the original creator abandoned copyright explicitly. Putting a password on a diagram is the complete contrary of saying: Here is my diagram, do with it as you wish! and therefore breaking it is in fact just the same than forcing open a door to a house that is not yours. And to counter your possible argument that the Vi is on your computer and HD, if your house stands on some ground that is leased from someone, it is still your house and you would get furious and call the police if the owner of the land forced your door open to nose through your belongings.

But how could you define a super-abstract method and use it anywhere except in the implementor of that method (and possibly inherited classes from the implementor)? LabVIEW, C(++) and Java all have a parameter interface that is defined at compile time, so needs to be well known when compiling and therefore no one who doesn't see the full interface definition of a method can possibly use it. C allows some trickery with function pointer casting but that is not only ugly but outright dangerous. C++ is much more strict in that sense and normally doesn't allow function pointer casts just as Java, which doesn't really know anything about casting other than between compatible objects. Lua goes in fact into that direction, as functions are themselves full objects and can have variable number of arguments, with a function always knowing how many parameters it was passed to (and it of course shouldn't try to retrieve more parameters from the stack than it got passed, but the Lua engine protects that). In addition return parameters of functions are always returned as function return values and yes a function can have 0, 1, or any other number of return values too.

So if you happen to park your car (suppose just for a moment you have one, might not be true for someone who is 19) on my ground, I'm free to do with it as I wish? I really thought property right works a little bit different!

As far as I understand it, abstract methods always define at least the interface (parameter list) but what Jack seems to want is a super-abstract definition that just defines the method name without any interface. How that could possibly be useful I can't really understand as nobody can use this method, except the class implementing it (and possibly classes inheriting from the implementing class), so why even force the inherited class to implement a specific method? I use abstract methods in Java and C++, if I want to have a method that I can call from the parent class but which needs to be implemented by the inherited class, but for super-abstract methods that couldn't work since the parent doesn't know how to call it. So what would it bring me then at all? Another use of abstract methods is to provide an abstract parent class that defines a common method all children need to implement in order for any client of any of the actual implementation classes to be called. One could define an empty method in the parent that all children can override, but an abstract method forces the implementor of a child to provide a method implementation, while an empty method could be forgotten and then produces unnecessary errors. Maybe a more loosely typed language could benefit from such a concept, but LabVIEW, C(++), and Java only can use a function/method if the interface is fully known (vararg functions in C and Java being a somewhat special case here and rarely implemented by programmers outside the runtime libraries itself). Maybe you need to go with Lua then, where even functions are just another object!

Well in the same way you can of course argument that users do not want to pay for contents and software and therefore it is legal to crack software and put it on the street for free. However there are users who rather pay some money for something useful and also enjoy the added benefit to not download viri festered content that way (most crack download and password cracker sites contain nowadays mostly unhealthy junk if they even contain a single working crack of what they claim to do). And as Djed and James pointed out, the password protection is there because of user request, not to protect the few NI secrets they have (they are better protected by putting them in the 30MB of binary compiled LabVIEW executable code nowadays, and a few more 1000MB of compiled shared libraries). So which user do you want to protect with your password crack? The one who feels nobody has a right to prevent him from seeing a diagram, or the one who produces content for people to use, without wanting to throw all the details on the street. There have been numerous cases of people posting "their" own libraries on various LabVIEW sites, some of them copying open source VIs verbatim, others copying functions from commercial toolkits. If your position is that nobody has a right to hide his code from you you may have to live with the consequences that that code is not developed anymore for sale, but kept internally, so nobody can profit from it anymore. Well, why do you think someone being very much active on this forum and providing contents and answers should pay, while someone who mostly uses this forum to talk about how to hack the software the forum is about shouldn't?

Well, in all other languages you have only the choice to distribute the source code or binary compiled files, although .Net binary code is easily decompiled into very readable C# code if the creator didn't put it through an obfuscator and for most obfuscators there exist pretty good working deobfuscators already too. LabVIEW is not much different, except that it adds an extra password protection option, which is a bit between those two extremes. Obfuscation of the binary code is so far useless since there doesn't exist any working decompiler so far, unlike for .Net bytecode or CPU assembly codes. So you can say what you want, and correctly state that the password protection is not an ideal solution for a very sensitive code, however any form of distribution of that code will pose a certain risk and I would consider compiled C code not much more secure than a password protected LabVIEW diagram, and definitely less secure than a diagram removed LabVIEW VI. Does that entitle you to claim that password protection is unrightful and wrong? By no means! And does that opinion entitle you to try to circumvent that protection? In most western juridications in no way legally and morally you have to decide yourself! However your decision will certainly have influence on your professional merits.

Which would indeed require to wrap them instead of extending them. Wonder why they would be sealed. Seems to be the same as a Java class declared as final.

The person who wrote that cracker definitely had inside knowledge about the LabVIEW sources. I doubt he still works in a position that would allow him such access to checkout how the changed password check is done, so it is rather unlikely that he will be able to "fix" it.