microsoft
Non-shell based archive handling
Description of the new feature / enhancement
Relying on the Windows shell archive/zip handler feels a bit... fragile? Odd? I just ran into an issue with winget failing due to the archive handler being unregistered (see https://github.com/microsoft/winget-pkgs/issues/171477 for details). That problem is certainly my fault, and I shot myself in the foot with it. However, I noticed there's other issues in this project (e.g. #3311 and #3505) that may be a direct result of using the shell's archive handler, and I wonder if it's wise in the long term to use an archive library directly? No idea what lib would be best for this project, or the work that would be involved, but... figured I'd raise the question.
Proposed technical implementation details
No response
The only place this caused trouble was in the system context which is why the following was implemented:
- https://github.com/microsoft/winget-cli/pull/4541
We had looked at libarchive, but it wasn't available in earlier versions of Windows where WinGet is supported. We also didn't want to bloat ourselves by bringing a library along for the ride when others are already available on the system.
Fair enough, and hard to argue when my argument is based on "feels", but it also seems like the two linked issues aren't fixable while the shell extractor is being used.
If the default registry association does not support opening the zip file as an IShellFolder, winget could fall back to accessing it directly by CLSID.
