ShaunR

Awesome. I was struggling with C malarky. Since it's hard for me to use extcode.h, I usually find the types and paste them in the header of whatever I'm using. However. I thought the InstanceDataPtr was a void * so I was using prototypes like this: Makes sense, right? WRONG! InstanceDataPtr is a typedef which means you can do things like *data = (InstanceDataPtr)malloc(sizeof(MyManagedStruct)); Can't do that with a untypedef'd void * so the compiler was bailing with: That caused me to try all sorts of pointer voodoo which would only work for a pointer-sized variable since: Looking at your replies it became obvious you were able to do something my compiler was complaining about and It was unlikely to be the compiler. This is why I do LabVIEW. lol

The CFLN has a page for callbacks. These are useful in certain rare cases but there is very little information available about how to use them, MgErr and InstanceDataPointer are defined in extcode.h and, it seems, InstanceDataPointer is a pointer passed by LabVIEW but there the information ends. Does LabVIEW free the InstanceDataPointer? - it is readable in the Abort, Reserve and Unreserve. Are we limited to a pointer sized variable? It's a (void *) so can we resize the memory it points to and, if so, does LabVIEW free that? (unlikely). Who owns that pointer? Does someone have a working, concrete, example (including C code) of the DLL side of these functions and how to dereference, write to and free the InstanceDataPointer? Does someone have skeleton templates for these functions that can make life easier for users like me, that know enough C to be dangerous?

I know this trick and it used to work but it seems to now be marked as a "toolkit" VI and it doesn't matter where you save it.

Well. I removed my offerings from Lavag about 4 years ago, so it works But the real reason i removed them was that there used to be a size limit and I ran out. I deleted all files so I could post images in the threads going forward. You'll also find a lot of my old posts that no longer have images.

Hmmm. Can't back-save a non password protected VI? That's new ... and how do I set my VI's to do that?!

The usual solution for this kind of thing is RPC. I'm still struggling to understand the need for thunking. I might be missing something but If you are calling a 32 bit DLL on a machine, I expect LabVIEW 32 bit is being used to do it. In the couple of years I've been doing LabVIEW, I've never needed to do this. I wrote a network thingy a long time ago (Dispatcher) with similar characteristics. It was a publish/subscribe RPC but with an emphasis on data streaming. Servers would tell a broker what functions or channels they supported and the and clients would connect or call the functions directly on the the servers. I didn't use network streams but maybe they were not available then. It sounds like this is something similar.

I don't really understand why you want a DLL at all but calling a 32 bit DLL from 64 bit is called "thunking" and you really, really don't want to go there. If it's just a case of choosing a 32 bit or 64 bit depending on the LV bitness then the CLFN wildcards will do that for you (for different platforms too).

Some things that need to be done so it doesn't crash arbitrarily (not particularly you, just commenting on the latest incarnation). EVP_DigestFinal_ex mdlen parameter needs to be pointer to value instead of value as it returns the length, Return values need to be used (and checked). Currently the functions return Void when they should be I32. Need to check the MD_CTX pointer isn't 0 for each function. Edit. almost forgot. Remove EVP_cleanup(). In versions prior to 1.1.0 it will crash other functions that use EVP and after 1.1.0 it's a no-op.

Not mine. It's just two unconnected error clusters. For this reason I have a VI that I wrote in 2009 similar to what NI eventually eventually implemented (except it defaults to 4). . This is the diagram

Error 4 (EOF)still really annoys me. I still maintain it should be a warning and not an error. Every time I have to use my filter error to prevent passing it through I curse and wish a plague on NI. lol

There is an opk package in one of the feeds if it's not there already. Chances are, if it has SSH, it'll have compatible binaries. NIlibeay is just NI's compilation of OpenSSL.

Nice work. Glad you got there.

The destroy should be an Unsigned Pointer Sized integer (Passed by value) rather than adapt to type. You can also set the nodes to "Run in any thread" Rolf got there 10 secs before me.lol Untitled 1.vi

I don't think you can see the wood for the trees. I am saying I can't supply the actual code I used because it's commercial but I can help you "discover" how to do it which isn't bound by commercial restraints.

That is the old way. The EVP_Digest interface abstracts away the different hashes into unified set of functions. All that is needed is a while loop where they have two update functions in the example about 2/3rds of the way down in that link..

As I explained. The code I used is part of ECL so commercial IP prevents me from sharing. You should know or at least appreciate this! Correct. New, Init, update, final and free (the EVP interface). You will also need digestbyname. Once you have this you will also be able to do *all* the hashes, not just MD5.

I have a different solution... .. which is demonstrably an improvement. You can lead a horse to water but, this time, I guess I underestimated it's thirstiness.

Sorry. No can do. It's part of ECL but I've given you all the info to replicate it and proved it might be worth your while

This is fun Here are my comparative benchmark results for MD5 the NI SHA are abysmal.

Yuck. Cmd line Try using the EVP_Digest interface of the NIlibeay32.dll You can even have progress events if you want to be fancy I don't know why NI didn't use it

That's BS. MD5 is still the 2nd fastest checksum (SHA-1 being the fastest) and a checksum has little to do with security. They are obviously confused between security and integrity.

Hmmmm. They have removed MD5Checksum from the palette in recent LabVIEW versions?

Well. the output of the python hmac is a byte array and the output of the LV hmac is a hex string so I expect you have to convert the LV hmac output into a byte array before passing it to the encode like this: Generate Signature.vi By the way. None of your sources (message or key) are base64 encoded so you may run into errors when trying to b64decode normal text.

Well. If your key is greater than the block size (64 bytes) then the library you are using will hash it first to make it 64 bytes in length. If you are passing the hex-text representation of the key, it will probably be longer than that so maybe it's being hashed first.

There are some primitives but not easy to get to, so here they are. UTF8 LV80.vi