Microsoft finally gets around to supporting rar, gz and tar files in Windows Microsoft has signaled it will add native support for tar, 7-zip, rar, gz and "many other" archive file formats to Windows. Redmond's not cooked up some super-duper decompressor: it's used the libarchive open source project to pull this off. Windows has offered native support for the zip file format since Windows 98. In those …
Embrace... now what were the next couple of steps?
To be honest, Windows could claim to support WMF and I'd still rather open them in an entirely different program that whatever MS wants me to open them in.
Hell, Chrome still keeps trying to open my PDFs and I have to tell it to beggar off on a regular basis!
What makes you say that? I've just put some files in a password-protected zip archive. If I try to open one, I'm asked for the password. If I try to extract it, I'm asked for the password. In both cases, when I enter the right password, it decrypts it and opens as expected. What problems did you notice?
"The apps often demand acquisition of a paid license after a few days' use. Also, criminals noticed the constant demand for decompressors, making them a target for ridealong adware and malware. Many a download site also tried to confuse those who sought decompression tools with dark patterns, luring users to unintended downloads.
But if you managed to find a legitimate download that didn't infect your computer, enslave you to the criminal underworld or harass you with advertising, the ads mostly worked just fine.
All of that will soon, hopefully, be behind us."
This seems unfair. 7-Zip is free and open source, available at 7-zip.org. No malware, no ads, and the first thing that pops up when doing a Google search (yes. also in Incognito mode, so not an artifact of my search history).
WinRAR OTOH is of course trialware, and should have been dead years ago. I have no idea why anyone would ever recommend it.
Windows Registry Editor Version 5.00
; Created by: Shawn Brink
; Create on: October 4, 2021
; Tutorial: https://www.elevenforum.com/t/disable-show-more-options-context-menu-in-windows-11.1589/
[HKEY_CURRENT_USER\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32]
@=""
; or
; reg add HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32 /ve /d "" /f
; from a command prompt, /ve = null, /d = data, /f = no prompt
RAR was best for integrity and spanning disks across large sets. ZIP could do it (hell, I even know the PKZIP command-line syntax even today), but RAR allowed you to add some more "integrity" to the files so they were more likely to survive corruption.
RAR should have been dead since the days of the floppy, though, it's only used as some kind of "hacker" cachet label, to show you were around in the heyday of "Software Name (cracked).r57" and hoping and praying you could get the complete set off Usenet before it disappeared.
RAR serves no useful purpose nowadays.
Even PAR (which is designed to have a configurable amount of redundancy to avoid data corruption) is pretty niche and obsolete nowadays. Data storage corruption is far less of an issue than it ever was now.
7z has better compressions, but nothing that ZIP couldn't add with a "ZIP v4" or whatever we're up to now (PK/WinZIP extended ZIP with AES encryption, etc. over the years). To be honest, compression is far less an issue now than it ever was. Short of disk space? Buy another few Tb. Far beyond the old releases where people would down-sample in-game FMV just to try to shrink it into a sensible number of RAR files, etc. and used RAR rather than ZIP (before 7z existed) to get a few more bytes on the disk.
I used IZArc for years until it went ad-ware, and I'm now on Peazip. Because I want one tool that handles compressed files, and only one. RAR and WinZip are dead, and even 7z.exe is only on my computer as a command-line version to plug into Peazip (I think).
They seem to be largely used as container files these days anyway. If you look at a releases page on Github, the zipped files are more or less the same size as their unzipped contents. It makes sense, especially for projects with daily versions, the time to compress the file would probably be more than the extra time needed to upload it uncompressed. I think 7-zip defaults to Fastest anyway.
> RAR should have been dead since the days of the floppy, though, it's only used as some kind of "hacker" cachet label
That would be the ZOO file.
> RAR serves no useful purpose nowadays
All of the formats are much of a muchness (bar "I can compress just that little bit better than you") and if one is established in a niche there is no reason (other than "give me the shiny or die") to just stop using it (and having to change otherwise perfectly functional code for no good reason).
You may not (knowingly!) be using RAR files, but I've downloaded some from perfectly safe places fairly recently: e.g. paid good money for totally legit copies of comics & GNs from Humble Bundle and downloaded them as CBR files.
RAR is a container format (much like the media container formats for video/audio), so it's not really apples to apples to compare it to bzip. Here are some of my other thoughts.
1: It is still intrinsically part of the Unix ecosystem, invisible to most on a day to day basis as the operating system quietly manages packages and libraries in the background.
2: RAR isn't a compression format and it was chained with zip, bzip, or another compression tool for decades. For convenience zip compression support was added on many platforms.
3: PAR is awesome tech and some clever math, but is also an over the top add on. Since most people experienced PAR on Usenet or a similar service where the idea was to maximize the recoverability individual files withing a larger archive that had been split up, it made less sense to compress or encrypt the parts of a file, and video files were already compressed due to the video codecs
4: It is just as relevant as ever to compress data in flight, even down to the hardware layer. Systems are starting to compress data at rest in RAM now, because fast cpu efficient compression is so cheap now with a modern CPU it is often faster to compress/decompress data in the memory tier than to pull from a deeper storage tier. It literally takes less time to decompress the block you just got than to read and wait for the next block.
5: so as a container format, you can compress whatever you want, however you want, and even include the tools to extract whatever that is, and in most cases end up using significantly less space than you started.
6: All the little things add up to big things at scale. Why do you think that web developers push so much crap JavaScript onto your machine? Becuase using 95% of your CPU costs them nothing, and if it saves them 5% overhead on their end, that is one less server in a rack, one less rack used in row. The lowest storage tiers may not be expensive, but the middle ones are, and the power that drives them has bigger costs too. So inline and on the fly compression is a comparatively easy drop in, and low hanging fruit for performance enhancements, and it can achieve similar gains without the expert time and cost of line-by-line performance tuning of a code base.
"RAR serves no useful purpose nowadays."
I have a use for it - it's my password manager. I chose .rar because a-shell on iOS has the unrar command, so the following works on all platforms:
$ unrar p passwords.txt passwords.rar | grep -F "theregister.com"
Speaking of which, unrar is reverse engineered and I suppose the WinRAR team let it go because it's Linux and not Windows. So now Microsoft is taking that open source code, what will the lawyers do?
OK, OK – crumbs, we didn't intend to lump 7-zip in with the paid-for others, though we can see how people read it that way. We've made the wording clearer and linked to the project.
Don't forget to email corrections@theregister.com if you spot something odd. Us humans will get onto it and fix it.
C.
Domain squatters, SEO-bombing, and "Download portal" sites all slinging adware or malware infested installer bundles make getting a clean copy of 7-zip or other popular free or open source tools something that requires a degree of situational awareness.
Worse was when the big download sites, that had offered clean downloads and a searchable index, started to go the dark side. This meant that the developers site was getting crushed by traffic by users hunting for a more reliable download source then cnet or tucows, and even the big source repo sites started to go the dark side.
The big search engines getting slapped on the wrist pushed the Developers sites up in most cases, and the scammers down, but the issues still remain largely unaddressed.
I'm not quite sure why WinRAR should die - Never got any adware or such from the installer, though I haven't looked for a few years once 7-Zip either caught up in speed, or Moore's Law and faster SSDs made the point moot. "Trialware" always just seemed like an honour system in WinRAR's case. Not like they made a huge effort to stop people using it after the trial expired.
I have certainly got my money's worth from the (I assume) still-functioning license I purchased in... let's see... 2009.
that the ability to ask what the time is in Cyprus, or the ability to book flights and hotels there, is properly a function of an operating system, whose job is surely to allocate processor resources to applications as required?
As a test, I just asked a search engine what time it was in Cypress, and sure enough, it offered dozens of possibilities.
You don't suppose this could be (whisper it) an MS-sponsored retail opportunity?
I’m a developer, at times, know what I want?
Less fucking distractions, and more available RAM for my actual applications. Shut up Teams and stop eating 4 fucking GB while you’re sitting there doing nothing, I can’t open a fucking browser tab.
Literally can’t code, browse, and be “available” at the same time, with 16Gb of RAM. A joke. Bye Teams… I’ve got work to do
I'll agree with the OP.
Why not just open them? It's like when someone [who I don't know, even those that do] sending an .XLS file and just 'expect' me to be able to handle and open it, because OF COURSE they use Excel, why don't you??
.RAR is not a Windows-standard file format. I'm with the OP, send the file in a damn compatible standard, you know you're sending it to a Windows user, don't make me [go download the equivalent of a Signal app because you use it and expect me to]. It's RUDE to send a file format that isn't a "universal" standard and expect others to deal with it; send that spreadsheet as a PDF, damnit, that's why it was created.
I'm fed up with everyone deciding what is good for everyone else by expecting *their* choice of (some proprietary app) to be used by everyone who *ever* comes in contact with them.
"It's RUDE to send a file format that isn't a "universal" standard and expect others to deal with it;"
I feel two ways about this. (1) I wish people would stick to open standards. (2) The more people there are using computers, the more _ignorant_ people there are using computers, so I'm happy just to be getting _something_ digital from them.
As I see it, it's not the hapless end user with the losing ticket in the file format sweepstakes. They really don't know any better. The blame lies with the OS and application vendors, and we all know their motivations. Since I'm multilingual in file-format-speak, I just suck it up and do the translation on my end, both ways if necessary. There too many monolingual people out there for us to make any real changes, let's not go tilting at windmills.
Look, everyone just uses variations on the .norm normal file format. Just go with the flow...
> send that spreadsheet as a PDF, damnit, that's why it was created.
Just so long as you only want a copy that looks like it was printed.
But if you were expected to use it as a, well, a spreadsheet, PDF will be pretty useless.
> they use Excel, why don't you?
Other programs can eat XLS...
> It's RUDE to send a file format that isn't a "universal" standard and expect others to deal with
As already pointed put, the most well-used archivers, such as Winzip and 7z, handle all the old formats as well - if the user just double-clicked, it'll open, same as a ZIP. And now MS is even extending that to opening in Explorer.
> .RAR is not a Windows-standard file format
If you want a properly Windows-standard file that competes with RAR then you presumably are looking to using CAB files? Windows did, eventually, add some support for looking inside ZIP files, but they aren't a Windows native format, more there because they had their arm twisted.
Sending a spreadsheet as a PDF breaks a lot of things. Try sorting that data in a different way than it was. Try importing that data into a database. Try making a graph out of it. You'll spend much longer on any of those tasks than if you opened that spreadsheet in a spreadsheet program, nearly all of which can open the Excel format. I don't have Excel on this computer, but I do have Libreoffice and it can also open those. I also have libraries allowing me to import them into programs or scripts. In addition, it's not as if PDF is a universal format. Currently, Windows includes a PDF reader by default, but not that long ago, they didn't and you had to install one. That wasn't difficult, but I don't know why you think that's a much more universal format.
As for .rar, I never create them, but if someone has sent it to me, I can read it. Unless there's some problem actually processing the file they've sent, I think it's a bit rude to demand they change their workflow if you're perfectly capable of dealing with their file.
I'm curious what list of formats you think are "universal standard" ones. If you're only including ones that can be processed by the bundled programs that come with a basic Windows installation, that's a relatively small list.
"I'm curious what list of formats you think are "universal standard" ones."
The closet "universal standard" would probably be 7-bit ASCII. Apart from the languages that don't use the same alphabet, ie a fair chunk of the world. And even then, you'd still still need to install bin2hex and hex2bin to convert anything not in 7-bit ASCII.
Copilot, Dev Drive and Dev Home sounds like Clippy 3: The Bloatening to me.
Of course, we'll need a shiny new (preferably Surface) PC to run this on, won't we? And a OneDrive subscription? Oh, and an Azure subscription, don't forget that. And it'll be near impossible to turn it off, if they can find a way to make that happen.
We'll be stuck moaning about it for years until they finally decide to loosen their claws. It's like Internet Explorer all over again, isn't it?
I just wish people could choose a format and stick to it. At my organisation there's no official policy or mandated format (or if there is, nobody complies) so everyone just uses whatever they like and you have to be prepared for everything. On my corporate machine I have third-party WinZip, the regular Windows zipping function, WinRAR, 7-Zip... these can open tarballs as well because I get some of those from time to time.
However, a particularly bad example I did see was an accountancy firm my mother was dealing with. She phones me up one day and says "They've sent me this strange file with my documents in and I can't open it" - after talking her through how to reveal the file extension, turns out it was 7-Zip. They hadn't told her that's what it was and it took a moment of digging to figure it out. She'd never heard of that and, obviously, didn't have it on her quite basic Windows machine. She had to forward it to me so I could repackage it as a regular Zip.
Annoying. That has to have caught out other clients before.
> On my corporate machine I have third-party WinZip, the regular Windows zipping function, WinRAR, 7-Zip...
Any reason you feel the need to have so many tools that replicate each other's functions? Perhaps if you stuck with just, say, 7zip you'd find things less confusing?
Possibly because each app has to out-do the others, so they tweak the compression or the checksumming or anything they can claim makes theirs "better" and so there is a constant arms battle for market share and the punters have to keep upgrading to the next most recent version to open a file not yet supported by the other compression apps.
Not so different to this company that sends Word files, this other company that sends OpenDoc, and this other one that sends PDFs...and there's always this outlier that will dump an RTF file on you.
And let's not talk about the gibberish that arrives from a completely screwed up translation between character sets...or, worse, entity encodings and HTML stuck in unrelated file formats, like some code pulled the data from a website and pasted into a document literally.
And just to confuse things even more, there are only so many "human readable" 3 letter extensions so they get used, reused and recycled so who the fuck knows what a .dbf or a .pub file *actually* is until you try to open it and fail! It's not like there's any filesystems out there still in common usage that is actua\lly limited to 3 letter extensions any more. An yet new apps still come long and enforce yet another recycled 3 letter extension, confusing things even further. Let's not even go near the MS default of hiding extensions debate.
I'll definitely not hear a bad word said about 7 Zip. WinZip did stuff that Windows built in zip handling didn't but it's otherwise pretty terrible. I know there are command line utilities for tar and gz files but I can never remember the incantations to use them.
Phil Katz died in 2000. If he hadn't published the Zip file format we might be using something else now. I wonder what he'd be doing now if he was still around.
Only for some files, mainly text. But you could also just enable compression on the transfer. What compression/archiving did provide was all the files at once, Windows had to use Zip because it didn't support tar.
Compression made sense when disks were small: before we had compressed folders, we have disk compression like stac. There's generally a trilemma: diskspace, CPU power and bandwidth. CPU power is probably the current bottleneck as the price per GB continues to fall.
The Internet (or even your own LAN - same thing, after all) hasn't ever compressed the data itself.
Perhaps you are thinking of the commands you used to use "back in the day" to send your data from A to B? Quite a few people had a favourite sequence they'd use each time, using streams: e.g. tar into gzip into ... [1]
[1] nope, not going to try and give a real command sequence: I'd never get all the args right without a lot of looking things up, so you'd then be all "Fule! You just overwrote the remote's /bin with your /var"
Many services support on-the-fly compression. As do some link protocols like PPP.
But that requires processing power for each and every connection. If you compress the files and then send them to a dozen people, you've only had to compress once rather than a dozen separate times (and probably achieved better compression too)
Efficiency was a big thing back then. Before people thought that replacing 3 lines of javascript with 5MB of jQuery would make things 'easier' (yes I am bitter, now get off my lawn)
As libraries went, I found JQuery reasonable both for functionality and size. It was popular because it provided a lot of extremely useful functions such as feature detection that were essential as we moved away from purely desktop websites. As time went by, less was required and it became more modular.
Caching (both on the client and server) has always been the best strategy to handle resource contention and quite a few servers effectively cached compressed versions of files. The problem with websites that were heavy users of Javascript was more related to limits on connection numbers, especially for blocking requests. With a little thought it was possible to optimise most of this so that the website would render quickly while some resources continued to load. Of course, lots of "theme" based websites will still chocka with Javascript and CSS they never needed. http2 solved most of the problems by providing persistent and reusable connections, which meant additional requests had a much lower overhead.
Dial-up modems developed the possibility of compression as well. I fiddled about with MNP 5 and V.42bis in my time. The problem was that they obviously did not work if the data you were transferring had already been compressed (like zip files) - a point my less technical colleagues failed to appreciate: "but it says 4:1 compression...".
That's an impressive set of misleading statements, most of which contain elements of truth, but which have almost nothing to do with each other, leading to entirely wrong conclusions.
1) Yes, modem-based data compression depended on line (signal) quality.
2) I don't think audio compression happened in the local loop for some time after digitalisation started (PCM/G.721) on digitalised circuits, but modems and digitalised circuits don't play together very well anyway.
Long distance and international circuits would likely have used G.721 compression, which would have made modems connect at much decreased data rates (if at all). It certainly affected faxes, and much effort was put into recognising fax tones and demodulating them and sending the data as data then remodulating at the far end, which did not work reliably (see ITU T.38).
Basically, modems are meant to work on analogue circuits, and dumping a digital (PCM) circuit in the middle, especially with compression, causes problems, so as digitalisation progressed, long-distance modem connections were more and more likely to give poor throughput. Luckily, the Internet took over.
NN
Some protocols did support compression, but doing that means that the uncompressed data takes up more space on the server and requires extra processing every time someone downloads it. If it's not going to be accessed or modified by the server other than to send it to you, there are advantages in compressing it once and just sending that compressed version, even if the speed doesn't change.
Also, it isn't guaranteed that the speed would be the same. Compression can be set up to compress as much as possible, which is slower, or to compress at a certain speed. If the compression speed was lower than the network speed, as would be the case with an old CPU or one that's serving a lot of connections, it would either slow down your connection to wait for compression to complete or make the compression less efficient so that it could send as fast as you could receive. Either way, that would be slower than compressing once and just sending you that.
I've seen this in practice when I was compressing a disk image to send it over a network. The image was certainly going to get compressed because a lot of it was empty space or very compressible text files. I originally set the compression level rather high, and this was running on an ARM chip, and not a particularly fast one. It took hours to compress that way. Meanwhile, the destination for the data was on a local network, so it would have been pretty fast to just send it. I ended up lowering the compression level to optimize the time spent compressing and the space the file would eventually take, a tradeoff that any server eventually has to make.
"I always thought internet back in the day had compression so even if you did zip it it still took roughly the same amount of time. Did it or am I making something up my mind?"
Not "the internet" as such, but even in BBS days and especially when the WWW arrived, graphics compression was pretty important to many people, hence .GIF and JPG graphics compression. Even prior to that, there was Run Length Encoding[*], popular both as a very simple graphics encoding format and even built into hard disks, RLL hard disks generally held about 50% more than standard MFM hard disks (some people even used an RLL controller with an MFM drive, living dangerously with their data! I don't recall ever losing data using a an RLL controller to make a 20MB HDD into a 32MB HDD :-))
{*] so primitive that it basically looked for "runs" of the same value and then basically stored the information to say there was a run of 35 zeros, or 29 twelves etc, which worked ok on the basic bitmapped images that were often b/w line drawings or 8/16 colours at most. PCX a slightly more complex format, is still around but has evolved out of all recognition
One key advantage of 7-Zip was (and maybe still is) how it handles encrypted archives.
With 7-Zip, you can encrypt the file names of the files within the archive. Without the password, you cannot get a list of the contents.
With zip-formatted archives, the individual file contents can be encrypted, but the file names remain in the clear (that might have changed now).
That meant that a nasty feature of zip archives was (and maybe still is) that you could replace the contents of a file within an encrypted archive with a non-encrypted substitute, and the zip decompressor would not complain about it (that also might have changed now). This allowed subversion of zip-encrypted collection of files.
One way of getting round this is to zip your collection of files, then zip the subsequent zip archive again - it won't compress further (in fact, it will expand slightly), but the non-encrypted content listing will be a single file: the actual zip archive.
I moved to using 7-Zip a long time ago, so I simply don't know if WinZip or other programs that produce zip archives sill have this behaviour. I know that ARC and RAR formats allow for encryption of the list of filenames as well, but I don't know whether the actual utilities make use of that capability.
The 'replace an encrypted file in a zip archive with a non-encrypted substitute' technique in the below stackexchange answer by l0b0 on May 14, 2013 at 8:21 still works. I just checked. 10 years later.
StackExchange: Are password-protected ZIP files secure?
The zip twice technique is described in Rowan Thorpe's answer in this StackExchange thread: How to zip directory with encryption for file names?
NN
Thanks for the heads up. I just checked rar command on linux. It also allows replacing a password-protected file with an unprotected file. Rar can encrypt the header as well, in that case it prompts for the header password before replacing the password-protected file with the unprotected version. Not the way I would expect passwords to be handled, but fortunately it doesn't affect my personal use case.
"zip your collection of files, then zip the subsequent zip archive again"
I don't see how this helps. It just kicks the can down the road. Hiding the filenames is security by obscurity. What happens when the recipient doesn't know what filenames to expect?
I don't see how this helps. It just kicks the can down the road. Hiding the filenames is security by obscurity. What happens when the recipient doesn't know what filenames to expect?
If you encrypt a zip archive of a collection of files, the filenames are in cleartext, even though the contents are in encrypted text. Someone can replace one of those encrypted files with a different file of the same name, without needing to know the encryption password. The example given in the StackOverflow answer shows this. This individual file in the updated zip archive does not have encrypted contents, but when you decrypt the archive, the zip decryption utility does not tell you this. So what might have been, for example, an encrypted .dll is replaced with a non-encrypted .dll which might do something completely different.
If you take an archive of encrypted files, then zip+encrypt it again, you end up with a new archive with a single file in it - the encrypted archive. So an attacker cannot replace a single file - they would have to replace the entire archive with a new (non encrypted) one, but without knowing the underlying file names within the encrypted archive.
So, in one sense, you are right: if the recipient has no idea of the expected filenames, we are no further forward.
If, however, you 'double encrypt', and say to the recipient on a different communications channel to the one in which you are sending the archive: "I'm sending you an encrypted archive. If you unpack it with the password 'Horse-Battery-Staple' you will find an archive that can be decrypted with the same password with a file within it named 'Squeamish-Ossifrage'. If Squeamish-Ossifrage is not there, do NOT use the archive."; then you have a chance of preventing an attack. Assuming encryption is working adequately, an attacker will not know the filename 'Squeamish-Ossifrage' and cannot replace it indetectably.
Obviously this is not ideal, and open to all sorts of social engineering to get people to accept unexpected files, but if zip is the only tool you have, it is a possible workaround. I've had to use it when communicating with people with locked-down corporate PCs that had no other (easy) possibilities than using WinZip.
NN
The file names may be important as well. If you're encrypting the contents, you may not want to rename the files to hide what they are, but leaking that metadata could be undesirable. That's in addition to the risk of replacing a file with an unencrypted substitute. Nothing is foolproof, but it's usually safer to encrypt a lot rather than leave a few things out on the assumption that nobody will care.
Before the advent of 7zip, WinRAR could compress a SQL Server backup file to one-tenth of its original size and unpack it before any of the contemporaneous zip applications could even get started. Defeating the payment nag was trivial once you found the free version.
After Microsoft began to include a compressed backup option in its Standard versions of SQL Server, the compression was only about one-fourth and recovery was slow, but predictable. So, no extra steps necessary and we lived with it.
Yes, it's all 7-Zip now if you roll your own file compression, on Windows at least. I just like to remember why some of the older stuff was great in its day.
No, I wouldn't
And I won't use Copilot any more than I'm using Cortana (which I am still hoping for a way to entirely uninstall from my PC, with Bing as well).
You're not fooling me. All of this is just to hook me up into your advertising engine and I won't have anything to do with it.
I don't need to talk to my computer, I have a cat for that.
I don't know about tar, but the Windows 10 curl is a bit complicated.
curl.se: curl shipped by Microsoft
1) "The curl tool shipped with Windows is built by and handled by Microsoft. It is a separate build that will have different features and capabilities enabled and disabled compared to the Windows builds offered by the curl project." ... "If you have problems with their curl version, report that to them. "
2) " The curl tool comes installed in addition to the dreaded curl alias that plagues Powershell users since it is an alias that runs the invoke-webrequest command and therefore isn't acting much like curl at all. A work-around is to invoke curl as "curl.exe" to prevent powershell from treating it as an alias. "
(1) Is just like any distribution repackaging curl - you should report bugs to the distribution first, so it's not necessarily a Microsoft/Windows specific thing, but worth taking note of. (2) has enraged people for quite some time.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
