Linked by David Adams on Thu 15th Sep 2011 07:08 UTC, submitted by kristoph
Permalink for comment 489720
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 06/17/13 17:58 UTC
Linked by Thom Holwerda on 06/17/13 17:52 UTC
Linked by Thom Holwerda on 06/14/13 21:03 UTC
Linked by Thom Holwerda on 06/14/13 20:46 UTC
Linked by Thom Holwerda on 06/14/13 17:32 UTC
Linked by Thom Holwerda on 06/14/13 11:39 UTC
Linked by Thom Holwerda on 06/14/13 11:32 UTC
Linked by Thom Holwerda on 06/13/13 19:39 UTC
Linked by Thom Holwerda on 06/13/13 14:45 UTC
Linked by Thom Holwerda on 06/13/13 11:43 UTC
More News »
Sponsored Links



Member since:
2006-03-18
When you think about it, this makes a kind of sense. Currently the plug-in architecture is pretty agnostic. It allows basically any DLL which supports the right API to take over a section of the browser canvas.
Now Metro it appears is entirely legacy free. Nothing you see in Metro depends on the win32 API as we know it. So running IE or any other browser in Metro, you can't just allow Adobe's flash player to load as a plug-in. You'd need most of the win32 API to support it, and that's gone in Metro.
Now that doesn't explain why IE won't support a new WinRT plugin architecture. I doubt the flash player is closely coupled to win32, and could be ported to the WinRT IE plugin API pretty darned easily if such existed. There is no reason not to support a WinRT plugin architecture - and I betcha Microsoft will have to concede this at some point.