New Microsoft Silverlight Features Have Windows Bias 251
An anonymous reader writes with this quote from a story at El Reg about an early look at the Silverlight 4 beta:
"There are ... major changes to Silverlight's out-of-browser functionality, a loose equivalent to Adobe Systems' AIR runtime for Flash. Even when fully sandboxed, which means having the same permissions that would apply to a browser-hosted Silverlight applet, out-of-browser applications get an HTML control, custom window settings, and the ability to fire pop-up notifications. ... Unfortunately, some of these features are not what they first appear. The HTML control in Silverlight 4 is not a new embedded browser from Microsoft, but uses components from Internet Explorer on Windows, or Safari on the Mac, which means that the same content might render differently. The HTML control only works out-of-browser, and simply displays a blank space if browser-hosted. Clipboard support is text-only in the Silverlight 4 beta, though this could change for the full release. More seriously, COM automation is a Windows-only feature, introducing differentiation between the Mac and Windows implementations."
Re:COM Automation = ActiveX (Score:3, Interesting)
COM is windows only... (Score:5, Interesting)
...thank God.
Only Microsoft has the peculiar genius that allows them to take a relatively straightforward concept (reference counting/smart pointers) add a totally over-the-top, incomprehensible library that was designed around the limitations of the broken template support in VC6 (ATL), then totally abandon it for "teh new shiny" because you lost a court case against Sun (.net).
I have written a *lot* of code in ATL, and I regret practically every moment of it; I liked the idea of COM/ActiveX, it's actually a really cool concept, and it even seemed to have an awesome future (all these COM objects that could talk to each other...Excel could control my toaster via my custom ActiveX dll) but suddenly it became all about the web and the era of a component-laden operating system ended before it really ever began. So for that I slogged through a bunch of ATL books, got to the point where I thought I knew how it all worked, and then all Microsoft wanted talk about was C# and .net.
Quick, someone notify Miguel! (Score:3, Interesting)
Obviously this is some kind of mistake. Miguel assured all us Linux users that Microsoft was a changed company, they would NEVER do something like this! Surely Moonlight would be 100% compatible with Silverlight and Linux would be considered a tier 1 platform!
He wouldn't have lied, would he?
Microsoft pollution at its best (Score:4, Interesting)
Each time I read about silverlight I get angry. Why won't Microsoft invest time and energy making IE html5 compliant instead of promoting this f*** product that nobody wants anyway. I mean, look at the competition for god sake. IE is stuck with Javascript 1.5 since November 2000. Man we are now 9 years since Ms has updated its Javascript engine. Firefox, Chrome, Safari, name it, all have javascript support almost if not ready for ECMAScript 5.
What is comforting in a way is the low deployment of silverlight. Google can give us a slight idea : http://www.google.com/insights/search/#q=adobe%20flash%2Cmicrosoft%20silverlight&date=today%2012-m&cmpt=q [google.com]
I know at least that it is not deployed at work : 20,000 less pcs for Microsoft + the 2 mine at home.
Speaking of Bias.. (Score:5, Interesting)
From TFA:
Unfortunately, some of these features are not what they first appear. The HTML control in Silverlight 4 is not a new embedded browser from Microsoft, but uses components from Internet Explorer on Windows, or Safari on the Mac, which means that the same content might render differently. The HTML control only works out-of-browser, and simply displays a blank space if browser-hosted.
The difference in rendering between IE on Windows and Safari on Macosx is a reality, whether silverlight is involved or not. The purpose of the HTML Control is to allow scenarios dependent on the HTML Bridge, the part of silverlight that blurs the lines and allows communication between the html dom + javascript and C# code, to run correctly when the app is hosted out of the browser. It's essentially a crutch to allow developers that want to use siverlight a way to leverage existing investments in web application development.
More seriously, COM automation is a Windows-only feature, introducing differentiation between the Mac and Windows implementations. Since cross-platform Mac and Windows is a key Silverlight feature, it is curious that Microsoft has now decided to make it platform-specific in such an important respect. Microsoft Office and parts of the Windows API have a COM interface, so access to COM makes Silverlight a much more capable client.
This is a fairly obscure feature, and I'm fairly surprised that it was included at all, but doubt it'll be of use to the vast majority of current and future silverlight developers out there. Like the html control, it's a crutch, to allow developers that want to use silverlight a way to leverage existing investments. The mantra I've heard out of the silverlight team is to focus on unblocking customer scenarios (scenarios they cannot unblock themselves) without compromising the overall feature goals (like keeping the runtime download small).
Nevertheless, Silverlight has crossed a threshold. It is now a runtime that has extended functionality only on Windows. That will not help Microsoft win developers from Adobe AIR, which has the same features on both Mac and Windows.
I don't think it'll matter. Any developer that is seriously considering using silverlight over Adobe AIR, but is then persuaded not to because Silverlight's Trusted Out-Of-Browser scenario has COM support on Windows and not on Mac is "Doing It Wrong". It's an edge case feature that doesn't affect Silverlight's over all "Cross-Platforminess".
Flame On.
Windows bias? Is that what you see? (Score:3, Interesting)
The HTML control in Silverlight 4 is not a new embedded browser from Microsoft, but uses components from Internet Explorer on Windows, or Safari on the Mac, which means that the same content might render differently.
So on the Mac it'll use Webkit, which means it'll render correctly. On Windows it'll use IE, which means... okay, anyone who's done any web development at all knows what that means.
I guess I'm not seeing the "pro-Windows bias" here - it looks like an anti-Windows bias to me!
Re:History (Score:3, Interesting)
We should be boycotting the Olympics then. This is unacceptable.
Re:History (Score:1, Interesting)
I will agree with you on that, it was much better, but now Microsoft just went and ruined it like they do with everything.
OS lock-down and bias is awful. :(
Especially because it means Adobe won't need to care as much and might decide to suddenly "stagnate" their development a little.
Re:Microsoft pollution at its best (Score:4, Interesting)
I don't know where they are in terms of language support (not great, if Acid3 is any indication), but IE8's JavaScript engine was a massive step up from IE7's and an even more massive step up from IE6. It's more standards-compliant (i.e. less incorrect behavior), implements more of the spec (not necessarily any of the newest changes to the spec, but more of the language as a whole), and is much, much faster than before.
Don't get me wrong, it's still way behind the other big-name browsers, but claiming 9 years since MS updated the javascript engine is a bald-faced lie.
Re:History (Score:4, Interesting)
BFD (Score:2, Interesting)
Here's a more comprehensive listing of the changes to come. [silverlight.net]
Re:History (Score:5, Interesting)
Silverlight was supposed to be a departure from CO (Score:3, Interesting)
Re:COM Automation = ActiveX (Score:3, Interesting)