Novgorod

You, Sir, are a hero! I've seen that "super secret" string in the binary code, but didn't have a clue what that meant.... Anyhow, a quick benchmark shows an order of magnitude better performance compared to the G code for large block sizes! (Run several times, of course, with similar results, so it's not a fluke..) The G code is exactly the vi.lib implementation but consolidated into a single VI and the output is a raw 16-byte string (not converting to a hex string, though it's irrelevant here because it's only called once). For smaller block sizes, the performance is getting closer, but the function call is still several times faster (but have to properly benchmark it with with many calls in a loop for short blocks). So now it looks not completely unreasonable to poke around in the attic...

I'm not complaining about an undocumented/non-public API change after 20 years, just being curious .. I poked around a bit more - the prototype looks alright, it's just that the function is not intended to provide an MD5-hash of a caller-supplied message. The "message" parameter is actually an output that returns 16 random bytes (there are RNG/GUID calls at least under Windows), which get MD5 hashed. So it outputs a 16-byte random string (GUID) and its MD5 hash for some very specific application. The actual MD5 subroutine is not exposed, so it was all a red herring stinking up the attic...

What the heck? You're right, my Ctrl+F didn't search the whole document, my bad...

W00t, thanks! Where did you steal the forbidden .h file? 😁 Of course you're right, it should be sufficient in almost all use cases to simply use the provided vi.lib version. It's more a curiosity thing and also a neat trick to have very compact portable tools. For example, the built-in zip/deflate/inflate functions eliminate the need for external dlls, since (to my knowledge) there is no pure G code zip implementation, but that's a story for another thread. I tried using the GetMD5Digest function but I'm getting strange behavior (unsurprisingly, I know)... The MgErr type is not defined in extcode.h, but I assume it's just an int32 error code (right?), so that shouldn't be the issue. Here's a minimal implementation: The digest output string seems to require at least a 16-byte pre-allocated buffer or it returns an empty string. The confusing part is that the input string buffer gets overwritten with a seemingly random 16-byte string and the output MD5 digest is the correct MD5 hash for that random 16-byte string and NOT for the actual input string. That random string also changes every time the function is called. Maybe it needs some kind of initializer? I'd appreciate if you have any more info on that, just for the sake of curiosity... 😉

Interesting topic.. Has anyone successfully played around with the built-in (undocumented) Labview manager function "GetMD5Digest"? I assume it's used internally for VI block hashing and other stuff and I'm wondering what's the performance compared with the "public" G code MD5 utilities. If it's faster, it could be a very practical alternative because the manager functions are platform-independent (right?)..

Hi there from the future! I stumbled upon the same problem due to this exact .NET bug in labview, which apparently is known to NI since at least 2014 and hasn't been fixed 5 years later. The issue is that you can't select the constructor with CompressionMode as parameter - it's always overridden with the version using CompressionLevel as parameter. So you can use it for compression (because the default CompressionMode is compression) but you can't decompress. Anyway, thanks for the great workaround and the excellent explanation - that's rare to find!

Hi, I'm wondering whether there is a way to monitor the SVE (or single processes/variables) on a per-client basis. The purpose of this would be network diagnostics or access control. I know the DSC module allows logging of data and events for shared variables, such as the very handy "value changed" event, but they contain no client-related information (to my knowledge), such as the client name or IP address. Are there any other shared variable events besides the value changed notification (e.g. "variable accessed"), which I have missed? Anyway, the SVE seems to be aware of clients, because it allows some access control through the DSC module (and with a bit of hacking even programmatically). You can define access control lists based on computer name or IP address, which is very buggy, but it works somewhat. Is it possible to somehow access this client information (number of clients, names/addresses and activities) from the SVE? I don't see any tools for that, but maybe there is an underlying API through DLL calls or whatever?