Category Archives: silverlight

Silverlight in Microsoft products – Silverlight the new Windows runtime, HTML 5 the new Silverlight?

Is Microsoft ditching Silverlight and embracing HTML 5? Or is Silverlight the future of desktop and browser-based development on Microsoft’s platform?

Good question; and I am not sure that Microsoft itself can answer. There is evidence for both cases.

One thing I have noticed though is that Silverlight is turning up in numerous Microsoft products. This is in contrast to the early years of the original .NET Framework, which Microsoft used rather little in its own stuff, though the context is different today because of the growth in web-based development.

I guess we cannot really count Visual Studio LightSwitch, which is a tool that builds Silverlight applications, though it is interesting insofar as the target market is not expert developers, but smart general users who want to build database applications.

Lync Server 2010 is a better example. Silverlight is used for the control panel.

image

Windows Azure, a strategic product for Microsoft, uses Silverlight for its control panel

image

Windows Intune, for maintaining networks online

image

System Center for managing Microsoft servers. I’m not actually sure how much Silverlight is used in System Center, but I understand the newly announced “Concero”, a new feature for managing public and private clouds, uses a Silverlight control panel and I suspect it is used elsewhere as well.

image

These are a few that I am aware of; I would be interested in other examples.

Now, you can make sense of this to some extent by distinguishing “Windows platform” from “broad reach” applications. It is curious, but Silverlight which started out as a broad reach plugin is gradually moving towards a Windows platform runtime, though it still runs on a Mac with some limitations, mainly lack of COM interop. There has been speculation that Silverlight could merge with the desktop Windows Presentation Foundation and become a commonly used application runtime for desktop Windows as well as web apps, and of course Windows Phone.

When Microsoft wants broad reach, it uses HTML, an example being Office Web Apps which make hardly any use of Silverlight.

Nevertheless, using Silverlight for products like Windows Intune could be annoying for administrators who might otherwise use an Apple iPad when out and about; but I guess Microsoft figures that if you are deep enough into Windows to use Intune, you probably will not be using an iPad.

Let me add that Silverlight seems to me to be working well in the examples above, to the extent that I have tried it. Could they be done equally well in HTML and JavaScript? Probably, if users have IE9, but probably not if it is IE8 or earlier.

Silverlight the new Windows, HTML 5 the new Silverlight?

Mono project: no plans for cross-platform WPF

Miguel de Icaza’s report from the Game Developer Conference is upbeat, rightly so in my view as usage of Mono is continuing to build, not only in game development with Unity, a development tool that uses Mono as its scripting engine, but also for mobile development for Apple’s iOS with Monotouch and for Android with Monodroid. These mobile toolkits also give Mono a stronger business model; many sites use Mono for serving ASP.NET applications on Linux, but without paying or contributing back to the project.

Mono is an open source implementation of C# and Microsoft’s .NET Framework.

That said, it is interesting that Mono is still struggling with an issue that has been a problem since its first days: how to implement Microsoft’s GUI (Graphical User Interface) framework on other platforms. Mono does have Gtk# for Windows, Mac and Linux, but this does not meet the goal of letting developers easily port their Visual Studio client projects to Mono. There is also an implementation of Windows.Forms, but de Icaza mentions that “our Windows.Forms is not actively developed.”

Apparently many tools vendors asked the Mono team at GDC when Windows Presentation Foundation (WPF) would be implemented for Mono. WPF is the current presentation framework for Microsoft.NET, though there is some uncertainty about where Microsoft intends to take it. I remember asking de Icaza about this back in 2003, when the WPF framework was first announced (then called Avalon); he said it was too complex and that he did not plan to implement it.

This is still the case:

We have no plans on building WPF. We just do not have the man power to build an implementation in any reasonable time-frame.

That said, Mono has implemented Silverlight, which is based on WPF, and there are some signs that Microsoft might merge WPF and Silverlight. What would the Mono team do then?

Miguel de Icaza says:

Silverlight runs on a sandbox, so you can not really P/Invoke into native libraries, or host DirectX/Win32 content inside of it.
There are other things missing, like menubar integration and things like that.

Of course, this is no longer true on Windows: Platform Invoke is coming in Silverlight 5.

Perhaps the Mono team will knuckle down and implement Silverlight with desktop integration, which would be good for cross-platform Silverlight and compatibility with Microsoft .NET.

Then again, it seems to me that Mono is increasingly divergent from Microsoft .NET, focusing on implementing C# in places that Microsoft does not touch, such as the mobile platforms from Apple and Google.

That is actually a sign of health; and you can understand why the Mono team may be reluctant to shadow Microsoft’s every move with Silverlight and WPF.

Where is Microsoft going with its Rich Client API? Microsoft drops some clues as developers fret

A discussion taking place in a Windows Presentation Foundation (WPF) newsgroup, in a thread called WPF vNext, shows how Microsoft’s confused rich client development strategy is affecting developers, and offers some clues about what is coming.

Developer Rudi Grobler, who posted on his blog some wishes for Windows Phone, Silverlight and WPF, describes his difficulty in discerning Microsoft’s direction:

The strategy for the future is very vague… I daily get questions about should I use WPF or Silverlight? Is WPF dead? Is Silverlight dead? etc…

Jeremiah Morrill describes his frustration with WPF performance:

Microsoft has known of WPF’s performance problems since the first time they wrote a line of code for it.  You will be hard pressed to find a customer that hasn’t complained about perf issues.  And you will not have gone to a PDC in the last few years and not hear folks bring this up to the WPF team. This is 3rd party info by now, but I’ve been told the issues I have noted have been brought up internally, only to be disregarded.

and remarks his frustration with what has happened to Silverlight:

Silverlight’s strategy USED to be about cross-platform, get-the-runtime-on-every-device-out-there, but it’s obvious that is not the strategy any more.  What happened to Silverlight on set-top-boxes?  Android? I read an article that some people saw it on XBox, but nobody has talked about it since.  Cross-platform with OSX has become symbolic at best.

Developer Peter O’Hanlon describes how the uncertainty has affected his business:

I run a small consultancy, and I bet the company on WPF because I could sell the benefits of faster development time for desktop applications. We have spent a lot of time learning the ins and outs of the platform and saw that Silverlight gave us a good fit for developing web apps. In one speech Microsoft caused me months of work repairing the damage when Muglia seemed to suggest that these technologies are dead and Microsoft are betting the farm on Html 5. We hand our code over to the client once we have finished, and they ask us why they need to invest in a dead technology. I don’t care what you say on this thread, Microsoft gave the impression that html 5 was the way to go.

[…] Muglia’s statement about the future being html caused serious issues for my company. We lost two bids because the managers didn’t want to commit to "dead" technology.

Microsoft’s Jaime Rodrigues, WPF Technical Evangelist, offers the following response:

You are telling us to improve perf in WPF. We hear this loudly and we are trying to figure how to solve it. Unfortunately, there are a few pieces to consider:

1)      First of all,  a lot of our customers are telling us to invest more into Silverlight.  Let’s say (again made up) that demand is  4-to 1. How do we justify a revamp of the graphics architecture in WPF.  This is not trivial work; the expertise in this space is limited, we can’t clone our folks to 5x to meet everyone’s needs.

2)      Let’s assume we did take on the work.  My guess (again, I am not engineering) is that it would take two years to implement and thorougly test a release.  At the stage that WPF is at, a rearchitecture or huge changes on the graphics stack would be 80% about testing and 20% about the dev work.    It is not a trivial amount of work.   Would we get the performance you want across myriad of devices? We don’t know. WPF bet on hardware, and there is new devices out  there that are trading hardware for battery, weight, or simply for cost.  it would suck to do that much work, make you wait a long time, and then not get there. Let’s get real on the asks; you say "improve perf" but you are asking us to do a "significant re-write"; these two asks are different.

3)      By the time we get there, what will be a more powerful framework?  Silverlight, WPF, C++, or SuperNew.Next ??  we don’t know today.  We go back to #1 and look at demand We are in agreement that "customers" is the driving principle.

The WPF has looked at the trade-offs, and risk many times.  We are also looking at what customers need. Jer, to you it is all about graphics.  To many others, it is about data.  So, how do we serve all customers??
The strategy is exactly what you have seen/heard:

1)      WPF 4.5 is going to have some significant data binding performance improvements.

2)      We are not redoing the graphics framework, but we are doing a lot of work to let you interoperate with lower level graphics so that if you need more graphics perf you can get it, and still keep the RAD of the rest of the framework.

[…] Hope it helps; apologies if it does not, and again, wait for Rob Relyea or someone else to make it official.  That is just my 2c as a person who bet heavily on WPF but has seen the data that drives the trade-offs the team has to make.

This will be disappointing to former Microsoft evangelist Scott Barnes, who has initiated a Fix WPF campaign.

The problem though is lack of clarity about the strategy. Look at Rodrigue’s third point above. Nobody can predict the future; but what is Microsoft’s current bet? Silverlight, HTML5, or maybe SuperNew.Next – for example, the rumoured new native code UI for Windows 8 or some variant of it?

My own view is that the current difficulties are rooted in what happened with Longhorn and the fact that the Windows team abandoned WPF back in 2004. I’ve written this up in more detail here.

Lest this post be misinterpreted, let me emphasise that Microsoft has a good track record in terms of supporting its Windows APIs long-term, even the ones that become non-strategic. Applications built with the first version of .NET still run; applications built with Visual Basic 6 mostly still run; applications built for ancient versions of Windows often still run or can be coaxed into running. Build an application with WPF or Silverlight today, and it will continue to work and be supported for many years to come.

My guess is that events like the coming 2011 MVP Summit and Mix 2011 in April will bring some clarity about Microsoft’s mobile, tablet, Windows and cross-platform story for rich clients.

Update: Barnes has his own take on this discussion here.

Microsoft still paying the price for botched Vista with muddled development strategy

Professional Developers Conference 2003. Windows Longhorn is revealed, with three “pillars”:

  • Avalon, later named Windows Presentation Foundation (WPF)
  • Indigo, later named Windows Communication Foundation (WCF)
  • WinFS, the relational file system that was later abandoned

With the benefit of hindsight, Microsoft got many things right with the vision it set out at PDC 2003. The company saw that a revolution in user interface technology was under way, driven by the powerful graphics capabilities of modern hardware, and that the old Win32 graphics API would have to be replaced, much as Windows itself replaced DOS and the command-line. XAML and WPF was its answer, bringing together .NET, DirectX, vector graphics, XML and declarative programming to form a new, rich, presentation framework that was both designer-friendly and programmer-friendly.

Microsoft also had plans to take a cut-down version of WPF cross-platform as a browser plugin. WPF/Everywhere, which became Silverlight, was to take WPF to the Mac and to mobile devices.

I still recall the early demos of Avalon, which greatly impressed me: beautiful, rich designs which made traditional Windows applications look dated.

Unfortunately Microsoft largely failed to execute its vision. The preview of Longhorn handed out at PDC, which used Avalon for its GUI, was desperately slow.

Fast forward to April 2005, and Windows geek Paul Thurrott reports on Longhorn progress:

I’m reflecting a bit on Longhorn 5048. My thoughts are not positive, not positive at all. This is a painful build to have to deal with after a year of waiting, a step back in some ways. I hope Microsoft has surprises up their sleeves. This has the makings of a train wreck.

Thurrott was right. But why did Longhorn go backwards? Well, at some point – and I am not sure of the date, but I think sometime in 2004 – Microsoft decided that the .NET API for Longhorn was not working, performance was too bad, defects too many. The Windows build was rebased on the code for Server 2003 and most of .NET was removed, as documented by Richard Grimes.

Vista as we now know was not a success for Microsoft, though it was by no means all bad and laid the foundation for the well-received Windows 7. My point though is how this impacted Microsoft’s strategy for the client API. WPF was shipped in Longhorn, and also back-ported to Windows XP, but it was there as a runtime for custom applications, not as part of the core operating system.

One way of seeing this is that when Longhorn ran into the ground and had to be reset, the Windows team within Microsoft vowed never again to depend on .NET. While I do not know if this is correct, as a model it makes sense of what has subsequently happened with Silverlight, IE and HTML5, and Windows Phone:

  • Windows team talks up IE9 at PDC 2010 and does not mention Silverlight
  • Microsoft refuses to deliver a tablet version of Windows Phone OS with its .NET application API, favouring some future version of full Windows instead

Note that in 2008 Microsoft advertised for a job vacancy including this in the description:

We will be determining the new Windows user interface guidelines and building a platform that supports it. We’ll eliminate much of the drudgery of Win32 UI development and enable rich, graphical, animated user interface by using markup based UI and a small, high performance, native code runtime.

In other words, the Windows team has possibly been working on its own native code equivalent to XAML and WPF, or perhaps a native code runtime for XAML presentation markup. Maybe this could appear in Windows 8 and support a new touch-oriented user interface.

In the meantime though, Microsoft’s developer division has continued a strong push for .NET, Silverlight and most recently Windows Phone. Look at Visual Studio or talk to the development folk, and you still get the impression that this is the future of Windows client applications.

All this adds up to a muddled development story, which is costly when it comes to evangelising the platform.

In particular, eight years after PDC 2003 there is no clarity about Microsoft’s rich client or RIA (Rich Internet Application) designer and developer story. Is it really WPF, Silverlight and .NET, or is it some new API yet to be revealed, or will IE9 as a runtime play a key role?

There is now a little bit more evidence for this confusion and its cost; but this post is long enough and I have covered it separately.

Nokia plus Windows Phone 7 – would that be a smart move?

The rumour is that Nokia’s CEO, ex-Microsoft Stephen Elop, is planning a major strategy announcement on Friday February 11. The obvious move would be to embrace a new Smartphone platform, since neither Symbian nor MeeGo look likely to catch up with frontrunners Google Android or Apple iPhone. Could Elop be planning to partner with his former company and embrace Windows Phone 7?

It is a fascinating proposition. Here is the case in favour. For both Nokia and Microsoft, Android is the key competition in this market. The momentum behind Android is deterring both phone manufacturers and operators from investing seriously in Windows Phone 7. Microsoft’s phone is well-regarded, but has made little impact on the general public. Nokia could change that; it could make beautiful Windows 7 phones and get them to the mass market.

Microsoft has also done a good job with the developer tools for Windows Phone 7, with Visual Studio 2010, Silverlight, XNA, and the .NET Framework.

On the other hand, if Nokia were to adopt Windows Phone 7 for its high-end phone platform, would it not alienate its own development community, which is oriented towards Linux and C/C++? I think it would, unless Nokia insisted that as part of its deal with Microsoft, Windows Phone 7 would also support native code development with Qt, Nokia’s cross-platform application framework. This would be great news for Microsoft as well, though it might not recognise it. Windows Phone 7 needs to allow native code development, and Qt is ideal for the purpose. Qt already supports Windows CE, which underlies Windows Phone 7. If Nokia could present Windows Phone 7 as just another platform for Qt, the deal would be palatable for existing Nokia developers.

If Nokia were to announce this, it would transform the prospects for Microsoft’s Smartphone OS as well as helping Nokia to make a renewed impact.

Now for the case against. I am not sure that Qt on Windows Phone 7 would be acceptable to Microsoft, which might prefer to keep developers locked to Visual Studio and .NET; and Nokia has an easy alternative, which is to adopt Android instead. Qt support is still an issue, but there is already an independent project to bring Qt to Android. The combination of the Android and Nokia brands has obvious appeal, whereas taking on Windows Phone 7 would be risky.

The biggest shadow over Windows Phone 7 is cast by Microsoft itself. I do not doubt the commitment of the team which builds it within Microsoft, nor the quality of the developer tools. I do question though whether Microsoft as a whole sees a long-term future for Windows Phone 7 and its “Metro” user interface. The strong hint at CES was that Windows 8, rather than Windows Phone 7, is the basis of Microsoft’s tablet strategy; and if that proves to be the case, then Windows Phone 7 may gradually be displaced. Another puzzle is how Microsoft intends to use “Jupiter”, a rumoured new user interface library for Windows that may well be designed with mobile and touch control in mind. Maybe full Windows with “Jupiter” is the future of Microsoft’s mobile platform, rather than Windows Phone 7? I discuss this in more detail here.

There is enough uncertainty around Windows Phone 7, and enough buzz around Android, that Google’s mobile platform looks to me more attractive than Microsoft’s from Nokia’s perspective. I do not dismiss the Windows Phone idea though; it would be a bold and interesting move.

I expect this post to be very out of date soon, if not by Friday, then certainly by early next week at Mobile World Congress.

Update: A Nokia and Microsoft partnership is looking more likely since Google’s Vic Gundotra tweeted:

#feb11 "Two turkeys do not make an Eagle".

Silverlight native extensions allow deep Windows 7 integration, but forget cross-platform

Microsoft has released Native Extensions for Silverlight, a set of libraries which enable access to Windows 7 features including taskbar Jump Lists; access to attached devices including webcams, cameras and phones; the sensor API for accelerometer support; and even the ability to intercept Windows messages. The ability to intercept Windows messages allows lots of interesting hacks as veteran Visual Basic developers will recall; it was one of the tricks used to overcome limitations in early versions of VB.

The native extensions are only available to out of browser applications running outside the sandbox; the user must consent to trust such applications. Silverlight 4 already had the ability to use COM automation. These new extensions simply build on this existing feature, providing COM automation wrappers for these Windows 7 APIs.

What this means though is that Silverlight developers can create applications that integrate deeply with the Windows 7 desktop and local hardware.

Another way of looking at this is that the subset of Windows applications that can be implemented in Silverlight rather than the full .NET Framework has now increased. It lends some support to the theory which I considered here, that a future version of Silverlight will be the application platform for the Windows 8 app store and for mobile devices running Windows 8. This is speculation though; Microsoft has not said much publicly on the subject. Silverlight is well suited to an app store since installation is easy, updates are near-automatic, and apps are isolated from the rest of the operating system.

The native extensions are Windows 7 only. Forget the Mac, these things do not even work on Windows XP. They only apply to trusted out of browser applications though. Silverlight running in the browser still has similar features on Windows and Mac.

Talk of Windows 8 on an smartphone shows Microsoft’s mobile confusion

During a conference call to discuss Intel’s latest financials, CEO Paul Otellini raised the possibility of putting the full Windows OS onto a smartphone, running a low power Intel SoC (System on Chip). The matter came up with Otellini was asked about the impact of Windows on ARM, announced at CES earlier this month:

The plus for Intel is that as they unify their operating systems we now have the ability for the first time: one, to have a designed-from-scratch, touch-enabled operating system for tablets that runs on Intel that we don’t have today. And secondly, we have the ability to put our lowest-power Intel processors running Windows 8 – or ‘next-generation Windows’ – into phones, because it’s the same OS stack. And I look at that as an upside opportunity for us.

The reasoning seems to be: if Windows 8 is designed to run well on mobile devices with ARM, it will also run well on mobile devices with an Intel SoC, which will let us put it on phones.

Note the point he highlighted: Microsoft unifying its operating systems. No more full Windows vs Windows CE; one OS from mobile to desktop.

Although that sounds compelling, the snag is that Windows is not well suited to low-power mobile devices, which is why Windows CE was invented in the first place. Microsoft can fix this to some extent by fixing the things that make it unsuitable, but it carries a heavy compatibility burden.

It also throws up the question: just what are Microsoft’s long-term plans for Windows Phone 7, which is built on Windows CE, has its own GUI mostly written in native code, and a development platform based on .NET – Silverlight and XNA – plus a native code SDK that only mobile operators and device manufacturers get to use?

At CES Microsoft Steven Sinofsky sort-of denied that Windows will encroach on Windows Phone 7 territory. “Windows Phone 7 is uniquely focused on the small form factor that Windows doesn’t focus on,” he said.

Nevertheless, the company’s decision not to use the Windows Phone 7 OS for tablets may make that inevitable. What is the difference between a smartphone and a small tablet? Does Microsoft expect developers to write apps designed for Windows on a small tablet and then rewrite them for Windows Phone 7 using Silverlight?

It does not make sense; and despite the Windows Phone 7 promotion included in CEO Steve Ballmer’s CES keynote, I was left wondering whether Microsoft’s new mobile OS really has a future.

That said, Silverlight abstracts the OS, so in principle Microsoft could use it to form a consistent mobile development platform irrespective of whether the underlying OS is Windows CE or full Windows. I am not getting that sense from the company though, and I’d expect the primary Windows SDK to remain based on C++.

I am struggling to understand how Microsoft expects this to work. App compatibility is the obvious benefit of full Windows; but two big issues are that most Windows apps are not touch-friendly and are not designed for small screens. Putting Windows on a tablet with a decent screen size and the dreaded stylus works to some extent, but will never compete with Apple’s iPad for usability. On smaller screens most existing apps will not work properly; and if Windows on small devices sprouts a completely new touch-friendly GUI, or borrows the one from Windows Phone 7, then app compatibility with desktop Windows will be limited.

It feels as if Microsoft’s Windows team is saying one thing, the Windows Phone 7 and developer teams saying another, and partners like Intel saying yet another. Windows Phone 7 was meant to be the thing that made belated sense of Microsoft’s mobile strategy, but even that now looks doubtful for the reasons stated above.

Microsoft is still a long way from having a coherent strategy for mobile devices, and that lack is damaging the company and helping Apple and Google to establish their competing operating systems.

Update: Mary-Jo Foley writes about Microsoft “Jupiter” which is a rumoured new user interface and application model designed for Windows 8 and its app store:

Jupiter is going to be a new user interface (UI) library for Windows, built alongside Windows 8. It will be a thin XAML/UI layer on top of Windows application programming interfaces and frameworks for subsystems like graphics, text and input. The idea is Jupiter will bring support for smoother and more fluid animation, rich typography, and new media capabilities to Windows 8 devices.

Is Jupiter a .Net technology, or XAML adapted for native code, or both? Is it one and the same as, say, Silverlight 6? That is not stated, though Senior VP Soma Somasegar helpfully (or not) said that:

some of the information in this post is not right and out of date, not reflecting Microsoft’s current thinking.

That seems to tacitly confirm that it fairly represents Microsoft’s thinking at some time in the not-too-distant past.

It would make sense to me if Microsoft used Silverlight to unify its application platform as mentioned above, and combining the XAML presentation layer with native code could address performance and memory usage concerns with .NET. This is the kind of news that would really give confidence to Silverlight developers, rather than the damage limitation PR that Microsoft has put out since PDC late last year.

On the other hand, I believe Somasegar when he says the information is out of date, so for the time being it is just another dose of uncertainty.

Adobe AIR is user-hostile compared to native apps says BankSimple CTO

Alex Payne, CTO at BankSimple, has written an analysis of Adobe AIR from the user’s perspective. The scenario: his team was looking for a an alternative to Campfire for group chat, and selected HipChat. They liked the features of HipChat, but not the desktop app, which is built using Adobe AIR:

My team experienced a number of the usual problems one has with AIR applications: lousy performance, odd interface bugs, key combinations and UI elements that didn’t conform to our operating system. AIR apps exist in an uncanny valley between a web application and a desktop application, and the result is unsettling and annoying. Pretty soon, we were itching to go back to Campfire (via the native Mac client Propane), even though HipChat has better features and the promise of improved reliability.

Payne investigated further and came to the conclusion that users prefer native apps; and that cross-platform toolkits are for the benefit of software companies not users. Echoes of Steve Jobs’ Thoughts on Flash:

Flash is a cross platform development tool. It is not Adobe’s goal to help developers write the best iPhone, iPod and iPad apps. It is their goal to help developers write cross platform apps.

And lest you think this is bad for AIR but good for Java, note that Payne adds:

For anyone who used a computer in the 1990s, AIR probably brings back scarring memories of Java apps: slow, ugly, inconsistent, awkward.

I was also reminded of Evernote’s experience with .NET versus native code, which I blogged here.

Payne is not all wrong, neither is Jobs. That said, the distinction between what is good for users and what is good for developers is not absolute. Maintaining a single cross-platform code-base, for example, is good for both users and developers, because it reduces bugs and assists feature-compatibility across platforms. It is also good for users of minority platforms who might otherwise have nothing.

Another question: how many of the issues Payne identifies are inherent to using AIR (or another cross-platform runtime), and how many are implementation issues? It is impossible to know without drilling into the details; but I don’t believe that all AIR (or Java, or .NET) apps have “lousy performance”.

It is true that ActionScript code is slower than Java or .NET code, and much slower than compiled C/C++, but speed of script execution is not always the performance bottleneck that users will notice most.

This is seemingly one of those never-ending computing debates; but a post like Payne’s is a reminder that neither Adobe AIR, nor any cross-platform runtime, is a perfect solution to the challenge of multiple client platforms.

Bob Muglia leaving Microsoft, CEO Steve Ballmer searching for new cloud leadership

Microsoft has announced that Bob Muglia, President of Server and Tools, is leaving Microsoft.

In his memo, Steve Ballmer says:

Bob Muglia and I have been talking about the overall business and what is needed to accelerate our growth. In this context, I have decided that now is the time to put new leadership in place for STB. This is simply recognition that all businesses go through cycles and need new and different talent to manage through those cycles.

It is always hard to tell from the outside, but in my encounters Muglia has been among the most articulate and confident of Microsoft’s top executives. I have also noticed in my regular look at Microsoft’s financials that the Server and Tools business has performed consistently well for as long as I can remember.

Most recently, Muglia took over the Azure business and seemed to know where he was going with it. He is also responsible for developer tools, and while his remarks about Silverlight at Microsoft’s PDC in November were disappointing to developers on that platform, they showed a clear sense of direction.

In this context, it seems surprising that Ballmer is in search of “new and different talent”. It does sound as if Ballmer and Muglia do not see the future of the cloud business – which is the focus of the memo – in the same way.

The key question: in what way did Ballmer and Muglia’s vision differ? I guess we will get some more clues as today’s news is discussed.

Update: Mary Jo Foley has posted Bob Muglia’s internal email to his team:

Later this year, I’m moving on to new opportunities outside of Microsoft, so I wanted to take a few minutes to share with you what’s important to me in life and leadership.

The foundation of who I am is based on living with integrity. Integrity requires principles, and my primary principle is to focus on doing the right thing, as best I can. The best thing, to the best of my ability, for our customers, our products, our shareholders, and of course, our people.

Just sugar, or did Muglia feel that staying at Microsoft would compromise those principles?

Since the announcement, the reaction across the industry has shown the high regard in which he is held, and bewilderment at why he is being let go. Here’s Redmonk analyst James Governor on Twitter:

Another exit: Microsoft server chief Muglia leaving company normally i say so what but this is TERRIBLE for microsoft

Steve Ballmer at CES: Microsoft pins mobile hopes on Windows 8

Microsoft CEO Steve Ballmer gave the keynote at CES in Las Vegas last night. It was a polished performance and everything worked, but was short on vision or any immediate answer to the twin forces of Apple iPad and Google Android which are squeezing out Microsoft in the mobile world – smartphones and tablets – which currently forms the centre of attention in personal computing.

That said, CES stands for Consumer Electronics Show; and Ballmer did a good job showing off how well Kinect is performing, claiming sales of 8 million already. He showed more examples of controlling Xbox through speech and gesture, and said that Kinect is also boosting sales of the console; clearly it is now taking it beyond the hardcore market of first-person shooters.

We saw some fun new Windows devices, such as Acer’s dual-screen Iconia laptop.

image

There was also a demonstration of the updated Microsoft Surface which now runs full Windows 7 and does not require hidden cameras, so that it can now be used in more scenarios, such as for interactive digital signage.

All well and good; but what about mobile? We got a Windows Phone 7 demo, but no sales figures, nor any mobile partners on stage; I’m guessing they are too busy promoting their new Android devices. Ballmer did say that the phone is coming on Verizon and Sprint in the first half of this year. Application availability is improving, but how will Microsoft win attention for its smartphone? My local high street is full of mobile phone shops, none of which even stock it as far as I can tell. There is a tie-in with Xbox Live which may help a little.

The problem though is that Microsoft does not seem to be wholeheartedly behind the Windows Phone 7 OS, which is based on Windows CE with a new GUI and Silverlight/XNA runtime for applications. Rather, Microsoft is signalling that full Windows is its future mobile operating system. At CES it announced Windows on ARM, the processor of choice in mobile, and during the keynote we saw the next version of Windows (though with the Windows 7 GUI) running on various ARM devices.

The power available in new System on a Chip packages like NVIDIA’s Tegra 2 leaves me in no doubt that full Windows could technically run on almost any size of device; but that does not make it the sensible choice for all form factors. Note also that while it was not mentioned at CES, NVIDIA has said that Tegra 2 is optimized for Android.

Microsoft could plausibly have released a tablet based on the Windows Phone 7 OS, which is built for touch control, this year. Instead, it will be at least 2012 before we see a Windows 8 tablet, and we are taking it on trust that this will really work nicely with touch and not need a stylus dangling at the side. By then Apple will, I presume, be releasing iPad generation 3.

Putting this in a developer context, what is Microsoft’s mobile development platform? Silverlight and XNA? The full Windows native API? Or HTML 5? Each of these is very different and it seems to me a muddled story.