<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: WinZip: Bug found in version 10.0, New features (and more backward incompatibility, and a controversy) in 11.0</title>
	<atom:link href="http://www.c10n.info/archives/459/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.c10n.info/archives/459</link>
	<description>All about the most recent compression techniques, algorithms, patents, products, tools and events.</description>
	<pubDate>Thu, 08 Jan 2009 18:49:49 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>By: SanDengo</title>
		<link>http://www.c10n.info/archives/459#comment-70343</link>
		<dc:creator>SanDengo</dc:creator>
		<pubDate>Wed, 29 Nov 2006 20:29:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.c10n.info/archives/459#comment-70343</guid>
		<description>Mr. Peterson, from pkware how can you blame competetion ?
  The problem, in my point of view, is that your company, the original inventor of ZIP, this pkware, now so called 'professionals in data compresison' has been unable to come up with anything good for the last 20 years after ZIP inventor died. 
  Leaving the standard alone, what other big step in compression your company did in the late DECADE?
  Your products are only newer compilations of horroble old assembly code that no one in the company was able to read. When working with 1024 KB compression how can you achieve such powerful compression ration like the competition?
  No one at this company knows what compression is therefore i think the name "data compression experts" should be left to professionals not to so called programers.</description>
		<content:encoded><![CDATA[<p>Mr. Peterson, from pkware how can you blame competetion ?<br />
  The problem, in my point of view, is that your company, the original inventor of ZIP, this pkware, now so called &#8216;professionals in data compresison&#8217; has been unable to come up with anything good for the last 20 years after ZIP inventor died.<br />
  Leaving the standard alone, what other big step in compression your company did in the late DECADE?<br />
  Your products are only newer compilations of horroble old assembly code that no one in the company was able to read. When working with 1024 KB compression how can you achieve such powerful compression ration like the competition?<br />
  No one at this company knows what compression is therefore i think the name &#8220;data compression experts&#8221; should be left to professionals not to so called programers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sachin Garg</title>
		<link>http://www.c10n.info/archives/459#comment-69072</link>
		<dc:creator>Sachin Garg</dc:creator>
		<pubDate>Tue, 28 Nov 2006 19:12:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.c10n.info/archives/459#comment-69072</guid>
		<description>To add to my comments above, IMHO maintaining a patent-free-open-standard and making money from it are two very conflicting tasks, none of them is evil but striking the right balance is inherently tough.

For example, a once-every-few-years major democratic overhaul of ZIP format deciding which new algorithms to add to it after an open community discussion would help everyone, but well, it conflicts with the dollar goals.

Also, even if the company decides to do spec updates by itself, they shouldn't be too frequent and updates to specs should be published a few months before the tool starts creating the new format files, so that other standard compliant tools get a chance to update themselves, thus reducing user agony.

Nothing evil in trying to make money, but it does conflicts with other goals ;-)</description>
		<content:encoded><![CDATA[<p>To add to my comments above, IMHO maintaining a patent-free-open-standard and making money from it are two very conflicting tasks, none of them is evil but striking the right balance is inherently tough.</p>
<p>For example, a once-every-few-years major democratic overhaul of ZIP format deciding which new algorithms to add to it after an open community discussion would help everyone, but well, it conflicts with the dollar goals.</p>
<p>Also, even if the company decides to do spec updates by itself, they shouldn&#8217;t be too frequent and updates to specs should be published a few months before the tool starts creating the new format files, so that other standard compliant tools get a chance to update themselves, thus reducing user agony.</p>
<p>Nothing evil in trying to make money, but it does conflicts with other goals ;-)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sachin Garg</title>
		<link>http://www.c10n.info/archives/459#comment-68660</link>
		<dc:creator>Sachin Garg</dc:creator>
		<pubDate>Tue, 28 Nov 2006 08:28:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.c10n.info/archives/459#comment-68660</guid>
		<description>But that still requires users to upgrade. Giving more options to users is a good thing but it shouldn't lead to confusion.

I don't see myself as an expert, but what I would have liked to see is that the updates to original ZIP format be recognized by some other extension (like maybe .zip2?)

With an unwritten code saying that those who want portability and backward compatibility can stick to zip and those using zip2 will need to make sure they use the latest versions of tools supporting zip2.

ZIP's only advantage is its popularity which is *because* anyone can send it to anyone without worrying about explaining which version of which tool they will need to open it. Why else could something so technically obsolete still hold ground all these years?

With this USP gone, it puts ZIP on a level (and crowded) playing field with all the other formats.</description>
		<content:encoded><![CDATA[<p>But that still requires users to upgrade. Giving more options to users is a good thing but it shouldn&#8217;t lead to confusion.</p>
<p>I don&#8217;t see myself as an expert, but what I would have liked to see is that the updates to original ZIP format be recognized by some other extension (like maybe .zip2?)</p>
<p>With an unwritten code saying that those who want portability and backward compatibility can stick to zip and those using zip2 will need to make sure they use the latest versions of tools supporting zip2.</p>
<p>ZIP&#8217;s only advantage is its popularity which is *because* anyone can send it to anyone without worrying about explaining which version of which tool they will need to open it. Why else could something so technically obsolete still hold ground all these years?</p>
<p>With this USP gone, it puts ZIP on a level (and crowded) playing field with all the other formats.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jim Peterson</title>
		<link>http://www.c10n.info/archives/459#comment-68424</link>
		<dc:creator>Jim Peterson</dc:creator>
		<pubDate>Tue, 28 Nov 2006 01:27:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.c10n.info/archives/459#comment-68424</guid>
		<description>One clarification on the backward compatibility of ZIP files.  The ZIP format has always supported the addition of new algorithms and a number of new compression methods and features have been introduced over the 18+ years ZIP has been in use.   These features have been added, and continue to be added, to meet the changing needs of users over time while still ensuring they can extract data they compressed many years earlier.  It does not guarantee they can continue to use the same program purchased 18 years ago and expect it to fully meet their current needs.  

User headaches typically result from using applications not written to properly recognize and inform a user that a newer feature was used in creating a file they received from a friend that is using a newer software program than they may have.   With proper notice from a well written application, the user should be informed of the reason the file cannot be extracted.  This notice should give them sufficient information to decide whether to ask their friend to resend the file compressed using features supported by their older ZIP program, or update to a newer version of the program that supports the new features.  Further, a good application may also inform the person creating the file that features they have chosen to use may not be supported by users of older applications.</description>
		<content:encoded><![CDATA[<p>One clarification on the backward compatibility of ZIP files.  The ZIP format has always supported the addition of new algorithms and a number of new compression methods and features have been introduced over the 18+ years ZIP has been in use.   These features have been added, and continue to be added, to meet the changing needs of users over time while still ensuring they can extract data they compressed many years earlier.  It does not guarantee they can continue to use the same program purchased 18 years ago and expect it to fully meet their current needs.  </p>
<p>User headaches typically result from using applications not written to properly recognize and inform a user that a newer feature was used in creating a file they received from a friend that is using a newer software program than they may have.   With proper notice from a well written application, the user should be informed of the reason the file cannot be extracted.  This notice should give them sufficient information to decide whether to ask their friend to resend the file compressed using features supported by their older ZIP program, or update to a newer version of the program that supports the new features.  Further, a good application may also inform the person creating the file that features they have chosen to use may not be supported by users of older applications.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
