Rolf Kalbermatter

And just to add a bit to it. Even if you find that location where the password is checked, things get a lot more complicated if you take password protected libraries (and maybe classes) into the picture. Those do not use the same code paths to check for password protection and the passwords of each are actually used in the hash of the other.

Yes you are not supposed to do that and I can't guarantee that it works for 64 Bit OSes. I treated it so far simply as a NumericArray of 32 bit integers for 32 bit OS and 64 bit integer for 64 bit OS, but never really tested any code on a 64 bit system so far. As to handles passed by value: Yes you can assume that they are not null, as you rightly have reasoned that you could not resize them in your code then. It still means that the pointer inside the handle can be null but DSSetHandleSize() should be able to deal with that correctly.

The VI in VI lib should work. It may use a different API internally, if NI hasn't updated it, but should in fact do the same. Early on when networking was really sort of an addon API in LabVIEW (~ V 4) there existed a function to retrieve all kinds of internal parameters. One of them was to get the associated network socket of a network refnum. But that function ultimately called the predecessor of NCGetRawNetObject() which wasn't exported back then. Being a standard VI lib function it should solve your source code control issues.

The rules are simple C programming rules. If you pass an array of handles to C code and resize the array size, you are fully responsible to deallocate any elements that are occupied by the previous array beyond its new size and to allocate any elements thathaven't existed before in the array. Additionally you have to make sure to resize any existing handle to the required size before you modify its contents. And your last remark about that who allocated it also needs to deallocate it, that is ambiguous at least. In C the caller is usually responsible for both since there is no standrad way of passing ownership of memory between caller and callee, but APIs can decide to change that, by allocating and returning memory, but that has to be specifically documented by the API and such an API better provides a function to allow the caller to deallocate that memory later on, since the malloc/free from the API may not be compatible and not even refer to the same heap than the malloc/free of the caller. In LabVIEW the situation is different. LabVIEW uses a standardized memory manager throughout, so this limitation does not exist. Whoever holds onto a handle is responsible to manage and eventually release it and all of its contents. For a C function being called by LabVIEW with native handles, this means you may get in a handle, you may modify it and allocate/deallocate any handles therein, provided you also keep the related information such as the array size consistent. If you then pass the array back (which you basically always do if it is in a value parameter, and usually also if it is a reference parameter, you pass on ownership of that handle back to LabVIEW and it will need to manage it from thereon. An additional tidbit you should know is that LabVIEW uses for performance reasons often a null handle when an empty handle is required, but treats an empty handle also correctly. So your C code needs to be prepared to handle an array of 1000 empty strings to be really an array of 1000 null handles, meaning when you want to write something into these strings you can not just do a DSSetHandleSize() as that will crash on a null handle. Instead use NumericArrayResize() with element type uB, as this function gets the handle passed by reference and will correctly allocate a new handle if it was null.

Well there are two open sources projects you can try to find and check out. The first one is libopenSRTP and the second one is Visual HMI, both from the same author. There also used to be a GEFCOMM Visual Basic example around from someone from GE Fanuc support but not sure if this is still available anywhere. I found the VB example here: http://forums.mrplc.com/index.php?app=downloads&showfile=574

It might work! I'm not sure about the array of pointer sized integers though. On the LabVIEW diagram they are always 64 Bits, but possiby LabVIEW does the right thing here and only converts to a 64 Bit value when passing it to an indicator. That should be indicated with a coercion dot IMO, but it isn't.

You need to write a C wrapper function for that. LabVIEW strings are not the same as a char*, so creating an array of LabVIEW strings does something quite different than char**. Besides, char ** is rather ambiguous anyways. It could be an array of string pointers as your API expects it or it could be also a reference to a string pointer. Basically you need to write a C function that increases every LabVIEW handle in the array with one character annd fill in the terminating 0 char there, then create an array of pointers where you fill in the string pointer extracted from the LabVIEW handle. Something like this: typedef struct { int32 len; LStrHandle elm[];} **LStrArrHdl;yourtype LVfunctionWrapper(....., LStrArrHdl arr, ....){ int32 i ; char **ptr = malloc((*arr)->len * sizeof(*char)); if (!ptr) bailout; for (i = 0; i < (*arr)->len; i++) { int32 len = LStrLen(*((*arr)->elm[i])); LStrHandle h = (*arr)->elm[i]; err = DSSetHandleSize(h, len + 1); if (err) bailout; ptr[i] = LStrBuf(*h); *(ptr[i] + len) = 0; } retval = yourfunction(......, ptr, ......); free(ptr); return retval;}

I had created a 64 Bit version last year already using the Windows SDK command line compiler but it crashed somewhere. And I still need to get a 64bit development version of Visual Studio installed to do some useful debugging. So that will take some time and probably some fiddling around to get working properly.

I have played a little with the vxWorks toolchain. The reason that the // comments are not accepted is that the example vxWorks makefiles that I used as a template for my lvzip makefile do specify the -ansi switch to the C compiler. This reverts to C90 and disables C99 features such as // comments and inline keyword explicitly. Removing that allows compilation without problems but I'm not sure if the resulting shared library is still fully operational for the LabVIEW realtime target as it also has a few effects in terms of compiler builtin symbols that are enabled and are in C90 replaced with library symbols that the compiler will link the resulting object files to. This library shouldn't use any of those symbols but not sure if there are side effects.

Have you tried playing with the mode input from TCP Read? Do you use message termination scheme with CR LF or something else? Basically LabVIEW defaults to a semi buffered mode but most simple socket programming without any poll() operation resembles more the immediate mode of LabVIEW. A mismatch in this mode with what a C program expects is usually the most likely reason for the behavior you see. The C Read with LabVIEW Write most likely will simply work if above is the culprit.

Most likely it's location is stored in a key in the registry in a National Instrument specific subtree.

Well the actual code that adds appending support to an archive was incorporated around 2006 or so, so it should definitely have been in the .out library you had first used. There were other changes to the c source including the change to zlib 1.2.5 but not really between the two dates you show. But it is good to know that it the current source seems to work fine now. I will try to go through all targets and build a new shared library file for them in the next few weeks. This would be by now: Windows x86, Windows x64, Mac OS X x86, Mac OS X PPC, vxWorks 6.1, vxWorks 6.3, Linux 32 bit. A serious series of toolchains that one can't install on one computer or even two or three alone. And Mac OS X x64 is probably coming too, as the newest OS X doesn't seem to allow to startup in 32 bit mode anymore. I'll check about the comments. If they are not in the zlib files I'm going to change them, otherwise I'm not sure what is the right solution at the moment.

Well I had submitted a few zlib related fixes lately that haven''t made it yet into the official upstreams zlib library, so those changes could be the reason that it now works. I didn't expect those changes to have such an influence though, as it was really about troubles when compiling as 64bit code. But I'm baffled about the need to change comments! I have compiled this library with the same toolchain and no modifications to the source code without any compile errors about comments. And I would rather leave the comment style as it is, since most of the files are just taken from the zlib project and changing them each time the zlib project has modified files is simply to painful. Can you give some information as to what errors you got from the // comments One guess I have might be that the updated_gcc toolchain that is now on the NI page incorporates a new gnu version that stumbles over the // comments when compiling .c files, as // comments were originally only a C++ feature. But that would be a rather awkward change, since most C compilers nowadays accept both comment styles anyways and it seems also part of the official C99 standard, which is for standard C compilers. So not sure why GNU would revert a feature that is officially declared in the C99 standard.

I'm afraid so but don't have a quick idea what the problem would be. Debugging on VxWorks is also a pain, since I don't have the integrated VxWorks development environment available (which costs $ and I can't justify this as the whole library and especially the VxWorks port is simply voluntary work).

The first parameter needs to be SHCNE_ASSOCCHANGED = 0x08000000 and the second SHCNF_IDLIST = 0x0000. The first parameter is a bitmask where the set bit defines the type of event and with no bit set, you simply invoke this function to post no event at all.

Of course there is! Use a recent LabVIEW version and of course don't use functions that are synchronized through the UI thread. That includes all VIs itself set to run in the UI thread but also just about every LabVIEW VI server function including Property Nodes and Methods.And everything else that will put up a UI screen such as a dialog or similar.

Is the framework you remember maybe RT System Replication? If so this is not for the application on the RT system to replace itself, but to push down an update from a host application to the (running) RT system. And honestly I don't think you want to have an RT system poll some remote location and attempt to replace itself with a new version. Imagine the system crashing somehow because the new version is not operational. And that system being at the other end of the world. You do want someone to take responsibility when the running app is replaced and be ready to take action if things go wrong.

But if there is no diagram it wouldn't run in a different version than the one it was created in, would it? I remember some dialogs in the past when trying to open a diagramless VI in a different version.

When you leave the address input open to Open Application Reference, LabVIEW does make a short-cut connecting directly to itself rather than routing everything through TCP/IP. So it's a bit different than the TCP/IP nodes.

Well, it's obviously the .Net DLL that is doing something wrong. So the first question to me would be, how was this DLL even tested? I would recommend to try to test it for instance with a Visual Basic test program, unless the programmer is willing and able to use LabVIEW himself. It could be a lot of things, from obvious programming errors in the C# code, to setup errors for the type library that LabVIEW then uses to generate the correct interface stubs, to simple setup errors such as the need to first call some other methods in the library to configure certain things, such as the FT communication port to use, before you can run the test method. So the .Net exception could be a bug in the C# such as referencing invalid objects, but it could just as well be an exception thrown by the code on purpose since it can't perform anything without the proper setup information.

Naw! They don't seem to read the internal HW serial number of the drive. What they seem to do is preparing some 2MB of data space on the flash Drive with some specific data that is read back by a specially prepared DLL that will return this data after some encryption/decryption. Supposedly they do something to prevent the simple cloning of the flash drive by ghost or similar software. How they do that is not clear and I doubt they will tell you. However it does not seem to read any serial number of the flash drive itself.

In general, it's hopeless unless you have a specific USB drive for which you know a proprietary access method to retrieve its chip serial number.

A combination of the File Dialog and the Create Folder function.

Well usually you don't create backup files in the same directory anymore, just for the reason you mention of not having the according rights to the directory anymore. Instead you copy it to the temp directory, update the old file and if anything fails, attempt to move the backup back or on success delete the backup file.

This is also part of the online manual that gets installed with your LabVIEW software. Read the last paragraph to find some samples that are also installed with your LabVIEW installation! It took about 10 seconds to go to www.ni.com and type in "LabVIEW ActiveX Server" in the search box and it was one of the first links on the list.