If you have questions related to my Zip Classes, you can post them here if you think there’s interesting to other users, too.
I would love a 100% Xojo implementation of Zip that doesn’t rely on DLLs or plugins. Any thought to writing that? I’m sure it would be difficult and not terribly fast, but might be a fun demonstration of bit-twiddling & optimization.
Michael: Uh, no way. On Linux and OS X, it does not rely on any extra DLLs anyway, because OSX and Linux include the necessary zlib libs already. Only Windows doesn’t. And since even simple Xojo apps for Windows include a set of DLLs nowadays, what’s so bad about copying just another DLL into the bunch? Now, with Build Automation available to everyone, you only need to set up a CopyFilesStep to copy the libz1.dll into the Libs folder and you’re good.
The use case I was imagining here was for building a single-file EXE (using an older version of REALbasic that supported this). A very unusual situation.
Although only marginally related, I was looking at lib7zip and wondering if it would make sense to move to it from the original zip libraries. It would expand the formats supported and it exists and is actively maintained for all three platforms with a Mozilla license (I suspect it also would support iOS out of the box).
So for use on Windows do I only have to copy the zlib.dll to the Libs folder?
The documentation on the website made it sound like it had to be installed into the system.
Windows is such a pain.
Bump because I need an answer.
If you are using Windows, first download the “zlib compiled DLL” from http://www.zlib.net/ and place the contained file zlib1.dll into C:\Windows\system\.
That’s from the complete readme that’s available under download on Thomas’s website http://www.tempel.org/RB/ZipPackage
It should also work if placed in the Libs folder…
yes this works… I use the zip class with several of my internal (to my company) modules.
Thanks for confirming this, Scott. I should really update the docs for it.
Putting it in your app’s DLL folder “MyApp Libs” is generally a much better solution, as it avoids the dreaded http://en.wikipedia.org/wiki/DLL_Hell
Thanks everyone for your answers 
So now that I’ve started to use ZipPackage it seems there are quite a few instances of deprecated methods.
I can (and did) fix a few of them, but I have no idea how to safely remove things revolving around MacType.
Also, “TTsFolderItem.SameFolderItem line 10 - MacDirID is deprecated”
Any plans to update? Or clues on how to fix?
Has Xojo provided a replacement for MacDirID? If not, file a bug report.
FolderItem.MacDirID says to use FolderItem.MacFSRef, but there’s no information available on how MacDirID was used, so I’m not entirely sure how to update it to MacFSRef.
What about the MacType? It seems pretty tightly wound in, when I start taking it out I end up with errors, which I track down and get more errors until I finally end up with an error that comes down in a sheet with no reference to anything, just says there’s an error with something RBXML.
Not sure how MacDirID was used in Thomas’ code to know how to replace it
But those things have only been deprecated - not removed
The underlying OS API’s and structures exist & continue to operate
Thomas might be the best person to update the zip code to not use those deprecated items as he’s likely the most familiar with the code
Deprecated means planning to remove them, though!
I don’t want to come back to my code later (hopefully not 10 years of thread updating ui ignorance) and suddenly have a mess to fix!
Sure
We’ve had some items deprecated since 2008 - but they still exist
Apple has as well
It appears to have been used to determine if two files were the same location on disk (see FolderItemSupport.SameFolderItem). I’d change this to compare the NativePath property on all platforms, but a declare to FSCompareFSRefs could be used on OS X (which is where MacFSRef comes into play). Note that FSCompareFSRefs is deprecated by Apple as of 10.8, along with all of the other functions that deal with FSRefs.