I have quite a few posts lined up, and I’m excited about all of them, but… I’m very stressed, and writing is very hard right now. So in the meantime, this post title-links to a very cool recent writeup by Gravislizard, a streamer (&c.) whose dives into retro computing I really admire. The linked post compares basically every notable revision to Windows Explorer since… before it was even called Explorer. Twenty little writeups complete with screenshots, from Windows 1.04 to Windows 10. Lovely little trip through history.
I’m in the middle of quite a few posts, and honestly… this one should be pretty short because I had no idea I’d be writing it. I’m trying to make my Windows experience as pleasant as possible (that itself is an upcoming post), and part of that has involved looking for a good archive tool. Windows handles ZIP files well enough, but it’s kind of a barebones approach and it doesn’t handle any of the other major archive formats that I’m aware of. I looked at a few alternatives; as is typical for Windows they basically all had miserable, nonstandard user interfaces. Many appeared to be adware or scummy bundle situations. I only ended up testing three, and didn’t make it very far with one of them (PeaZip), simply because whatever Linux-esque toolkit it was made with prevented it from working with FancyZones.
So I tried out 7-Zip, WinZip, and benchmarked these against the inbuilt Windows archiver. I’m not settled on anything yet, but both of the alternatives offer support for all of the common archive formats; 7-Zip supports a ton of additional formats. WinZip wins on the UI/UX front, feeling nearly native and offering a nice dual-pane view; 7-Zip is pretty barebones in this department. 7-Zip is free, open-source software; WinZip is proprietary, closed-source software with a $29 price tag.
What really shocked me, however, were the benchmarks. I wanted to test ZIP files specifically, as I run into them most often (other formats tend to be things I’ll be handling on the Linux side of things), and I couldn’t benchmark anything else against the inbuilt Windows archiver. My test machine is an 8th Gen Core i7, quad-core @ 1.8GHz, with 16GB RAM and only Intel onboard graphics. WinZip has an option to use OpenCL and offload the task to the GPU; I thought it would handily outperform the others accordingly. Only 7-Zip has a built in timer, so results on the other two may have been off by a second or two as I was doing it manually with a stopwatch. I did three runs of each and averaged. The test was enwik9, the first 109 bytes of English Wikipedia. A gigabyte of source that reliably FLATEs down to under 350MB.
- 7-Zip was the slowest, which did not surprise me. It took about two and a half minutes, and compressed very well, down to ~313MB.
- Without OpenCL enabled, WinZip was the second slowest, but the most highly compressed. Despite being next-to-last for speed, it still shaved around 50 seconds off of 7-Zip, averaging about one minute and forty seconds. File size was ~311MB.
- OpenCL-enabled WinZip blazed through it at around a minute and ten seconds. This was about what I expected; the performance was excellent. Compression was the third worst with a final file size of ~318MB. It kept the GPU around 50% throughout.
- Windows tore through the file. Its progress bar basically did nothing for about 30 seconds. This coupled with my lack of faith in the archiver actually led me to miss my first attempt with it. Then I assumed that it crashed, leaving a corrupt file. Nope. Averaging at around 45 seconds, though leaving the largest file at ~327MB, it worked reliably, and it worked quickly. It wasn’t using GPU, and it only pegged a single core. I’m floored by how fast it was.
YMMV, of course, and this was… a single giant file run through only a handful of times. But I was shocked that Windows tore through a gigabyte source so quickly. Unzipping any of the resultant files was uniformly fast; decompression is not an intensive task. I don’t know that there’s an actual takeaway here, but I was shocked by the speed at which Windows compressed that file.
Earlier this week, Tom Scott posted a video to YouTube about the forbidden filenames in Windows. It’s an interesting subject that comes up often in discussions of computing esoterica, and Scott does an excellent job of explaining it without being too heavy on tech knowledge. Then the video pivots; what was ostensibly a discussion on one little Windows quirk turns into a broader discussion on backward compatibility, and this inevitably turns into a matter of Apple vs. Microsoft. At this point, I think Scott does Apple a bit of a disservice.
If you’ve read much of my material here, you’ll know I don’t have much of a horse in this race; I’m not in love with either company or their products. I’m writing this post from WSL/Ubuntu under Windows 10, a truly unholy matrimony of software. And while I could easily list off my disappointments with MacOS, I genuinely find Windows an absolute shame to use as a day-to-day, personal operating system. One of my largest issues is how much of it is steeped in weird legacy garbage. A prime example is the fact that Windows 10 has both ‘Settings’ and ‘Control Panel’ applications, with two entirely different user experiences and a seemingly random venn diagram of what is accessible from where.
This all comes down to Microsoft’s obsession with backward compatibility, which has its ups and downs. Apple prioritizes a streamlined, smooth experience over backward compatibility, yet they’ve still gone out of their way to support a reasonable amount of backward compatibility throughout their history. They’ve transitioned processor architecture twice, each time adding a translation layer to the operating system to extend the service life of software. I think they do precisely the right amount of backward compatibility to reduce bloat and confusion. It makes for a better everyday, personal operating system.
That doesn’t make it, however, a better operating system overall; it would be absurd to assume that one approach can be generally declared better. Microsoft’s level of obsession in this regard is crucial for, say, enterprise activities, small businesses that can’t afford to upgrade decades-old accounting software, and gaming. There is absolutely comfort in knowing that you can run (with varying levels of success) Microsoft Works from 2007 on your brand new machine. It’s incredibly valuable, and it requires a ton of due diligence from the Windows team.
So, this isn’t to knock Microsoft at all, but it is why I think dismissing Apple for a lack of backward compatibility is an imperfect assessment. I’ve been thinking about this sort of thing a lot lately as I decide what to do moving forward with this machine – do I dual-boot or try to live full-time in Windows 10 with WSL. And I’ve been thinking about it a lot precisely because of how unpleasant I find Windows to be. Thinking about that has made me examine why, and what my ideal computing experience is. Which is another post for another day, as I continue to try to make my Windows experience as usable as possible. Also, I’m not in any way trying to put down Scott’s video, which I highly recommend everyone watch; it was enjoyable even with prior knowledge of the forbidden filenames. It just happened to time perfectly with my own thoughts on levels of backward compatibility.