Problem in ZLIB 4.0.0-2 on PXI-RT

[mike5]

Hi all OpenG fans!

I have a ZIP file with some folders and files inside. I want to extract entire archive exactly as it is with ZLIB Extract All Files To Dir__ogtk.vi.

The thing works on Windows, but on PXI RT it throws the following error.

Create Folder in Create Dir if Non-Existant__ogtk.vi->ZLIB Get File__ogtk.vi->ZLIB Extract All Files To Dir__ogtk.vi->Download Data Bundles.vi:1->Prepare device.vi<APPEND>

c:\dev\software\BD-Controller/

The library is 4.0.0-2.

Can someone help me work out a fix for this?

Thanks in advance, Mike

[mike5]

Sorry if I'm venting here, but this library has tons of problems with folder '/' separator and I cannot believe that I have the only ZIP archiver that uses this. Didn't anyone test this? Am I missing something simple here, or what?

Mike

[mike5]

Another question - if I fix this, what is the procedure for getting it included the next version? Also, who to discuss the fixes with? I guess the code has to conform to some standards.

Br, Miha

[Ton Plomp]

Your best bet is to discuss your fixes with RolfK.

Could you tell what RT OS is installed on that PXI?

Ton

[Ton Plomp]

One question, how did you get the zip-library on that computer?

For RT there are some special procedures.

Ton

[mike5]

Thanks for the pointer to the special procedures. I'll check it out.

Regarding the ZLIB - I just built the project and assumed everything is alright But in the mean time I also tried creating and explicit function which iterates through the ZIP file, creates folders as it goes and generally takes care of "/" -> "\" conversion. I got a method that was running on RT without any errors (simply run a VI on the RT target).

So now I'm trying the project again. Will let you know of the results.

And the OS is ETS Phar Lap.

Thanks, Mike

Edited November 9, 2011 by mike5

[mike5]

My hand-coded function works as it should. Here is the snippet if anyone is interested:

This is the case for Folder (16):

Br, Mike

[Rolf Kalbermatter]

My hand-coded function works as it should. Here is the snippet if anyone is interested:

This is the case for Folder (16):

Br, Mike

Thanks for pointing this out. And no I haven't run the ZLIB library on every possible target that is out there. For several good reasons:

1) I don't have all that hardware available.

2) I do have a normal daytime job to earn my living

3) LVZLIB already is targeted at Windows 32 Bit, MacOS Classic, MacOS X 32 Bit (with some issues related to long path names), Linux, Pharlap ETS, and VxWorks and I'm working on Windows 64 Bit support too. Testing the library myself on all of these systems with many different scenarios is simply not an option.

What I did in case of the RT targets, was simply to assume that the ETS Pharlap system should work with the same code as the Windows system. In the case of the VxWorks system I simply compiled the according .out file and asked people to test it, which it of course didn't to start with. Thanks to a very helpful engineer at NI who had access to the (rather expensive) integrated development system for VxWorks we could debug the issues, which required actually some significant changes to the entire source code framework to make it work for VxWorks.

As to the path handling: Can you positively confirm that your change will work without issues on all the aformentioned targets? If someone can confirm this to me, it would be fairly easy to make the necessary changes to the library, possibly at a place that is actually less performance intensive, such as in the actual shared library code itself.

Specifically the change to the path separator should be handled in "ZLIB Common Path to Specific Path.vi" instead. It also takes care of stripping the path from any trailing seperator. So the real fix is to simply use this VI.

The VI in the SVN repository does this already and I changed that in April of this year, but for some reasons, your library doesn't seem to use that VI. I'll check what the OpenG library contains and if there is indeed some problem with having the latest source code in the package.

EDIT: Ok I checked. 4.0.0-2 seems to be based on the old 2.5.1 source code and doesn't contain the fix to treat the Pharlap platform as Windows platform in the "ZLIB Common Path to Specific Path.vi". But the orginal code contains definitely the "ZLIB Common Path to Specific Path.vi" in the "ZLIB Extract All Files To Dir.vi" and the only thing needed to make it work for Pharlap platforms is to add the Pharlap enumeration to the case structure inside "ZLIB Common Path to Specific Path.vi" that handles Windows 3.1 and Windows 95/NT enumeration already. No need to handle directories and files differently as the LabVIEW Build Path primitive is smart enough to work for both correctly.

[jgcode]

EDIT: Ok I checked. 4.0.0-2 seems to be based on the old 2.5.1 source code and doesn't contain the fix to treat the Pharlap platform as Windows platform in the "ZLIB Common Path to Specific Path.vi".

That's correct. The 4.x package was based on the 2.5.1 code.

I am not sure of any issues relating to the following and of the current state of the project: but it would be great to have this project converted to the new (VIPM) directory layout, re-compiled in LabVIEW 2009 and released using VIPM 2011 so that it is inline with other OpenG Library Packages (same for PortIO).

Cheers

-JG

[Rolf Kalbermatter]

That's correct. The 4.x package was based on the 2.5.1 code.

I am not sure of any issues relating to the following and of the current state of the project: but it would be great to have this project converted to the new (VIPM) directory layout, re-compiled in LabVIEW 2009 and released using VIPM 2011 so that it is inline with other OpenG Library Packages (same for PortIO).

Cheers

-JG

I personally find 2009 a rather steep step to go to. I still have projects that are maintained in 7.1.1 and I don't like to go through hoops to backconvert the code after each modification. I can look into the directory layout you mention. Can you point me to a document that describes the specifics and the exact problems this is supposed to solve?

PortIO is as far as I'm concerned EOL. I don't plan to do any maintenance on that. It solves a problem that should be not even considered as a solution in modern OSes, and uses technology that is very unportable to other LabVIEW platforms, including 64 Bit Windows.

[mike5]

Thanks for looking into this, and glad I helped to move things along. I'll rather keep my own function until a new OpenG release, since consumers of my project need to be able to get zlib independently.

Br, Mike

[jgcode]

I personally find 2009 a rather steep step to go to. I still have projects that are maintained in 7.1.1 and I don't like to go through hoops to backconvert the code after each modification. I can look into the directory layout you mention. Can you point me to a document that describes the specifics and the exact problems this is supposed to solve?

Yer, I thought there would be a reason (i.e. older version) - my intention was to keep it inline and up to date with other packages.

The new layout standard was designed to work the best with VIPM, so unless the project moves to VIPM 2011 etc... there is no point.

PortIO is as far as I'm concerned EOL. I don't plan to do any maintenance on that. It solves a problem that should be not even considered as a solution in modern OSes, and uses technology that is very unportable to other LabVIEW platforms, including 64 Bit Windows.

Do you think that project should be deprecated?

[Rolf Kalbermatter]

Do you think that project should be deprecated?

I think so. Leave it on sourceforge for whoever wants to look at its implementation and do his or her own stuff with it. But it probably shouldn't be an official OpenG package anymore. I started it for a quick and dirty test once, and after it got a personal thing between me and Windows, to try to force it into submission . Once that point was proven it lost its appeal for me.

I learned quite a bit about Windows device driver programming with it, but mostly stuff I didn't want to really know.

[mike5]

Any idea when the bug fixes will be coming into a new release?

Thanks and best regards, Miha

[Rolf Kalbermatter]

Any idea when the bug fixes will be coming into a new release?

Thanks and best regards, Miha

I won't be able to spend any time on this before the christmas vacation. And at the same time I want to address Windows 64 Bit compatibility. So I would say a good estimate for a new release that includes the newest source code already present in SVN is sometimes after start of next year.