This article gets more than a smidge of its history wrong. For instance, it makes it seem as if WPF (nee Avalon) was written by DevDiv in isolation from Windows, where in reality the Avalon team was mostly made of the former IE team after its legal dismemberment. In fact, we moved my team (which was focused on developer tools on, for, and made with WPF) from DevDiv buildings into Windows buildings just so we could build apps and tools for Avalon to help test their platform.<p>But, it was a big effort. And even coming from inside of Windows, getting the rest of the shell to run on a whole new stack -- from drivers, through C++ layers, through managed -- was a challenge, especially with all of the other things going on in Longhorn. Sometimes, you bite off more than you can chew, especially when you make the dependency stack too deep.<p>Also, all of this happened <i>long</i> before Silverlight efforts started... XAML came out of the WPF work. Arguing Silverlight stole DevDiv focus from WPF during the Longhorn timeframe is temporally impossible. Certainly, you could argue DevDiv was being pulled in many directions with the concurrent efforts to placate the VB4 crowd, push out a new version of VS, figure out a new syntax for Managed C++, compete with the then-rapidly-expanding Java tools ecosystem, and support all of the internal and demanding partners (especially SQL and other Windows efforts). But a substantial portion of both the tools and .NET runtime team's efforts were spent making Avalon perform, and I don't think that even now anybody who was there would claim that more DevDiv resources could have made the "Windows Shell is now made from WPF" effort succeed in the desired schedule.
The article plays on the ambiguity in the phrase "Windows is not based on .NET."<p>On the one hand, if "Windows" refers to the black box bits and pieces of code which make up the Windows operating system, then it is pretty much true that Windows is not based on .NET.<p>On the other hand, if "Windows" refers to the interfaces to the black box with which software developers <i>typically</i> interact, then it is largely true that Windows is based on .NET because .NET provides control of the operating system for the vast majority of projects. Yes, there are exceptions - but from a practical standpoint, the working of the black box is irrelevant for most projects and it appears that Microsoft recognized this when Longhorn was shelved.<p>The speculation that the javascript/HTML5 model indicates a fundamental architectural shift in the Windows OS core seems to be unjustifed - the meaningful evidence for such an architectural shift being underway is the demonstrated ability of Windows 8 to run on diverse architectures.<p>Which is why the FUD being disseminated about the Javascript HTML model is so interesting. It is nothing new; merely another implementation of an idea Microsoft has been kicking around for years: i.e. HTA's (HTML Applications) have been a part of Windows for more than a decade.<p>[<a href="http://en.wikipedia.org/wiki/HTML_Application" rel="nofollow">http://en.wikipedia.org/wiki/HTML_Application</a>]<p>[<a href="http://msdn.microsoft.com/en-us/library/ms536496%28v=VS.85%29.aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/ms536496%28v=VS.85%2...</a>]<p>In addition given that .NET can provide total control of the browser and that such a browser exists on the Windows platform in the form of IE, the whole javascript/html model Microsoft demonstrates can be seen as just another layer running on top of .NET.
I sell a Windows application targeted toward business users. 57% of my site's visitors are still running XP. Of those who purchase, 50% are XP, 40% are Win 7, and 10% are Vista users. So forgive me for not getting excited about changes to any upcoming version of Windows because until the folks in Redmond design an OS that businesses are interested in, it's mostly moot.
How can there be so much in fighting within Microsoft?<p>Surely there must be a manager somewhere that looks over both teams and makes sure they aren't trying to shaft each other.
".NET would be the way to write Windows applications. Win32 would still exist for backwards compatibility, but it would be frozen and left static."<p>OMG, Another non-technical person trying to write about technology again <sigh>