LabVIEW
Unzip files within labview
Brian K. wrote:So I guess to summarize:
1) Change all the conflicting function names to have lvzip_ prefixed. The source to that is attached. I also recompiled the DLL so that the Call Library Funtion does not get confused.
2) FTP lvzlib.out onto the controller in the ni-rt\system directory
3) Make the correction to InitializeFileFuncs() Call Library Function node, a few other house cleaning operations (conditional disables), and it works. I zipped the partially corrected (I only fixed Compress Directory.vi) library.
Step one is in fact very ugly. I tried to contain all lvzip specific code in one source file and leave the sources from ZLIB and ZIP/UNZIP intact as much as possible. The reason is obvious: Every time a new version of one of these libraries is created I want to be able to import them without having to apply lots and lots of changes to the sources. Up to now I managed to actually keep it like that. With this lvzip_ prefix I loose this possibility completely having to touch just about any file in both the ZLIB and ZIP libraries. I do HATE that!!
I'll look into point 3
Rolf Kalbermatter
Brian K. wrote:3) Make the correction to InitializeFileFuncs() Call Library Function node, a few other house cleaning operations (conditional disables), and it works. I zipped the partially corrected (I only fixed Compress Directory.vi) library.
Ok I checked in to it. the problem is as follows: You did use the VIs from the released 2.3 package. But the currently created lvzip.out file is from the unreleased 2.4 sources from the CVS.
In 2.4 I have added support forusing memory streams as source of unzip operations as well as target for ZIP operations. For this I had to modify the InitilializeFuncs function adding a new parameter for a LabVIEW string handle as memory stream. I do try to maintain compatibility between officiel APIs in different versions as well as maintain compatibility of documented VI functions but reserve the right to modify shared library APIs in between versions making the VI library in fact tied to the shared library version as well as modifying low level VIs in the LVZIP library itself.
You should use the LVZIP VIs from the Opengtoolkit sourceforge CVS archive to go with the lvzip.out library.
Rolf Kalbermatter
rolfk wrote:
Brian K. wrote:So I guess to summarize:
1) Change all the conflicting function names to have lvzip_ prefixed. The source to that is attached. I also recompiled the DLL so that the Call Library Funtion does not get confused.
2) FTP lvzlib.out onto the controller in the ni-rt\system directory
3) Make the correction to InitializeFileFuncs() Call Library Function node, a few other house cleaning operations (conditional disables), and it works. I zipped the partially corrected (I only fixed Compress Directory.vi) library.
Step one is in fact very ugly. I tried to contain all lvzip specific code in one source file and leave the sources from ZLIB and ZIP/UNZIP intact as much as possible. The reason is obvious: Every time a new version of one of these libraries is created I want to be able to import them without having to apply lots and lots of changes to the sources. Up to now I managed to actually keep it like that. With this lvzip_ prefix I loose this possibility completely having to touch just about any file in both the ZLIB and ZIP libraries. I do HATE that!!
One night of (not so restful sleep) later I see a fairly easy way of changing that. It involves creating an additional header with a whole bunch of preprocessor defines to redefine the function names. Doesn't deserve a price for prettyness but it should work and I can include that header in zconf.h so there is a minimal invasive change in the zlib and zip source files. Of course I have to cross fingers that there are not suddenly other weird issues with certain toolchains. I remember some weird issues with older VC projects with to deep nested include file hierarchy.
Rolf Kalbermatter
This is a prerelase version of the newest sources from the sourceforge CVS repository. All public symbols should have been prepended with lvzip_ to avoid name collisions with the already defined functions in the VxWorks kernel. The Windows and Linux version are also updated in that way and seem to work just fine. Sorry for the Mac guys but I saw no opportunity to recompile for Mac targets yet and there is one outstanding issue with this new version that needs some more testing.
This has not been tested on vxWorks targets yet as I still haven't one available to play with.
The prerelease OpenG package can be downloaded here and is best installed using VIPM.
I had to place the package on another site since this board does not allow .ogp files to be attached. Could maybe someone from the websupport add .ogp for the OpenG package to the allowed attachement here?
For VxWorks support you should ftp the according lvzlib.out to the controller into ni-rt\system, from the correct subdirectory (vxWorks82 for LabVIEW 8.2.x and vxWorks85 for LabVIEW 8.5.x and 8.6) inside the lvzip directory created where you installed the package.
As already mentioned this should now work for following targets:
Windows, Pharlap RT targets lvzlib.dll
VxWorks RT targets lvzlib.out
Linux targets lvzlib.so
MacOS X, x86 support will follow.
Rolf Kalbermatter
Hey Rolf,
I forwarded your request to web support, but since .ogp isn't a very common attachment type, I don't think it's likely that it will be added. However, you can always just zip the .opg file and just attach the .zip file. Or just continue to crosspost from LAVA, since this OpenG package benefits both communities 
Anyway, it's been really interesting following this thread, and I appreciate all the work you've put into it. I don't have time at the moment to test it out on a VxWorks target, so I'm going to sit back and let Brian do the dirty work and post his results 
Cheers,
We finally did a definite release of the OpenG LVZlib library. There are no real changes to the library itself apart from some documentation updates and cosmetic changes but it is now official.
For a more detailed list of changes in this new version relative to 2.3 you can refer to http://wiki.openg.org/Oglib_lvzip-2.4
Specific to this thread: All public symbols should have been prepended with lvzip_ to avoid name collisions with the already defined functions in the VxWorks kernel. The Windows, Linux and MacOS X version are also updated in that way and seem to work just fine. Sorry for the Mac Classic guys but I saw no opportunity to recompile for Mac Classic targets yet and we do probably not intend to build for that target anymore unless there is some real demand.
This has not been tested on vxWorks targets yet as I still haven't one available to play with.
The OpenG package can be downloaded here and is best installed using VIPM.
For VxWorks support you should ftp the according lvzlib.out to the controller into ni-rt\system, from the correct subdirectory (vxWorks82 for LabVIEW 8.2.x and vxWorks85 for LabVIEW 8.5.x and 8.6) inside the lvzip directory created where you installed the package.
As already mentioned this should now work for following targets:
Windows, Pharlap RT targets lvzlib.dll
VxWorks RT targets lvzlib.out
Linux targets lvzlib.so
MacOS X lvzlib.framework
Rolf Kalbermatter
rex1030 wrote:Does anyone know if this package is compatible with LabVIEW 2009?
I installed Virtual Package Manager then installed the package. Like info for the library says, "For VxWorks support, after installing the lvzip package, you should ftp "<LabVIEW>\user.lib\_OpenG.lib\lvzip\lvzlib.out" to the RT controller into ni-rt\system."
So I navigated to that directory and the _OpenG.lib is not present. Obviously I did something wrong but I can't figure out what. Any help someone could give would be awesome.
You should probably contact the JKI support. It seems VIPM has on your system somehow problems to install the packages into the proper place. It could be a LabVIEW 2009 issue, or a bad installation of VIPM or maybe a problem with the version detection in VIPM.
Rolf Kalbermatter
