I wrote a piece for The Register about the arrival of Windows-specific features in Silverlight, which attracted some comments both on the Reg and also on Slashdot. Plenty of people said it was just what they expected from Microsoft, some of them misunderstanding the point that this only applies to out-of-browser applications that are trusted: the user has to pass a dialog box granting the application permission to access the local system. A few defended Microsoft’s decision; and this Slashdot comment on COM automation in Silverlight 4 strikes me as a good encapsulation of the official line:

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) … it’s an edge case feature that doesn’t affect Silverlight’s over all "Cross-Platforminess".

The idea that COM automation is merely an “edge case” surprises me, even though I also recall it being described like that at PDC. Access to COM automation gives a Silverlight desktop application on Windows substantial extra capability. At PDC program manager Joe Stegman showed how Silverlight 4 can integrate with Office, sending data into an Excel spreadsheet: an example with obvious value for real applications. I also heard developers at PDC discussing how they might wrap up a Silverlight application with a COM DLL, creating an application which in effect has full access to the local operating system. Although Silverlight cannot access the Windows API directly, there are no such restrictions on the COM DLL, so the combination means that pretty much anything is possible.

Let’s also bear in mind that Microsoft’s Brad Becker is on record saying that one day WPF and Silverlight might simply become different .NET profiles. He told me this at Mix earlier this year; and said a similar thing to Mary Jo Foley at PDC:

Some day — Microsoft won’t say exactly when — Silverlight and WPF are going to merge into one Web programming and app delivery model that, most likely, will be known as Silverlight, Brad Becker, Director of Product Management for Microsoft’s Rich Client Platforms, told me this week

If Microsoft is contemplating such a thing, then clearly full access to the native features of Windows will have to be possible.

I am not entirely negative about this prospect. Even if you are only targeting Windows, Silverlight has a lot to commend it: a small runtime, easy setup, and options for browser-hosted or desktop deployment. If you have ever wrestled with the Windows installer or tackled a failed .NET runtime installation you will like the simplicity of running a Silverlight application.

Nevertheless, with version 4.0 Microsoft is changing its Silverlight story. It is no longer a pure cross-platform play; rather, it is a runtime where some features are cross-platform, and others Windows only. Microsoft calls this developer choice; I see it as evolving into the inverse of Sun’s aim with Java. Sun tried strenuously to guide developers towards cross-platform, but provided a way out – via Java Native Interface – if absolutely necessary. Microsoft will provide cross-platform where we really need it, but make it easy to slip into Windows-only development in order to get some nice feature like a location API, or Office integration.

I see this as an advantage for Flash, because developers know that Adobe has no incentive to prefer one operating system over another – except to the extent that minority platforms (like desktop Linux) tend to receive less investment.

Personally I think Microsoft should at least provide a way for Mac users to get similar benefits – perhaps by implementing something like the native process API in Adobe AIR 2.

I also think Microsoft will have to get real about Linux support. It is wrong that Microsoft will cheerfully state:

Silverlight 4 runs across all platforms and major browsers

as it does in the “Fact sheet” handed out at PDC; while leaving Linux implementation to a third-party process uncertain in both features and timing. Here is the reality of cross-platform Silverlight, in a screenshot taken seconds ago from Linux:

Right now it is a two-platform play – admittedly, the two platforms that matter most, especially in a Western world business context, but never forget that Google Chrome OS is coming.