Tuesday, June 12, 2007

By the gleam of yonder moon

Microsoft® Silverlight™
Welcome to a new age of .NET. With the Customer Technology Preview (CTP) of Silverlight™ 1.1, the first commercial cross-platform Microsoft® .NET™ components became available. Furthermore, my tongue is no longer officially tied. The cat is out of the bag, and thus I can now clue you all in on what I’ve been doing in the last year.

Since there’s already been quite a bit of posting on the subject of Silverlight, I figured I’d fill in some of the details about its composition and some of the nomenclature, since, even within Microsoft, it’s not completely obvious what’s in the package at first glance.

duced Version
WPF/EJolt1Windows Presentation Foundation / Everywhere is the browser plug-in variant of its bigger brother in Windows. It is XAML-based presentation engine.
Windows Media codecsThese allow for high speed video streaming inside a Silverlight solution.
(Managed support)
CoreCLRTelesto2The core execution engine and platform adaptation components of .NET. These are the only parts of the managed support that are native; the rest are all managed libraries. Officially, the CoreCLR project is also responsible for the Base Class Libraries (BCL), which has been reduced for both size and portability reasons.
UIFXThe standard framework libraries, similarly reduced from the Desktop for both size and portability reasons.
.NET Language RuntimesManaged libraries to support C# and VB.NET
DLRDynamic Language Runtime support libraries

The “level-1” components of Silverlight are entirely to provide a managed programming model for WPF/E, as an alternative to its built-in JScript model. The part of Silverlight I’ve been working on is the CoreCLR component, focusing on Mac OS X integration, but have been banding together with my Mac counterparts on the other related teams (mostly WPF/E, with a little bit of UIFX) to make sure the collective Silverlight story on the Mac is a good one. If you have feedback for us, head on over to the Silverlight.net forums, specifically the Programming with .NET forum, and let us know. It may take more than one of us to give a full answer (for example, I know much more about how we handle native exceptions on the Mac than about what XAML you’d need to use for a particular operation), but we’ll help if we can.
1In the era before marketing took over code-name generation, we could have tributes to fine beverage products. However, since code names regularly leak out of Microsoft, and out of worry that we will get stuck with a trademark lawsuit for something that isn’t the name we’re ultimately going to use, marketing now comes up with names, presumably with some kind of trademark search ahead of time to verify that we’re not going to run afoul of someone else’s.
2No, “Silverlight” isn’t the “the gleam of yonder (Telesto) moon,” but I figured it sounded good.


David Weiss said...

Can you explain how you go about selecting which parts of .NET (which is huge) you decide to port to the CoreCLR framework you are developing? Also, if a developer of a Cocoa application wanted to use a CoreCLR engine, but a Cocoa UI, would they just "load the CoreCLR.framework" or is there more to it than that? I think folks would like to know, if you are at liberty to say.

David Weiss

Nathan Herring said...

Good questions! I'll try and address them in future posts, as it seems like it deserves more than just a comment.