I do some work with various embedded extension APIs in different office and collaboration tools, and it's quite a mess trying to figure out what those web browsers actually are
This is a strategy tax, for a strategy that stopped being reasonable a decade ago. Numerous alternate browsers have had no problems competing with an "integrated" IE, for many years now. The DOJ case was settled by a completely different set of executives, so the current bunch don't have to pretend that OS integration is somehow vital to the function of a browser. Someone should draft a memo to the browser department: that stupid shit you were supposed to do 15 years ago? stop doing that. An organization that continues with such a farce for so many years is puzzling.
What do you propose to MS - to spend time supporting Windows Vista? Or make a browser that supports it? Bet they just don't care about Vista, besides security patches and alike stuff that they have to do under various enterprise contracts. Given that they go lengths to persuade 7 & 8.x users into upgrading to 10, doubt they care much about those versions, too.
I'm regularly in an office that is rife with XP. I won't be in that office to check the exact versions on all the installed Chromes for a couple of weeks, but they certainly seem up-to-date.
Messy.
They could do the equivalent of static linking and include the necessary components in the browser instead of the OS.
That's more or less what the Utilu IE Collection does I think.
So on the older operating systems, programs that shipped with the OS will be embedding the browser as a COM component, usually for help purposes. If they're rendering local HTML (or generated HTML!) then they require that to keep working. So that particular interface has to be maintained, making it very difficult to upgrade.
Microsoft were kind of correct in the "browser choice" lawsuit that they'd used the browser as an OS component, and everyone else was correct that this was kind of a bad idea.
On the other hand, how do you embed a browser component in a forward-compatible way?
Android uses a WebView component. If an app wants to display a webpage, it can make use of this to render HTML. I imagine iOS uses something similar.
I believe this component is compiled separately for different versions of Android, and Android will only update to the newest compatible version.
Docs: https://developer.android.com/reference/android/webkit/WebVi...
Store page: https://play.google.com/store/apps/details?id=com.google.and...
Unfortunately, Microsoft signed a consent decree with the DoJ in 1995 which allowed them to add features to the operating system but meant they couldn't tie a separate program to the operating system. Therefore the browser had to be an added feature.
This was only a tiny part of a much broader decree. None the less, you can thank Janet Reno and the US government for the problems this has caused ever since ;-)
The IE6 era (2001 to 2005 or 2006) was a period of great creativity, and it was when a lot of dominant web properties became established. Examples include Wikipedia, LinkedIn, Second Life, The Pirate Bay, MySpace, Orkut, Facebook, Gmail, Flickr, OpenStreetMap, YouTube, MegaUpload, Pandora and Twitter.
Web 2.0 became popular during that era (2004 onwards).
That "stagnation" compares rather well with much of the flashy, transient rubbish being launched nowadays.
Also, when it came out, IE6 was the most standards-compliant browser and generally performed better than its main rivals.
Remember that "the decree does not address any of Microsoft's applications software." It only regarded their dealings with OEMs.
Use a consistent API and just upgrade the rendering engine, while maintaining quirks mode. It's not as much of a problem anymore because HTML5 specifies consistent parsing and rendering behavior for new and old documents.