There has never been a time when the future of Windows and Windows development looked so uncertain.

The recent blog comments about in-fighting in the Microsoft camp between the Developer and Windows teams and the death of WPF (and possibly Silverlight) seemed all too believable given the state we find ourselves in.

Now Microsoft has answered by claiming that there are more than 200 engineers working on Silverlight and WPF - but of course that could be 199 on Silverlight and 1 on WPF.

What is going on?

So where are we and where might we go?

First a quick reminder of the basic architecture of Windows

Windows is a message passing co-operative multit-asking operating system that has been upgraded to pre-emptive multi-tasking with various levels of process security and protection.

However, when it comes to the basic UI it is still the same framework that was introduced in the days of the 8/16-bit microprocessor. Every application has a window which is the focus of  its interaction with the outside world - both the user and the operating system. Each window has a message pump which receives messages from hardware and from other software and which is used to control what the application does.

In Windows everything is a window

The UI of a Windows application uses other windows to create buttons, textboxes and anything you care to mention. The basic implementation of a window is via the original Windows API which has been growing since the early days.

Even so, every application still looks like an assembly of windows working together sending messages to keep other windows informed of what is going on and receiving and processing messages from yet other windows to react to button clicks and so on.

Now we come to Windows development

In the dark ages before Charles Petzold told us how to program the Windows API it was hard to write even a "hello world" program. Then Petzold's book appeared on the scene and things seemed a little easier - not very easy but at least possible.

Then there was Visual Basic and suddenly anyone could write a Windows program because it wrapped the Windows API into something easier to use.

Next along comes .NET which introduced a managed code environment and a Windows Forms Framework that simply wrapped the old API in a fully object-oriented class library.

But this wasn't sufficient for the future. We needed something better than the clunky old Windows Forms and so WPF was introduced.

WPF enters the frame

WPF isn't just a new wrapper for the underlying windows - it's a new way to work. It makes use of the DirectX 3D rendering engine to create a whole new set of features.

Each WPF application has only one old-fashioned Windows window and this processes the messages to and from the application. You can imagine this acting as a container for the WPF application. After this the WPF framework does the rest, inventing an entirely new windowing system with its own rendering, layout, property system, event handling and so on. It's more like a new graphical front end for Windows than anything else.

But it has its problems. Compared to Windows Forms and the native windowing system it is big, sophisticated, and much more difficult to use. WPF is a step change in complexity and is only a practical proposition because of the way nearly every machine has hardware accelerated  graphics, i.e. a GPU.

Then we have Silverlight

Silverlight is a re-invention of WPF for the browser. It takes WPF cross perform. At first some programmers were worried that Silverlight was a threat to WPF. Why keep something that is platform-specific when you have something that is equal but platform-independent.

The simple answer is that Silverlight is only a subset of WPF and is restricted by security considerations to not using the GPU while running in browser. It was also an unwritten assumption that WPF would develop faster than Silverlight with Silverlight always trying to keep up with the "big guns" of the desktop.

WPF the new Windows...

Part of the expectation was that .NET would also grow into each version of the operating system but this didn't seem to be the way things were actually going.

Each new API and API update were and are still firmly rooted in COM - the technology .NET was supposed to replace.

And the only application to have adopted WPF as its user interface technology is Visual Studio - from the development team not the people working on the operating system. As far as we know there isn't even a sampler for WPF on Windows 7 - Notepad for example might have proved a good candidate for finding out how WPF performed and how to handle it.

At the moment all of the standard windows utilities and applications have ignored WPF.

Consider the environments

The Windows team works in C or C++, creates COM-based APIs and UIs based on the original Windows API i.e. Windows forms.

The Developer team, and the external developers they influence, works in C#, creates .NET object-based APIs and UIs based on WPF or its derivative, Silverlight.

Any resistance the Windows OS camp has to moving to something more sophisticated is fairly natural - it would be a sea change for system programmers wedded to an old technology but one that has served them well.

Now enter HTML5 and its associated hype

When the web was new Bill Gates worried that the browser would kill off Windows. Why have Windows as a desktop OS when you can do everything you need in a browser?

The browser could be the desktop. Microsoft came up with an incredible number of technical ploys to keep Windows essential to the mix - ActiveX, Active Destkop, integrated IE and so on.

The threat from the browser now seems to have been forgotten - just at the moment in time when it looks credible that the browser really will take over the desktop.

Consider a super browser, let's call it Chrome for no particular reason. It implements HTML5 and a lot of new "native" interfaces such as OpenGL, Canvas, Sockets and really anything that is usually supported on the desktop.It has to be native because HTML5 isn't enough to do anything like 1% of the job, but all of these features can be wrapped up under its ever-growing banner.

Now let's add a bit of Linux to the browser so that it can run on bare hardware without a desktop OS. We might as well change the name of the browser to Chrome OS and watch it take over what used to be called the desktop and Window's ecological niche..

And what is Microsoft currently doing to avoid this catastrophic (from its point of view) event?

Nothing - or worse?

Now  it is even suggested that they embrace the opposition by taking HTML5 and making it the core of Windows apps.

Dump WPF. Dump Silverlight. Dump .NET because without the other two it is irrelevant and move to a super browser just like Chrome OS - you could call it something like Explorer OS.This is, of course, speculation but it is reasonable given the lack of OS support for .NET that is in evidence wherever you care to look.

This might be a good move. But it seems to fit in more with an operating systems group who simply will grab at any opportunity to not have to move to .NET, WPF and Silverlight.

These are exciting times - the paradigms they are a changing - and Microsoft is sleepwalking into the trap it has managed to avoid for so long.

<ASIN:0735626707>
<ASIN:143022455X>

<ASIN:157231995X>

<ASIN:0735611319>