Using OpenG Zip Tools On 64-bit LabVIEW

[MatthewHarrison]

I'm porting some code to 64-bit LabVIEW 2009, and one thing that is not working is the OpenG Zip tools. It looks like the problem is that the .dll that the toolkit calls into is not executable in a 64-bit environment. This makes perfect sense, but I wonder if it would be possible to recompile lvzlib.dll to overcome this problem. Is the source code for this .dll available, or has this port already been done?

Best Wishes,

Matthew Harrison

Systems Engineer

Moore Good Ideas, Inc.

[jgcode]

I'm porting some code to 64-bit LabVIEW 2009, and one thing that is not working is the OpenG Zip tools. It looks like the problem is that the .dll that the toolkit calls into is not executable in a 64-bit environment. This makes perfect sense, but I wonder if it would be possible to recompile lvzlib.dll to overcome this problem. Is the source code for this .dll available, or has this port already been done?

Best Wishes,

Matthew Harrison

Systems Engineer

Moore Good Ideas, Inc.

Last release was 2.5.1 to fix a LV2009 VI scope issue (off the top of my head) .

There seems to be no current upgrade planned as per here

[Jim Kring]

I'm porting some code to 64-bit LabVIEW 2009, and one thing that is not working is the OpenG Zip tools. It looks like the problem is that the .dll that the toolkit calls into is not executable in a 64-bit environment. This makes perfect sense, but I wonder if it would be possible to recompile lvzlib.dll to overcome this problem. Is the source code for this .dll available, or has this port already been done?

Best Wishes,

Matthew Harrison

Systems Engineer

Moore Good Ideas, Inc.

I'll ping Rolf K (main developer of the OpenG Zip Library) to see how much work this would take and if he has time.

[Ton Plomp]

Last release was 2.5.1 to fix a LV2009 VI scope issue (off the top of my head) .

There seems to be no current upgrade planned as per here

The source code for the library can be found here

Ton

[Rolf Kalbermatter]

I'll ping Rolf K (main developer of the OpenG Zip Library) to see how much work this would take and if he has time.

Well, there has recently been some work on the underlying ZLIB library to make it ready for 64 Bit. There is also a ZIP library on top of that that will require some careful review for 64 Bit compatibility. I think there might be a few issues there. Then there is also the VI library which would need to be updated to use pointer sized integers for some of the parameters. Last but not least this all needs to be compiled with a 64 Bit ready Windows compiler. I guess one of the Visual C Express Editions might do the trick but I haven't done any work in that direction yet.

I have plans to incorporate the recent ZLIB 1.2.5 version into it. This is mostly a simple replacement of existing files in the source code and should help to make that part fully 64 bit ready. Then I will need to setup a working 64 Bit compiler tool-chain somehow and get a bit familiar with it. The real work is trying to find areas where 64 Bit might cause issues. Even if the code compiles fine and seems to do work, that is no guarantee that all the critical areas are fine.

So all in all in it is quite some work and even more testing and I'm at the moment a little tied up with other stuff. I do intend to work on this if nobody else beats me to it, but it is for sure not just a recompile. And since the code changes in some ways there will be a new release of all shared libraries necessary and for true 64 bit support pre LabVIEW 8.0 support might have to vanish.

[Ton Plomp]

Matthew out of curiosity (we would need to do some work on OpenG package builder as well)

could you run this code:

Ton

[MatthewHarrison]

Here is the output from the command:

Operating System:Build Number: 7600

Operating System:Detailed Name: Windows 7

Operating System:Name: Windows: x64

Operating System:Version Number: 6.1

Thank you for taking time to look at this.

Best Wishes,

Matt

Matthew out of curiosity (we would need to do some work on OpenG package builder as well)

could you run this code:

Ton

I wondered how much would be involved in the port. It sounds like there are several non-trivial aspects to it. Thank you for your willingness to look at this issue.

Best Wishes,

Matt

Well, there has recently been some work on the underlying ZLIB library to make it ready for 64 Bit. There is also a ZIP library on top of that that will require some careful review for 64 Bit compatibility. I think there might be a few issues there. Then there is also the VI library which would need to be updated to use pointer sized integers for some of the parameters. Last but not least this all needs to be compiled with a 64 Bit ready Windows compiler. I guess one of the Visual C Express Editions might do the trick but I haven't done any work in that direction yet.

I have plans to incorporate the recent ZLIB 1.2.5 version into it. This is mostly a simple replacement of existing files in the source code and should help to make that part fully 64 bit ready. Then I will need to setup a working 64 Bit compiler tool-chain somehow and get a bit familiar with it. The real work is trying to find areas where 64 Bit might cause issues. Even if the code compiles fine and seems to do work, that is no guarantee that all the critical areas are fine.

So all in all in it is quite some work and even more testing and I'm at the moment a little tied up with other stuff. I do intend to work on this if nobody else beats me to it, but it is for sure not just a recompile. And since the code changes in some ways there will be a new release of all shared libraries necessary and for true 64 bit support pre LabVIEW 8.0 support might have to vanish.

[Rolf Kalbermatter]

Can someone post the labview.lib file from the cintools directory from a LabVIEW 2009, 64 Bit for Windows installation? I need that to make some compile test for a 64 Bit version of the ZLIB Tools DLL, but haven't a 64 Bit machine handy where I could install the 64 Bit version of LabVIEW.

[Jim Kring]

Can someone post the labview.lib file from the cintools directory from a LabVIEW 2009, 64 Bit for Windows installation? I need that to make some compile test for a 64 Bit version of the ZLIB Tools DLL, but haven't a 64 Bit machine handy where I could install the 64 Bit version of LabVIEW.

Here you go.

labview.lib_64-bit.zip

[clynch]

Hi Rolf,

I was wondering how this was going, as I am trying out 64bit LabVIEW and I ran into the same thing.

Cheers,

Chris

[Rolf Kalbermatter]

Hi Rolf,

I was wondering how this was going, as I am trying out 64bit LabVIEW and I ran into the same thing.

Cheers,

Chris

Well I'm soon going to get a new machine and it will most likely come with Windows 7 installed (not really happy about this but I probably have to bite the bullet at some point). One advantage will be that it is going to be 64bit and therefore I can do some debugging of my own. My first dry exercise with just compiling a 64 bit DLL, did crash on Jim's computer, so there must be something still wrong with the DLL.

[ShaunR]

Well I'm soon going to get a new machine and it will most likely come with Windows 7 installed (not really happy about this but I probably have to bite the bullet at some point). One advantage will be that it is going to be 64bit and therefore I can do some debugging of my own. My first dry exercise with just compiling a 64 bit DLL, did crash on Jim's computer, so there must be something still wrong with the DLL.

Is it the wrapper dll or the zlib dll thats crashing?.

I've have a zlib dll that I'm using successfully in LVx64 if that's what is causing you problems. I'm not using it for zip files as I'm currently using the LV shipped ones (although it is compiled with the minizip 64 bit functons - not sure if you use them or not ). It passes all the zlib and minizip tests and labview isn't complaining (or dying) when compressing buffers.

Anyhoo. I'm attaching it in the hope it might save you a bit of time.

[Rolf Kalbermatter]

Is it the wrapper dll or the zlib dll thats crashing?.

I've have a zlib dll that I'm using successfully in LVx64 if that's what is causing you problems. I'm not using it for zip files as I'm currently using the LV shipped ones (although it is compiled with the minizip 64 bit functons - not sure if you use them or not ). It passes all the zlib and minizip tests and labview isn't complaining (or dying) when compressing buffers.

The zlib library is most likely not a problem. I have used the latest source code too. It's either an oversight in the Call Library Node configuration since I attempted to make the wrapper functions so that they will work in 32 bit and 64 bit without modifications to the VIs or something in the wrapper code that goes wrong. I'll take a look at it when I have installed the new machine.

[ShaunR]

The zlib library is most likely not a problem. I have used the latest source code too. It's either an oversight in the Call Library Node configuration since I attempted to make the wrapper functions so that they will work in 32 bit and 64 bit without modifications to the VIs or something in the wrapper code that goes wrong. I'll take a look at it when I have installed the new machine.

As far as I'm aware, lv can only load a dll of the correct bitness so I envisaged at least 2 zwrapper dlls (one x32 & one x64 if you stayed with an intermediary) even if you managed to thunk down to a single 32 bit zlib (expecting 4 dlls in total though). There's obviously a trick I'm missing and can't wait to see the solution. PC on next day delivery?

[Rolf Kalbermatter]

As far as I'm aware, lv can only load a dll of the correct bitness so I envisaged at least 2 zwrapper dlls (one x32 & one x64 if you stayed with an intermediary) even if you managed to thunk down to a single 32 bit zlib (expecting 4 dlls in total though). There's obviously a trick I'm missing and can't wait to see the solution. PC on next day delivery?

Well, the DLL has to be the correct one for the actual LabVIEW platform of course. But since OpenG ZLIB is distributed as OpenG package, the package installer can make sure that the correct DLL is installed depending on the current LabVIEW version and platform. But what I want to avoid is any platform specific settings in the VI interfaces to the DLL. That would make distribution and maintenance of the library rather more complicated. I don't have a seperate wrapper DLL but have combined all the code (zlib, minizip, and wrapper code) into one library. This library is compiled into whatever platform shared library format is required including Win32, (Win64 hopefully soon), Mac OSX, Linux, and VxWorks 6.1 and 6.3. All of them are included in the ogp, with the MacOS X shared library being zipped up first to avoid loosing the resource fork of the files, and then the OGPM or the VIPM takes care to install the one that is required for the current LabVIEW version the package is installed into (and unzips the library through a custom post install step in the package for the MacOS X plaform). All the VIs and other help files are supposed to be platform independent and stay that way if possible at all. And the wrapper code is where I have spend some time in to make that independence happen.

And the delivery takes a little longer since I went for a Dell Latitude machine. Also there are company internal delivery paths that add some time to this too .

[ShaunR]

Well, the DLL has to be the correct one for the actual LabVIEW platform of course. But since OpenG ZLIB is distributed as OpenG package, the package installer can make sure that the correct DLL is installed depending on the current LabVIEW version and platform. But what I want to avoid is any platform specific settings in the VI interfaces to the DLL. That would make distribution and maintenance of the library rather more complicated. I don't have a seperate wrapper DLL but have combined all the code (zlib, minizip, and wrapper code) into one library. This library is compiled into whatever platform shared library format is required including Win32, (Win64 hopefully soon), Mac OSX, Linux, and VxWorks 6.1 and 6.3. All of them are included in the ogp, with the MacOS X shared library being zipped up first to avoid loosing the resource fork of the files, and then the OGPM or the VIPM takes care to install the one that is required for the current LabVIEW version the package is installed into (and unzips the library through a custom post install step in the package for the MacOS X plaform). All the VIs and other help files are supposed to be platform independent and stay that way if possible at all. And the wrapper code is where I have spend some time in to make that independence happen.

And the delivery takes a little longer since I went for a Dell Latitude machine. Also there are company internal delivery paths that add some time to this too .

IC.

I thought I was missing a trick That's a lot of work - Kudos for even considering it.

I took the decision a while ago to cater for cross platform in Labview rather than support my own wrappers or modifying pre-tested API source. I figured that platforms change rarely, but dlls change often. If I just interface directly to the DLL from LabVIEW I could also take advantage of tested, pre-compiled binaries from the developers and just download and overwrite. But I am not as comfortable in C as you are. I also don't have to contend with backward compatibility to LabVIEW versions from 10 aeons ago (when there were no things like "pointer-sized" int). But presumably that could be worked around with the package builder too.

I think there are a lot of people lurking on this thread waiting to pounce once you announce a 64 bit version.

[Ton Plomp]

Well, the DLL has to be the correct one for the actual LabVIEW platform of course. But since OpenG ZLIB is distributed as OpenG package, the package installer can make sure that the correct DLL is installed depending on the current LabVIEW version and platform. But what I want to avoid is any platform specific settings in the VI interfaces to the DLL. That would make distribution and maintenance of the library rather more complicated. I don't have a seperate wrapper DLL but have combined all the code (zlib, minizip, and wrapper code) into one library. This library is compiled into whatever platform shared library format is required including Win32, (Win64 hopefully soon), Mac OSX, Linux, and VxWorks 6.1 and 6.3........All the VIs and other help files are supposed to be platform independent and stay that way if possible at all. And the wrapper code is where I have spend some time in to make that independence happen.

What about conditional disable structures? They should nowadays offer the functionality that you packed into the OGP installer.

Ton

(PS Welcom to Win7, it is superb to XP)

[Rolf Kalbermatter]

What about conditional disable structures? They should nowadays offer the functionality that you packed into the OGP installer.

Ton

(PS Welcom to Win7, it is superb to XP)

Why bother now with it? When I started with it it was for LabVIEW 5.1 or so. No option there. Then we wanted to keep it workable in 6.0 and later 6.1 at earliest. No Conditional Compile structure and even in the versions where it is available it has some issues breaking a VI if something in the disabled cases can't be compiled.

And the conditional disable structure wouldn't take care of everything anyhow. First you don't want to write different code in the VI for each platform. It's much easier to keep that in one C file than in many VIs. And since there are usually always some things that are easier to translate in C into LabVIEW friendly datatypes than trying to make some pointer voodoo in the diagram, that C file is already there anyhow.

Second there are platform specific distribution issues anyhow such as the need to archive the MacOS shared library resource, since you otherwise loose the resource fork when building the package on a non Mac computer and that makes the shared library useless (it looses most of the information about how to load the library). Also why install shared libraries into a system that are useless on that system? Just install whatever is necessary and leave the rest away.

I'm not so fond of Windows 7 because they hid lots of the more advanced settings quite effectively. Will be some time to find them.

[Jim Kring]

I was just curious if there's been any movement on 64-bit support.