12-19-2024 07:51 AM
I'd want it as a VIP when project local packages are a robust thing...
12-19-2024 07:59 AM
@IlluminatedG wrote:
I'd want it as a VIP when project local packages are a robust thing...
It would be even as normal OGP/VIP already very interesting. Haven't looked in detail at it yet so it may need a little polishing, but this looks like gold.
01-21-2025 02:35 AM - edited 01-21-2025 02:36 AM
Just a little shout out that I'm still busy with this. I did create a little Memory Manager Library of my own from various code fragments I had created over the years. That allows me to handle the entire structure in a way that makes it relatively easy to read and write the individual data elements, while automatically accounting for platform specific alignment rules and all that voodoo logic needed.
Still trying to finalize this Memory Manager Library to something that is good enough to solve most of the common problems without getting to much into esoteric details.
Once I feel things have settled down enough for that library, the plan is to release it as a separate package on vipm.io and then release a Credential Manager library similar to the one in this thread, that makes use of this Memory Manager. The advantage will be that it does not require any external shared library while still working for both 32-bit and 64-bit transparently.
The Memory Manager Library will still not be a panacea to solve interfacing to complex external shared library interfaces. For one it can't easily handle very complex memory manager schemes that might be used in certain libraries. And most importantly, you do have to know what you are doing, how the C compiler works when arranging data in memory and a few more such low level C compiler details, that you can simply skip when writing an external shared library to act as translation shim between LabVIEW and the actual shared library.
02-07-2025 05:31 PM
I released version 1.0 of the Windows Credentials library on vipm.io.
https://www.vipm.io/package/easlib_win_credentials/
It makes use of another library to handle the API data structures without the use of an intermediate shared library:
https://www.vipm.io/package/easlib_memory_manager/
04-17-2026 09:53 AM - edited 04-17-2026 09:56 AM
Rolf, thanks so much for providing this!
A couple of notes:
1. Not sure why, but I am getting LabVIEW crashes (in LabVIEW 2018 32-bit) when the Read.vi calls the credfree(). But it does seem to work properly (presumably while leaking memory) if I don't call credfree().
2. I think the RW Credentials Record.vi seems to have a small bug in the True case where the Target Alias and User Name are written in the wrong order. My understanding is that the Target Alias should be written first and then the User Name.
04-17-2026 10:36 AM - edited 04-17-2026 11:25 AM
Thanks for the report. Will look into it and it is definitely possible that there are bugs in it. This is pretty low level stuff that can go wrong easily if not careful.
First error: the call to CredFree in the Credential.lvlib:Enumerate.vi and Credential.lvlib:Read.vi needs to be set to stdcall. Shame on me.
I developed this in LabVIEW 2009 which has a little known feature to autocorrect the calling convention if it detects a certain naming convention of the exported function. And tested it in a later version only in 64-bit LabVIEW which has only one calling convention so can't be wrong. NI abandoned this autocorrection of the calling convention in 2011 or thereabout, and I agree with them that it should never even have been attempted although since they did do it, it should in fact have been corrected with automatic mutation code when loading such a function into a later LabVIEW version.
The switching between alias and user name is also correct.
Edit: Updated the library on vipm.io to version 1.0.1