Jump to content
Mads

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

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

 

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.

  • Like 2

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

...abominable ...

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

  • Like 1

Share this post


Link to post
Share on other sites

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 :lol:)

Edited by ShaunR

Share this post


Link to post
Share on other sites

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:

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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)? 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

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

Guest
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.