I’m sure we’ve all seen Richard’s commentary on the state of .NET as well as Dan Fernandez’s rebuttal. If not, go read those first. Since the subject has already been talked to death from the .NET framework perspective, the only thing that I wanted to address is the assertion that Richard makes in his follow up comment in Dan’s rebuttal where he states:
As to your comments on Avalon and Indigo. I concede your point about Indigo, but I refute your point about Avalon. In Dec 2004 a tech preview of Avalon was made publicly available on MSDN downloads, and by examining this with ildasm it is clear to me that Avalon is yet another wrapper over Win32. Avalon is based on Windows messages, and uses GetMessage, DispatchMessage et al, that Windows developers have been comfortable with since 16 bit Windows!
First off, Richard’s absolutely right, there are all kinds of calls to Win32 messaging APIs in the Avalon CTP. However, the important thing to realize is that none of this is exposed via the Avalon API itself. Of course there needs to be calls to Win32 APIs under the covers, this is just how things get done on Win32. Therefore, backporting Avalon to Win32 meant that some things had to be accounted for and handled using the existing platform’s plumbing. Why do we care how Avalon is implemented under the covers so long as those details are hidden from us? If I can write an Avalon application that runs on Win32 just as good as it will run on WinXXX three to five years from now, who cares what they do to preserve that?
Let’s examine the one specific area which demonstrates Avalon’s abstraction from the underlying OS: the UIDispatcher class. The UIDispatcher class’ job is to dispatch messages received from the underlying OS to the UIContext for a particular Avalon application. Now obviously in Win32, these messages need to be handled via a message pump, so there is a specific implementation of a UIDispatcher called the Win32Dispatcher (go figure). More specifically, if you’re writing an Avalon application that is going to use WinForms controls (or any windows controls really) you need to go one step further and use the HwndDispatcher. Oh and by the way, this is also the piece that enables the reverse scenario: Avalon controls hosted in legacy Windows/WinForms applications. The key to this part of the API though is that this is the piece where things get translated from native OS messages to strongly typed Avalon events. Beyond Win32Dispatcher, there is no such thing as a Win32 style message.
Next let’s examine the most obvious dependency of Avalon: DirectX. Under the covers, Avalon is making heavy use of the DirectX API in order to achieve its rendering goals. This is another area where there is there is just zero leakage in the API. As an Avalon programmer working at almost the deepest depths of the graphics plumbing in the API I see no signs of DirectX whatsoever. What does this mean? It means that once again Avalon could technically run on any graphics API under the covers. It happens to be DirectX9 right now, but whenever DirectX10 rolls out the Avalon team could also roll out some optimizations to the Avalon API which take advantage of that version without my application being any wiser.
So, is this a bad thing? If so, I just don’t see it. What this really means to me is that they’re doing an excellent job separating Avalon from any one underlying architecture and, in fact, enabling it to run optimally on any architectures they introduce down the line with very little work and almost zero changes to existing applications. The reason we’re at the point where Avalon is even being built on these “older” architectures, as has already been mentioned, is because customers were demanding it and Microsoft actually listened.