This.

If you are a corporation, you must have a legal application for your employees to use. Most likely WinRAR customers have their purchase bundled with other (Microsoft) software. Or, equally, they might be unaware that they can purchase software from outside the Microsoft App Store.

Also, +1 for 7zip.

unaware ? hmm they cant be that dumb can they?:O
just the usual , probably another troll alt used for dvoting

Honestly from what i can see, only a handful of features are locked behind a licensed copy of PKWare, or Rar (Adding comments, copyright data as notes in zip files for example, though i'm thinking back to 2.04g). You can't get a piece of software popular if no one can use it.

As for Rar, well in only a handful of cases i'll get a rar file that is better compressed than what i can get using 7-zip at my preferred settings. (Ultra, 1024Mb dictionary, 273 sized matches, 3 threads). This may be due to Rar having built-in recognition of certain media types like mp3 so it actually may encode it differently that's a bit more optimized or does it's own compression on said media. I'm not sure what it does and don't recall doing before/after compares to see if the data was 1:1 exact or not.

Though i do remember when 7-zip really got my attention. I'd downloaded something like the SRD for D&D, and compressed in zip it was like 30Mb. When compressed in 7-zip it was like 1Mb. The reason is because the solid block references other files rather than each file being individually encoded. This makes sense since zip needed it's specs to be broken up so each file could be added/removed/referenced for backups and on split disks with the TOC at the end of the zip file. 7-zip you can't do this and it's all a solid file. All-or-nothing. The better compression though is probably well worth it.

nah better compression doesnt worth it anymore

How about a tar.gz?

tar.gz / .tgz files compress well enough, but remember gzip uses zlib which has a 64k window or so for the lookbehind. As such it's no better than using 7-zip at the fastest level. If a lot of very small files are put together it will probably get similar results. But more likely you will have 100k+ html files where only a handful of tags would be recognized and not carry over the larger matches that would really help it.

tar and gz are two separate operations, that just happen to be used together.

gzip is a compressed file format that, by itself, is limited compared to the likes of zip or 7z, in that it can only compress one file.

tar is a file archive format; it allows multiple files to be combined into one. (One trick I read about somewhere; if the files you want to transfer are barely unable to fit on a formatted USB drive, you might be able to tar up the files, then transfer the archive to the device file directly (using something like dd, though cp to a device file also works), and transfer them that way.) Notably, it does not compress its data.

tar.gz, then, is really a compressed tar file; gzip sees the archive as a single file, so you get something like block compression. This behaves more like 7z than zip, as I believe it's not easy to extract just one file from the archive, but it does give good compression when the files are similar.

One other interesting compressed format found on Linux is the squashfs file system. It's like a zip in that individual files can be extracted easily (in fact, it's designed to be mounted as a read-only filesystem), but I believe it finds blocks common in multiple files and dedupes them. (Note that this form of de-duplication is not as resource intensive as zfs's approach, as zfs (with dedupe enabled) has to compare each new block to be written while the file system is mounted, while squashfs doesn't bother with that.)

One use of squashfs is, in a Gentoo system, storing the portage tree there. The portage tree consists of a large number of small files, enough so that an ext2/3/4 filesystem that looks like it should be big enough to store the triee might not have enough inodes (by default). squashfs handles that case nicely, and it does compress the inode data as well.

-Because that is their price? (a.k.a the freedom to valuate their work)
-Because is a perpetual license key?
FYI, Winrar was released 26 years ago: That's less than 2usd a year (notice: And counting!)
Use the McDonalds Big Mac Index, the Starbucks conversion rate, the number of MB (yes, Mega Bytes. Not GB, Not TB: A term probably a lot of so self-smart hipsters haven't really understand at all) of HDD (Hard Disk Drive, mechanical stuff people nowadays feel repulsive to. Yes! Another thing hipsters auto-think they are gurus...), floppy disks, CD-ROMs, internet bandwidth!! (and the hours waiting for successful transfers)... saved during 26 years, account it along those 26 years and then tell me how insulting the license cost is!
Somebody here remember how costly were all those? "Necessity as the mother of invention" rings any bell??... Someone???
Gosh... come on people! Are our memories so stunted we can't recall the sweat, blood and tears to get today's technology? Why is so difficult to value it? Because the free software? Wow!!
And then we feel so aggrieved and surprised by the way the world spins... incredible.
Anyway... let's order a $2c item from Amazon, packed in a box 5 times bigger, delivered in the next 10 minutes at zero cost... and meanwhile let's close the eyes to the precarious salaries, the economic bubbles we promote and let's complain and rant how DRM is a crime to the democracy and genre parity. Cheers!
(Disclaimer: No, I do not have any interest conflict or relation to win.rar GmbH and RARLAB!)

I'd thought this was obvious. Although gzip is really good at stream compression too rather than having to just be a file, and as all the file(s) in the archive is in a continuous stream it may find matches of nearby files better than individually.

TAR is simply Tape ARchive, which basically is intended for making backups and reading/writing from tape, the fact we are using it without that particular technology doesn't mean much. Actually i'd had fun using netcat to select several files i wanted to send in a stream, it would look something like this.

tar -c games/*.exe games/*.bin | dd bs=1M status=progress | gzip -c -1 | nc 192.168.0.101 22000

then on the other end

nc -l 22000 | gzip -c -d | tar -x

You can, of course, replace the gzip portion with any other file compressor that works on a single file.

There's .tar.xz files, for example; xz compresses better than gzip, but is a lot slower.

(There's also something like lzop or lz4, if you prefer (or require) the opposite trade-off; worse compression but much faster.)

xz is effectively 7z LZMA compression, just not with the 7z extension.

lzo is the fastest algorithm good for realtime stuff, and using that in my slax squashfs images for simplicity.

But as you mention, it's a tradeoff of resources and speed, and like my other posts elsewhere that Linux/Unix not being a GUI you can combine things that didn't exist rather than having to recompile or do a lot of extra work.

I guess that is not really an issue, unless the files are big and thus preventing nicely matching split sizes. At least that is what I infer from reading what you are saying.

I am about to embark on a file splitting exercise with 7-Zip, for a game folder backing up program of mine, so I guess I will find out. I am toying with the idea of making an archive split at either 2 Gb ... or 4 Gb like GOG's BIN files.

Dunno if 7zip has this feature nowadays, but there is a particular reason why I bought WinRAR: If you extract files without the proper locale, they will become corrupted. I play many Japanese games, such as those bought off DLSite. WinRAR lets you set a locale for reading and extraction. 7zip at the time, (2018?) didn't.

Well keep in mind zlib has a max of a 16bit window it can look. (Probably more due to 64k limits per segment and they just worked within those limits). And It's easy for images and files to exceed 64k, be it exe files, data files or anything. Though you only need to match 4+ bytes to make it break even or profit space-wise, now matches need to be 6+ bytes overall, although 7zip does employ a variable length encoding scheme so different lengths can match better to the size. Quite interesting. But if we are doing say html files, you'll have a lot of tags, from italics to bold to tables, etc. If a bunch of files from the site have an identical header of 1k (the tag, the pointing to the css or css embedded, font data, links to other pages or the menu system, java files it loads, etc, this can easily do direct matches and give you huge amounts of compression, but only if it's within range of the dictionary match or the window)

The splitting 7zip does is literally just making a new file and continuing at the next part, but you can't add/change files like how they did the TOC on the zip files. Split 7z files you can just concat together to get the original. Not the same as zip files.
I'd found a specific zip archiver version that let you specify the locale as well (to handle this)... but for the life of me i don't know where i got it at.

Thanks for that and the other info.