Reinventing Windows
By Tim Anderson
Tim Anderson reports from BUILD where Microsoft lifted the veil on Windows 8, WinRT and more.
HardCopy Issue: 54 | Found In: Development | Published: 01/11/2011 | Last Revision: 14/12/2011
Microsoft’s September BUILD conference in Anaheim, California took place at a critical time in the company’s history. Competitors from Google to VMware are talking gleefully about the post-PC era; Windows Phone has so far failed to win the market share Microsoft was hoping for; and Apple’s iPad, together with sundry Android devices, have quickly made Windows an also-ran in tablets.
BUILD was also flagged in advance as the moment when Microsoft would reveal its future development strategy for the Windows platform, with rumours that .NET would be downplayed in favour of HTML 5.
All this led to considerable anticipation when Windows Division president Steven Sinofsky took the stage to present the developer preview of Windows 8. That first day keynote was a spectacular success, and not only because attendees were promised a rather smart Samsung tablet on which to try out the new operating system. Microsoft showed a new user interface called Metro, inspired by the design work for Windows Phone, which is smooth, responsive and, above all, touch-friendly. Microsoft’s catch-phrase ‘Windows reimagined’ is justified: the Metro-style interface feels like a new operating system. It does not even support overlapping windows, one of the key characteristics of old-style Windows, though unlike Apple’s iPad you can have two applications side by side.
Conference attendees try to make sense of the literature in the sunshine outside the Anaheim Convention Center.
Just to be clear: traditional desktop Windows is also present in Windows 8, and if you do not want to use Metro you can ignore most of it other than the Start screen, which replaces the Windows 7 Start menu. There are new features in desktop Windows 8, including a ribbon UI for Explorer and an improved file copy dialog, but they are minor compared to the Metro revolution.
The consensus at BUILD was that Windows 8 Metro is a delight to use. Talking to developers at mealtimes though, it was apparent that most will not be switching their development efforts to Metro-style applications any time soon. In most cases, that switch would mean a complete rewrite of the user interface. Further, Metro-style apps are sandboxed to the extent that some features which Windows developers take for granted are not available. There is no SQL Server driver, for example; all data access is meant to be done through Web services. This tension between the prettiness of Metro and its immediate usefulness was one dampener on the enthusiasm generated.
The developer story
Much of BUILD was focused on the developer platform for Metro in Windows 8. At its heart is a new runtime called WinRT. Although conceptually this is a layer between applications and the underlying operating system, Sinofsky was keen not to present it like that: “everything we’re showing you today is built into Windows – it is Windows. We’re not building layers on layers. We’ve built everything natively into Windows.”
One way of looking at this is that the Windows team learned from mistakes made with Windows Vista, originally codenamed Longhorn. Vista introduced Windows Presentation Foundation (WPF), which is a .NET API, resulting in an overhead for WPF code versus native code. Microsoft’s ambivalence toward WPF was obvious, since little in Windows Vista or Windows 7 depends on it. Earlier prototypes of Longhorn used WPF more extensively, but performance was terrible, and work on Longhorn was reset at great expense in time and money.
WinRT has no .NET dependence, and we were told that under the covers it is similar to COM, the old Windows object model which .NET was intended to replace.
The road to Windows 8? The new Metro-style control panel.
That said, WinRT borrows two key features from .NET. It uses XAML for its presentation language, and it uses the same metadata format as .NET IL (intermediate language) to describe the WinRT API.
Next, Microsoft added an interop layer to both the .NET runtime and the Internet Explorer JavaScript engine so that the API looks like a .NET API if you are coding in .NET, and like a JavaScript API if you are coding in JavaScript.
This means developers have three choices for Metro development: C/C++, .NET or JavaScript with HTML/CSS. Although there is a slight performance edge to C/C++, it is small, and all the samples seen at BUILD performed well irrespective of their development language. There was high attendance for session on developing Metro apps in .NET, and any wild predictions that .NET would be deprecated in Windows 8 were proven false.
WinRT is intended to be a safe application platform, to an extent that desktop Windows will never be able to match. WinRT applications do not have access to the file system other than to isolated storage, and to user-controlled open and save actions though file dialogs. Only a safe subset of the Win32 API is available, whether through C/C++ or via Platform Invoke in .NET. Reading and writing data is normally done through Web services, as in a Silverlight or Adobe AIR app, rather than through a traditional database driver. That said, you could use a local database that is isolated to your app.
Another key feature is that WinRT apps cannot communicate other than through pre-defined ‘contracts’ of which there are five: Search, Share, PlayTo, Settings and Picking (which lets your app access files belonging to another app, subject to opt-in).
Async in Windows 8
One of Microsoft’s smartest moves in WinRT was to make all API calls that might take more than 50ms into async-only functions. Microsoft considered having synchronous alternatives but rejected the idea in order to force developers to do the “right” thing.
Async functions return immediately, delivering results later via a callback function. The goal is to have a user interface that is always responsive.
This means that Metro developers will be writing a lot of async code, often a challenge than makes it hard to structure your code sensibly.
Fortunately there is a new feature in C# 5.0 which makes this easier. The ‘await’ keyword instructs the compiler to exit the current function while making any code you wrote after that line into a continuation that runs when the awaited function returns. The details of the callback are hidden from the developer.
The beauty of ‘await’ is that you can use it more than once in the same function: the compiler will manage all the nested continuations that result.
What about Silverlight?
Microsoft developed Silverlight, its cross-platform .NET runtime and browser plug-in, with great energy between the first version in 2007 and version 4 in 2010. There was speculation that it could eventually merge with WPF as a primary way to deliver applications on Windows. Then, at PDC in October 2010, Microsoft talked up Internet Explorer 9 and HTML as its Web strategy, barely mentioning Silverlight: “Our strategy with Silverlight has shifted,” confessed Bob Muglia (then VP). With hindsight, it is obvious that this followed the decision to focus on WinRT rather than .NET as the foundation of Windows client programming. There is no Silverlight runtime in WinRT, not even in the Metro-style Web browser.
On one level then, the fears for Silverlight’s future were justified by what was announced at BUILD. That said, another way of looking at this is that key features of Silverlight, including XAML and the .NET runtime, are alive and well in WinRT. Silverlight developers will have the easiest of transitions to WinRT, since the sandboxed model is close to what they are used to.
Silverlight continues in desktop Windows and its browser, with version 5.0 to be released in late 2011. It also remains as the development platform for Windows Phone 7.
Will Microsoft eventually replace Silverlight with WinRT in a future Windows Phone release? That would make sense, but the company will not confirm the idea yet, no doubt to avoid giving the impression that Windows Phone 7 is based on an old platform.
A tale of two keynotes
BUILD was not just about Windows 8. The Day Two keynote focused on the server and cloud side of Microsoft, both the public Windows Azure cloud, and private clouds based on Server 8 and a greatly enhanced Hyper-V virtualisation platform. Server 8 will share code with Windows 8 and presumably be released at around the same time. (Both Windows 8 and Server 8 are codenames, and the final releases may be called something different.)
Windows Division president Steven Sinofsky at BUILD
Microsoft had run a strong press preview of Server 8 the week before BUILD; yet the Day Two keynote lacked the energy of the previous day and failed to show off the new server features effectively, though VP Scott Guthrie received a warm welcome in his new role managing the Windows Azure development platform. CEO Steve Ballmer appeared at the end, emphasising the importance of this event to the company.
There was a preview of Team Foundation Server (TFS) running on Azure, which may well make sense for many teams given the difficulty of configuring and maintaining TFS.
The most over-subscribed session at BUILD was from C# inventor Anders Hejlsberg on the future of C# and Visual Basic. The main focus was the asynchronous capability (see above), and a forthcoming project codenamed Roslyn which he described as “compiler as a service”.
Another way of describing it is an API for the compiler and its semantic analyser. Using Roslyn, it is easy to execute C# or VB expressions generated at runtime. It also makes writing smart IDE features easier, so developers can look forward to more powerful refactoring. Hejlsberg demonstrated how you can take a block of C# code and “paste as VB”, or vice versa. Roslyn will not be in Visual Studio 11, but is now available for Visual Studio 2010 as a technical preview.
Another BUILD highlight was Herb Sutter’s two sessions on C++, especially the second on writing modern C++ code. It was a myth-busting talk on how, contrary to its reputation, writing C++ code is now safe and fast thanks to features like automatic lifetime management and auto type deduction.