Rolf Kalbermatter

Actually as far as the functions are concerned that do not use any callback pointers you can also call the original DLL directly. A DLL, unless it does some nasty SxS (side by side) loading voodoo, does only get mapped once into every process space and any module (DLL) inside that process referencing a DLL with the same name will have the function pointers relinked to that single memory space. While the method of Shaun to only implement the callback function in your external DLL will work too, it requires you to do a LoadLibrary() and GetProcAddress() call for that callback function. Personally I would tend to wrap the entire function needing a callback parameter into a second DLL.

It's not meant to be a discouragement and I would be definitely trying to help with advice for the more low level difficulties, but I have no time and resources to substantially contribute to and drive such a project myself. If I would start this seriously, it would be out of a project for which we need that and that would almost automatically mean that it could not be provided as open source without a lot of hassles.

It's an interesting idea but also one which requires a lot of work to get to a point that is even remotely useful. IMAQ Vision isn't just a small collection of C functions gathered together but a pretty involved function library and at the same time lots of supporting glue to put those functions in an easy to use way into LabVIEW without sacrificing performance in a big way. OpenCV would probably be the library of choice for such a project. I've been looking into it to make some DLL interface that integrates OpenCV in an easy to use way into LabVIEW. But OpenCV also has a legacy with an old style C interface and a more modern C++ interface and I have found that not every functionality is equally available in both. That makes a generic interface to LabVIEW more complicated as you need to provide different datatypes for the different functions. Creating OpenG interfaces to Halcon, Sherlock, Matrox, Keyence, etc, is probably not very interesting for a larger audience. These softwares are expensive, with strict license control and totally out of reach of most non-commercial developers and even many commercial projects. Whatever you decide, it's a serious undertaking to get something like this started and even more work to get something usable up and running.

What doesn't work for you in the library that is provided in the LVSpeak link mentioned earlier in this thread?

The reason there isn't is that it is usually not necessary. Binding a client socket to a specific network card address is basically a fix of a problem that should better be resolved in the routing configuration. For generic clients like a web browser you can't usually specifiy to bind to a particular network address either. It requires from the end user knowledge about the network configuration on his computers that you want to avoid whenever possible. If the routing tables are correct and the subnet ranges for each network adapter configured properly the packets should be routed to the right network adapter based on the destination address. If you have overlapping subnet ranges and those network cards are not logically connected to the same network you will of course run into problems that the routing may choose the wrong adapter. Same about if there has been set up a to large subnet range for a network adpater. It may capture all the packets that should really go to the default adapter. Depending on the network card driver Windows may have trouble to determine that a specific adapter is not connected at all to any network and may still use its configuration in the routing of packets making them land in the adapter queue but because of the disconnected state they will never leave the computer.

I would guess a configuration issue in the network stack. The LabVIEW function calls into WinSock which then will query the DNS resolver to return the TCP/IP network name. The WinSock provider works with internal timeouts when quering other services such as the DNS resolver. There is no easy way to influence those timeouts from a WinSock client. The .Net function most likely calls GetComputerNameEx() which queries some information in the registry that is usually updated with some largish interval in the background.

LabVIEW can in principle create ARM code for the crosscompilation to the ARM based NI RT RIO devices. But that doesn't work on other ARM targets easily. For one it must be an ARM Cortex A7 compatible device. And you need the LabVIEW runtime library for NI Linux RT which is technically not trivial to get running on a different target and legally you need to buy a runtime license from NI to be allowed to do that. Also it doesn't use Windows at all but the NI Linux RT OS which you would have to port to that board too. Supposedly the guys from TSExperts are working on a version of their cross compilation toolchain that is supposed to work for the Raspberry Pi device which is also an ARM based embedded board. I have no idea how they get to create code from LabVIEW to port to those targets but would assume they make use of the LabVIEW C Code Generator module which has a hefty price tag. What their license deal with NI might be I also have no idea, but I don't expect this to be standard procedure. So in conclusion, it is not a clear no as tst put it, but for most applications still not a feasable thing to attempt. To the OP: The Windows 10 version running on the DragonBoard is not a normal Windows version as used on your desktop computer but the Windows RT kernel which is also used for the Windows Mobile platform. This is a Windows version build around .Net technology and does not provide any Win32 API but only the .Net API. Also it is typically not compiled for the x86 CPU but for some RISC based architecture like ARM. LabVIEW for Windows definitely can't run on this and never will since it's interfacing to the Win32 API and is compiled for the x86 CPU.

I'm not sure how that code being LGPL would change much in that respect. The required knowledge remains the same and LGPL doesn't prevent anybody from modifying code and relicensing under LGPL (or even GPL but nothing else really) or simply request commit access to the repository and add the change to the code with a nice copyright line added in the head of the file. I might agree or not with the quality, or method used in that change and being still active might ask the person to reconsider certain aspects but other than that, there isn't really anything wrong about that. Even better would be of course to first consult me with a patch that can be cleanly applied. And if we are at it and somebody is just now digging out his patches, which he has worked hard for, he or she could also mention what license they would prefer to be applied to that contribution. In all those years I haven't really received any request for any of those libraries that contained even one single line of patched code that could directly be applied. The only thing that I received occasionally were bug reports often with very little technical details, and I don't think this would change in any way with another license. Most likely I could put it in the Public Domain and except that someone somewhere might use it to create his own product and try to sell it as his own, nothing would change. It might actually already have happened but then I hope they feel at least some form of guilt.

I did a rundown of the projects which I have provided to OpenG and which contain shared libraries which are still under LGPL: lvzip: Contains ZLIB and Minizip sources and sources developed by myself. ZLIB uses the ZLIB license which is actually more lenient than BSD as it does NOT REQUIRE attribution but only inclusion of the ZLIB license text (which may not be removed from a source distribution). Minizip is somewhat unclear, there is a readme stating it uses the ZLIB license but there is also a license text in the unzip.c file refering to the InfoZIP license which is in fact more or less the same as the 3 clause BSD license. This seems to apply to the crypt code in there which was taken (albeit in reduced form) from the MiniZIP software. So compiling with NOUNCRYPT define might technically remove the code this license applies too, but I find it a pretty shaky assumption that you can get away with just the ZLIB license if you include the unzip.c in any way in your code (which NI apparently did in LabVIEW too). All the rest is copyright from me. So yes it seems I could change the license to BSD here, since the only C code and project files that is not originally copyrighted under BSD or ZLIB is from me alone. LabPython: As far as the C code goes, everything is copyright by me. OpenG Pipe library: As far as the C code goes, everything is copyright by me. This never has been released as an official OpenG package so not likely a problem for most people so far. OpenG PortIO: As far as the C code goes, everything is copyright by me. However this is obsoleted by the fact that the used technique doesn't work on modern Windows systems anymore and there is really no practical way to make it work in a different way. Remains the question if I should change it. As it is, without some effort to also make a uniform single license file that could be added to every installation of any OpenG Toolkit and that users then could include in an application build, I do however not see much merit in going to change it. As to using another license for future work: It won't help much as long as there is one single VI with the old license in the Toolkit. And more importantly, active development on OpenG libraries has almost stopped, with the exception of the libraries I'm involved. So unless someone new steps up and does new development, there really won't be any future work to apply such a license too. Also unless I totally misunderstand the Apache license text, section 4d would pretty much mean to me a similar attribution requirement in any build application too, if there is any mentioning of your own copyright in that application in a license file, about dialog or similar. Basically a build LabVIEW application would not be allowed to display any copyright information of any form anywhere or this section applies. And MIT also makes a requirement to include the MIT license text with the orginal copyright in any copy or substantial portions of the software and although it doesn't explicitedly say that this applies to object form too, it also doesn't say anything about source only, so substantial portion can and probably should be just as well understood to include object form too. Therefore I wouldn't see MIT or Apache as a solutions to the problem at hand. I think this is slightly misleading. NI has stopped to request royalities for the LabVIEW runtime license and many other licenses too such as NI-VISA, many years ago. For driver software excluding NI-VISA and NI-IMAQdx under certain circumstances, the roalities are covered by the purchase of the according NI hardware which quite often are directly purchased from NI without involvement of the software developer who distributes a compiled app. The exception to this are certain Toolkits and drivers such as IMAQ Vision, LabVIEW DataLogging and Supervisor module, and some of the special analysis libraries etc. and also for instant TestStand. If you use them you need to get a runtime license from NI. You usually will notice quickly, at least under Windows, as those components require license activation to run properly.

Probably but who is going to take the time to do all the administrative work? I'm not opposed to change that license but feel very little for doing all the other work that would be involved in this. Coincidentially I was trying to find any mentioning of ZLIB and the minizip copyright in there and failed. That is almost 100% sure the base for the ZIP functionality in LabVIEW since even the exported function calls are the same as defined in minizip. It could be my search foo that failed me here but not sure.

I guess it could. But then ever looked in a LabVIEW distribution? And noticed all the open source licenses in there? I guess if you want to split hairs like this, and build a LabVIEW application you need to add all those licenses too nowadays or risk violating one of them if you add an innocent VI. HTTP VIs used anywhere, SMTP? Sorry they all use open source software underneath. Just take a look at C:\Program Files (x86)\National Instruments\_Legal Information for a moment and feel overwhelmed. The OpenG software problem looks trivial in comparison.

The DLLs only which are dynamic by nature without any special tricks necessary. And the entire source code being on sourceforge. So what remains is a copyright notice like for the rest.

You are right on all accounts. LGPL required you to separate the LGPL code into external libraries that could be dynamically called and theoretically replaced with the source code version. That made building apps pretty complicated albeit not impossible. BSD is IMHO one of the most practical open source software licenses to allow commercial use. It's unfortunate that even that seems to troublesome for some but I wouldn't know of a better solution.

The Transpose can be a free operation but it doesn't have to stay free throughout the diagram. LabVIEW maintains flags for arrays that indicate for instance the order (forward or backward) as well as if it is (transposed or not) The Transpose function then sets that according flag (as does the Revert 1D array does the according flag). Any function consuming the array either has to support that flag and process the array accordingly or first call a function that will normalize the array anyways. So while Transpose may be free in itself it doesn't mean that processing a transposed array is never going to incur the additional processing that goes along with physically transposing the array. I believe it is safe to assume that all native LabVIEW nodes will know how to handle such "subarrays" as will probably autoindexing and similar. However when such an array is passed to a Call Library Node for instance LabVIEW will ALWAYS normalize the array prior to calling the external code function. Similar things account for other array operations such as Array Subset which doesn't always physically create a new array and copies data into it but also can create a subarray that only maintains things like the offset and length into the original array. Of course many of these optimizations will be void and invalidated as soon as your diagram starts to have wire branches that many times require seperate copies of the array data in order to stay consistent.

The download ZIP button is not to download an installer but rather an image of the source files as present in the github project repository. Not sure I would consider this unfortunate as one might expect users going to github to know a bit about software development and the difference between a source code tree and a build package. Sourceforge has it in that respect a bit more clearly structured where you have the code section where you can browse the source code and download an image of it and the files section where the project maintainer usually puts installers or source tree executable packages for end users to download and use. If only it wasn't acquired by slashdot and turned into a cash machine with advertisment and download wrappers for popular projects, with the wrappers trying to force all kinds of adware on a users computer.

I would questions someones engineerings abilities who finds 150 Euros to be expensive for something which can make the difference between a properly working system and one which regulalry looses communication and/or trips the computer in a blue screen of death. If an engineer has to spend two hours to debug such an error caused by a noname serial port adapter then the more expensive device has paid itself already more than once. And two engineering hours are just the top of the ice peak, with lost productivity, bad image towards the customer and what else not even counted in.

Yes as is mentioned in the post #12 by James David Powell, the VIPM attributes the individual names. The reason being that OpenG started some more than 15 years ago like this and it would be pretty unpractical to get agreement by all authors to change that now, since some might not even be involved in LabVIEW work and impossible to contact anymore. There definitely is nobody who seriously considered to do that so far and I'm not volunteering. I would guess that VIPM does use most of the OpenG libraries in one way or the other and its license attribution is pretty complete but I can not talk for the VIPM developers nor for JKI and they would really be the more appropriate people to contact about this. One other thing to consider here: If you only use OpenG inside projects that are used inside your company, your company is your own customer and you maintaining the source code of the applications on a company provided source code control system (You do that, right???) does take care of all the license requirements of even more stringent Open Source licenses like GPL. Of course you have to document such use as otherwise an unsuspecting collegue may turn over a built of your application to a contractor or other third party or such and create a license violation in that way. Only when you start to develop applications that your company intends to sell, lend, or otherwise make available to third parties without source code, will you have to seriously consider the various implications of most open source licenses out there, with the BSD license being definitely one of the most lenient licenses out there (with the exception of maybe the WTFPL (Do What the Fuck You Want to Public License), which some lawyers feel is so offending that they dispute the validity of it. And of course there is the Public Domain code but again some lawyers feel that it is impossible to abandon copyright and putting code into Public Domain is an impossibility. Isn't law great and live without lawyers would be so easy?

I'm not a lawyer and as such my advice will definitely not help your company lawyers to think different. But IMHO if you use OpenG functions you simply need to add somewhere in your application or at least your documentation a reference to that fact and with the OpenG BSD style license text. This license text basically means you can not claim to have written those functions yourself and you have no right to sue any OpenG developer in any way if your application causes a nuclear meltdown or similar. Not really that much different to commercial software where you also don't usually get any rights to claim damages if the software doesn't perform as you want. If you use for the license text in your application or documentation the same text as is used by VIPM you should be fairly safe. It contains more or less all people who were at some point substantially active in providing functions to the Toolkit libraries. More than that really isn't there. You can also add a link to the OpenG Toolkit sourceforge site as extra service for anyone who wants to check out where this all comes from.

Yes it is. It's not just a few Windows API calls to create a menu and set it as the windows menu but you also need to somehow hook the Windows message queue and intercept the according WM_COMMAND messages and handle them somehow either directly or by redirecting them as user event to an event structure. Not impossible to do but I don't see how this could be easily made into a reusable library. Also there is the potential that your menu command IDs might conflict with command IDs that LabVIEW is using itself and that would mess up the whole pretty good. Not sure LabVIEW is even using the WM_COMAMND messages at all, since it doesn't really use Windows menus but there is still a change that it somewhere somehow does use them for some reasons.

It's clearly a bug. The encoding even goes well and the actual JSON decoding too, but then somewhere between there and the conversion into a proper LabVIEW string handle things go awry by using a standard C string function instead of allowing for embedded \0 characters.

FTDI also gets counterfeited regularly. They had even a pretty bad issue when they released a driver through Windows Update that had specific code in it to clear the USB PID/VID of a chip. For genuine FTDI chips that did nothing since those locations were not writable, for counterfeit chips it cleared the PID/VID and made the chip unusable, although with some low level tools one could fairly easily reprogram them back to a working state, at least if you used a Linux computer for that, On Windows it was more complicated and generally beyond most users ability. People got really mad at FTDI, with many promising to never again buy anything that contains FTDI chips, which is strictly speaking a bit hilaric since they didn't buy anything containing real FTDI in the first place already. That the real culprits really are the copycats who sell cheap chips with the FTDI logo and saving engineering costs by making the chip use the original FTDI device driver is of course another story that is hard to sell to the average computer user.

RS-232 may be an old standard, and pretty hard to do wrong, that can't be said about the USB controller in an USB-to RS-232 converter. They almost all use the same two types of chips and the according chip manufactorer has drivers released that do work (most of the time). But these drivers aren't really industrial quality and are more a reference design that the OEM actually should improve and stress test before releasing a product with that driver. However most no name manufacturers compete on price, not on stability of their product and they release the product as a copy paste design from the reference design of the chip manufacturer with the standard reference design driver. Their only added value to the whole is a more or less fancy casing around the chip and plug. And then you have the manufacturers who actually use a copycat silicon in their products. Their is no guarantee that this product is working the same under all circumstances. EMI and other environmental influences require specific considerations that are not really any concern of those copycat manufacturers. The only thing that counts is to sell as many chips as possible with as little expenses as possible. There is no brand name that can be damaged since their operation only works in the shadows anyways and they have no intention of coming out with their own name for those products as that would be admitting their IP theft and after who the original IP owner needs to go. USB communication can be made pretty reliable but that requires knowledge about both electrotechnical and electromagnetic matters as well as how to write a reliable device driver for any modern OS. And of course about logic design of the chip itself but that is another story.

I can't say for sure, but at least under MacOS Classic LabVIEW used indead the standard OS menu. However at least the 64 Bit version of LabVIEW for MacOSX had to undergo a serious rewrite since Apple discontinued most of the Carbon APIs for 64 bit applications. Everything UI related and many more things most likely got moved to use the Quartz and Cocoa API rather than the Carbon API. So during that rewrite many things could have changed completely. But it is quite probable that they did not redraw the menu themselves since it is really part of the OS and not part of the individual window.

Don't think so. While it seems that LabVIEW does for some things use the QT framework somehow, that is almost certainly not going to be the case for any standard window features like menus, scrollbars and its controls. These originate all from way before LabVIEW 8.0 or so where some QT DLL mysteriously appeared in the LabVIEW directory. LabVIEW draws its controls, menus and most anything including the scrollbars itself in an attempt to provide a multiplattform experience that looks and behaves everywhere as much as possible the same. One of the only things where it relays heavily on the platform itself are fonts.

What Hooovahh already said. Windows APIs meant to work for menus specifically, won't work for LabVIEW menus since LabVIEW renders and handles its menus itself, not by using Windows menu infrastructure. As far as Windows is concerned the menu area in a LabVIEW window is simply normal client area.