[pud]

One of the things that's held back Windows and made it so complex, according to an MS engineer I recently spoke with who's been with the company since the 80's, is that it contains thousands of pieces of code to fix bugs in third-party software.

In other words, there's code in Windows 7 that prevents crashing due to a rare bug in Where In The World Is Carmen Sandiego v1.3 (hypothetical example). And so on.

[quotemstr]

Relevant Old New Thing post: "The real cost of compatibility is not in the hacks; the hacks are small potatoes"

(The Old New Thing is a blog by veteran Microsoft shell team developer Raymond Chen, and it's a must-read for all developers.)

https://blogs.msdn.com/b/oldnewthing/archive/2007/07/23/4003...

[rburhum]

"a must read" for all Windows developers.

[someone13]

Actually, I think it's a good read for all developers, irrespective of platform. The underlying message of the post above is relevant to anyone writing something that interfaces with third-party code. Not to mention, it's a good look into how one of the larger software companies approaches compatibility.

[kabdib]

If you find yourself doing a platform, you're going to run into these issues.

The biggest problem seems universal: You were an idiot and cut a corner three years ago, and you have to break something to move forward. Now what?

The Mac has some classic and poignant examples of this that have actually been trapping people for 50 years. Such as: Use of the high byte of a pointer to have non-pointer meaning (some 1980s ear Mac callbacks set flags in the "unused" high bits of a pointer, and the IBM 360 team made the same mistake in some of their OS data structures). In both cases, fixing this issue was pretty nasty.

Study history or repeat it, your choice. :-)

[jpxxx]

Not just Windows developers.

Microsoft Office for Mac v.X was released on November 19, 2001. It ran without incident for a decade on the latest and best Macs that money could buy through July 20, 2011. This was not by happenstance.

[pjmlp]

Other operating systems have similar issues as well.

[forrestthewoods]

I'll go one further and say all software has similar issues.

To give you a more concrete examples a game project I work on has many characters with skills. There is a lot of shared code across the skills, which is a good thing. A handful of skills are of the "charge" type. Press a button and lunge forward, each with it's own variation. Knockback targets, grapple targets, throw, throw backwards, apply buff to charger, apply debuff to victim, leave acid trail of damage, etc.

The whole setup has been built up over years and is tragically fragile today. Adding in a new charge variant requires being very careful you don't break any of the pre-existing skills. It may seem safe, and even appropriate, to make minor changes in the sequence of events but there's a good change it will break one skill in one particular case where multiple, infrequent combination of factors are in play.

[avbor]

This is obviously off topic, but do you happen to work on a MOBA?

[TeMPOraL]

Real example I heard on internship interview at MS:

Printers lie. Printers have embedded fonts and when you can use them instead rendering the text in software, the results end up better. But printers lie about which fonts they have and which characters are represented in them, so Word has (or used to have) this very big lookup table that basically tells "if you're printing on printer X from vendor Y, don't trust what it says about fonts and just send rendered text to it".

[nodata]

> One of the things that's held back Windows

It's also one of the things that's kept Windows strong.

[ZoFreX]

Windows 95 contains special memory management code for the original Sim City, but I suppose that probably got removed with all the other 16-bit supporting files in x64 versions of Windows, at least. Perhaps it's still hanging around in 32-bit Windows 7, though?

[wslh]

Imagine legacy stuff and standards on the web after 32 years!