|Making sense of Microsoft .NET and HTML5|
|Written by Mike James|
|Friday, 24 June 2011|
The suggestion that is now doing the rounds that Windows 8 is going to finally bring the Longhorn project to fruition may be a rumor - but it seems to make a lot of sense when you piece the puzzle together.
There has been much speculation on where Microsoft is going with .NET and HTML5. The company hasn't helped in this and its pronouncements and lack of pronouncements have made a difficult situation much worse.
Now we have some light at the end of the tunnel. An article in Ars Technica - Windows 8 for software developers: the Longhorn dream reborn? spills the beans - although there is no indication where the beans actually came from. Should you trust such unattributed information? In most cases the answer should be no but in this case the description makes a lot of sense so perhaps there is some truth in it. The argument presented is also remarkably detailed and it fills in some of the missing features absent from earlier leaks and speculations.
The argument presented is that Windows 8 is to be the big step forward that the ill-fated Longhorn version of Windows was supposed to be. We all know that Windows has a legacy problem. It's basically a C/C++ system with an unsophisticated low level API. Longhorn was supposed to be the first step away from this but it was too ambitious and we ended up with .NET and WPF instead. There's nothing much wrong with .NET and WPF but the Microsoft Windows team ignored it and is still ignoring it. New Windows APIs have been based on function calls or at best COM.
The new idea is that Windows 8 is a move away from the raw API and will ship with a new .NET runtime plus a COM derived C++ runtime called WinRT. A new native UI library called DirectUI will be built on top of Direct2D. This will bring a COM or .NET UI to Windows 8 that has all of the advantages of WPF - i.e. the hardware acceleration and sophistication offered by a modern GPU based graphics hardware.
Why not just use WPF? The answer is that its not easy to use from C++ so in a sense the C++ Windows development team has won and managed code has lost out. In short it is not WPF and .NET that replaces Win32 but WinRT/DirectUI.
Silverlight will be available in this new world but will be built, or is that rebuilt, on top of WinRT/DirectUI. DirectUI will also have a XAML interface making .NET programmers feel at home. It isn't clear at the moment how much of Silverlight 6 or Jupiter as it is codenamed will retain the way that Silverlight does things.What of WPF? Well at the moment it seems probably that this is simply lost in transition. Why do you need WPF when Silverlight is the .NEt tool used to create the UI?
If all of this sounds like a backward step then you are a .NET programmer. If you think it's a great leap forward then you are most probably a C++ programmer. The whole point is that that this shift gives .NET and C++ an equal stake in an advanced API.
Is this good or bad?
A unified UI API for Windows that is based on something modern is good. Ripping up the infrastructure and starting over is bad - but it's a tendency that most programmers can't resist. It seems that the managed code faction in Microsoft never managed to convince the firmly C++/COM Windows development team to use the new technology and now they are paying the price.
Why be so silent on a matter where silence is clearly doing more harm than good?
As they keep on saying - watch this space....
In an article Mary Jo Foley reports a leaked email:
"Microsoft on June 20 split up its XAML team, sending part of it to Windows, part to Windows Phone and leaving part in the Developer Division, according to an e-mail from Developer Division chief Soma Somasegar dated June 20."
This fits in reasonably well with XAML becoming a core Windows technology and not part of the .NET sub-system.
|Last Updated ( Friday, 24 June 2011 )|