Why is Windows Compressed Folders (Zip folders) support stuck at the turn of the century?


Every so often, a customer will ask whether Windows Compressed Folders (Zip folders) supports something fancy like AES encryption, and we have to shake our head and apologize. "Sorry, no."

Why this sad state of affairs?

The compression and decompression code for Zip folders was licensed from a third party. This happened during the development of Windows XP. This means that the feature set of Zip folders was locked to whatever features were hip and cool as of around the year 2000.

Since its release in Windows XP, Zip folders has not been actively developed. The reason is the usual: Because adding features requires engineering resources, and engineering resources are limited. Furthermore, since the compression and decompression code weren't written by anybody from Microsoft, there is no expertise in the code base, which means that debugging and making changes is a very difficult undertaking. (Sound familiar?)

AES encryption was added to the ZIP file format in 2003, which is after active development ceased (and after the ink on the license agreement had dried), so the Zip folders code in Windows XP doesn't have support for it.

One thing that did make it out of the minus 100 points deficit (which really is more like minus 1000 points because there is nobody around who understands the code) was adding Unicode file name support in Windows 7.

Bonus chatter: On of the terms of the license is that the compression and decompression code for Zip folders should be tied to UI actions and not be programmatically drivable. The main product for the company that provided the compression and decompression code is the compression and decompression code itself. If Windows allowed programs to compress and decompression files by driving the shell namespace directly, then that company would have given away their entire business!

This is why Zip folders may work really well when manipulated in the user interface, but they aren't very helpful when you try to use them programmatically. They don't tell you when a Copy operation is done. They display password prompts for password-protected ZIP files, even if you said not to display UI. Various annoyances to make it impractical to use the Zip folders compression and decompression engine programmatically.

I recall one time a customer was setting up a system that received ZIP files from clients and uncompressed them on the server. They were planning on programmatically driving the Zip folders shell extension to accomplish this. Since it involved Zip folders, the question was sent to me for my thoughts. The first thing I thought was, "Well, I can DoS your server by sending it a password-protected ZIP file."

If your mission is manipulate ZIP files programmatically, you should use something designed and supported for programmatic manipulation of ZIP files, something like, say, the Zip­File class.

Thanks to PowerShell, you can do this from script:

[Reflection.Assembly]::LoadWithPartialName(
    "System.IO.Compression.FileSystem") | Out-Null
[System.IO.Compression.ZipFile]::CreateFromDirectory(
    $directory, $zipfile,
    [System.IO.Compression.CompressionLevel]::Optimal, $false)
Comments (85)
  1. Alan Hardman says:

    I’ve never felt like the limited feature set of Compressed Folders was an issue. It already offers far better functionality than most other operating systems’ file compression UIs, and if you really need additional features you’ll probably want something best implemented in a third-party application anyway.

  2. kantos says:

    This is one thing that if there was a Windows Uservoice I would upvote. Unfortunately this having been frozen in time means people are forced to use things like 7zip and WinRaR both of which have security issues an no patching mechanism. Having this sort of thing available as an OS API (preferably with an api compatible with gzip?) would be a huge boon. I know the code is there, IIS uses it, but as far as I know it’s not exposed anywhere documented.

    1. Kirby FC says:

      The .zip file format was created circa 1989 and its creator, Phil Katz, made the specs freely available so that anyone could write their own zip handlers. That’s why free programs like 7zip are able to exist and why there are many programs out there that routinely handle zip files. This is a weird issue, especially for a company as large and rich as Microsoft.

  3. Mikko says:

    Oh, Unicode file name support was exactly what I was going to complain about… I don’t care about all the fancy features like AES, I would just very much like if it could *create* archives with Unicode names, not just extract them.

  4. Austin says:

    In recent Windows 10 you can create ZIPs with PowerShell using Compress-Archive/Extract-Archive: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.archive/compress-archive?view=powershell-6

    Only downside is it can’t handle archives >2gb (which I think is a limitation shared with the GUI-based archiver).

    1. I believe that was a limitation in the ZIP spec in general until ZIP64 was introduced (in 2001, though it wasn’t implemented broadly until much later). Not sure why .NET wouldn’t implement that particular extension though… might be a limitation in the file streams it’s using. I’ve noticed some inconsistencies in buffers and streams where some expose a LongLength and LongIndex and others do not, forcing you to only have access to 2GB of a file.

    2. cheong00 says:

      I believe you can use System.IO.Compression namespace in .NETv4.5+ in PowerShell for older operating systems

    3. Robert Hall says:

      2017: The most popular desktop OS gets support in its primary scripting language for the most common compression format. How can this be a -100 feature? Instead a poorly performing lz library was added, the lz algorithm is surely more patented than zip, which should have been bundled in windows since day 1. Fun isn’t something one considers when using winapi, but that nano edition removed lz32.dll recently does put a smile on my face.

  5. Mikko says:

    But on another topic, doesn’t Windows happen to have another implementation for said “compression and decompression code” by which it implements e.g. loading of .appx or .docx files (which are zips under the hood)? Or is _that_ also licensed in strange ways?

    1. Chris Iverson says:

      I imagine that’s part of Microsoft Office code, not Windows code.

      1. cheong00 says:

        I would imagine there were a “licensing terms change” between Microsoft and PKWare, because .NET framework now provides programmatic mean to do both zip and unzip, and .NET runtime is an optional “windows feature” that comes with installation media of Windows OS.

        Also, IMO those companies selling archiving algorithm nowadays only care about the ability to create archive but not extracting archive. RARSoft was giving away the unrar library so that utility programs such as 7-Zip can extract RAR but not create RAR file. The allows the algorithm to reinforce its “industrial standard” status. I suspect if Microsoft just ask them if Microsoft is allowed to add code to extract AES encrypted ZIP files, it would be an easy okay.

        1. Giacomo says:

          Why do you think it was PKWare?

  6. RaceProUK says:

    Presumably, the ZIP code in .NET is independent of the ZIP code powering Compressed Folders. If this is the case, then why not re-implement Compressed Folders using the .NET implementation (converted to native if necessary)? That way, MS would then be able to extend support to include AES encryption and ZIP64, and also allow programmatic manipulation of ZIP files.

    And yes, I realise I’ve asked a question that has likely been asked dozens of times already :)

    1. pc says:

      I’m sure you and I weren’t the only ones with that thought. It’s not clear to me if Raymond is trying to say that the “terms of the license” actually prohibits Microsoft from implementing their own Zip shell extension (hopefully only until some specific future date), or whether it’s just prohibiting Microsoft from using this licensed shell extension for those purposes.

      Companies get upset with Microsoft when they start including features in the OS that these companies had been selling (see when MS added a web browser and when they added anti-malware, just to name a couple), and beyond legal anti-trust concerns, there’s also just the business concerns of annoying companies which provide the software that makes it worthwhile for people to buy Windows. I’m sure they sometimes feel like they can’t win, where if they continue to not include some feature inside the core OS people aren’t happy, and if they do include it then also people aren’t happy.

    2. kantos says:

      As far as I can tell there are at least three different compression implementations in the windows codebase: IIS, .NET, and Compressed folders. I’m pretty sure that none of them share code either.

      1. Marek says:

        It could be more than three. There is zlib in Windows HTTP library (client, not server). I discovered it by accident by placing a break-point into inflateInit2 function and the debugger matched it in my binary and, to my surprise, inside webio.dll.

        1. kantos says:

          All the more argument for having a single common OS maintained zlib.dll that everybody can share. I don’t think it would help compressed folders but it would allow for the rest of us to not have to duplicate functionality the OS can ship and patch.

          1. DWalker07 says:

            As was mentioned, there are other things to spend development resources on. Even if there ARE three different compression libraries in Windows, if they all work, there’s not a big incentive to refactor stuff that is working.

          2. Jan Ringoš says:

            There’s sqlite (winsqlite3.dll) in Windows 10, so that’s a start.

    3. Jason says:

      It’s likely another instance of the -100 point barrier. The existing UI and code work just fine for 90-some percent of cases, whereas using ZipFile would require someone to rewrite all the Explorer hooks, mimic the existing UI, and generally do a lot of drudge work for little to no gain. And like Raymond said, developer resources are limited.

    4. Yuhong Bao says:

      That implementation had its own problems, and they eventually switched to zlib I thinl.

  7. Koro says:

    A third-party to implement ZIP functionality, really?

    When zip file parsing/generation can easily be implemented from scratch in a day by someone who knows nothing about it, and, as for compression, zlib existed since 1995 and I believe its license is permissive enough.

    1. mimon says:

      A component that is mostly independent and implementable from scratch by someone who knows nothing about it in a reasonable timeframe is a slam dunk candidate for a component to outsource when you are short on time.

    2. zboot says:

      And yet, nobody is out there getting rich implementing this and selling it to Windows users. . .

  8. Peter Doubleday says:

    I think one obvious answer to the customer would be, “why do you want this?” Because I’m pretty sure they just read about it in an in-flight magazine.

    Compression algorithms in the shell are really nifty in theory, although I think much less useful than they were in 2000, because floppy disks are dead and bandwidth is exponentially better and, in fact, you can do compression on-the-fly on a decent network connection.

    But encryption is a different animal. If, for some reason, you wanted to encrypt a file/directory at one end, and decrypt it at the other — just pipe the zipped file through your choice of encryption algorithm (and back again at the other end). And, of course, the more useful question is “which encryption algorithm do you, the sender, and your partner, the receiver, intend to use?” It might be AES. It might not.

    I don’t even know that I’d budge the -100 point needle as much as a single digit on this one, were I a manager in charge of engineering resources.

    1. Max says:

      Compression isn’t the only advantage to compressed archives. Since multiple files can be compressed into a single compressed archive, they’re a popular way to transfer or distribute files. For example, if you need to send someone a month’s worth of logs, you can individually send them one at a time, or you can package the whole logs folder up into a single ZIP and just send that one file.

      1. Peter Doubleday says:

        “…or you can package the whole logs folder up into a single ZIP and just send that one file.”

        Indeed you can. I should have made it clear that I’m talking about compressing anything — an entire disk if you want — not just files.

        It’s important not to get fixated on the tool used for compression. Compression does one thing and one thing well — it reduces the size of the source. Encryption, on the other hand, does the opposite — if the entropy of the input equals the entropy of the output, well, it’s really not much of an encryption algorithm, is it?

        You get basic encryption for free over the wire, these days. I was puzzling over my favorite news feed, which for some reason is delivered over https, and then it occurred to me: why not? The extra bandwidth is not relevant, and who knows when that newsfeed might need encryption?

        Think of it as a pipeline. Source data -> appropriate size for transmission -> appropriate encoding -> appropriate decoding -> appropriate decompression -> back to source data.

        Separating the two steps (compression and encoding) doesn’t lose you much, if anything, in terms of comprehension, but it gives you as much flexibility as you and the other end of the conversation might need.

    2. morlamweb says:

      Compression algorithms in the shell are more than just a way to save disk space, which yes, seems quaint in an era of TB-sized volumes. They’re a convenient and nearly universally understood file packager. It’s a lot easier to package a series of photos, for example, into a single Zip and send it off versus sending hundreds of separate files, even though the disk space savings is nil for an already-compressed format.

  9. Paul Topping says:

    Sounds like a bad deal was made.

  10. Joe D says:

    I really wish there was an option to disable Zip folders in explorer. I wind up using registry hacks to remove them, but they keep getting re-enabled on random updates.

    My issue is that it’s treating them like a directory when they are not. So if I have a directory with a couple of dozen zip files in them, and I happen to open that directory in Explorer, it happily proceeds to expand the folder tree into all of the zip files.

    I want my zip files to be treated as files.

  11. AberAber says:

    At the least…it would be good if it didn’t just say “Unspecified Error”. for AES. It’s really confusing, especially for those without ever having encountered this before. If it just said something like “AES Encryption in Zip not supported natively in Windows, please download a Zip tool.” (well something that directed the user what to do)…it’d be easier to stomach Microsoft’s decision here. I think there was something similar with DVD playback, where it allow for downloading from the Windows Store or something like that (may be remembering wrong), instead of just failing with unspecified error.

    1. Naturally, code written before the AES feature was introduced cannot have an error message talking about a feature that didn’t exist. As far as old code is concerned, the file appears to be corrupted.

      1. AberAber says:

        Knowing nothing about the way the Windows or Zip code works, I wonder if Microsoft could somehow pre-process the zip header themselves in new code (before using whatever licensed zip tool you have used and are locked in to), and notify about the AES error beforehand, avoiding some confusion.

        1. Just for you, I took a look at the code. It took a while even to find the part that checks the flags that would indicate AES. (Somebody didn’t believe in giving names to constants.) And I don’t know what sort of header preprocessing leads to automatic code generation that detects and reports AES.

          1. Joshua says:

            I’m pretty sure he meant use the .NET code as a reference to write a new header parser to check if a file is AES.

          2. I’m not going to throw out the old header parser and replace it with a new one inspired by the .NET version. That parser is almost certainly tightly-coupled to the rest of the code.

      2. bystander says:

        I feel like you can’t blame all deficiencies on old code, especially given MS resources.
        Yes, pre-AES code didn’t have a crystal ball and could not have a clear error message for a future feature.
        Maybe, ZIP is not high enough on the priority list to warrant assigning resources to support new features.

        But in 15 years, you could have added some error handling and a helpful error message.
        The user experience is bad and you’re just making up excuses.

        1. Drak says:

          In 15 years, I’ve not had a single ZIP file on any Windows machine that used AES encryption. So perhaps your case is an edge case, and Raymond isn’t making excuses for not implementing something that could cause bugs for the majority of users to satisfy a minority of users (who can probably figure out what the problem is themselves anyway).

          1. bystander says:

            Many people won’t try to open an AES-encrypted zip, ever. Good for you that you belong to this group.
            Turns out some of my customers have sent me a bunch of files by e-mail in a single AES-encrypted zip archive. I would say it’s a reasonable use-case if you’re going to transmit files by e-mail.

            As Raymond himself mentionned before, when you have 200 millions customers, even a small percentage of them is a lot of people.
            I’m making up numbers, but if as few as 0.5% of users have seen an encrypted zip at least once, that would still be 1 million customers affected.

            Turn it anyway you want but “Unspecified Error” is a terrible UX. That’s a fact.
            It could be “AES encryption is not supported” with relatively little resources and little risk for existing users. I have a hard time believing that making this change is that much of a deal for a behemoth like Microsoft. Raymond could say “we just don’t care”, but instead he’s making up excuses about the code being older than the feature… If he _wanted_ to do something about, he _could_.

          2. morlamweb says:

            @bystander and Drak: if AES-encrypted Zip files were to somehow become as commonplace as unencrypted Zips, and if users were to run those files through the compressed Files feature, then I supposed that would move the needle on the -100 points deficit. The feature set is limited to just the most common Zip file cases circa 2000, which are still the most common cases today. I would reasonably expect that a user who receives Zip files with post-2000 encryption algorithms would have a separate tool to handle those files.

          3. Erik F says:

            I believe that ZIP files are much less important as a transfer mechanism today than they were even a couple of years ago. I remember when most Web sites stored their downloadables as ZIP, RAR, or GZ files on an FTP server; now FTP servers as essentially gone on many sites and have been replaced with cloud storage or torrents (or some equivalent.) One of the first things that I used to do was install 7-Zip because I often encountered oddball archives; since 2010 or so, I haven’t bothered doing so and honestly rarely missed it. As for the new features that were added to the ZIP format this century, I think that, like CD-I and HD-DVD, most came too late to gain widespread adoption and other technologies filled the need: I certainly have never handled a ZIP file using any of the features except for ZIP64.

  12. AberAber says:

    Also, hasn’t 7zip and Gzip even, made big advances every year in zip compression since the year 2000? It seems like there would be a benefit with much smaller files, maybe faster times, even without updating to AES, but just updating the zipping algorithm.

    1. cheong00 says:

      System.IO.Compression.DeflateStream that added in .NETv2 was switched to use zlib instead of built-in deflate algorithm as of .NETv4.5 because of the same reason.

  13. Wayne says:

    I wish there was a good way to turn off zip folders in Windows (a files and folder setting would be awesome). The feature is confusing on it’s face (is it a file or is it a folder?) and typically causes more problems than it solves. It used to be a simple matter of unregistering the zipfldr.dll COM component but it’s no longer that simple.

    If Microsoft isn’t going to update this feature (or make it user friendly) then they should at least allow us to turn it off.

  14. Native Zip support was one of the new features in Windows ME I enjoyed the most. No more need for WinZip and other nagware!

    I have never felt restricted by the limited functionality of Windows’ Zip support. Still, I do find it somewhat interesting that a lack of resources hinders the development of this (moderately advanced) feature, given the fact that Microsoft is one of the world’s largest companies. I suspect that the demand for improved Zip support is pretty low — maybe most users are as satisfied with the current functionality as I am.

    1. Rick C says:

      There are some edge cases where the built-in zip functionality falls down badly. The main one is large zip archives with lots of subfolders and files. Use Windows to unzip, say, the Eclipse zip file, and it could take 10-15 minutes (even with an SSD, when you’re extracting from one physical drive to a different one!), whereas WinZip can do it in just a couple.

      1. Drak says:

        It may be slow, but it does work. The majority of Windows users aren’t going to be unzipping huge files anyway, and if they do, the don’t have any expectation that it’s going to be quick.

  15. Yuhong Bao says:

    It dates back to Plus! for Windows 98 I think, and was also in Windows Me.

    1. Osexpert says:

      It had to be a different code: june 17, 2002 press release “We are very pleased to announce that Microsoft has chosen Inner Media’s DynaZip technology to provide the compression backbone for their Windows XP Compressed Folder features,” says Inner Media President, Neil Rosenberg. “

      1. That could just be a continuing engagement kind of announcement sort of thing. It wouldn’t surprise me if Microsoft went back to the same vendor and said, “Hey, this needs to work against NT now.”

        1. GP.Burth says:

          “Anybody who has worked with the Compressed Folders feature currently in Windows XP will know that DynaZip will probably be an improvement, as the Compressed Folders feature isn’t exactly a top performer. ” – source linked in “Website”.

  16. Richard says:

    Honestly, the bits I hate about ZIP in Explorer are the weird arbitrary limitations in what you can do from the UI.
    eg you can’t drag’n’drop move or copy from one compressed folder into another, or even open a file with a non-default handler.

    Plus it grinds to an absolute halt when simply directory listing inside a ZIP that contains a thousand files. No excuse for that, given how ZIP works internally.

  17. florian says:

    I’m always amazed with the Cabinet (.cab) compression format. It has good command line utilities, more than competitive compression ratios, and Windows built-in support for decompression. It’s a convenient solution to attach text or configuration files as compressed resources to executable files.

    1. Stefan Kanthak says:

      There’s more!
      0. .CAB is Windows native archive format!
      1. the “Microsoft Update” files .MSU of Vista and newer versions are .CABs.
      2. the “Microsoft Installer” uses external .CABs, or .CABs embedded into .MSI and .MSP, and processes them without unpacking the .CABs to disk.
      3. the SetupAPI introduced with ’95 can install directly from .CABs (https://msdn.microsoft.com/en-us/library//aa376957.aspx); it can even run .INF scripts packaged in .CABs (https://msdn.microsoft.com/en-us/library/aa768006.aspx).

      1. If it was made into a standard, it would be interesting to perform comparisons against the other major compression algorithms to see how well it fares. But my guess is that Microsoft is happy keeping it internal instead of effectively “productizing” it.

        1. florian says:

          For everyday use, i.e. with a reasonable speed vs. archive size tradeoff, I’m absolutely happy with CAB (my “gut-feeling” is that the resulting archives are small enough).

          There’s a nice zip utility [0] to produce standard zip-files even smaller than what’s possible with 7-Zip, but it’s taking much longer, so I’m using it only for automated tasks.

          [0] http://www.advsys.net/ken/utils.htm

          1. Stefan Kanthak says:

            .CAB archives of Windows executables are typically just half the size of .ZIP archives, sometimes much less,

        2. Stefan Kanthak says:

          Which part of “it’s Windows native archive format”, i.e. the standard on Windows, is not understood?
          JFTR: Microsoft published the format specification https://msdn.microsoft.com/en-us/library/bb267310.aspx in the last millennium.

  18. Azarien says:

    “Because adding features requires engineering resources, and engineering resources are limited” – I wish Microsoft didn’t waste so much of its resources on Windows Runtime and other such things that no one really wanted.

  19. Medinoc says:

    Ah, I experienced some of the unpleasantnesses involves with trying to use the Zip Folder extension programmatically. Including the fact that when you use the SHFileOperation trick to add a file, the adding will always be done asynchronously, with no non-kludgy way to wait for it (including that it doesn’t use SHGetInstanceExplorer() as explained in May 28, 2008 article: I know, I tried. — That said, I didn’t know these functions existed until I read that article, published 5+ years after Windows XP).

    Somehow, learning at least some of those problems were intentional makes me both more and less angry about it.

  20. jon says:

    Exactly why are engineering resources so limited, in a multi-billion dollar multi-national corporation? This excuse is one I’ve never understood.

    My own company has three employees, we licenced the same zip code as Microsoft did, then we bought the source code, updated it to support things like Unicode filenames, and all is dandy. Took a few weeks.

    Exactly how can your resources be this limited?

    1. You probably don’t have to maintain a three-million file code base.

      1. I have heard this excuse once too many. Yet, during Steve Ballmer time, Microsoft purchased other companies as if they were candy, rebranded their products, failed to gain traction, sold them to some other company and moved on. The ill-fated Expression Studio brand and the ForeFront brand were such examples. And don’t let me mention a certain very reputable European hardware manufacturer! Obviously, having to maintain a three-million codebase file has never been a problem.

        1. Peter Doubleday says:

          My own experience at Microsoft (take it as you will) is that you can make local changes quite easily. Let’s say you want to change a logit analysis to a probabilistic analysis on the server — easy! A few test gates to production, and you’re done.

          Now, imagine Raymond’s scenario, which he underestimates. Three million files is nothing at Microsoft. Add in the customer dependencies and the versions and the different operating systems and ask yourself, would you really want to build AES back into that?

          I think not. Even if the product wasn’t licensed from somebody else, it would still be a -100 engineering points before you could come up with a good reason for doing it, rather than doing something rather more relevant to your customers.

          On the plus side, from your point of view … this is why the world needs responsive three person software engineering companies that are responsive to the < 100 small companies they deal with.

          1. kantos says:

            Honestly I’d want to combine all the windows compression libs into one anyway and use that for the shell as well. I’d know at some point the Google project zero folks are going to test this code and find things I don’t want to have to fix. So personally to me the question is: What’s the cost to switch to something fairly common and standard (zlib) vs what we have now and what’s the time cost if someone finds a vuln (which they will).

      2. jon says:

        Per dollar of revenue I guarantee we maintain more code than you do!

  21. If that’s the case, Microsoft should have moved on to something free and open-source (like 7-zip) a long time ago. This would have cut down royalty fees too.But since PowerShell can now compress and decompress ZIP operations, I can only assume the restricting license terms have expired.

    1. The licensing terms are still in full force. What you see in .NET is an unrelated implementation which therefore not subject to the licensing terms that apply to the Compressed Folders implementation.

      1. Seems like the matter is more complex than it appears from your post. The interesting this is, you seem to have written to clarify things.

        Oh, well. I guess you can’t; NDA, anyone?

        1. Erik F says:

          It seems pretty clear to me: it does the minimum required for most people (which was deemed sufficient), and while Microsoft has the source code, and it’s not a codebase that anyone internally has any real knowledge of (i.e. it’s essentially a FCIB.) Making changes to it would be a massive pain, some of the extensions are patented (e.g. https://patents.google.com/patent/US7793099B2/en), and there are many, many alternatives that you can choose from to access ZIP files; this makes it unlikely as a candidate for updating, and rewriting a component that works fine in general seems silly!

          1. DWalker07 says:

            The code is a FirstCarribbean International Bank?

        2. Chris Crowther says:

          I agree, it seems pretty straight forward to me. The ZIPed folders functionality in Windows is sufficient for the majority of users’ purposes; there’s no compelling reason to do extensive changes which would soak up development resources for little benefit.

          Anyone who needs extended functionality, like AES or better compression, would be better served just installing one of the third party options, most of which integrate in to the shell window anyway (we standardised on using 7-zip at work ages ago).

  22. Erkin Alp Güney says:

    Why did you not consider replacing it by an opensource library having a suitable feature set, then?

    1. The interface to the library would be different, which means changing all the places where the existing code interacts with the library. (Oh sorry, you have different handle lifetime policies? And you encode locations in the ZIP file differently? Too bad we persisted that in the IDLIST, so now we have to add a translation layer that can take old IDLISTs and convert the locations into the new library’s format.)

      1. Robert Hall says:

        When will you learn? No, you *don’t* keep such backwards compatibility, because that will make the whole OS irrelevant in the OS market when more of your development resources are spent keeping old stuff working instead of developing new stuff that more people want. A good opportunity to break backwards compat is for example each time when the hardware architecture are changing, like going to x86-64 (b/c then applications have to be recompiled anyway). You missed that opportunity, please don’t miss the next.

        Also, as you probably know, the compression library that you licensed have had security issues because the infamous supplier stopped patching your library years ago. Please move to zlib instead, it’s free, it’s faster, supports encryption, and you’re already using it in other ms products, etc, etc. You’re really just making up excuses.

  23. deskrule says:

    here’s a NSE (should work for windows explorer too) that does most archive types, including zip/7z/rar. Read-only at present
    http://zabkat.com/blog/compressed-folder-shell-extension.htm

  24. dmex says:

    Raymond,

    Windows 10 includes the open-source libarchive library by default (system32/archiveint.dll) and that library supports tar, pax, cpio, zip, xar, lha, ar, cab, mtree, rar, gzip, bzip2, lzip, xz, lzma etc… and even includes support for… encrypted zip archives! :)

    The shell should deprecate support for “zip folders” and instead support “archives” considering the licence terms for “zip folders” are detrimental to the security of end-users while also preventing development of a modern shell experience with multi-archive support.

    The libarchive library (in your words) is an “unrelated implementation which therefore not subject to the licensing terms that apply to the Compressed Folders implementation”… and it’s already included on Windows 10. Why doesn’t the shell make use of it and add multi-archive support to Explorer?

    1. Drak says:

      Because 99% of the users are not impacted by this issue, and the other 1% know how to install and use 7zip?

    2. cheong00 says:

      “archiveint.dll” does not exists on my Win10 x64 system at home. I suspect that it comes from WSL that’s currently for Insider only.

      https://docs.microsoft.com/en-us/windows/wsl/install-win10

  25. Max says:

    The story of compressed files in Windows is a good example of how shortsighted management and careless corner-cutting can end up creating more work for everyone in the long run. The ZIP support in Windows Explorer has been left to stagnate because management didn’t want to spend resources on maintaining it or building their own…but in the end, full ZIP support had to be implemented at least twice more elsewhere in the Microsoft codebases, and the Explorer implementation couldn’t be reused for that due to the limited featureset and restrictive license terms. An outsourcing decision that seemed like a labor-saver at the time ended up creating more work for Microsoft as a whole than if they’d just developed their own non-encumbered library in the first place and reused the code (or at least the expertise) across products.

  26. BobbySalsa says:

    Great post, as always, Raymond.

    “Since its release in Windows XP, Zip folders has not been actively developed. The reason is the usual: Because adding features requires engineering resources, and engineering resources are limited. Furthermore, since the compression and decompression code weren’t written by anybody from Microsoft, there is no expertise in the code base, which means that debugging and making changes is a very difficult undertaking. ”

    Has there ever been a reported security vulnerability regarding Zip Folders in Windows? I presume the limited expertise in this code base would make fixing them more difficult.

    Besides Pinball and ZIP folders, how many other parts of Windows are like this? :-)

  27. Marijn says:

    Did the old Win7 image preview application have special knowledge about zip files? It could show the previous/next image in those, while its Win10 counterpart cannot.

    However seemingly from https://answers.microsoft.com/en-us/windows/forum/windows_10-files-winpc/windows-photo-viewer-cant-navigate-to-prevnext/b82ab5ac-a310-4a44-9d13-3db9dc95dc0e this functionality doesn’t always work on Win7 either.

  28. Seva Alekseyev says:

    For the record, ZIP shell folders *are* programmable. Scriptable, even. Create a COM object “Shell.Application”, then call Namespace(), passing the ZIP name.

Comments are closed.

Skip to main content