A lot of the conspiracy theories spawned from the unusually intense level of pre-event secrecy have been put to rest: Windows 8 will not break from the past, and it will support the .NET Framework and its accompanying languages and technologies. But certain questions remain about the technology and the path forward. Before a look ahead, though, it’s good to understand how things got to where they are.
So, how did we get here? The short answer is Steven Sinofsky. Sinofsky, as the president of the Windows division at Microsoft, is by all accounts the champion and the hand behind the push to make Windows 8 what it is, and that includes the shift to the Windows Runtime (WinRT) as the developer framework of the future.
He gave the first-day keynote at BUILD, in which he declared that enabling developers is the goal, and that Microsoft was focused on building on the success of Windows 7. Microsoft claimed that there are more than 440 million copies of Windows 7 sold thus far, and that is a lot of success to build upon.
Other messages from Sinofsky were that touch on a PC is addictive and plays a huge role in the Metro interface, that Windows 8 is “breaking down the connectivity silos for app developers” (note the use of the term “app” rather than application there, more on that later), and that Windows 8 is designed to be service-aware, since services are everywhere.
Reach is a theme that came out early and was a telling hint of why things are shaping up this particular way. Perhaps the most important promise made is that everything that runs on Windows 7 will run on Windows 8. There were no exceptions, which is the one statement that might have been helpful if it were made a couple of months ago.
The only equivocation on this aspect is that the ways they will run are not created equal. Applications not specifically updated for the Metro style are relegated to the desktop interface that supports touch, but is more retro than Metro.
At the heart of things, the Windows 8 experience really was the focus of the entire conference. Even before the conference you could go to the Windows 8 Engineering blog to see how Windows Explorer and many other nuts and bolts of the system will be improved—or in the vernacular of BUILD, re-imagined. But they were not even mentioned at the conference.
There was surprisingly little coverage of Windows 8 management features, but a great deal of focus on developers, hence the feel that BUILD truly was the next iteration of Microsoft’s Professional Developers Conference. But some of the other announcements were so subdued that those of us in the hall had to turn to our neighbors and say things like, “Did they just off-hand mention that a dev release of Visual Studio 2011 is available?” The answer to that question is “yes.” More on that later, because the heart of the message of the first-day keynote was that the WinRT is here and it is meant to be the way forward for developers.
I believe this is a significant moment in history and is right up there with the PDC when the .NET Framework was first introduced a decade ago, but as with that announcement, there is time before this future becomes the present, and we are going to need to get up to speed with all this new stuff.
Similarities to .NET’s start
One area of uncertainty around WinRT is whether it will ever be back-ported to support older versions of Windows, and as of this writing, the answer from insiders and others I have asked is “no.” That will serve to slow things down a bit, which, given all we have to come up to speed on, is a good thing.
We had the same challenge when .NET debuted, but in this case I would be surprised if ports to operating systems like Windows 7 ever happen. This is not a break with the past. It is more of an evolution.
A recurring theme and a central feature of the new system is the ease of leveraging asynchronous operations. If you plan to build Metro-style apps, then a good deal of asynchronous communication is definitely in your future, like it or not. Prominent in the event’s demonstrations were calls that might take a long time being done with the Async and Await keywords to keep them from blocking the UI. In this context, a long time is anything longer than 50 milliseconds. There appears to be strong evidence that the whole reason for the move to WinRT is to avoid the problems of the past, such as UI blocking synchronous code, and to pave the way for Microsoft to compete at the Apple end of the market.
It is as if .NET was a decade-long holding action that allowed us to avoid the pains of COM and memory management. A fantastic holding action, but it took us further from the metal, which causes its own set of problems. The indicators that this works in favor of WinRT include what we are told can and cannot be put in the coming app store. While Win32 applications seem to be allowed (in that they can be linked to), .NET applications not adapted to Metro seem to be shut out.
To understand what that means, we now have to look at exactly where the .NET Framework fits now in the new world order of Windows 8. In some sense, “Framework” seemed like a dirty word at BUILD as it connotes a layer between the developer and the hardware, and that is exactly where WinRT is different from .NET, on the surface at least.
The inference was that WinRT takes developers of all stripes closer to the hardware, all the while enabling Microsoft to clean the slate in areas it cares about greatly. In fact, while C# and VB on top of WinRT do still run on top of the CLR, and it is the same CLR used when run in Desktop Mode on the same system, the terms people have used is that there is a different “profile” in effect. In reality it is about pruning certain calls back to protect an application running over WinRT from straying from the path, specifically the path to a successful app store.
Doug Seven, vice president at Telerik, put things very clearly regarding how the CLR is leveraged both in and outside Metro in Windows 8. In a post entitled “A bad picture is worth a thousand long discussions,” he discussed the “Boxology” slide presented during the first-day keynote (see the image below). This is a great slide for introducing us to the concept of WinRT, but it really does need lots further explanation, which has yet to arrive officially.
Doug’s post goes a long way to filling in the blanks especially in regard to how the .NET Framework fits into the architecture. I expect most of that information to come from the community as Microsoft works on the next round of public disclosures. In other words, I do not expect the control over information disclosure from Microsoft to change anytime soon from the precedent that BUILD has created.
The risks of these bold moves by Microsoft are still there. If the final release of the Metro interface of Windows 8 is not incredibly intuitive, then even the already great touch performance will be for naught.
The .NET revolution was where Microsoft established its dominance of the enterprise. Metro, and by extension Windows 8, is a very consumer-oriented play. The risk is that the change in focus risks the enterprise dominance. If .NET had been declared at end-of-life or hobbled, then this would be a real possibility.
Again, this is not what has happened and there is no reason to think this misstep will be made between now and final release. There are reasons to be confident that Microsoft is on the right track, but we need to remember that there have certainly been missteps by Microsoft in the past, and the most preventable ones, in my view, had to do with failing to make things easy enough to really take off.
The demonstrations of Visual Studio 2011 helped allay the fears that this would be the case with the shift to WinRT-based development. In spite of those efforts, there were hints that porting existing Silverlight and .NET applications to WinRT will not be trivial in most cases, and several attendees told me they thought as much.
As you may have noticed, competing with Apple seems to also be a trend at BUILD, though it was an unspoken thing. Microsoft wants several market positions that Apple currently has, and they are fairly easy to enumerate. These provided insight into the intended role of Windows 8.
Obvious objectives for Microsoft include prominence in the consumer market in the tablet and phone space, a consistent app dev story between phone and tablets (and with desktops would be nice as well), and an app store that just works for the consumer space in terms of trust and profitability. The Metro interface baked into Windows 8 provides a path to the first two of these goals, though they are still fraught with pitfalls related to the actual execution.
That brings us to the app store. The coming app store will consist of Metro-style apps that are safe from the slow performance, system-altering side effects and distance from the metal that non-Metro/WinRT applications risk. There are no guarantees of course that Metro applications will do no harm, but there are many obstacles to bad apps ending up in the app store.
For example, since the Metro style of deploying apps is to place an appx file that can simply be deleted to remove the application, there is no contamination to the OS no matter how many apps are installed or deleted. The emphasis on Async makes even more sense in this context, though it is clearly a good idea in its own right.
Jensen Harris, Microsoft’s director of program management and Windows User Experience, laid out at BUILD what Metro means and how Microsoft has provided for developers without digging into the tooling too much. At one point, he showed the built-in animations that the Metro-style controls provide, and the difference in effect is jarring. These subtle little effects are like so many things in our lives in that once you get used to them, you really notice their absence. Cell phones are the best corollary since I never missed them when I was a kid, but I feel so cut off from the world if I am out and about without my cell. Harris explained the eight principles that make Metro tick, including the back story on how and why.
As mentioned earlier, the Visual Studio 2011 developer preview is released and was used for every demo as near as I can tell. It was never formally announced—just mentioned—and therefore there is no timeline or even release cycle to reference. However, it looks like the releases of Windows 8 and Visual Studio 2011 will be synchronized, though this is not officially announced.
Visual Studio 2011 has a good deal of interesting developer goodness in its own right. Application interoperability is accomplished using a new technology called “Charms,” and there are a number of them available to Metro-style apps, but three were specifically called out by Harris. The Share Charm lets you leverage all applications that support the Share Contract, which is the rule behind the Charm. You can think of this functionality as a rich clipboard that allows you to stay in context of the originating application while shipping data to a receiving app that supports the contract.
The other two Charms demonstrated in the big group sessions were the Search Charm and the Picker Charm. In these two cases, Microsoft is trying to make common scenarios for users that transcend the application level and allow integrations without prior coordination between the authors of any two apps. This app synergy is an important part of the Windows 8 vision for Metro-style development. As with all things, the pressing question is how this is enabled in the developer tools. The demos make it look easy of course; let’s hope the tools make it so.
During the Day 2 keynote, many of the most interesting features of Visual Studio 2011 were outlined. There was a Simulator, which is like super preview for debugging Metro apps, and an Image editor so greatly improved that I doubt someone building an immersive video game has to stray very far to create all the graphical components.
Jason Zander, Microsoft corporate vice president for Visual Studio, did a demo that showed debugging a 3D tank combat game and decomposing each layer of the display to see where a transparency had gone wrong. It really showed the power that the synthesis that Visual Studio plus Blend can bring to bear. Visual Studio 2011 is that synthesis.
As the developer demos of the Day 2 keynote progressed, Zander showed off how far Azure development tools have come. The pace of progress underlines how big of a bet Microsoft has placed on Azure.
The keynote mentioned that the Productivity Power Tools are now built right into Visual Studio 2011, making for one less download and expanding the arsenal for developers to get things done out of the box. There is now an ability to find duplicate code snippets throughout a project, but rather than just a simple find, this feature allows for variable names, constants and such to be named differently in the code, resulting in the ability to find code that has been copied and modified superficially. This is the next level of refactoring. I expect we will appreciate this immensely as we find ourselves updating a legion of applications to take advantage of Metro and the .NET Framework 4.5.
Changes to .NET
Scott Guthrie, Microsoft corporate vice president of Server & Tools Business, showed off .NET 4.5 and MVC 4. Immediately we noticed that the basic template generated just keeps getting better.
With MVC 4, the basic shell application looks very polished for something we get instantly for free. The resulting page even suggests the next steps for the developer, such as configuring Membership.
The thing I liked the most is that it will now be so easy to figure out what causes any given element to be displayed. To that end, you can show both markup and the design view in Visual Studio 2011, and the two are synched in that you can click on a section of markup, and the tool will highlight the corresponding section in the design view and vice versa.
This is debugging for Web projects on steroids. It even shows you which branch of flow control, like IF statements, caused the displayed result when selections are made by the user in the design view. They even said that jQuery mobile is going to be included in Visual Studio 2011.
These are all great features, but my favorite is folder references. With folder references, whole folders are referenced instead of individual scripts, and they are huge for getting the tools out of your way. Any file in the referenced directory is added to the project. It even does minification, which means that all the scripts are combined and made as small as possible on compilation, which enhances performance. This is a feature that had not occurred to me before, but now I can see that I will wonder how I lived without it all this time.
No coverage of BUILD would be complete without some discussion of the tablet device handed out to attendees at the end of the first day. The device is surprisingly good, even running a pre-beta version of Windows 8, and it has contributed greatly to the positive vibe surrounding what Microsoft is trying to create with this new version. There are some glitches, but fewer than reasonably expected in my opinion.
One thing about it that I cannot for the life of me figure out is how one takes a screenshot while in the Metro interface using touch. Maybe this will be fixed, or I am just missing something (obvious or not). This reinforces that there is still a road to travel between now and final release.
The questions to be answered are far deeper than the questions we had before the conference. The mantra of “Lets you pick the language you want” does not lay out what the tradeoffs will ultimately be when choosing from the available options. I believe that C++ is still the choice for best performance on Windows, but now the tax of using C++ is greatly reduced if not totally eliminated. C# and VB.NET have their place, but they are no longer the monopoly on productivity that they have been over the last period.
Now we all have to dig in and figure out what it all means and where our corner of the development community fits into this mosaic of technical choices.
Eight things about Metro
What will distinguish the best Metro-style apps, according to Microsoft’s Jensen Harris? Here is an extremely condensed breakdown of his list of eight touch points that will make or break these new applications.
1. Metro style design: Metro is the new thing; get on the bus or no app store for you!
2. Fast and fluid: If touch is slow, we notice. Do not let anything get in the way of the UI thread.
3. Snap and scale beautifully: Microsoft has provided for multiple viewing sizes. Support them or you will be left out.
4. Use the right Contracts: The Charms let you play well with other Metro apps, so apply them where they make sense for app-to-app sharing and stuff like that.
5. Invest in a great Tile: The Tile is your home page of sorts for your app; make it count and make it useful.
6. Feel connected and alive: Avoid static and go for active content, including notifications and updates.
7. Roam to the cloud: Go cloud or go home. No one wants to sync their data so just build it in with cloud storage.
8. Embrace Metro principles: Rinse and repeat, and always keep striving for a better user experience.