Just got off the phone with David Treadwell, Corporate Vice President of the .NET Developer Platform. Naturally, we started and ended the talk with the blogosphere's current buzz about ".NET 2.0 Breaks Apps" and "Longhorn Isn't Being Built On Managed Code." Along the way, we touched upon languages, optimization, and the future of managed code.
Warning: This is “I didn't have time to make it shorter“ stream of consciousness.
Is it scandalous that Microsoft's next generation OS isn't being built upon a foundation of managed code? Coming out of PDC '03, it seemed like a set of boxes neatly fitting into each other: Longhorn will be built on top of WinFX, which will be built on top of Managed Code / the .NET CLR. But that never [really]{style="FONT-STYLE: italic"} could have been the whole story. Take Avalon, the new display stack: it simply couldn't be the case that you could achieve those levels of graphics achievement (video streams mapped onto objects rotating in 3D space and so forth) within the realm of managed code. The CLR just doesn't abstract the hardware to that extent.
Of course, as Moore's Law marches on, it's natural to think that we [can]{style="FONT-STYLE: italic"} achieve more functionality without necessarily modeling the complexity of the underlying hardware. For instance, maybe we don't have to worry about individual pixels anymore when drawing text, maybe we have enough processing power now that we can draw a good-looking 't' that's really 14 points high without worrying about pixel density. So maybe you could move the operating system's text subsystem into managed code. Maybe, maybe not. Flicker-free text (for instance) is not trivial, but if Microsoft stood up and said "In 5 years, the hardware will have gotten to the point where we can move all logic associated with text rendering into managed code. Of course, the final blt to screen will be handled by an unmanaged device driver, but that's at a level where no non-games application developer will every worry about the unmanaged component." I'd say "Okay." And I think some people came out of PDC '03 feeling that Microsoft [did say that]{style="FONT-STYLE: italic"} about [everything]{style="FONT-STYLE: italic"}.
But it never made sense. You cannot do Avalon-y sorts of graphics in a world where memory is an abstract concept; you can't turn a videostream into a relocatable array of Color structs and map them into a dynamically sized array of Triangle structs while playing a sound constructed from a loop that's calling Math.Sin(). The CLR doesn't model on-board graphics memory and GPU capabilities and bus speeds and interrupts or lots of other things that make a difference when dealing with multimedia.
It's always been a case of "How thick and how good are the managed abstractions?" For instance, Windows Forms does a great job of abstracting away Windows' message loops and HWNDs and probably 99% of Windows Forms developers don't have to deal with those unmanaged resources, even though they still exist. Some may not even know they exist and a sizeable percentage certainly don't know the details. As luck would have it, I've been spending a lot of time dealing with Managed DirectX lately, a set of APIs where the abstractions are not nearly as thorough: you need to know about (for instance) message loops and you need to explicitly manage certain resources just as you once had to explicitly manage memory. Managed DirectX is hard. Not as hard as unmanaged DirectX, but hard enough to still be a barrier to some kid with a great idea for a game. To the extent that WinFX / Longhorn exposes APIs that have abstractions as powerful as WinForms, the cause of productivity advances. But if they just slap a managed wrapper around something and say "Ta da!" it's not worth praising. "Managed" is no guarantee of productivity or comprehensibility nor does it inherently provoke innovation.
So what Treadwell clarified is that there are certain parts of Longhorn that will not even have thin managed wrappers. On the other hand, WinFX is "all about managed code," so to the extent you work with Avalon or Indigo, you ought not to have to worry about P/Invoke or breaking out unmanaged C++. He said that WinFX is "our deepest platform bet on managed code," and compared it to the bet they took with ASP.NET, where they achieved something pretty inarguably great. Of course, is API design in WinFX great or shabby? Are the unmanaged APIs for those portions of Longhorn that don't have wrappers great or shabby? These are the issues, not whether those APIs are in or out of the CLR.
I used Managed DirectX as an example of a challenging managed API and he said look, WinFX is trying to hide things like unmanaged resource lifecycles but it won't be 100% for 100% of developers in the first incarnation. Over time, more and more developers will be able to use more and more managed APIs to achieve more and more functionality. But that's the only promise.
So if the concept coming out of PDC '03 was the nice boxes fitting each other, now you have Longhorn as off to the side, but WinFX is still a box that holds nothing but managed code. As Treadwell explained, WinFX's [schedule ]{style="FONT-STYLE: italic"}is coupled to Longhorn's [schedule]{style="FONT-STYLE: italic"}, but technologically, they're not as coupled as they were (I can't believe that Longhorn could be [totally]{style="FONT-STYLE: italic"} uncoupled technologically from WinFX).
I asked about the concern that Avalon and WinForms could create two developer "tracks," each developing in a different paradigm. I wondered if one would be more appealing to corporate developers and the other more appealing to shrinkwrap. He didn't go for it; instead, he insisted that the two are designed to work well together. He said that the first release of Avalon [will not be ]{style="FONT-STYLE: italic"}as good as WinForms for certain things (and, of course, vice versa). There's going to be a "longer transition" to Avalon. He said that it's going to be a "case-by-case, capability-by-capability" thing rather than two clearly defined tracks.
"Realistically, the use of Avalon will be minimal in Office 12," He said, although he mentioned that, for instance, SharePoint has managed components. He [claimed]{style="FONT-STYLE: italic"} not to know if Office 12 will have killer Tablet PC support. (Dammit. All I want to hear from someone is "Yes, Larry, you can write your novel in ink." Speak to me, secret sources: lobrien\@knowing.net)
Since we were talking about abstraction levels and so forth, I asked if the CLR had gotten to the point where it would begin to be the place where we see major innovations or if those were still strictly in the realm of native code. He said that for the foreseeable future it would "be at both levels." He mentioned superfetch (aggressive pre-fetching of files into RAM according to system prediction, presumably using the same general family of algorithms used by CPUs) as something that's fundamentally native and contrasting that with JIT technologies. (I asked about Phoenix and he perked up -- it's clear that's coming along well -- although Phoenix is apparently not inherently bound to either a native or CLR environment.)
Finally, I asked about IronPython. He said that Microsoft's strategy for dynamic languages is "a little up in the air," and they "don't know what our [IronPython] strategy will be." I said that although I loved IronPython, I would have preferred Ruby. He laughed and said he didn't want to get into religious issues.
\<
p style="FONT-SIZE: 10pt; MARGIN: 0in; FONT-FAMILY: Verdana; mso-outline-level: 1"> Oh yeah: he promised that Visual Studio 2005 will ship "later this year" and not in 2006.