Confirmed: Silverlight 1.1 will only support Intel OS X machines
John Lam has posted a “gathering of facts” about Silverlight and the DLR. His #9 on the list was the one I was most interested in.
“Silverlight V1.1 will only target Intel Mac OS X machines.”
That’s pretty disappointing to me, but not unexpected. My bet is that this will slow, to a crawl, adoption of Silverlight by OS X users. While it’s true the techno-elite, ADD generation, gotta-have-it-because-it’s-new group have adopted Intel Macs en masse. There is a HUGE group of loyal Apple users still happily using their Blueberry and table-lamp iMacs using OS X. Apple’s upcoming Leopard release will support PowerPC machines, but no word has come out on how long PowerPC support will continue. I’d love to hear the reasons for supporting Intel only. If I were to put out a SWAG, I’d say it has to do with Endian-ness and byte swapping. But I’d like to think that there is a more intractable problem with moving the CLR/DLR to PPC than just not wanting to write some code.
There are a couple of other facts that have been hinted at but it’s nice to see them confirmed by a MS employee.
Silverlight lets you run compiled .NET code in the browser, not just Python and JScript code. Any assembly that has been compiled to target the Silverlight libraries should just work. So if you want to write code in C#, VB.NET or Boo to target Silverlight, knock yourself out.
Which is nifty and not unexpected. That’s the whole point of having a Common Language Runtime.
The DLR will also run on top of the desktop CLR V2.0, not just the Silverlight CLR. We have a generic hosting API that lets us retarget the DLR to run on top of arbitrary hosts. Silverlight is only one such host.
Which is a little more interesting to me. I keep wondering if assemblies written against the DLR would be able to run against either CLR. I’m still trying to wrap my head around what MS really means when they say “CLR” in the context of Silverlight. Up until now, there has just be one CLR. It’s evolved to support new language features, but the .NET Framework itself has evolved parallel to the CLR. Now it appears that we have two distinct CLR’s. CLR Desktop and CLR Silverlight. Are they compatible? If you compile an assembly against one, do you have to recompile to get your assembly to work with the other (provided you use the namespaces available in Silverlight). I think it does.
An interesting side note: So now we have a “portable” CLR. Meaning you don’t have to have the full .NET runtime installed on your client machine (at least as far as I can tell) to run Silverlight applications. Silverlight brings it’s own small runtime along with it. It would be nice if this option were available to desktop developers as well. Meaning you hit “build” in the IDE, the compiler bundles up the specific namespaces and references that your application needs and puts them, along with the portable CLR, in your build directory. Almost like static linking.



Pingback: Lazycoder » Blog Archive » Giving up on Silverlight