Open G Zip Tools on Linux RT

[Mads]

Having been using the Open G Zip Tools on both Windows and VxWorks targets for a long time I just ran into the issue of compatibility with Linux RT...

I'm sure I can find an alternative on Linux RT, but the otpimal solution of course would be to have the existing toolkit also support Linux RT 

 

Has anyone compiled and modified the kit already for Linux (or set up a nice replacement)? Are there any plans to add such support in the official version?

 

MTO

[Rolf Kalbermatter]

Having been using the Open G Zip Tools on both Windows and VxWorks targets for a long time I just ran into the issue of compatibility with Linux RT...

I'm sure I can find an alternative on Linux RT, but the otpimal solution of course would be to have the existing toolkit also support Linux RT 

 

Has anyone compiled and modified the kit already for Linux (or set up a nice replacement)? Are there any plans to add such support in the official version?

 

MTO

 

I have been slowly working to add a few new features to the lvZIP library and also make it Windows 64 bit compatible as well as support for additional RT targets. It's not quite finished yet, especially the support for UTF8 encoding of file names on non-Windows systems proofs tricky to make it work with the LabVIEW multibyte encoding, which can or can not be UTF8 on Linux systems depending on the system configuration. As soon as I get that working I plan to release a new package with support for Windows, Linux and NI RT targets. Sorry no Mac at this time, maybe I manage to get hold of a Mac at some point but that has low priority for me at the moment.

[Mads]

Thanks Rolf. Until then - I've began playing with alternative solutions, and have posted a description of it on the Linux RT forum.

[Jim Kring]

Hi All: Please let me know if/when you need this built/released. I want to support this!

[Mads]

I had forgotten that I also need to do deflate/inflate in memory on strings. When do you think a new release might come about Rolf 

 

Perhaps I can use some of these tips to do it until then though...

[Rolf Kalbermatter]

I had forgotten that I also need to do deflate/inflate in memory on strings. When do you think a new release might come about Rolf 

 

Perhaps I can use some of these tips to do it until then though...

 

I'm not going to make any promises here. But I'm working on it and tackled one more problem this weekend. As it seems it is now mostly some more testing for the Linux/VxWorks version and then wrapping everything up in an OpenG package. I might post a prerelease package here for testing and review and certainly will need some assistance in getting the final package uploaded to the VI network somehow.

[Michael Aivaliotis]

How about fixing it for Mac OSX?

https://lavag.org/topic/16662-macbin-resource-file-info-core-generating-error-on-mac-osx/#entry102203

[ShaunR]

Multi-platform binaries are far from trivial. LabVIEW makes cross platform development a breeze, but to create binaries for it to use is still very resource intensive especially as they have just added Linux and Mac 64 bit support in LV2014. That equates to a minimum of 8 different binary builds that must be created, maintained and tested on multiple operating systems, multiple hardware targets and multiple LabVIEW versions and lets not forget build tools, scripts and 3rd party stuff. Testing and debugging alone is a full time job in reality and Rolf has a life and paying work to factor in too.

 

The good news is that once it is done. That should be it for a few years

[Rolf Kalbermatter]

How about fixing it for Mac OSX?

https://lavag.org/topic/16662-macbin-resource-file-info-core-generating-error-on-mac-osx/#entry102203

 

If you send me a nice modern Mac I might be able to work on that.

 

My experiments with a MacOSX installation under Virtual Box were pretty abdominal.

[ShaunR]

If you send me a nice modern Mac I might be able to work on that.

 

My experiments with a MacOSX installation under Virtual Box were pretty abdominal.

 

I'm sure you are aware, but it probably needs to be stated that it is an infringement of the Mac OSX EULA to run it in a VM. They specifically code defensively against it (hence your abominable  experiments) . Mac OSX can [legally  ] only be run on Apple hardware.

Edited January 26, 2015 by ShaunR

[Yair]

...abominable ...

You never know. Maybe it gives you an ulcer, and then it could also be abdominal...

[ShaunR]

You never know. Maybe it gives you an ulcer, and then it could also be abdominal...

Well. It gives me the sh@ts   (Queue the toilet humour )

Edited January 26, 2015 by ShaunR

[Rolf Kalbermatter]

I'm sure you are aware, but it probably needs to be stated that it is an infringement of the Mac OSX EULA to run it in a VM. They specifically code defensively against it (hence your abominable  experiments) . Mac OSX can [legally  ] only be run on Apple hardware.

 

I'm aware of it. Figured that trying couldn't hurt, but can only discourage such attempts!

 

And yes it's pretty upsetting and bad for the health although not everyone may develop ulcer from it.

[hooovahh]

I had tried OSX in VMware years ago and it was slow but usable.  I looked into Hackintosh PCs at some point but really it was just a curiosity factor.  And having more exposure to other OSs to be familiar with them seemed like a good idea.  When Vista came out I was excited to try to learn something new since XP had nothing new to teach after so many years of use.

[Stobber]

Rolf, I can provide some testing in Win7x64 with LVx64 if you need it. I'm in dire need of an update to the OpenG ZLIB package for one of my build tools.

[hooovahh]

I feel like more information would be useful.  Why is the x64 needed?  What is wrong with LabVIEW 32 bit on x64 Windows?  And is this a place where a command line 7-zip built for 64 bit could be used?

[Stobber]

I'm building a 64-bit binary using LVx64. My build tool uses the ZLIB package. I could change it to use the command line, but that complicates distribution of the tool.

 

A counter to your post, since we're questioning one another's motivations (or possibly justifications for making a request?): What use is this information anyway? Am I missing something obvious?

[hooovahh]

A counter to your post, since we're questioning one another's motivations (or possibly justifications for making a request?): What use is this information anyway? Am I missing something obvious?

Settle down there partner, you can make all the requests you want, no need to justify that to me.  I was just trying to help by giving you an alternate solution until a better one is possible.  If this matter is as urgent as you made it sound, I figured you might be interested in some kind of temporary solution, like complicating your build process with command lines, or moving to 32 bit if it is possible.  That's what the purpose of that information was.

[ShaunR]

What is wrong with LabVIEW 32 bit on x64 Windows?

Can't build 64 bit apps with 32 bit LabVIEW.

And is this a place where a command line 7-zip built for 64 bit could be used?

We moved away from CLI with windows XP over 14 years ago. Us point and clicky people will drag you secretarial typists with eidetic memories kicking and screaming into the 21 century Begone to Linux

[hooovahh]

Can't build 64 bit apps with 32 bit LabVIEW.

I agree, but that information wasn't given until after I asked that question.

 

We moved away from CLI with windows XP over 14 years ago. Us point and clicky people will drag you secretarial typists with eidetic memories kicking and screaming into the 21 century Begone to Linux

I meant using something like system exec to run a command line version, of a 64 bit built application.  Here was a quick and dirty solution using this method a while ago.

[Rolf Kalbermatter]

I'm building a 64-bit binary using LVx64. My build tool uses the ZLIB package. I could change it to use the command line, but that complicates distribution of the tool.

 

A counter to your post, since we're questioning one another's motivations (or possibly justifications for making a request?): What use is this information anyway? Am I missing something obvious?

 

Actually the 64 Windows version is not the real problem. Haven't tested all but it compiles. What is the challenge is the various Linux variants at the moment.

[Stobber]

Actually the 64 Windows version is not the real problem. Haven't tested all but it compiles. What is the challenge is the various Linux variants at the moment.

 

Glad to hear it! For my own needs today, I found an MGI API that wraps .NET's System.IO.Compression and seems to work fine.

[Mads]

Rolf - are there parts of the toolkit that could be pre-released already for Linux RT, if you disregard the outstanding issues for the overall toolkit (like deflate/inflate   I can live without the file functions as they are easier to replace)? 

[Rolf Kalbermatter]

Well, it seems I should be able to do something here, sans Mac support, if I leave all the encoding stuff out. There is a potential problem about extended ASCII characters in filenames inside the archive that has existed since the beginning and caused some problems in the past that I was trying to tackle. But no matter what I try to do, it always turns out to cause problems somewhere. So I have started to remove all the encoding translation from the current version in order to get a version out that should be functionally at least the same as older versions of the OpenG ZIP library (but support the new 64 bit platforms and the RT systems). It will still badly fail for filenames that contain extended characters but I'm not really anymore sure it's useful to try to fix that.

 

I might try to add later some simple conversion function on LabVIEW level to handle those filenames a little more gracefully when extracting an existing archive (there is no way to guarantee letter for letter matching between the original archive name and the resulting file name after extraction since LabVIEW doesn't support Unicode filenames yet) but it will at least extract the files to a similar name. As I'm going to ski vacation at the end of this week I don't think I will be able to create a fully featured OpenG package but will try to post a preliminary and limited tested package here before that.

[Rolf Kalbermatter]

I have created a new package with an updated version of the OpenG ZIP library. The VI interface should have remained the same with the previous versions.

 

The bigger changes are under the hood. I updated the C code for the shared library to use the latest zlib sources version 1.2.8 and made a few other changes to the way the refnums are handled in order to support 64 bit targets.

 

Another significant change is the added support for NI Realtime Targets. This was already sort of present for Pharlap and VxWorks targets but in this version all current NI Realtime targets should be supported. When the OpenG package is installed to a LabVIEW 32 bit for Windows installation, an additional setup program is started during the installation to copy the shared libraries for the different targets to the realtime image folder. This setup will normally cause a password prompt for an administrative account even if the current account already has local administrator rights, although in that case it may be just a prompt if you really want to allow the program to make changes to the system, without requiring a password. This setup program is only started when the target is a 32 bit LabVIEW installation since so far only 32 bit LabVIEW supports realtime development.

 

After the installation has finished it should be possible to go in MAX to the actual target and select to install new software. Select the option "Custom software installation" and in the resulting utility find "OpenG ZIP Tools 4.1.0" and let it install the necessary shared library to your target.

 

This is a prelimenary package and I have not been able to test everything. What should work:

 

Development System: LabVIEW for Windows 32 bit and 64 Bit, LabVIEW for Linux 32 Bit and 64 Bit

Realtime Target: NI Pharlap ETS, NI VxWorks and NI Linux Realtime targets

 

From these I haven't been able to test the Linux 64 Bit at all, as well as the NI Pharlap and NI Linux RT for x86 (cRIO 903x) targets

 

If you happen to install it on any of these systems I would be glad if you could report any success. If there are any problems I would like to hear them too.

 

Todo:

 

In a following version I want to try to add support for character translation of filenames and comments inside the archive if they contain other characters than the ASCII 7 bit characters. Currently characters outside that range are all getting messed up.

 

Edit (4/10/2015):

Replaced package with B2 revision which fixes a bug in the installation files for the cRIO-903x targets.

oglib_lvzip-4.1.0-b2.ogp