Leaderboard

<sarcasm>What could possibly go wrong with this?</sarcasm>

I found a hack to remove the time limit to edit your posts, see here

And using a class instead of input fields doesn't work because.......

Your proposed enforcement is an illusion. Due to the code not having any interface representation it may never be executed. Not being able to compile a class just because of a missing VI prototype which is (quite possibly) never called seems seriously flawed to me. Your proposal sounds like my wife. She often not only wants me to do something (lets think of this as the interface) but she also wants me do do it her way (your enforcement) even though this has no bearing on the start or end status of the operation. I've never had the spontaneous idea that this was a good thing. When finished, if she asks me if I did it "her way" then of course the temptation is to say "Of course dear" event hough you know it's not true. If a class is in the position to do WHAT you want, why is it important that it does it your way?

That's the "She was asking for it" argument and says it all really!

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!

"So, I think your question indicates you're still seeing Implemented methods like a Dynamic Dispatch override." No, I get it. You're looking for a statically resolved link. The possible paths code could take is completely resolved when things are compiled. Note: I'm going to use the word "interface" a lot in this post, and I mean it as a general point of interaction between pieces of code, not the abstract sense which comes up in some languages that use it as a keyword, or in several theoretical discussions we have had here on lava. I guess for me dynamic dispatch isn't fundamentally about just changing behavior via overrides or producing concrete implementation. Sure, that's the mechanics of it, but in isolation is of very little value. A class that has any dynamic methods defines a programming interface at one level that derivative classes can modify or must implement. The value in such a mechanism comes when the programmer writes code calling the dynamic methods from the superclass interface-- completely unaware of any derivative classes. This code can be part of the superclass itself or completely separate. The code that operates on the dynamic interface at the superclass level is essentially laying down a series of hooks, detailing the conditions when these methods will be called and has done so completely decoupled from any derivative classes which may exist at run-time. I suppose if I'm going to boil it down to one sentence it is this: just as important as the dynamic dispatch method itself is the contexts under which the method is called. (You can at this point hopefully imagine how important I feel documentation is for these methods. I die a little inside every time I see an undocumented dynamic dispatch.) So that's why I'm not sure I understand why a "must implement" could be useful. You're basically saying if you're going to have an "is a" relationship with me, you need to do something(). But an interface can't be provided so you can't provide the context in which something() will be called. No code that operates via the superclass interface can do anything with something() due to the lack of this interface. The code requires direct knowledge of the derivative class, which has completely defeated the purpose of defining something() at the superclass level. I will concede one point though, a "must implement" will indeed provide a good set of clues as to what derivative classes should be doing. However I feel the inability to enforce anything beyond the mere existence of something with a given name means these hints really don't belong in code in my opinion.

Well. The adult way to go about it is to furnish NI with the exploit so they have the chance of evaluating whether they want to expend the effort in plugging it before you release it into the public domain. This would allow you to gain a moral position rather than just looking like a petulant script kiddie. Careers have been made this way and the skills are usually prized rather than punished. White hats and black hats come from the same milliners, however they are viewed and treated very differently both in the community and in the law courts.

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.

Resolution isn't that important for Iris recognition (labview can achieve sub-pixel accuracy and the relative proportions of the eye are quite large). Focus and noise is more of a consideration. Therefore it is important you don't buy a webcam with a fixed focus (mobile phones have auto-focus which makes them extremely useful, webcams don't tend to) You've probably seen the simple ones with the annulus (Find Circles) that do some distance measurements (Caliper), but you can achieve better than that with LabVIEW and detect the number and sizes of "dark spots" (Particle Analysis Report) and changes in color, shading and discontinuities (ROI Profile).

Softice is the tool of choice. However. There are easier ways that don't require "cracking" the file or finding the "branch".It's a bit of a moot point with regards to LV though. Most of the time it's just used to prevent critisism of messy diagrams and there are no real secrets hidden. If IP is the problem it's buried in the exe. So apart from the exercise or the challenge, there isn't a lot of point in cracking diagrams. You're better off spending the time going out and getting laid.