ShaunR

I think, maybe, we are talking about different things. Exposing the myriad of OpenSSL library interfaces using CLFN's is not the same thing that you are describing. While multiple individual calls can be wrapped into a single wrapper function to be called by a CLFN (create a CTX, set it to a client, add the certificate store, add the bios then expose that as "InitClient" in a wrapper ... say). That is different to what you are describing and I would make a different argument. I would, maybe, agree that a wrapper dynamic library would be useful for Linux but on Windows it's not really warranted. The issue I found with Linux was that the LabVIEW CLFN could not reliably load local libraries in the application directory in preference over global ones and global/local CTX instances were often sticky and confused. A C wrapper should be able to overcome that but I'm not relisting all the OpenSSL function calls in a wrapper. However. The biggest issue with number of VI's overall isn't to wrap or not, it's build times and package creation times. It takes VIPM 2 hours to create an ECL package and I had to hack the underlying VIPM oglib library to do it that quickly. Once the package is built, however, it's not a problem. Installation with mass compile only takes a couple of minutes and impact on the users' build times is minimal.

Yes. But not a good enough reason.

You may say that but ECL alone is about 1400 Vi's. If each DLL export is a VI then realising the entire export table of some DLLs can create hundreds of VI's, alone. However. I think that probably the OP's project is OOP. Inheritance and composition exponentially balloon the number of VI's - especially if you stick to strict OOP principles.

Ooooh. What have you been doing with the icon editor?

I still use 2009 - by far the best version. Fast, stable and quick to compile. 2011 was the worst and 2012 not much better. If they had implemented a benevolent JSON primitive instead of the strict one we got, I would have upgraded to 2013.

Steganography Version 1.0.0 is now released. Enjoy.

Should never do this. Anyone can sit between you and the server and decode all your traffic. The proper way is to add the certificate (public key) to a trusted list after manually verifying and checking it. What's the point of using HTTPS if you are going to ignore the security?

You can get some of the way like that but there are a couple of bits per byte that have to be concatenated. So at some stage you have to convert to bits. The speed of the encoding for-loops with shift was a surprise to me though. Yup. It was purely for relative performances and will not be included in the release proper. For this sort of thing I would rather deal with relative performance (removes differences between systems that they are bench-marked on). The in-built Performance>Profile Performance and Memory is better for identifying which individual components contribute what; so I would use that if someone found a better solution.

I don't do Discord. I don't even do Ni.com. Feedback isn't really necessary. I only knocked it up because I went down a rabbit hole and wasn't impressed with the existing LabVIEW solutions. I thought I'd throw it in here to see if someone could improve it. My solution is optimised but there may have been a better alternative solution or maybe someone had a nice JPEG one (LSB doesn't survive JPEG compression). You might get a mention in the readme just for responding

Nothing? No improvements. No bugs? Not even the superfluous length parameter or the example images in the wrong location? I'll give it one more week then release the version 1.0.0

I only switched to Win10 3 years ago from Win 7 and that was only because I wanted encrypted SMB to my NAS. I'll think about desktop Linux when they fix their application distribution methods . I dropped my Linux LabVIEW product support for a reason->my products broke every time someone else updated their product.

This all sounds very awkward for a home automation GUI. Why would you compile software on the target? Surely all the devices are wifi with their own REST API so you only need an aggregating web server with pretty javascript front end. What am I missing?

Nah. It was just an icon I generated for an Ollama client.

The llama is cuter

Hi all. A bit of nerdy fun if you can spare some brain cycles. I've written a Steganography API (0.9.0) and will be putting it on my site under a BSD-3 licence. It currently only uses the LSB method but I may do others if there is interest. I've optimised it as much as I can but I expect that better people than I can improve it's performance. So. The task is to make it as fast as possible. There is a benchmark with some images included so we can do comparative benchmarks. I'm looking forward to some innovative improvements. The winner gets a mention in the readme under SALUTATIONS. If you can find the time and/or inclination then please post your times for the vanilla installation and then after any improvements as shown below. Times to beat so far: LabVIEW 2009 x64, Win10 Before Modification: Encode: 297.9 ms Decode: 98.1 ms After Modification: Encode: 297.9 ms Decode: 98.1 ms Oh yes. And finally. If you find any bugs, let me know and I'll fix them.