Reflections on Microsoft BUILD 2011

I’m just back from Microsoft’s BUILD conference at Anaheim in California, which lived up to the hype as a key moment of transition for the company. Some said it was the most significant PDC – yes, it was really the Professional Developers Conference renamed – since 2000, when .NET was introduced; some said the most significant ever.

“Significant” does not necessarily mean successful, and history will judge whether BUILD 2011 was a new dawn or the beginning of the end for Windows. Nevertheless, I have not heard so much cheering and whooping at a Microsoft conference for a while, and although I am no fan of cheering and whooping I recognise that there was genuine enthusiasm there for the new direction that was unveiled.

So what happened? First, let me mention the Windows Server 8 preview, which looks a solid upgrade to Server 2008 with a hugely improved Hyper-V virtualisation and lots of changes in storage, in IIS, networking, in data de-duplication, in modularisation (enabling seamless transition between Server Core and full Server) and in management, with the ascent of PowerShell scripting and recognition that logging onto a GUI on the server itself is poor practice.

The server team are not suffering the same angst as the client team in terms of direction, though the company has some tricky positioning to do with respect to Azure (platform) and Server 8 (infrastructure) cloud computing, and how much Microsoft hosts in its own datacentres and how much it leaves to partners.

What about Windows client? This is the interesting one, and you can almost hear the discussions among Microsoft execs that led them to create the Windows Runtime and Metro-style apps. There is the Apple iPad; there is cloud; there are smartphones; and Windows looks increasingly like a big, ponderous, legacy operating system with its dependence on keyboard and mouse (or stylus), security issues, and role as a fat client when the industry is moving slowly towards a cloud-plus-device model.

At the same time Windows and Office form a legacy that Microsoft cannot abandon, deeply embedded in the business world and the source of most of the company’s profits. The stage is set for slow decline, though if nothing else BUILD demonstrates that Microsoft is aware of this and making its move to escape that fate.

Its answer is a new platform based on the touch-friendly Metro UI derived from Windows Phone 7, and a new high-performance native code runtime, called Windows Runtime or WinRT. Forget Silverlight or WPF (Windows Presentation Foundation); this is a new platform in which .NET is optional, and which is friendly to all of C#, C/C++, and HTML5/JavaScript. That said, WinRT is a locked-down platform which puts safety and lock-in to Microsoft’s forthcoming Windows Store ahead of developer freedom, especially (and I am speculating a little) in the ARM configuration of which we heard little at BUILD.

BUILD attendees were given a high-end Samsung tablet with Windows 8 pre-installed, and in general the Metro-style UI was a delight, responsive and easy to use, and with some fun example apps, though many of the apps that will come as standard were missing and there was evidence of pre-beta roughness and instability in places.

The client strategy seems to me to look like this:

Windows desktop will trundle on, with a few improvements in areas like boot time, client Hyper-V, and the impressive Windows To Go that runs Windows from a bootable and bitlocker-encrypted USB stick leaving no footprint on the PC itself. Many Windows 8 users will spend all their time in the desktop, and I suspect Microsoft will be under pressure to allow users to stick with the old Start menu if they have no desire or need to see the new Metro-style side of Windows..

A new breed of Intel tablets and touch-screen notebooks will make great devices towards the high end of mobile computing. This is something I look forward to taking with me when I need to work on the road: Metro-style apps for when you are squashed in an aeroplane seat, browsing the web or checking a map, but full Windows only a tap away. These will be useful but slightly odd hybrids, and will tend to be expensive, especially as you will want a keyboard and stylus or trackpad for working in desktop Windows. They will not compete effectively with the iPad or Android tablets, being heavier, with shorter battery life, more expensive and less secure. They may compete well with Mac notebooks, depending on how much value Metro adds for business users mainly focused on desktop applications.

Windows on ARM, which will be mainly for Metro-style apps and priced to compete with other media tablets. This is where Microsoft is being vague, but we definitely heard at BUILD that only Metro-style apps will be available from the Windows Store for ARM, and even hints that there may be no way to install desktop apps. I suspect that Microsoft would like to get rid of desktop Windows on ARM, but that it will be too difficult to achieve that in the first iteration. One unknown factor is Office. It is obvious that Microsoft cannot rework full Office for Metro by this time next year; yet offering desktop Office will be uncomfortable and (knowing Microsoft) expensive on a lightweight, Metro-centric ARM device. Equally, not offering Office might be perceived as throwing away a key advantage of Windows.

Either way, Windows on ARM looks like Microsoft’s iPad competitor, safe, cloud-oriented, inexpensive, long battery life, and lots of fun and delightful apps, if developers rush to the platform in the way Microsoft hopes.

There are several risks for Microsoft here. OEM partners may cheapen the user experience with design flaws and low-quality add-ons. Developers may prove reluctant to invest in an unproven new platform. It may be hard to get the price down low enough, bearing in mind Apple’s advantage with enormous volume purchasing of components for iPad.

Still, one clever aspect of Microsoft’s strategy is that everyone with Windows 8 will have Metro, which means there will be a large installed base even if many of those users only really want desktop Windows.

I also wonder if this is an opportunity for Nokia, to use its hardware expertise to deliver excellent devices for Windows on ARM.

Finally, let me mention a few other BUILD highlights. Anders Hejlsberg spoke on C# and VB futures (though I note that there were few VB developers at BUILD) and I was impressed both by the new asynchronous programming support and the forthcoming compiler API which will enable some amazing new capabilities.

I also enjoyed Don Syme’s session on F#, where he focused on programming information rather than mere algorithms, and showed how the language can query internet data sources with IntelliSense and code hints in the IDE, inferred from schemas retrieved dynamically. You really need to watch his session to understand what this means.

In the end this was a great conference, with an abundance of innovation and though-provoking technology. In saying that, I do not mean to understate the challenges this huge company still faces.

I’m fascinated by how they handled (arguably mis-handled) the messaging of the “maturity” (clearly its not “death”) of traditional .NET/SL/WPF. They could have, for example, chosen to address that explicitly in a separate “The future of .NET/SL/WPF” session, but did not. I’d love to hear the actual behind the scenes rationale for why not.

What is the future for WinRT vs. .NET/CLR. Is WinRT only going to be for Metro apps, or is this really the “new and improved” .NET long term?

WinRT is not .Net at all, it is native. The CLR on WinRT is the same as on desktop (v 4.5) but with a cut-down library profile. As for future, I expect continued evolution of C#, F# etc and in that sense .Net, but in terms of framework a slow pace now for SL and WPF.

What I find thought-provoking is that the whole purpose of a JIT is to abstract the underlying hardware. In theory, running on x86, x64, ARM is just the matter of having the corresponding bits installed.

Instead of that, we have Microsoft shoving the whole stack (including the kernel and everything on top of that) just to get something running on ARM.

Well yes of course, but IMO there’s a bit more to the question than that.

WinRT raises, for me anyway, the whole issue of how much value .NET really provides. (I realize the answer partly depends on what kind of app you need to write.)

Both WinRT and .NET are alike in that they are both system software that apps consume. .NET was supposed to introduce (and it does to some extent) a world of platform independence with JITing, and ease of programming with a managed heap.

But neither WinDiv nor Office have embraced .NET and those two big features. Instead WinRT just takes those parts of .NET (like the rich meta-data) which they see as having real value (for their OS-wide senario anyway).

Will the Metro version of Office use any of .NET? If they want to be as lean and power efficient as possible on ARM devices, they probably are going to write in C++ (as Office is today) and write direct to the WinRT APIs, and do their own “manual” garbage collection.

I think there will be two version of Office, when for Metro style, which is mostly geared towards consumption of data, and the good old desktop Office which is mostly geared towards producing content.

Touch is good for consumption not so good for producing content.

The most through proviking thing they annouced is that metro IE 10 won’t support Flash and/or SL. I can understand the reasons as metro style apps has a new state called suspended, which might not play well with current flash, SL apps (or even the runtime). But it will make some things awkward, and also remember that plugins is a path for innovation, if metro IE10 is old when it comes out plugins can fix that. Perhaps they will increase their release cadence for IE. But the thing I found most odd is that Microsoft emphasizes they are all for compatbilitiy, still they cut the coords for all SL LoB apps out there on XP, Vista and Mac. Many LoB apps integrated into a large website where some more advanced feature are implemented in SL/Flash. This kind of integration won’t be possible in Metro style (unless there will be a way to launch(and install) a Metro style app from IE10.

Another question is if there will be any other browser than IE10? Is IE10 implemented solely with the WinRT API or do they access some other goodies.

And I agree with Vic, I wish they would address the future of SL and WPF. If they don’t want people to use it, say so, don’t announce SL5 a few days before build.

And they current track record of keeping technologies alive is a bit scary, which will likely make a lot of poeple wary of depending on WinRT. They might just stick to HTML5 in IE10, which I am sure Microsoft really doesn’t want, as they sell software not hardware.

Still it can be turned around too, the marked for desktop clients will likely be less under pressure and Microsoft can lock that down even more.

And Tim, I really hope they bring back the classic desktop start menu, it was very annoying to see this out of place start button when you are in desktop mode. Also the nice and switch type and start apps you do in Win7 today moves you first to metro and then back.. that is just weird. I hope they go even further to make it possible to configure which “UI” you want to default to when loggning in.

I think we’re seeing Microsoft beginning to move in the same direction as Apple began moving with their ‘Back to the Mac’ WWDC keynote, the merging of desktop and mobile OS platforms. It’s interesting to note that the two companies are taking very different tacks to reach the same goal of unification. Apple seems to content to gradually merge features, blending one into the other, back and forth, between the two OSes, as they begin to look less and less distinct. It seems Microsoft is taking a more rapid approach, riffing on their relatively well received Windows Phone 7 design to create the Metro look for desktops and putting what seems to be as much emphasis on shifting over to it fully, without actually twisting arms, as they possibly can. I’ve already discussed how I think Microsoft’s decision show’s poor timing on this front, but on further consideration, maybe that’s the only out they had.

WinRT and .NET are complimentary technologieswe cannot really have one without the other. .NET and the languages will
Continue to evolve and the apis will change as future WinRT apis are introduced and the .net apis are given more capability. The main advantage of WinRT for me is finally being able to get rid of all that nasty pinvoke stuff.

@Alan Smith:
>WinRT and .NET are complimentary technologies, we cannot
>really have one without the other.

Yes, after some thinking, I’d agree that its best to look at WinRT and .NET as mostly complimentary, as you and Tim have pointed out. WinRT plays a role similar to the Win32 APIs underneath .NET in the pre-Win8 OSes.

OTOH, you can have WinRT without .NET, and for lean and mean apps that may be the way to go. For example, most (all?) of the apps that come with Win7 are written in unmanaged C++ and do not use .NET (Notepad, Calc, MSPaint, etc.).

This Doug Seven blog goes into some of the details of how .NET and WinRT are related: http://bit.ly/qhUxa8 Unfortunately, it doesn’t look like this interesting .NET-related session (TOOL-930C) was recorded http://bit.ly/oFAMog.