<story><title>PSD is not my favourite file format (2009)</title><url>https://github.com/zepouet/Xee-xCode-4.5/blob/master/XeePhotoshopLoader.m#L108</url></story><parent_chain><item><author>rdtsc</author><text>&amp;gt; Why, for instance, did it suddenly decide that &lt;i&gt;these&lt;/i&gt; particular chunks should be aligned to four bytes, and that this alignement (sic) should &lt;i&gt;not&lt;/i&gt; be included in the size?&lt;p&gt;Not saying this happened here, but I have seen this type of mistake before. It was because they &amp;quot;simply&amp;quot; cast a C&amp;#x2F;C++ struct to a binary blob &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Data_structure_alignment#Typical_alignment_of_C_structs_on_x86&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Data_structure_alignment#Typic...&lt;/a&gt; and wrote that to disk (or sent over the network in my case). So that particular compiler version and architecture-specific struct field alignment became the &amp;quot;official&amp;quot; format.  It just takes one goofy mistake like that and everyone has to deal with it for years to come.</text></item></parent_chain><comment><author>grishka</author><text>That&amp;#x27;s why you version your file formats and network protocols. Actually, designing file formats and network protocols is one of the few areas in software engineering where you do really need future-proof design and extreme extensibility, because once you release the thing, these are set in stone. Yet not many people seem to realize this. They instead &amp;quot;future-proof&amp;quot; their code with useless abstraction layers.&lt;p&gt;Anyway. Versioning helps you avoid ugly workarounds if you need to extend your format in the future in ways that its current version doesn&amp;#x27;t allow. You then keep the code for older versions as a backwards-compatibility-only kind of deal and move on to the new one.</text></comment>
<story><title>PSD is not my favourite file format (2009)</title><url>https://github.com/zepouet/Xee-xCode-4.5/blob/master/XeePhotoshopLoader.m#L108</url></story><parent_chain><item><author>rdtsc</author><text>&amp;gt; Why, for instance, did it suddenly decide that &lt;i&gt;these&lt;/i&gt; particular chunks should be aligned to four bytes, and that this alignement (sic) should &lt;i&gt;not&lt;/i&gt; be included in the size?&lt;p&gt;Not saying this happened here, but I have seen this type of mistake before. It was because they &amp;quot;simply&amp;quot; cast a C&amp;#x2F;C++ struct to a binary blob &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Data_structure_alignment#Typical_alignment_of_C_structs_on_x86&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Data_structure_alignment#Typic...&lt;/a&gt; and wrote that to disk (or sent over the network in my case). So that particular compiler version and architecture-specific struct field alignment became the &amp;quot;official&amp;quot; format.  It just takes one goofy mistake like that and everyone has to deal with it for years to come.</text></item></parent_chain><comment><author>wolrah</author><text>As I understand it that&amp;#x27;s more or less what the older MS Office formats were, just a dump of the entire OLE object representing the document as-is.&lt;p&gt;I believe SimCity used a similar strategy as well, the .cty and I think SC2k&amp;#x27;s .s2k formats just dumped the in-memory representation to disk,.</text></comment>