Results 1 to 13 of 13

Thread: [RESOLVED] Using Windows XP "Compressed Folder" shell extension to work with .zip files

  1. #1

    Thread Starter
    Addicted Member Wolfgang Enzinger's Avatar
    Join Date
    Apr 2014
    Location
    Munich, Germany
    Posts
    160

    Resolved [RESOLVED] Using Windows XP "Compressed Folder" shell extension to work with .zip files

    Hello everybody,

    if the subject of this tread sounds familiar to you, that's no surprise - it is stolen from Namespace Edanmo. Under this title a demo is available that shows how to handle ZIP files simply using what is contained in Windows since XP for this purpose.

    I like this demo, especially since, with some minor modifications, it also can handle files > 2 GB. (It cannot, however, handle encrypted ZIP files, the Windows Shell doesn't seem to support that.)

    The bad news is that, while it worked in Windows 7, it doesn't anymore in Windows 8.1 and 10. Where it fails is shown in this little bit of code:

    Code:
    Dim mStorage As IStorage
    Dim oPF As IPersistFile
    
    Set mStorage = CreateObject("CompressedFolder")
    Set oPF = mStorage  '-> type mismatch (not in Windows 7!)
    It looks like the mStorage instance lost its IPersistFile interface on the way from W7 to W8.1 ...

    Does anybody have any insight why that is, and probably has a way to work around it, if that's possible at all?

    BTW, it seems to make no difference whether I use the older olelib.tlb or the newer oleexp.tlb in references.

    Best regards,
    Wolfgang
    Last edited by Wolfgang Enzinger; Dec 2nd, 2022 at 03:59 PM.

  2. #2
    PowerPoster jdc2000's Avatar
    Join Date
    Oct 2001
    Location
    Idaho Falls, Idaho USA
    Posts
    2,393

    Re: Using Windows XP "Compressed Folder" shell extension to work with .zip files


  3. #3
    PowerPoster
    Join Date
    Jul 2010
    Location
    NYC
    Posts
    5,651

    Re: Using Windows XP "Compressed Folder" shell extension to work with .zip files

    Your best bet is to use IShellItem and related interfaces. This will work with not only with compressed folders (.zip and .cab), but also any virtual location lacking a file system directory, such as when you attach a mobile device. The oleexp sample project list has a bunch of demos for working with them.

  4. #4

    Thread Starter
    Addicted Member Wolfgang Enzinger's Avatar
    Join Date
    Apr 2014
    Location
    Munich, Germany
    Posts
    160

    Re: Using Windows XP "Compressed Folder" shell extension to work with .zip files

    Thank you.

    However, I think I checked most if not all of these before, and they alll lack one or more features I need. To avoid confusion, I didn't mention all requirements I have, but there are a lot of them. Edanmo's solution fulfiills them all (after minor modifications, as mentioned before), but sadly this stopped working with Win 8.1.

    Best regards,
    Wolfgang

  5. #5
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Location
    Sofia, Bulgaria
    Posts
    5,120

    Re: Using Windows XP "Compressed Folder" shell extension to work with .zip files

    Btw, Windows Shell zipfolders can handle encrypted ZIP files with the original PKWare ZipCrypto (which is broken) but cannot handle WinZip AES encryption indeed.

    Sizes above 2GB are possible only in Zip64 format which zipfolders support indeed.

  6. #6

    Thread Starter
    Addicted Member Wolfgang Enzinger's Avatar
    Join Date
    Apr 2014
    Location
    Munich, Germany
    Posts
    160

    Re: Using Windows XP "Compressed Folder" shell extension to work with .zip files

    Quote Originally Posted by fafalone View Post
    Your best bet is to use IShellItem and related interfaces. This will work with not only with compressed folders (.zip and .cab), but also any virtual location lacking a file system directory, such as when you attach a mobile device. The oleexp sample project list has a bunch of demos for working with them.
    Thank you! Sounds interesting; however at the moment I'd prefer something that makes my current solution work in Windows > 7 with as little hassle as possible. But obviously, there ist little to no chance.

    Currently I'm testing and extending the solution you showed in this Codebank thread; looks quite promising so far, but I'm not completely done yet.

    Best regards,
    Wolfgang

  7. #7

    Thread Starter
    Addicted Member Wolfgang Enzinger's Avatar
    Join Date
    Apr 2014
    Location
    Munich, Germany
    Posts
    160

    Re: Using Windows XP "Compressed Folder" shell extension to work with .zip files

    Quote Originally Posted by wqweto View Post
    Btw, Windows Shell zipfolders can handle encrypted ZIP files with the original PKWare ZipCrypto (which is broken) but cannot handle WinZip AES encryption indeed.
    Interesting, I didn't know this detail. But since PKWare ZipCrypto is broken anyway as you say (in which regard?), this feature of Windows Shell zipfolders is obsolete, more or less.

    I an ideal world, your fantastic cZipArchive class would support Zip64 format extension ...

    Just dreaming; I guess this would be a huge amount of work to implement.

    Best regards,
    Wolfgang
    Last edited by Wolfgang Enzinger; Dec 2nd, 2022 at 03:58 PM.

  8. #8
    PowerPoster
    Join Date
    Jul 2010
    Location
    NYC
    Posts
    5,651

    Re: Using Windows XP "Compressed Folder" shell extension to work with .zip files

    What exactly do you need to do... just creating/listing/extracting with IShellItem is trivial; you only need complex solutions like the thread you linked if you need to do partial extractions and other more complex work that Edanmo's class didn't do.

  9. #9
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Location
    Sofia, Bulgaria
    Posts
    5,120

    Re: Using Windows XP "Compressed Folder" shell extension to work with .zip files

    Quote Originally Posted by Wolfgang Enzinger View Post
    But since PKWare ZipCrypto is broken anyway as you say (in which regard?), this feature of Windows Shell zipfolders is obsolete, more or less.
    Crypto can be broken in one way only -- an attacker can unprotect a message without having the key. So ZipCrypto is supported only for extracting "protected" archives coming from encoders that do not support WinZip AES encryption (think about Linux tools for instance).

    WinZip AES is dated and incompatible w/ present day standards/modes but miraculously very correctly designed (by an actual cryptographer) back then and so much better implemented than newer 7-zip AES encryption (which needed couple of years and several iteration before getting done properly).

    Zip64 in cZipArchive is long overdue and I'll just make a new branch and start working on it now that I have a compact long filenames and large 2GB+ stream support implementation available. Have a couple of ideas for refactoring (and breaking compatibility with v1) too.

    cheers,
    </wqw>

  10. #10

    Thread Starter
    Addicted Member Wolfgang Enzinger's Avatar
    Join Date
    Apr 2014
    Location
    Munich, Germany
    Posts
    160

    Re: Using Windows XP "Compressed Folder" shell extension to work with .zip files

    Quote Originally Posted by fafalone View Post
    What exactly do you need to do... just creating/listing/extracting with IShellItem is trivial; you only need complex solutions like the thread you linked if you need to do partial extractions and other more complex work that Edanmo's class didn't do.
    Yes, I need to work a litte bit more "under the hood" here than just extracting a whole ZIP archive.

    A little bit of background: my main project is a GIS (Geographic Information System) that is operating in ~ 100 networks which are more or less separated from each other. The program runs without installation, so program and data files are simply located on a file server, and the program is started over client mappings.

    Very simple actually, and so are updates. The local admins download a (mostly quite huge) ZIP archive and integrate the contained directory structure into the existing one on their respective fileservers.

    But lots of things can go wrong during this process. Some integrate the new files into the wrong directory level; sometimes existing files on the server are still in use and cannot be overwritten, and some admins then simply stop the whole process at this point. Some use unpackers that behave strangely by themselves. Some skip one update pack and apply the next one despite all warnings that this will likely break things. And so on. As a result, either the old version is still in use and people wonder where the update is, or things don't match anymore and the environment is broken.

    Not quite easy for support folks to find out what happened and how to fix it.

    So I decided to make my own unpacker, with these features:

    * checks by a few indicators if the given ZIP file is actually an update of my software and not just any ZIP file
    * checks, with help of reserved filenames within the ZIP, whether the update in this ZIP can be applied to the existing installation (otherwise, a previous update was skipped and must be installed first, or a completely new installation is required)
    * checks for each existing file if it can be overwritten; if not, the user is informed which file it is so he/she gets a chance to unlock the file and then retry.
    * checks in advance if an existing file is up to date already and thus doesn't need to be updated
    * logs every action to a text file which can be sent to the support in case anything doesn't work as expected
    * and most of all: the unpacker knows, derived from where he himself is located, where the new files must be copied to.

    So a "black box" like "unpack the entire ZIP to somewhere" isn't enough here, I need to have access to almost any step during the unpacking process.

    The good thing is that your code using IStorage and IShellFolder allows exactly that; thank you! I mainly had to add some error handling, and now I have to integrate that into a suitable frontend; it will likely result in a console application.

    Best regards,
    Wolfgang

  11. #11

    Thread Starter
    Addicted Member Wolfgang Enzinger's Avatar
    Join Date
    Apr 2014
    Location
    Munich, Germany
    Posts
    160

    Re: Using Windows XP "Compressed Folder" shell extension to work with .zip files

    Quote Originally Posted by wqweto View Post
    Crypto can be broken in one way only -- an attacker can unprotect a message without having the key.
    Now that you're saying it - true.

    Quote Originally Posted by wqweto View Post
    Zip64 in cZipArchive is long overdue and I'll just make a new branch and start working on it now that I have a compact long filenames and large 2GB+ stream support implementation available. Have a couple of ideas for refactoring (and breaking compatibility with v1) too.
    That's excellent news, thank you! Looking forward to that! I'm already using your cZipArchive as a "fallback" for encrypted ZIPs; these are rarely needed here and fortunatly never touched the 2 GB barrier so far, but this may be needed in more or less near future. No problem with a compatibility break here.

    Best regards,
    Wolfgang

  12. #12
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Location
    Sofia, Bulgaria
    Posts
    5,120

    Re: Using Windows XP "Compressed Folder" shell extension to work with .zip files

    FYI, Zip64 extension support just landed in master branch of ZipArchive repository and the latest vbzip.exe version 0.3.0 companion utility now supports large files (above 4GB) incl. packing/unpacking AES encrypted ones.

    cheers,
    </wqw>

  13. #13

    Thread Starter
    Addicted Member Wolfgang Enzinger's Avatar
    Join Date
    Apr 2014
    Location
    Munich, Germany
    Posts
    160

    Re: Using Windows XP "Compressed Folder" shell extension to work with .zip files

    Quote Originally Posted by wqweto View Post
    FYI, Zip64 extension support just landed in master branch of ZipArchive repository and the latest vbzip.exe version 0.3.0 companion utility now supports large files (above 4GB) incl. packing/unpacking AES encrypted ones.
    Wow, thank you! Much appreciated!

    So my idea of on ideal world materialized much faster than I ever expected ...

    Well, this year's end-of-year-update of my GIS is almost done, but the new branch will definitely be used in the next one. This will make the whole thing much clearer, and usable in a universal way, i.e. without quirky limits. To my knowledge, this solution must be the only one that implements all relevant features, at least in COM world.

    Thanks again & best regards,
    Wolfgang

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width