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?
> 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.
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 consent decree is a large part of why we have browser (and OS!) choice at the moment. Imagine the world where IE6 won and use of ActiveX controls on websites was routine.
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.
The implication is that absent the consent decree IE would have been more dominant in that era, and that the dominance would have lasted longer than it did. This is plausible, since a world of sites built with non-web-standard crap would have been barren ground for nascent Firefox. It was for that exact purpose that IE has always been the way it has been, and would have been worse without the decree. Yeah, we're grateful for XHR, but that was just the tip of the iceberg.
On the other hand, how do you embed a browser component in a forward-compatible way?
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.
Embedded rendering of local HTML doesn't need security updates, so that's not a major problem. You can leave it alone while you update the actual browser.
Yes it does. They could ship a statically-linked copy of Edge to Windows Vista (and even XP) users via Windows Update. The old IE DLLs would have to stay there to be used by the system, but the actual web browser could be a newer one.
If they're stopping delivering security updates for those versions of IE then it's better than nothing. Actually assuming they keep the statically linked Edge updated via windows update then I don't see any issues (as annoying as a large update to a statically linked program will be).
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.