LabVIEW
openG Zlib library not working in Labview 2018 64bit
Solved!
Maybe a .net stream-object?
https://docs.microsoft.com/en-us/dotnet/api/system.io.compression.gzipstream?view=netframework-4.7.2
The dll you're looking for is the same one I'm using for the PDF Toolkit.
So you'll need that 64 bit dll. IIRC, the 64 bit dll I found online somewhere (will look where), uses WinAPI iso C calling convention. I only use one function (from libz, not LVZLib, but that's the same dll).
I'm not sure how much work it would be to change all calling conventions for each function in LVZLib…
At some point, I asked the makers of the zlib dll if they could put a pre-compiled 64-bit dll online. They said they liked the idea, but they didn't let me know if they ever did it (not did I asked again).
Some functions, even if we can get a 64-bit pre-compiled dll, might need adaptation to deal with proper pointer sizes. This might not be needed, as most functions will probably pass arrays\strings anyway, so the pointer size will automatically adapt.
EDIT: Just recalled that there is a widely available 64-bit dll available, but the version has a bug, making it not compress on Windows. I had to look long and hard for a more recent version, but I could only find one that had the changed calling convention... I think we need someone to recompile from source code...
Search LabVIEW like a graph! 
No it's not the same DLL at all. I do use the zlib library in its core but the ZIP archive handling is not standard included in the normal zlib DLL.
Here is a beta version of the LabVIEW ZIP Library that does contain 64 bit support. For Windows it works fine, for the 64 bit Linux variants there seems to be a strange bug that treats directories somehow as files when zipping up a file.
I'm currently working on a new release for this library that should work for all platforms on which LabVIEW is available.
And yes the old zlib library used the standard calling convention, then they changed it to cdecl for all platforms. Not sure if they changed it back again. It was one of the reasons I initially decided to create my own version for the OpenG library together with the fact that I also wanted to have the ZIP handling code in the same DLL/shared library. I found it pretty stupid to have to create conditional VIs just for the sake of interfacing to standard calling convention on Windows and cdecl on all other platforms and at that time there was no conditional compile structure at all, not even as undocumented feature. That only came to life in LabVIEW 7.x.
@rolfk wrote:
No it's not the same DLL at all. I do use the zlib library in its core but the ZIP archive handling is not standard included in the normal zlib DLL.
Ah. I was to hasty. Both work for me, as I only use the deflate function.
@rolfk wrote:
And yes the old zlib library used the standard calling convention, then they changed it to cdecl for all platforms. Not sure if they changed it back again. It was one of the reasons I initially decided to create my own version for the OpenG library together with the fact that I also wanted to have the ZIP handling code in the same DLL/shared library. I found it pretty stupid to have to create conditional VIs just for the sake of interfacing to standard calling convention on Windows and cdecl on all other platforms and at that time there was no conditional compile structure at all, not even as undocumented feature. That only came to life in LabVIEW 7.x.
How does that work on Linux systems? AFAIK, There's a zlib dll in the OS. Should programs using it test what the version is, before calling each function with either standard or cdecl? How would the application know what to use for future versions?
If it's a problem in LabVIEW, how do other applications deal with that? Sounds like a terrible thing to change.
wiebe@CARYA wrote:How does that work on Linux systems? AFAIK, There's a zlib dll in the OS. Should programs using it test what the version is, before calling each function with either standard or cdecl? How would the application know what to use for future versions?
You don't have stdcall convention on non-Windows (32-bit application mode) systems. So on Linux it is always cdecl. And on Windows 64-bit (for 64-bit applications) you only have fastcall (first 4 paramaters, except if they do not fit in 8 bytes, are passed through registers with shadow locations on the stack too, rest is passed only on stack).
If it's a problem in LabVIEW, how do other applications deal with that? Sounds like a terrible thing to change.
They changed the DLL name from zlib.dll to zlib1.dll for the cdecl version. Still since the name is not the same as under other OSes, you can not use the wildcard library name pattern in the Call Library Node (zlib1.*) where LabVIEW will automatically replace the * with the correct file ending for the actual platform.
