Hacker News Reader

Comment by pjc50 | Hacker News Reader

It's the other way round: programs include the browser as a COM component. https://msdn.microsoft.com/en-us/library/aa752040%28VS.85%29...

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?

View on HN

> 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...

> 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.

To quote myself from earlier...

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.

I don't see how that follows, seeing as the IE dominance era came years after the consent decree was signed (2000-2003).

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.

But the consent decree didn't impede the creation of non-web-standard crap, and in fact XHR was made after it was signed, so how did it help?

Remember that "the decree does not address any of Microsoft's applications software." It only regarded their dealings with OEMs.

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.

Reply on news.ycombinator.com