Rolf Kalbermatter

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.

Such a check is definitely not any significant cost in comparison to anything else necessary when opening a VI. As it seems, the performance bottleneck currently is in the maintenance of the linked lists that hold the project/library/class information as evidenced by those complains that seem to show a terrible slow down when opening a VI that is part of a several thousand VI hierarchy project in comparison to opening the same hierarchy outside of a project. It's not to surprising as the project needs to maintain dependency information for all the VIs in it and walking those linked list tables takes time and needs to be protected too from concurrent access to avoid inconsistencies. The password tamper check reads a few hundred bytes from the already opened VI resource (LabVIEW needs to open and load that file into memory no matter what) and then does some MD5 and possibly other hash checks on it, and that costs a LOT less time than walking the linked list even a single time for any non trivial project. As to the request for creating a new password cracker: be my guest! I'm not going to spend any time on this, as NI will and does have to modify the password check at least every time they get aware of the availability of such a cracker and even without such knowledge likely will change it every now and then just for the fun of it, to pester whoever may have made such a cracker in private.

Or it could just as well be true! In addition to making the password hash algorithme more complex they could in fact have added some password tamper checks to the opening of a VI altogether. Before the password protection was only checked when you tried to open the diagram, now there might be a check in the VI itself, when opening the front panel, not requesting a password entry but still failing completely for a tampered password, to prevent opening the VI altogether when the password hash is not consistent anymore.

Wouldn't the System.Threading.AutoResetEvent and System.Threading.ManualResetEvent objects be similar, although in my opinion better known? And again they do not support an inherent data transfer but that could be of course added easily with subclassing.

Or you go for a laptop with quite less than 150dpi! But yes the 1920*1080 starts to get the standard by now since everybody produces those displays and they are getting cheaper and cheaper in comparison to the rest. Personally I find them very awkward on Windows (not yet Retina style resolution, which Windows can't handle anyways, but also not a comfortable dpi resolution below something like 23 inch). And I'm not sure how the GDI based Windows graphic system could really be adapted to support true retina operation.

Wow James! How should we know that csrc=0x21 means a boolean? Of course now you have said it, I remember the typecodes of the typedef data, but would never have come on my own to this conclusion. Also is it just a problem with booleans on the conditional terminal or the conditional terminal in general? With booleans I could live easily as I usually would use bitflags anyhow for such applications.

You might have to make sure the instrument driver properly terminates all send commands with CR, LF or CR/LF depending on your instrument for it to work over RS-232. On IEEE-488.2 there is a specific handshake line to indicate an end of message, and most instruments support that by default (unless they are from before 1980 or so). On RS-232 there is no such way to indicated the end of a command, so this needs to be done with a specific character sequence, which is device dependent. Almost all devices offering GPIB and RS-232 options, will accept the additional character sequence without any trouble on GPIB messages too. Also make sure you initialize the VISA sessions to terminate all reads on the last character of your device specific termination character sequence. That can be done through properties in your initialize VI. Usually instrument drivers that are properly programmed for multi-interface operation, do read the "interface type" property and do a few additional configuration settings in case of serial interface, such as the "terminate on read" setting, but also baudrate, bitlength, stopbits and partity which are important for RS-232.

At the time I had started with this (LabVIEW 5) there were no shared variables (and when they arrived much later they had a lot of initial troubles to work as advertized) so the only options were to integrate some external code or DIY. An additional feature of my own simple TCP protocol is that I could fairly easily add support for other environments like Java on Android without having to wait for NI to come up with this, if they ever will. Of course I agree that it is probably a very bad idea to mix large high latency messages with low latency messages of any sort in the same server, be it LabVIEW or something else. They tend to have diametrical requirements that are almost impossible to solve cleanly in a single design. Using clone handler VIs does allow to alleviate this limitation but at some serious cost as each VI clone takes up considerable resources and it still complicates the design quite a bit when you mix these two types in the same server. Also using VI clone handlers involves VI server and the potential to get locked up for extended times by the UI thread/root loop issue. And shared variables are not the contra-proof to this, I wouldn't consider them really low latency although they can work perfect in many situations. So yea if I would have to start again now I might go with shared variables instead, although without DSC support they still have some limitations like real dynamic deployment and also the aforementioned event support, but that last one is not something my own TCP based protocol would offer out of the box either. I wouldn't go as far as declaring that as pointless, but it is a limitation of course.

You need to close the Notifier refnum wherever you want the consumer loop to shutdown. That should be enough to make the consumer loop exit on the resulting error. You may have to work a little on the Get Notifier Status inside the case structure. The current example mixes in fact the actual notifier event with a means to detect if the inner loop should terminate. I personally would remove this and the inner loop completely unless you really want that loop inside the consumer to execute as long as the switch is on.

My understanding of this is, that this is actually fully ok. Especially since it is LGPL and you are not really linking hard to the executable at all. In fact most people would think that even calling a GPL executable in such a way would be fine, but some puritans claim that any form of linking with GPL makes your program GPL too, unless there is a specific exclusion clause like with the Linux kernel. I personally would never distribute an application that makes use of GPL components in any way, without making everything GPL, just to be save even-though I believe that calling a GPL executable through SystemExec or such should be ok. Strictly speaking if this was not ok, one could not install a GPL application on a non-GPL OS since the act of double clicking the executable links that executable to the OS too, so the launcher of the application would make a GPL violation if he starts the application on a non-GPL OS. You would have to distribute the LGPL license text somewhere with your installation and preferably also some notice to what part that applies to as well as where one can find the source code (project website is enough) and what version you were using if the executable doesn't allow easy identification itself.

Actually as the original copyright holder you are entirely free to give it to NI and sell it too, unless you give it to NI with a clause in the license to the contrary. If it would be a commercially useful exercise is a completely different story, but legally you own the code, and most likely would simply allow NI to use it too and distribute it with LabVIEW, not to pass ownership of the code to NI.

Well when I was talking about polling I didn't mean the server to poll the clients but rather the old traditional multi client TCP/IP server example that adds incoming connection requests to an array of connections that is then processed inside a loop continously with a very small TCP Read timeout. Polling is probably the wrong name here. Unlike the truely asynchronous operation with one server handler clone being spawned per incoming connection, this solution simply processes all incoming data packets sequentially. While this can have potential problems in response time, if there are large messages to be processed and/or many parallel connections needing to be served, it completely avoids any root loop issues as it is not using any root loop synchronized LabVIEW nodes. I have done several applications with an architecture based on this scheme and aside from some race conditions in handling TCP Reads with low timeouts in LabVIEW 5.0 that could crash LabVIEW hard this has always worked fine, even with several parallel connections needing to be serviced. One architecture is based on a binary data protocol similar to the CVT Client Communication (CCC) Reference Library, the other is using in fact HTTP based messages that allow to even connect to the certain subsets of the server with simple web browsers also supporting user authentication for connections.

What is so bad about a polling server? Do you foresee dozen of clients connecting to the server at the same time and loading it with large messages to be processed and answered? Otherwise a polling server can work quite well. If you really need to do potentially many simultaneous connections at the same time you might have to rethink your strategy anyhow. LabVIEW is not the ideal environment for heavy load network servers and even in C it requires some very careful programming to not run into thread starvation, and/or process creation overload in such situations. The Apache webserver uses some very sophisticated and platform specific code paths to allow handling many simultanous connections at the same time, most of which is not directly portable to LabVIEW.

Most likely since it was added as a quick hack by someone from NI, to be used in a tool, that did not need to run as build executable. The person doing that 1) either didn't think it was useful in a build app 2) wasn't sure there might be certain implications in a build app, that might require extra work for this to work properly 3) made a mistake when adding that property so it does not work properly in a build app 4) or there may have been even some brainstorming and some very bright guys in the LabVIEW developer group identified at least one reason that this feature can't be working as intended in a built app without a lot of extra effort, and so the feature was intentionally disabled for build apps, and that might also be the reason that it was made private, since it is in fact an unfinished feature.

I think you need to distinguish a few things. First root loop and UI thread are close related but as far as I'm aware not exactly the same. Then not everything in VI server is blocked by the root loop, but Open Application and Open VI Reference surely are and any property nodes that operate on UI elements are executed in the UI thread. Once you have a VI reference open and can keep it open you should be able to invoke the VI remotely with Call by Refernece without blocking. Not sure about the asynchonous Call by Reference though. Do you see problems with the synchronous CbR or are you trying to do other things on the VI and application reference?

It depends on the type of GPS device you are using, but most civil type GPS will only be accurate to about 50m, and that can get less depending on weather conditions such as clouds or rain.

Aside from any encoding issues, it would be enough to change the line: System.out.println(b);[/CODE] [font=arial,helvetica,sans-serif]to[/font] [CODE] System.out.println((char)b);[/CODE] [font=arial,helvetica,sans-serif]The first invokes the println(int number) method, while the second invokes the println(char character) method. This of course will only work for ASCII characters up to decimal code 127 which LabVIEW should be normally generating, unless you use foreign language characters in the format specifiers itself.[/font][font=arial,helvetica,sans-serif]If you need proper character encoding too, you would have to wrap the input stream into an input reader of some sort.[/font]

You will need some ground reference somehow (so two wires at least) and also some biasing of the signal with a resistor to pull it to the passive level. Otherwise you can't measure an open collector signal properly. The cheapest will most likely be one of the USB DAQ boxes.

Well the name of the Windows DLLs has not changed between 32bit and 64bit Windows just because they wanted to avoid to having to change all DLL names everywhere when referencing DLLs dynamically by name. The 32 in the name is a left over artefact since all these DLLs also had the same name without 32 in Windows 3.x. Back then when moving to 32 bit architecture the MS developers chose to use a distinctive name to avoid name collisions. When moving to 64bit, MS decided to use different base directories instead and leave the DLL names alone. So VIs accessing system DLLs can work both on 32bit and 64bit Windows but you need to be aware that some parameters can actually change in size. For instance any HANDLE datatype (almost every WinAPI datatype starting with a H) is a 32 bit entity in 32 bit Windows and a 64 bit entitiy in 64 bit Windows. So the right data type to use for such parameters is the (unsigned) pointer sized integer. If you use a normal 32 bit integer it may still work on resource constrained systems but will sooner or later fail badly when your system has more memory and the value of handles can go above 4GB address range. Same for any pointer that you decide to treat as integer type for whatever reasons and there are also a few other Windows datatypes that can change bitness.

While ActiveX has the feature to also launch the application server there is no reason why you can't use the TCP/IP interface, and I'm pretty sure they do that for multiplatform reasons. You simply have to first launch the executable with System Exec yourself. The entire VIPM stuff is likely a bit involved and complicated, enumerating the installed LabVIEW versions from the registry, finding their install path, reading (and possibly manipulating) the according LabVIEW.ini file to find out the TCP/IP server properties and then trying to connect to it and in case of failure start it with System Exec and try again to connect. But it's all doable although the details about timeouts to use when trying to connect can be a lot of trial and error.

The most likely reason for this is that the concept of Recycle bin is not very consistent across the different platforms LabVIEW runs on (Windows, Linux, MacOSX) and works quite differently. Also technically the Windows Recycle Bin is in fact a tacked on feature to the actual Windows core, residing in the Windows shell component which is a very chaotic collection of interfaces, both COM and procedural oriented and shows that many people have added functionality over time with VERY different ideas of how to do it. There is no central authority making sure those interfaces are consistent nor interoperable, as every product division seems to have added their own gadget with their own preferred architecture into it. Also these interfaces often chance in incompatible ways between OS versions, with APIs being added, depreciated, changed and even removed at will.