On the one hand, we might say "get the one that supports the biggest
range of archives, so I can extract them all!"
On the other hand, if you just use one or two formats, why "support"
the rest, when the most likely reason to need oddball formats is
because malware use them to circumvent av scanning and/or exploit bugs
within the extraction code?
As at 2006, I'm leaning in favor of the latter.
Not quite true - there are three types of general lossless compression
that XP can use at the file system level:
1) DOS-era disk compression
This is a hangover from the Stacker and MS-DOS 6.xx days, and is
possible only on FAT16 volumes. What appears to be a hard drive
volume is in fact a single CVF (Compressed Volume File) on a "real"
volume, and the OS's file system code handles compression in and out
of this CVF file transparently. Never was a good idea; pointless now.
2) Native support for archives as "compressed folders"
This is what you are referring to. The shell may gloss over this
fact, but all "compressed folders" are really .CAB or .ZIP archive
files that are visualized as if they were file folders. Unlike disk
compression (FAT16) and file compression (NTFS), native archive
support applies to all types of file systems.
3) NTFS file compression
The NTFS file system supports native file compression on NTFS volumes
with particular (and typical) cluster sizes. Such files may be shown
in blue within the shell, if that feature is enabled. In addition to
this, NTFS supports "sparse" files which do not compress the contents,
but omit storing large sections of zeros, indicating they should be
inserted at that point in the file instead.
MS's native support for archives as folders is far from seamless:
- navigating Explorer into archive opens new single-panel window
- the proper full path is not displayed, in title bar or on Search
- processing of damaged archives is buggy
I stumbled on the latter by accident, when copying files out of a .zip
(viewed as a "folder" in native XP with no 3rd-party archivers). The
copy process showed no errors, but not all selected files were copied
out - and the only way I'd know this, is if I checked. If I
deselected one particular file, copy would work, but selecting that
file caused the copy operation to silently abort.
Checking the .ZIP on another PC with WinZip showed that although
WinZip would open the archive OK, it would generate an "invalid
compression" error when processing the affected file within the
archive. MS's code seemed not to detect this error condition at all,
and just silently aborted instead.
ZIP files work "just like folders"? Really? So you can run
applications right from a ZIP file? No, you can't--you need to extract
the archive first.
Let's test that... yes, such is the case when tested running ERUNT's
..exe from within the archive that contained it.
There are many good archivers, for both Windows and Linux, that can open
RAR files. Many of them are free.
If I'm not using .RAR files, I'd rather not have the system enabled to
"open" them. One less exploit surface to worry about
------------ ----- --- -- - - - -
Drugs are usually safe. Inject? (Y/n)