dll trouble

[zerotolerance]

I just downloaded the Blowfish encryption algorithm and extracted the original code from its library "llb" and placed them inside a "SubVI" folder. If I move the "LabVIEW Blowfish Encryption.vi" outside the SubVI folder, it doesn't work. But if I move and open the "LabVIEW Blowfish Encryption.vi" from inside the SubVI folder it works.

Its not really an issue, but I just wanted to check if I'm missing something simple. Attached is the code.

Thanks

kas

[Clad19]

Hi zerotolerance,

Good to hear you got the encryption algorithm working fine!

The reason the LabVIEW Blowfish Encryption.vi doesn't open correctly when the .dll file is within the same directory, is due to the following:

- LabVIEW won't search for the specific directory within which you saved the application but instead it will look inside the Windows directory.

This means it will look in C:\.

I downloaded the same .llb file with the .dll and saved them in the a new folder.

I tried having the .vi file in the subVI folder and running it from there but I received the following error: 

'The program can't start because the zlib.dll is missing from your computer. Try reinstalling the program to fix this problem'

I then placed the zlib.dll in the following directory:

- C:\Program Files (x86)\National Instruments\LabVIEW 2012\

I then ran the .llb again and opened 'LabVIEW Encryption.vi'. It then worked without error. This is because the .dll is now within LabVIEW 2012 and so it is appropriately called. 

I hope this helps. 

Kind Regards,

[zerotolerance]

I actually replaced the the "zlib inflate" and "zlib deflate" with the OpenG version. They use the "call library function" which solves this issue alltogether. Even better solutipn was to remove the zlib completely. This way the algorithm becomes multiplatform.
However, thanks for your solution, at least i now know how to deal in situations like these.

Kas

[Clad19]

Hi Kas,

Yes I read about removing the zlib.dll as well as an alternative workaround. 

I appreciate your prompt response. 

I hope the rest of your application goes well!

Kind Regards,

[rolfk]

---

@zerotolerance wrote:
I actually replaced the the "zlib inflate" and "zlib deflate" with the OpenG version. They use the "call library function" which solves this issue alltogether. Even better solutipn was to remove the zlib completely. This way the algorithm becomes multiplatform.
However, thanks for your solution, at least i now know how to deal in situations like these.

Kas

---

Actually the OpenG library is already fairly multiplatform as it comes with a shared library for Linux too, and even a MacOS X shared library. It is currently missing a Windwos 64Bit DLL and a MacOS X x86 shared library.

[zerotolerance]

------------------------------------------------------

It is currently missing a Windwos 64Bit DLL and a MacOS X x86 shared library.

------------------------------------------------------

Is this where the 2GB limit for ZIP files comes from? I have Win. 7 x64 and LabView x32, and it is a no go. I'm having to jump through hoops (separating files, parsing them etc.) to make sure I'm within the 2GB limit. 

[rolfk]

---

@zerotolerance wrote:

------------------------------------------------------

It is currently missing a Windwos 64Bit DLL and a MacOS X x86 shared library.

------------------------------------------------------

Is this where the 2GB limit for ZIP files comes from? I have Win. 7 x64 and LabView x32, and it is a no go. I'm having to jump through hoops (separating files, parsing them etc.) to make sure I'm within the 2GB limit. 

---

No that is a different issue. The ZLIB code that is used in the currently released OpenG library did not support 64 Bit file offsets (or more accurately it did have but not properly working). There is a new ZLIB versiont that should support 64 bit file offsets properly and I have more or less integrated it in the source code. However I also want to add support for 64 Bit LabVIEW for Windows to that library and that still needs some serious testing just as that the 64 bit files offset support is really working.

There is still some serious testing and possibly bug fixing to be done to release these two things as an OpenG library. But as I'm currently swamped with other stuff this has been lingering around for quite some time, but I still hope to get a chance to finish that.

[zerotolerance]

Thanks rolf. I hope it comes out. It would surely be useful.

Kas