Linked by Thom Holwerda on Mon 21st May 2018 20:50 UTC
Windows

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.

Thread beginning with comment 657136
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Comment by jmorgannz
by jmorgannz on Tue 22nd May 2018 13:52 UTC in reply to "RE: Comment by jmorgannz"
jmorgannz
Member since:
2017-11-05

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

Reply Parent Score: -1

RE[3]: Comment by jmorgannz
by darknexus on Tue 22nd May 2018 19:24 in reply to "RE[2]: Comment by jmorgannz"
darknexus Member since:
2008-07-15

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.

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.

Reply Parent Score: 3

RE[4]: Comment by jmorgannz
by jmorgannz on Wed 23rd May 2018 02:13 in reply to "RE[3]: Comment by jmorgannz"
jmorgannz Member since:
2017-11-05

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.

Reply Parent Score: 1

RE[3]: Comment by jmorgannz
by Duke on Wed 23rd May 2018 05:02 in reply to "RE[2]: Comment by jmorgannz"
Duke Member since:
2018-05-22

You're completely clueless, and this is why:

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.

But why would you bother doing that if Windows built-in ZIP capabilities are good enough? There's just no point deploying additional archiver when Windows arleady does all you need.

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.

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??

Reply Parent Score: 2