Microsoft Silverlight - now with hidden Windows bias
So much for cross-platform
PDC Silverlight 4.0 was the big hit at Microsoft's Professional Developer Conference (PDC) this week. "I can see that Silverlight is the future of Windows client development" one attendee told me.
The basis for this enthusiasm is an array of new features that resolve many of the frustrations discovered by developers working with the previous release.
These include printing support, clipboard support, a rich text control, bi-directional and right-to-left text, access to webcams and microphones, right-click and mouse wheel control, multi-touch support, and DRM for both online and offline media. Microsoft is also promising a significant performance boost thanks to better just-in-time compilation.
There are also 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. There is also a new trusted mode, which requires user approval, and enables local file access, COM automation, and cross-domain networking access.
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. 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.
Brian Goldfarb, director of product marketing, defended this decision. "[Mac and Windows Silverlight] are on a par in every other respect. It's important to give developers choice. We also want to have the option to light up the platform," he said.
He observed that future mobile implementations of Silverlight may have features such as access to the phone dialer that will not work on the desktop. "It's not terribly different in this situation," he said.
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. There is also the awkward matter of Linux support, which Microsoft leaves to third parties, mostly Novell's Mono but also Intel in the case of Moblin, a version of Linux for netbooks.
This last point is interesting in the context of Google's recently announced Chrome OS, which is based on Linux and likely to prove popular. If it does, Microsoft will have to take Linux support more seriously, or lose all pretense of cross-platform support. Mobile is another awkward area, about which Microsoft said little at PDC other than promising a focus on this at the Mix conference in Las Vegas in March. ®
Thanks for sharing. Yes that's a common situation. It's also an ironical one. Since they have to put in these "requirements" because of vendor lockin. Which is something they want to prevent... and round and round the circle goes.
So if a customer is serious about getting rid of vendor lockin, then they will listen to the arguments.
Given the situation you describe, your boss will listen if you find customers that would want an application based on open source or don't care about the plugin install.
They'll drop it, but not for a good decade of flogging that dead horse.
Not having developed with it yet, I can't say whether it's any good, but for me, it is yet another bolt on for your browser, and since the flash platform, which of course devoured shockwave, is quite apply cruising along, why rock the apple cart?
Sometimes I am amazed that .NET still exists.
@AC 10:39 GMT
Use OSS? I'd love to, but I can't.
Boss: So it all runs in the browser?
Boss: Any browser?
Me: Within reason, any modern one would do. FF, Safari, Opera...
Boss: Will it run in IE?
Me: IE7 & 8? Yes.
Boss: What about IE6?
Boss: Oh, and do they need to install anything?
Me: Well, they need to install the plug-ins so the software works.
Boss: Nope, can't have that. It must work OOTB based on their standard deployment, which is IE6 by the way, and we can't demand they install anything else.
This is what we have to live with. It *MUST* run in IE6 and if it needs to use anything more than a PDF plug-in, you're S.O.L. I'd love it if customers would use a proper browser (even IE7 would do) but it just doesn't happen. I know people who are still rolling out XP with that abomination IE6!