I’ve got two fun The Old New Thing stories for you today, starting with a story about Windows’ ZIP file support.
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.
You’d think Windows would eventually start supporting other archive formats as well, but no.
I kind of sympathise with Microsoft on this. I’m sure they’d love to include multiple compression formats, but then winzip, winrar, etc would probably all sue. They could probably have .tar.gz .tar.bz formats but that’d be supporting UNIX and that’s “bad”.
After adding support to Unix End of Line style on Notepad 33 years late, how adding tar.gz support can be worse?
I, at fist, would agree with your statement.
Then, after thinking it for a second, I find it bull**** for this:
How many companies have sued M$ for using “ISO mount” features in the OS Core? And you have a bunch of “ISO mount” apps still alive.
I’m not sure if tar is an optional feature you need to enable – I know ssh is.
Did they also explain why they added a 10 year old version of tar?
That’s ridiculous by itself.
There are two “shipping” versions actually.
– tar and curl added since nanoserver release. These are based on libarchive
– bsdtar from powershell (the latter is kept updated).
Unfortunately neither were meant for GUI implementation. Developers wanted them for container automatisation purposes.
There is also a bug in which if you run tar from powershell it takes over the version from command line.
This is why people like Macs. Apple goes the extra mile to make things “just work” out of the box.
So The Unarchiver has been one of the most popular *3rd party apps* on macOS for years for nothing because it’s unneeded?
Except in this case they don’t. Mac OSX native archive support sucks. Even more so than Windows.
Last I checked, they still don’t support:
* RAR (which I agree with not supporting, this crap should die).
* 7Z
* XZ and generic LZMA compression
* Certain older versions of tar archives
* Certain features for ZIP archives
* LZO compression
* LZ4 compression
* Zstandard compression (but nobody supports that OOB without needing extra tools yet).
And that’s just listing stuff that’s widely used. If you include historical archive formats and less widely used modern stuff, the list is almost as long as Windows’.
There’s a reason that the Unarchiver exists (hell, it’s even a good tool on Linux, which trivially supports all of that stuff listed above, simply because you just make one call instead of having to remember what particular string of letters you need on a command to extract a given archive format).
?
The format itself is not horrible, but there’s a bunch of questionable design choices, and it’s somewhat well known in certain communities for ignoring the existence of systems that behave differently from Windows, as well as a bunch of questionable ‘features’ that make any kind of third party implementation very difficult (aside from the licensing issues, which are of course a problem in and of themselves).
In particular, just to name a few things:
* It’s handling of symbolic and hard links mirrors NTFS behavior, which means it differs from the behavior of a vast majority of systems that actually use symbolic links.
* It includes a bunch of specialized compression algorithms (though the number has been reduced in the most recent version of the file format).
* It only added UTF-8 support in the most recent revision of the archive format, despite that being the standard for pretty much everything except Windows.
* Unlike almost every other widely used archive format, it’s not an open format (this is why there’s essentially no third-party support at all, as compared to ZIP, which almost everyone supports, which in turn means that you can’t really guarantee that anybody is able to access anything you compress with it).
Hm, then I wonder why the pirate “scene” standardises on RAR… (or at least it did last I checked, half a decade ago or so)
Japanese versions of Windows have native LHA support like Zip, but I can’t attest to how well it works.
Why? Is it used for some reason that much in Japan?
Somehow my comment got posted to the wrong article.
I wasn’t going to post here, but…go 7zip!
Edited 2018-05-22 00:12 UTC
I can’t say how well it works, but one of the commenters on that The Old New Thing post pointed out a 3rd-party shell extension that wraps up 7zip’s backend code into a Compressed Folders-style frontend:
https://www.zabkat.com/blog/compressed-folder-shell-extension.htm
I can’t say anything else than ‘ridiculous’. There are plenty of Open Source compression algorithms and programs, including the ZIP format. Sure, back in the XP days Microsoft was hostile towards FOSS, but now they claim they aren’t any more. Hell, they surely ship Open Sourced compression software inside Windows Subsystem for Linux.
Archive handling in Windows is still “good enough”. For anything more advanced you’ll install 3rd party archivers anyway. Windows natively does the bare minimum required for most users and that’s just good enough. There are much bigger issues with Windows to criticise.
And still a shame for such a big corporation to admit they lack the engineering power for such a tiny detail.
They won’t allocate any workforce to it precisely BECAUSE it’s such a tiny detail. It’s just not worth their attention, all the hassle etc. It’s just a tiny detail, why would you bother your engineers with it and distract them from real work?
Windows does include support for multiple compression formats.
Check the app store.
How is this any different to apt-get install p7zip?
If you’re asking that the default install should include pre-installed support for multiple formats: why should it?
I’d be more in favor to REMOVE the pre-installed zip support.
This would incentivise users to look in the app store and become aware there are more options, have more choice, etc.
There’s no need for Microsoft to re-invent the wheel here. There is rich, free support for compression already.
Edited 2018-05-22 11:32 UTC
Except you don’t work with thousands of servers where you cannot install any outside software even if it’s free. Windows native ZIP support becomes insanely useful when you need to extract considerable amounts of text logs or packet captures over slow links. Being higly compressible (often ~10 times) these formats benefit a great deal from integrated Windows ZIP suppor and you save countless hours in the end.
In a (windows) server environment, any sane deployment would have a compression tool installed at deployment time if the environment was going to require such work. One which the owner is comfortable with in terms of security.
If you’re admining a server that truly does require the level of lockdown that you cannot have any non-microsoft software as it’s standard deployment (lol), you should not be (de)compressing random archives on it.
Edited 2018-05-22 13:54 UTC
Sure. Problem is, a lot of work environments are not sane and neither were some of the people who set them up. Hindsight being 20/20 and all that.
Yeah get that.
I agree windows should have *a* built in archive tool – purely for the purpose that was stated: admin work.
Hell I don’t care if it’s their own proprietary format, so long as it fits the use case well.
But expecting built in support for many popular third party archive formats I don’t agree with.
Rather an eclectic community of apps/tools than a monocultre/monolith.
You’re completely clueless, and this is why:
Who said anything about de-compressing random archives??? The only thing I need to do on servers is compress logs, not decompress random archives. Where did you get the idea I was decompressing anything on servers??
Except most people in the Unix world don’t use 7zip, they use Tar with various forms of compression, which is universally and completely supported out of box without needing any extra software on pretty much every Linux distribution in existence.
In comparison, Windows’ ZIP support is missing a number of rather important and extremely useful features (compression other than DEFLATE, AES encryption support, reliable ZIP64 support, just to name a few).
Hell, even 7zip doesn’t have particularly amazing support for stuff when compared to tools like libarchive or The Unarchiver (which is unfortunately not available on Windows natively, though you could probably get it working under WSL).
ZipFolders is just for the GUI/Explorer. It is a great little tool for normal users.
Commandline compression can be done with the compact.exe or makecab.exe tooling, which is a good enough tool for admins that have to rely on built-in tooling that is available on all machines by default.
For all other usecases….7zip!
Why would people expect Windows to include the various compressors? For example, Linux doesn’t have built-in RAR or 7Zip support either. Then you have the fact that there are tons of tools readily available that support this stuff so while some may consider it convenient for an OS to include them, it’s certainly not a drawback that it doesn’t.
An OS should focus on being an OS and not try to be all things to all people.
It’s truly adorable to see UNIX/Linux fanboys griping about Windows zip support being stuck at the “turn of the century” – and then, without ANY apparent irony whatsoever, advocate for archive formats that are stuck 20-30 years before the turn of the century. Seriously, if you’re still using compression formats that don’t even support concatenation/concatenation formats that don’t support compression in 2018, you have no room to complain about other OS’s support for compression formats.