Jump to content

Open G Zip Tools on Linux RT


Recommended Posts

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  :yes:

 

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

  • Like 1
Link to comment

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  :D

 

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.

  • Like 2
Link to comment

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 :D

  • Like 1
Link to comment

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

 

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 :rolleyes: ] only be run on Apple hardware.

Edited by ShaunR
Link to comment

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 :rolleyes: ] 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. :rolleyes:

Link to comment

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.

Link to comment
  • 2 weeks later...

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?

Link to comment

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.

Link to comment

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 :D Begone to Linux :P
Link to comment

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 :D Begone to Linux :P

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.

Link to comment

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.

  • Like 1
Link to comment

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.

  • Like 1
Link to comment
  • 2 weeks later...

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 :D  I can live without the file functions as they are easier to replace)? 

Link to comment

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.

  • Like 1
Link to comment
  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.