104. //build It and They Will Come (Hopefully)
“I've never witnessed this much excitement in a Microsoft audience at a keynote before. It's electric.” –Tom Warren, Winrumors
Imagine building a computing platform that powers a generation. Now imagine taking the big step of building the replacement for that platform while the original needs to keep going for another decade or more. This is the story of unveiling the new Windows 8 platform for building modern apps, WinRT, at the first //build conference. The difficulty in telling this story is how everyone knows how the world came to view Windows 8. The developer conference of 2011 was a different story entirely. We still had to work through the big issue within the world of .NET developers and their extreme displeasure with the little we said about the Windows 8 developer story a few months earlier at the preview of the user experience. We had so much to share and were very excited as we made our way to Los Angeles.
Back to 103. The End of Windows Software
The iPad was out there and still had skeptics. Pundits continued to assert that tablets were not good devices for content creation. Techies saw it as a consumer toy for lightweight computing. This same thing had once been said of PCs, right up until they overtook computing. It was said of server PCs, right up until they overtook business workloads and cloud computing.
Steve Jobs, at the 2010 All Things Digital D8 conference, reminded the audience that the iPad was just getting started and added, “I think we’re just scratching the surface on the kind of apps we can build for it. I think one can create a lot of content on the tablet.” By 2011, Apple was demonstrating increasing confidence in the path they had created with iPad. The iPad was already the preferred tool for the road warrior, the boardroom, and the back seat. The iPad and iPhone combined with the developer platform had become the most formidable competition Microsoft ever faced. As much as Android unit volumes concerned the Windows Phone team, there was no ignoring Apple. Some were deeply concerned about the tsunami of small Android tablets. Given what we went through with Netbooks, low quality devices, even in high volumes, concerned me less.
The PC was moribund. The situation in Redmond became increasingly worrisome. This was despite our solid progress on Windows 8 and the interim Windows Phone release, Windows Phone 7.5.
The chicken and egg challenge of platforms is well known. How does a platform gain traction from a standing start? Every platform faces this, but it is unusual for the established world leader to be wrestling with this problem. When I think of how the computer world had literally revolved around every utterance about Windows, it was downright depressing if not scary.
The challenge the company faced was the dramatic loss of developer mindshare. Between web browsers, iPhone/iPad, and then Android, there was no room left for Microsoft. Win32 was legacy, a solid legacy, but a legacy. The latest efforts for Windows Phone seemed to have stalled at best. While there was a rhythm of press releases about app momentum for Windows Phone, the app numbers were tiny relative to Apple and Google and the app quality was low. Phone units were small too, meaning attracting developers was becoming more difficult not less.
Every leadership team meeting provided another opportunity to debate the merits of using financial incentives to lure developers to the platform. And at each meeting I raised the reality of adverse selection that every competitor to Windows had learned over the past two decades. The Xbox team loved to talk about how much they spent on exclusives, but that was a walled garden world of intellectual property. In an open platform, once you’re spending money to win over developers, the least motivated developers show up with the wrong apps creating an awful cycle where paying developers attracts more of the less desirable developers building even more of the wrong apps. But not spending money seems guaranteed to lose if there’s no organic interest. This debate would become front and center with Windows 8 as we faced the same challenge.
The concerns over the specifics of competing with iPad and Android tablets and how Microsoft and partners would respond occupied an increasingly concerned board. We had our plans for Windows 8, but the obvious question was could Microsoft do something sooner? In the summer of 2011, we were a couple of months from our developer conference in September and certainly less than 18 months from general availability of Windows 8. I assumed we could wait that long and knew we could not finish sooner. I also assumed there was no emergency product development that could finish something useful before then. That didn’t stop us from having a classic Microsoft hand-wringing series of meetings to attempt to cons up a plan. Time for yet another Gedankenexperiment as part of a series of meetings with some members of the board and others.
We were not yet certain of the how or who of delivering ARM devices, particularly tablets, though by this point we had test hardware running and we were deep in potential designs for our own device. As a result, I was my routinely cautious self in an effort not to over-promise, especially to this group. I was, perhaps wrongly, determined not to get ahead of our own execution. Such a conservative stance was my nature but also not the norm or even appreciated. I was happy to talk about our developer conference and what was possible. The specifics required to answer when and by whom there would be a mini tablet running Windows were well ahead of where we were.
I reviewed our progress on Windows 8, again. The problem seemed to be that we were not getting enough done nor was it soon enough. They were right. Who wouldn’t want more and sooner? From my vantage point, if we finished when we said we would it would be impressive and historically unique, even on the heels of Windows 7. How quickly people can forget the past. It felt like “more cowbell.”
Shaving time off the schedule was discussed—it wasn’t a grounded discussion, just a wish. After that, Terry Myerson (TMyerson) and his co-leader Andy Lees (AndyLees) of the Phone team, shared the early plans for Windows Phone 8. Since Apple had made a tablet out of the iPhone, the natural question was, could we make a tablet out of Windows Phone? Of course, we could do anything (“It’s just software” as we said), but which phone and how soon?
Some in attendance even asked if should do a “quick” project and build a tablet out of WP7 (or 7.5)? Could we take an Android tablet design and put Windows Phone 7 on it? Why not? Seemed so easy. None of these ideas could possibly happen. There’s no such thing as a quick project. The last quick hardware project Microsoft did was Kin, a poorly received smartphone.
There wasn’t much I could do. From one perspective, Windows was suddenly the product that was holding us back and Windows Phone was the new solution to our tablet problem. Given what we were seeing in the market, Windows Phone apps, and the technical challenges of the platform, this was a ridiculous spot to land.
Windows Phone 8, working with Nokia, introduced really big phones called phablets, pioneered by Samsung on Android. For a time, some analysts thought these larger phones would put an end to tablet demand because tablets were in between. Still, tablets continued to thrive for productivity and, as far as Apple was concerned, to become the future laptop. The iPad certainly thrived. It was the cheap Android tablets, the ones the Board was concerned about, that ended up on the trash heap with Netbooks.
Ultimately, there was no tablet market, just an iPad market. The iPad run rate soon approximated that of consumer PC laptops. It was difficult for Microsoft to see the low-volume player as the real competitor, especially when it was Apple and the last time it was the low-volume producer it nearly died. Android was shaping up to be the Windows ecosystem on phones—high volume, low profit, endless fragility, device diversity (or randomness), and so on, but with a new OS, new OEMs, new business model, and new mobile developers who were making apps on the iPhone, though the iPhone apps always seemed a bit better.
The Windows and Windows Phone teams would eventually go through a challenging period where in the middle of Windows 8, we on the Windows team learned that the Phone team had been taking snapshots of various subsystems of Windows 8 for use in the phone OS. This got the product to market but did not give us a chance to align on quality, security, reliability, and code maintenance. This wasn’t done in any coordinated or even transparent manner. Had we, Jon DeVaan and Grant George specifically, not intervened the company would have been set up for significant issues with security and reliability given we were not finished with the code and there was no process in place to manage “copies” of the code. Jon worked through a better process once the team got ahead of the issue. I had a super tense meeting with SteveB and the co-leaders of the Phone team about this lack of transparency and process and why it showed a lack of leadership, or even competence, on our part. In the new world of security, viruses, vulnerabilities, and more the company could not afford to be cavalier with source code like this seemed to demonstrate. This was all in addition to the lack of alignment on the developer platform as the Phone team made their early bet on Silverlight as previously discussed.
More and sooner was a constant drumbeat throughout the Windows 8 development schedule. I was called to the carpet many times to explain where we were and why we were not finishing sooner. I was grumpy about doing that and I’m sure it showed. Schedules did not get pulled in or completed early. In the history of the company (and software), that never happened. We weren’t going to finish Windows 8 early. We would be fortunate to finish on time, mid-2012 plus two months to reach availability on new PCs.
The leadup to the fall developer conference was a constant series of crises external to the development team but going on all around. It was stressful at the executive level for strategy reasons. Every meeting, every mail thread, every new online story was just more worry for us.
It was stressful at the team level because we had asked the Windows team to pull together most of the company for the release.
In particular, we wanted to fix—yes that is the right word—the schism of the past decade that had replaced what was once lockstep strategic coordination, the Win32 strategy, between the Windows and Developer product groups. The Windows team most accountable for success of the new platform was DEVX, the Developer Experience, and the counterpart to the UEX team. DEVX was led by Aleš Holeček (AlesH) in engineering, Linda Averett (LindaAv) in program management, and Yves Neyrand (YvesN) in testing. The breadth and depth required of this team was in every way as great as the user experience.
Just as Windows 8 designed a new and modern experience, we designed a new and modern new platform to go with it. This platform was designed with the intent of growing to the future Windows platform for all apps across all form factors and devices.
Prior to releasing to the public, we called the platform “Modern Application Model” and later the “Windows Runtime” and finally WinRT, which was the name we stuck with in honor of Windows NT. Like NT we never attached a meaning to RT and just said the letters. In this section, we’ll use the term “modern application” for new Windows 8 apps which had also been called Metro and Metro-style. We were still in the midst of resolving this legal dispute and frankly could not keep the terminology straight which confused everyone inside and out of Microsoft.
We’ve described the experience goals of Windows 8 and to realize these goals the platform for modern apps in the experience had the following goals:
Native APIs for the new application model, realizing the benefits of the experience
Rapid application development coming from great tools supporting an API that could be mastered with relative ease
Amazing tools of choice, including both .NET and standard web technologies
Broad distribution and a great business model for apps via a new Windows App Store (covered in the next section)
The importance of “native APIs” could not be overstated yet was also subject to many philosophical debates over what really constituted native. At one extreme, some believed native APIs simply meant they came from Microsoft and therefore first party was equivalent to native. At the other extreme native APIs implied written from the ground up from scratch, divorced from any existing capability and consequently all new. As with many debates along these lines, one could debate semantics or simply build the product and let it speak.
I was familiar with this debate from the earliest days of Windows programming. The advent in the 1990s of object-oriented programming called for a new era of APIs that were improved over the abstractions provided natively—in other words taking the native APIs and recrafting them so they would be easier and more amenable to object-oriented techniques. The story of approaching API development this way, and our failure, was documented in section 010. Our BillG Review. In that story, we developed a new API for Windows that was much prettier and tuned to C++ but was also bloated and different than Windows. This failure led to a super lean, efficient, and Windows-centric API that became the standard for building professional apps for the Win32 era, the Microsoft Foundation Classes, MFC.
Without diving too deeply into the weeds of architecture, there is an important point about systems design to make. What separated MFC from the era of object-oriented frameworks was, as described previously, a bet on the underlying platform to do the work. Our framework did as little work as possible and specifically never duplicated Windows functionality. That strategy permitted only one implementation of any given concept to exist and thus defines native. In that case, Win32 remained the native API because of the choices we made in MFC.
These choices were the exact opposite of those made in the various .NET technologies, which liberally duplicated capabilities in Windows. This duplication created both inefficiencies and deeper problems. Incredibly difficult problems to solve such as security, accessibility, localization, and so on were made vastly more difficult when there were potentially two (or more) ways to accomplish the same task or worse one way in a framework that made partial use of the OS. In this type of framework there was complete ambiguity as to what constituted native.
In the modern context, this debate over native capabilities of a platform is the situation currently consuming the Apple strategy of SwiftUI. SwiftUI is a layer on top of the existing native operating system API, but it also reimplements functionality and provides different implementations of other capabilities. Apple is attempting to decree the SwiftUI the answer, but even struggles themselves in moving apps from the old way to the new way. In the context of this story, SwiftUI and the debates surrounding it have a ring of .NET familiarity. I’ve been surprised at the approach but not the result. Apple has the ability to drive change across existing code that we did not have as discussed in the previous section which might smooth out this strategy over time. On the other hand, this entire section describes the outcome of fracturing even the most robust of developer ecosystems.
The approach for Windows 8 was decidedly to define new native APIs and implement those APIs such that there was a single code path for all capabilities. Sometimes the code was brand new to Windows and other times WinRT relied on existing code paths and reused them. Taken as a whole, the set of capabilities represented the first version of the future APIs.
The first version of Windows with any utility, Windows 3.0, was about 540 APIs and documented beautifully in the book Programming Windows by Charles Petzold that occupied a rarified position on every developer’s thick oak bookcase back in the day. Most of us just referred to the book as “Petzold.”
![A PROGRAM WITH A WINDOW In regular C programming, to step up from a program that does nothing to a program that displays a message, you simply add a single line to the program main puts ("Hello, world. \n") This program prints the text "Hello, world" on some teletype device (like the video display under MS-DOS) and then terminates. However, the Windows environment is obviously much more complex than the simple teletype device involved with the simple "Hello, world" pro-gram. A Windows program cannot simply display something on the screen. The Windows program must first build a window for itself. Let's write a Windows program somewhat equivalent to the simple C program shown above and call it WELCOME. This program will display a normal overlapped window with the title "Welcome to Windows" in its caption bar. The program will then terminate, just like the "Hello, world" program. All the source code (C file, module definition file, and make file) for WELCOME1.C is shown in Figure 2-4. welcomel.obj: welcomel.c c1 -c -D LINT_ARGS -Gsw -Os -W2 -2p welcomel.c welcomel.exe: welcomel.obj welcomel.def link4 welcomel, /align:16, /map, slibw, welcomel - m300r m& W E •ог M E WELCOME1.C -_ Welcome to Windows Program No. 1 */ #inelude <windows…h> long FAR PASCAL WndProc (HWND, unsigned, WORD, LONG) ; int PASCAL WinMain (hInstance, hPrevInstance, 1pszCmdLine, ncmdshow) HANDLE Instance, hPrevInstance LPSTR 1pszCmdLine int IWel come? " static char szAppName |] = HWND WNDCLASS hand undalass Figure 2-4. The WELCOME1 program (continued) 42 Chapter 2: Creating and Displaying Windows Figure 2.4. Continued if (!hPrevInstance) wnoclass style wndclass.lpfnWndProc CS HREDRAW CS VREDRAW WndProc wndclass.cbClsExtra wndclass.cbWndExtra wndclass.hInstance = Instance wndclass.hIcon = LoadIcon (NULL, IDI_APPLICATION) wndclass.hCursor = LoadCursor (NULL, IDC_ARROW) wndclass.hbrBackground = GetstockObject (WHITE BRUSH) wndclass.1pszMenuName WnOClass._oszClassName SzAppName if (!RegisterClass (Swndclass)) return FALSE hWnd = CreateWindow (szAppName, "Welcome to Windows! WS _OVERLAPPEDWINDOW, _USEDEFAULT, 0, CW_USEDEFAULT, NULL, NULL, hInstance, NULL) ; window class name window caution window style initial x position /* initial y position * initial x size initial y size * parent window handle window menu handle program instance handle /* create parameters Showwindow (hwnd, nCmdshow); Updatewindow (hwnd); return FALSE long FAR PASCAL WndProc (hWnd, iMessage, waram, 1Param) HWND hwnd unsigned iMessage WORD LONG Paran return DefwindowProc (hWnd, iMessage, waram, 1Param) NAME DESCRIPTION STUB CODE DATA HEAPSIZE STACKSIZE EXPORTS WELCOME1 Welcome to Windows 'WINSTUB. EXE MOVEABLE MOVEABLE MULTIPLE 1024 1006 WndProc](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F5f68d91c-f27d-422e-8d65-812b896f6e9c_2658x1850.jpeg "A PROGRAM WITH A WINDOW In regular C programming, to step up from a program that does nothing to a program that displays a message, you simply add a single line to the program main puts (\"Hello, world. \n\") This program prints the text \"Hello, world\" on some teletype device (like the video display under MS-DOS) and then terminates. However, the Windows environment is obviously much more complex than the simple teletype device involved with the simple \"Hello, world\" pro-gram. A Windows program cannot simply display something on the screen. The Windows program must first build a window for itself. Let's write a Windows program somewhat equivalent to the simple C program shown above and call it WELCOME. This program will display a normal overlapped window with the title \"Welcome to Windows\" in its caption bar. The program will then terminate, just like the \"Hello, world\" program. All the source code (C file, module definition file, and make file) for WELCOME1.C is shown in Figure 2-4. welcomel.obj: welcomel.c c1 -c -D LINT_ARGS -Gsw -Os -W2 -2p welcomel.c welcomel.exe: welcomel.obj welcomel.def link4 welcomel, /align:16, /map, slibw, welcomel - m300r m& W E •ог M E WELCOME1.C -_ Welcome to Windows Program No. 1 */ #inelude <windows…h> long FAR PASCAL WndProc (HWND, unsigned, WORD, LONG) ; int PASCAL WinMain (hInstance, hPrevInstance, 1pszCmdLine, ncmdshow) HANDLE Instance, hPrevInstance LPSTR 1pszCmdLine int IWel come? \" static char szAppName |] = HWND WNDCLASS hand undalass Figure 2-4. The WELCOME1 program (continued) 42 Chapter 2: Creating and Displaying Windows Figure 2.4. Continued if (!hPrevInstance) wnoclass style wndclass.lpfnWndProc CS HREDRAW CS VREDRAW WndProc wndclass.cbClsExtra wndclass.cbWndExtra wndclass.hInstance = Instance wndclass.hIcon = LoadIcon (NULL, IDI_APPLICATION) wndclass.hCursor = LoadCursor (NULL, IDC_ARROW) wndclass.hbrBackground = GetstockObject (WHITE BRUSH) wndclass.1pszMenuName WnOClass._oszClassName SzAppName if (!RegisterClass (Swndclass)) return FALSE hWnd = CreateWindow (szAppName, \"Welcome to Windows! WS _OVERLAPPEDWINDOW, _USEDEFAULT, 0, CW_USEDEFAULT, NULL, NULL, hInstance, NULL) ; window class name window caution window style initial x position /* initial y position * initial x size initial y size * parent window handle window menu handle program instance handle /* create parameters Showwindow (hwnd, nCmdshow); Updatewindow (hwnd); return FALSE long FAR PASCAL WndProc (hWnd, iMessage, waram, 1Param) HWND hwnd unsigned iMessage WORD LONG Paran return DefwindowProc (hWnd, iMessage, waram, 1Param) NAME DESCRIPTION STUB CODE DATA HEAPSIZE STACKSIZE EXPORTS WELCOME1 Welcome to Windows 'WINSTUB. EXE MOVEABLE MOVEABLE MULTIPLE 1024 1006 WndProc")
When Windows 3.0 arrived, it was not exactly meeting a known market demand. The platform was intriguing for a class of developers, some of whom had been working on Macintosh apps and others who just saw opportunity in a new way to program user interface. These developers, much like on Macintosh, could pick up a copy of “Petzold” and within a day or so would find their way writing Windows programs, often as a hobby or side project to impress people at work. It was exciting and rewarding. Within a relatively short time the effort paid off with a solid mastery of the 540 APIs. While there was all sorts of complexity and wizardry in the way tools worked, the breadth was such mastery was achievable by a single person.
The property of mastery is an incredibly compelling part of any new platform and often overlooked. The ability to master the platform and to use that mastery to complete an entire project is when something magical can happen, often for a just one or two engineers working together.
By the 2000s, there was no mastery of the Windows API to be had, by anyone. At the very best, one could master a subsystem of Windows such as networking, DirectX graphics, or the file system. Of course there were some wizards, but most of them worked at Microsoft or soon would. Even the largest software houses would struggle with building reliable and optimal Windows software. When the complexity of the various .NET, data access, graphics, and networking APIs were added to the mix the system was insurmountable. A huge part of the attraction of various aspects of .NET, such as Silverlight, was the notion that one could master some subset and complete a project. Unfortunately, as discussed, these runtimes were limited enough that one often needed to venture into other parts of Windows to complete projects. There is no escaping that the explosion of headcount and lack of management accountability to that proved to be our worst enemy when it came to strategic platform coherence for thousands of APIs.
Our Windows 8 plan was to create a new API that covered the full range of development scenarios we expected (or more accurately hoped) to see in the 1.0 version of the modern app world. That API would be the equivalent of “Petzold.” Due to the increasing capabilities of the underlying OS and development tools, the resulting apps would be vastly more capable and easier to write and debug.
Over the summer as we completed the software build that we would distribute to developers, the DEVX team created “Elements of a Windows tailored app: The Developer Story” which captured the “as we built it” mindset and working terminology used by the DEVX and Developer division teams.
The team took a scenario approach cataloging many types of potential applications along with how the platform could be used to write them. It also detailed how to reuse existing code, such as line of business code, within applications. At 275 pages it represented the amount of material one could master as an individual or team of 2 or 3 people.
The modern platform consisted of three main pillars: modern application behavior, application connectivity, and modern application user interface. Within the context of our ever-confusing terminology, the platform is WinRT which we also called the Metro platform.
One of the biggest changes developers needed to understand was that modern applications did not take over the computer. While many had become increasingly aware of the security model of Windows, which prevented access to various parts of the system without a password, the modern approach to applications meant that there was no access at all to the hardware or to other parts of the system. Every application ran in its own “container” (sometimes called “sandbox”) or essentially walled garden. Most requests to the operating system went through an intermediate “broker” to ascertain whether such an operation would be permitted. For example, in Win32 an application wishing to use the camera would simply connect to the camera as a device and start using it. In modern applications, the request depended on whether the user had given permission to use the camera and importantly whether the developer built into the app the proper requests of the user for permission. This was a dramatic change for Windows and was only just starting to make its way to phones, whereas today we are all too familiar with the endless prompts for permissions to devices. These constrains placed on applications created a new level of trust and security for Windows, though at the expense of the kind of flexibility and “anything is possible” that Windows developers had come to expect.
Applications also behaved differently relative to how they could consume battery power by constantly running. In Win32, every application ran all the time. It did not matter if the user expected the application to be doing something even if the user could not see the application, it was simply how applications behaved. Every little icon on the system tray, every application that created a “background” process, and every window on the screen could be running on the CPU while consuming power. In a modern application, if an application was not visible to the user, then it entered a new state called “suspended” and consumed no power at all. Only when the app was visible did it resume operating as normal. In the desktop computing model, every window must be constantly updated whether the user is looking at the contents or not with each update draining battery power.
This architecture was essential to reduce the power consumption of a modern PC. It was, somewhat surprisingly, controversial. Developers with their large screens envisioned a world with many tasks happening in many windows and work as keeping an eye on all the different windows. The billions on the verge of using phones and tablets, however, were using one app at a time and the screen filled with that app. They were immersed in the app. Switching between apps was instant and tasks resumed instantly when needed. By and large this style of usage so typical on phones mapped to how real-world customers used even current Windows laptops. Most all Windows users had for the longest time, and still, ran applications full screen and worked on one app at a time. Even switching between apps followed the way apps on phones worked. We built support for snapping apps side by side to provide two apps at once.
Still, creating only full screen apps with the new platform would be an ongoing debate or discussion with developers. It was the kind of change that was perfectly fine for the broad user base and certainly for future new users, but not what developers themselves wanted. For developers of course the desktop was still there where all their tools ran anyway. We expected developers to focus on the desktop and they did.
This was one of a number of issues where the initial audience seeing Windows 8 did not see the world the way we saw the next billion customers heading. They had their jobs to do. It reminded me of the early days of Word when the project was not going well and a Word developer asserted that they aimed “to please an audience of one. I write it for me. If I'm happy I know some cool people will like it.” which was a rather limiting way to think of word processors in hindsight.1
A distinguishing characteristic of modern applications was how they connected to each other and to Windows. In Win32, apps had a limited way of sharing information with any other app and that was through the clipboard via copy and paste. To do more usually required applications to open up files from one app inside another. This led to all sorts of potential risks, unbeknownst to users, as we learned with Office. Apps could insert malicious data into other apps or apps could crash opening data files created with another app simply because they did not fully understand the other app’s files. Worse, apps could simply navigate the hard drive and gobble up all of a user’s files (in the background!) without their knowledge.
Modern apps were therefore isolated from each other. This would be quite limiting if not for the invention of “contracts” between apps, and between the operating system and app. With contracts apps could easily tell Windows 8 they would accept or provide information to other apps. Windows 8 created super easy mechanisms for apps to share their information with other apps while at the same time accepting information from other apps. This all took place only when a user initiated an action. Across the system, inserting data such as photos, searching across apps, opening files, and sharing information within a file were all just a tap or click away. A key aspect of the design of the platform was to make it as trivial as possible for an app to add these features and access them via the charms.
There were other connectivity features for modern apps as well, all of which were implemented with security and privacy in mind while doing so with a minimal amount of code. Connecting to a printer, a speaker, or camera could be done with minimal code and trivially. One of our most common demonstrations showed how easy it was in the platform to add a live video feed from a camera with only a couple of lines of code.
There weren’t just new-fangled architectural changes in Windows 8. Even the mundane such as how displays worked underwent a dramatic rethinking. At one of the early meetings on Windows 7 tablets when we first showed touch to the PC team at Intel, their ever-enthusiastic platform leader, Mooly Eden, had a question for Windows. He couldn’t just ask he had to show us. Mooly always had to put on a show. He stood up and started flipping a new Windows 7 slate in the air, spinning it. He wanted to know “when will the screen image also rotate?” He was right. Windows had no ability to do what the iPhone and iPad did so well, simply handle the rotation of the screen, essential for a handheld device. Supporting this first required integrating a sensor to detect the rotation, something that no PCs had though Windows 7 provided some early support. Second, the whole video subsystem needed to be reworked. While it was possible to switch orientation of a display in Windows 7, doing so was cumbersome and involved a great deal of flickering and prayers to the Windows control panel. With little fanfare, Windows 8 added this along with support in the modern platform for apps to easily manage the transition between orientations.
At the other end of the spectrum of screen sizes, Windows 8 built the correct architecture to handle the new high-resolution screens coming on market. These screens would come to characterize iPhone and iPad as retina screens. While they were available as external displays for Windows, they were always buggy and flakey. Buttons or text would show up super tiny or where apps would click would not match on screen where the click took place. This failure of Win32 was rooted in the inability to uplevel the whole installed base of hardware and software as the hardware advanced leaving the old software in the dust. Supporting these new screens was one of over 100 features in Windows that improved the desktop and one of many features that were newly native in the modern Windows 8 platform.
Most would judge the completeness of a new platform for how it enabled them to build the main features of their application. In many ways this was the equivalent of Petzold and included the platform for creating the interaction between a developer’s app and their customers. Relative to Win32 and to the chaos of the .NET world, Windows 8 arrived with an incredibly strong story. Much of this came about because of our own efforts building applications for Windows 8 and the scenario planning for the product. Windows 8 provided a palette of over two dozen “controls” or user interface elements typically used in apps. While one could find these and more via third parties or counting everything offered by all of Microsoft’s existing platforms, never had the Windows platform delivered the full set of required controls all at once. This resonated with me personally because of my own history. Back in the early 1990s when toolbars were invented and developers wanted to add them, Windows provided no support even though Windows itself had toolbars. For Visual C++ I worked with a developer on the Windows 95 team who wrote those controls and added them to MFC, using the Windows code. That developer was also part of the Windows 8 team, so kind of full circle.
A key part of modern apps was how they fit in with the design language for Windows 8 to provide a beautiful, aligned, and consistent experience. Such polish and attention to detail was not something Windows had historically delivered. By and large Windows deferred to the marquee apps like Word and Excel to define the proper look of Windows apps though did not support that look with code or APIs. Windows 8 provided developers with a broad set of tools for typography, animations, color selection, user interface grids to align applications, and more.
Fitting into Windows also meant providing the support for system-wide features such as Live tiles, notifications and alerts, as well as all the necessary infrastructure to easily install and deploy apps. These were also features that Windows provided piecemeal, if at all, in the past.
Finally, everything discussed above was designed from the start to be programmed from all of the programming languages and tools offered by Microsoft. Developers could build modern apps using web tools of HTML and JavaScript, C#, XAML, Silverlight, and even C++ or Visual Basic. Every demo we planned on showing at the upcoming conference included use of all of these languages. We were ready to atone for the lack of communication over the summer.
The platform as delivered to attendees at the upcoming conference was as complete as anything ever delivered by Microsoft all at once, and in the first version. We knew we had a good deal to learn and a list a mile long of what we could do in the future. That was a given. We were so excited though to deliver the future of the Windows platform.
We arrived in Los Angeles on September 12, 2011 for our Professional Developers Conference, renamed //build to be attended by 5,000 people and what seemed like the entire technical press community. Marketing for the new Windows 8 Start screen and the new //build logo was everywhere—those live tiles, colorful rectangles, and animation. It was a breathtaking sight. And we were excited to be there. Even the Denny’s across the street welcomed Microsoft for breakfast, with a sign. A pre-show tradition for me is breakfast at Denny’s.
Unfortunately, there was also a something of sense of dread about the languages and tools for creating new modern apps—our self-inflicted crisis created at the unveiling of the user experience and the omission of .NET before the summer. There was so much cynicism in how the various existing platforms had been talked about—always implying one worked well with the other when in fact they were all separate, all had limitations that were not said, and all had major issues. As a result, however, we created the opportunity for a set of people to spend the summer alternating between conspiracy theories and anger over the developer platform.
The effort to make every single Microsoft language a first-class tool for the modern Windows platform was an immense cross-division project. To say it was easy or lacked controversy would be a huge understatement. It was extraordinarily difficult because many inside Microsoft also either believed or even wanted to believe the conspiracy theories surrounding the deemphasis of .NET by Windows. In some sense they had a right to as they believed in their own work and lived through the alienation and schism that Vista created between .NET and Windows. Windows 7 did offer any relief though it also did not do anything to make it worse. In that sense it was hardly a conspiracy theory, but a fact of life in the .NET world.
Windows 8, however, was when the strategic issues of the past required resolution. There was no simple answer. Realistically, the answer would require a degree of subtlety that tested those on every side of the mess, myself included. We absolutely intended to move forward with the languages of the .NET world (C#, XAML, Silverlight, VB, C++) while at the same time there was no plan to simply move all the code created that used the libraries and frameworks of the .NET era such as WinForms, WPF, VB forms, or Forms³ or third parties. This “technicality” would prove to be an enormous barrier to not only acceptance but even acknowledging the strategy we were embarking upon. To many, not being able to simply port their code to new Windows 8 apps was a non-starter. We had accounted for this by describing the difference between domain-specific code (for example all the code that connects to a remote database or cloud service) and the user experience code that would need to be reimplemented. Most all apps written in this world were divided cleanly in this respect. Not only that, this transition was precisely the one most had gone through to provide web access to the databases and cloud services they built.
We had two challenges. First, within the Microsoft bubble it was clear “everyone” used these technologies. The Developer division had created a bubble of the .NET developer world insulated, as previously described, from the world of HTML and the web browser. Within that world it was of course true that everyone used .NET. Anything we proposed that was not about leveraging that investment was by definition failing to leverage something everyone used. Arguing over how much .NET was used as a portion of total development or skilled developers was futile, especially because even defining terms was impossible as we’d learned for several years of Mid-Year Reviews and Developer Usage Surveys. Even discussing the lack of commercial software would only serve to exacerbate the challenges.
Second, the existing .NET world was the one that failed to account for synergy with Windows or address the problems we set out to resolve with a new platform. When it came to consistency with Windows, safety, security, reliability, battery life, or even basic attributes such as performance or accessibility, the plethora of .NET tools failed to achieve a level of performance or quality consistent with our main competitor, Apple.
These two challenges were not just external to Microsoft. The .NET bubble extended to the 50,000 person Microsoft enterprise organization that were the tip of the .NET spear and also the massive Developer division itself. Many people had spent a decade building out these capabilities and all was going well until, well, I came along.
It was no surprise that the whole time Windows tried to create the connections to the .NET languages to use the new Windows 8 platform we ran into discussions about interoperability or conflicts with the existing .NET platform and APIs. Each new advance in Windows 8 was met with an opportunity to debate the reuse a .NET mechanism to accomplish the same—there was a near constant effort to work to insert the old .NET into the new platform. Windows 8 had a strong point of view about a platform for the future that embraced a new set of qualities entirely absent from the existing .NET efforts.
We intended to deliver on that point of view. The good news, actually great news, was that the vast majority of efforts between the teams supported this mission. That didn’t preclude grumbling along the way. There were some outright stressful times. The release of code would surface many of those, either internally or unfortunately externally via the press as well.
Since we know now that Windows 8 did not achieve the success we hoped, this is a reasonable time to point out that it is precisely at this moment that the efforts between teams created the “told you so” people. In Microsoft parlance this is done by opening up Outlook and searching through Sent Items and reliving these debates to prove that no one listened, or someone knew all along. Success has many parents and failure is an orphan. No matter what happens someone always said it would. This isn’t about bitterness on any side, but I can promise many more people contributed positively at the time than seemed to contribute in hindsight. We’ll return to this reality.
We had an incredible keynote planed for the first morning. It would feature a demo of Windows 8 experience from Julie Larson-Green, an incredible overview of potential Windows 8 devices from Mike Angiulo, for the first Chris Jones detailed the many cloud-based services integral to Windows 8 experience, and on-stage Antoine Leblond would build a modern app using HTML and Silverlight. Even I did a demo showing only features improved in the desktop. It was a two hour and fifteen-minute tour de force by the full Windows 8 product executive team.
I had been to a lot (a lot a lot) of Microsoft keynotes and conferences and launch events over the years. I participated in many as well. With as much sincerity as I can muster, the keynote for the 2011 //build conference was absolutely Microsoft at its best. The whole of Microsoft had never come together to deliver such a coherent and compelling message. It was all done live on real computers running real software. Nothing like it has happened since and it is clear we’re in a new era where that 2011 presentation might have marked the end of the PC era live event. Even Apple would cease to take on the kind of risks we took on during that demo when it came to real products, demonstrated by real executives, in front of a live crowd while streamed around the world. It scares me now to think of just how crazy we were. It was by far one of my favorite days at Microsoft.
Within that favorite day were two favorite moments. Technically, three if you count the walk-on music at the very top of the keynote that I chose. I walked on to Renegade by Jay Z (with Eminem)—“No lie, just know I chose my own fate./I drove by the fork in the road and went straight.” Certainly, over the top. But I felt we could have taken an easy path and just built yet another version of Windows doing more of the same, there were many options for how to do that the equivalent of going left or right. Instead, we created our own path and went straight. The short sound clip is not in the official video because of copyright.
Over the summer we had become increasingly concerned that developers would have no way to experience Windows 8 on the type of hardware we expected to exist in the future. We were working with OEMs closely to create PCs with touch panels, ink pens, and in a variety of form factors from pure slates to convertibles to laptops to all-in-ones. While we tried to have some of those machines for Windows 7, they were few and not commonly owned because Windows 7 lacked the value proposition to drive sales.
The Ecosystem team had been working closely with Samsung on an Intel-based PC that was a pure tablet form factor with an available docking station which could be used to connect a mouse, keyboard, external display, and wired network. The PC was powered by the latest low voltage Intel Core processor. Many of our demos and most all of the demo sessions (over 100!) would use this PC at the show.
At the 2009 PDC we were excited enough by the prospects of touch computing that we provided attendees a free touch laptop. It was a new “thin and light” form factor which was just starting to come to market to compete with Apple. This announcement stunned the audience. Therefore, by the 2011 //build attendees were certain there would be another free laptop. As a point of information that stunt in 2009 cost millions of dollars more than even the revenue from the paying conference attendees.
In the keynote, MikeAng, ever the showman, walked through all of the platform capabilities that the ecosystem and developers could bring to life with Windows 8. Showing everything from ARM-based devices to liquid cooled gamer rigs the size of dorm refrigerators. Then he began to describe a new Samsung device. He said, slyly, the device was being produced in small numbers right now as a prototype. I looked at him and asked “so how many will they make” to which he replied “well, I’ve been told not to bring a cool PC unless we brought enough for everyone so there are 5,000 out on the loading dock right now.”
And with that we announced the “Samsung Developer Prototype PC” to go with the “Microsoft Windows 8 Preview Build.” And everyone went nuts. The key value of this PC was precisely to demonstrate the value of Windows 8. With one PC running Intel developers could run and develop Windows 8 applications for both Intel and ARM devices. The Samsung came loaded with Windows 8 software, sample apps, Visual Studio pre-release, and more.
Little did the 5000 attendees know but over the previous week a team of about 40 Microsoft engineers had been unloading the Samsung PCs from crates air-shipped from Korea to install all this new software and configure them for distribution. In order to get them to Los Angeles in time, Samsung had to manufacture them before the software was complete. It was an heroic effort and made it all the more rewarding for sure.
If you’re interested in more about this, Raymond Chen (RaymondC) a member of the Windows team (UEX) and author of “The Old New Thing” wrote a post with some insider trivia, Some trivia about the //build/ 2011 conference.
Loaded on the Samsung were 17 new Windows 8 applications, the source of my second favorite moment of the day. In addition to the apps from Microsoft such as Mail, Calendar, Bing, etc. each visible on the Start screens shown throughout the week, these 17 apps represented a chance to have fun with the pre-release. The amazing feature of these apps were that they were built entirely by the interns over their 10-week summer jobs. We asked 17 groups of 2-3 interns to work together to build these fun apps from scratch and zero baseline understanding of Windows 8. Not only were they able to create these apps on their own, but they did so when neither the platform nor the tools were near ready and were constantly shifting. I was so proud to both announce and share their summer accomplishments. While for most school had already started we were able to find about 20 of them who were able to sneak away from school to attend the conference and even provide a scheduled sessions detailing their experience. It was as amazing for them as it was for me. It was a career highlight for me. They even made a video of their summer experience which we showed to all the show attendees in the keynote.
That this group took their ideas with an unfinished platform and tools to create new apps was a huge source of validation for the “Petzold” test we hoped Windows 8 would pass.
After providing attendees with a candid roadmap from this moment to final release, there was a short break. We were not done with amazing day one content though. There were two absolutely amazing presentations to follow. We overwhelmed attendees with depth and quality of presentations.
First, JensenH provided an overview from the experience perspective of what makes for a great Windows 8 app. This was the touchstone presentation that brought together all we had learned to date, since the unveiling and subsequent feedback as well.
Following this, AlesH brought things down to the metal and showed the developers in attendance the ins and outs of the Windows 8 platform. He wrote a ton of code and built live apps on stage ably assisted by John Sheehan (JSheehan) who was a senior software engineer on the platform. Importantly, they showed off building apps from scratch using Visual Studio, connecting to Windows 8 to share information and use devices, and also detailed the architecture that provided apps with a sandbox to run in for safety, security, and predictability. They even showed off how apps don’t consume resources when they are not visible on the screen. Of course they used all the .NET languages and showed the broad support for bringing forward that knowledge.
Even with all that incredible content, there was one slide we worked the most on and that was a boxes and bullshit, or politely boxology, slide showing the new Windows 8 platform and its relation to all of the programming languages and APIs Microsoft had to offer.
This was not a slide I dreamed up in my office, not even close. Aleš in his role as distinguished engineering leading DEVX and the Windows 8 platform worked for weeks to create this diagram, collaborating with every part of the whole project across Windows and Developer division. I thought it was a work of art.
Aleš also made the slide a key part of his presentation. By the time he spoke the proverbial shit had hit the fan and he knew he had to somewhat rescue his slide. People had already written instant blog posts and the live blogs picked up on the diagram as well.
So what happened?
Presented in all the glory of the Metro design style, huge and on stage, was as clear a diagram as we could have created describing the Windows 7 world being brought forward for desktop applications, including support for Internet Explorer, Win32, .Net, Silverlight, HTML, C++, C#, and more. Everything had a box, resting on top of the Windows Kernel (a.k.a. MinWin!). New modern apps were shown in boxes with all the tools and languages available to build “on top of” WinRT, including that same list (XAML, HTML, C#, C++, VB, and JavaScript).
The diagram, created by dozens of people from nearly every team in the company, proved incredibly popular, but not in a good way.
To support the diagram, Antoine’s full demonstration of building a Metro app went through all the languages and tools, in real time on stage, by building an app. He built several apps. He built an app in HTML. Antoine took sample code from Developer division vice president (and previously manager of Silverlight) Scott Guthrie’s (ScottGu) famous (amongst .NET fans) XAML sample, and with no changes ran it as both a desktop app and a Metro app on WinRT. The new Metro apps were touch-enabled, integrated with search and sharing, and even showed off the beautiful graphical qualities of the platform by displaying nicely alongside the rest of Windows 8.
The problem?
Before I even got off stage, people were taking the image and redrawing their view of the architecture. Some were critical of precisely how their favorite tools were rendered. Others challenged the technical integrity of the diagram. Within the developer press there were even news stories and a quite a few blog posts dissecting the travesty that was this image. It all happened in real time before we had even finished.
There were blog posts that dissected the diagram and rewrote it. It was the technical buzzsaw applied to a conceptual diagram. The weirdest part for me was that this was a diagram we had created about our own technologies, but the .NET community thought of them as their technologies. In reality, they wanted Windows 8 to work like Windows 7 while further adopting their .NET technologies. They wanted Windows 8 to fulfill the .NET promises they believed were made, and even more so now that we were indeed delivering a new platform. There was little accounting for what we believed we needed to accomplish in righting the Windows platform or the necessary steps to modernize the Windows platform.
Some of the blogs centered around how much code was actually Win32 though repurposed, not because that would be bad but because of a theory that would undermine our argument about the modern platform being native or completely new. Others took aim at the use of the .NET languages versus the .NET runtimes or libraries. This issue was the whole point, unfortunately. Ironically for me this point also was one I made to BillG for years when it came to the value of owning a proprietary language versus owning the API. Now all those championing a language were learning the value was really in the runtime. Yes, that was always my point.
Emotions were running high. There were deep concerns about investments in existing code and porting it to modern apps. We didn’t make this promise to the degree developers wanted and, as a result, there was a wave of feedback over Microsoft abandoning them and costing “millions” of dollars of lost revenue. That’s what people said. To me, this had shades of past transitions, specifically, the major mistake Microsoft Word made in trying to reuse the code for character mode Word to build Windows Word. It did not work and cost the team years. It also felt like the carnage caused when much-loved Visual Basic switched to .NET.
The biggest mistake in platform transitions is attempting to deny that a transition is taking place or to believe a dramatic platform shift could be managed by incremental changes.
Not everyone writing about this diagram took such a negative approach. Several provided thoughtful views pointing out that there was a good deal to be excited about. In an in-depth view, Paul Thurrott wrote on his SuperSite for Windows blog:2
WinRT solves many of the problems of Win32, from an apps perspective, though it can't be used for certain things of course (writing NT services, drivers, and the like). Apps created for WinRT are safe, secure, and sandboxed, can't wreck other apps, can't cause "Windows rot," and all install in just 2-3 seconds. They feature isolated storage, single folder installs (as per the Mac), and require user consent to access the general file system. When Microsoft says it "reimagined" every aspect of Windows, this new runtime, or application model, must be included as well. This is part of it, a modern, truly different app platform that is far more different, and far more capable, than many people understand right now.
And in the same vein of blowing past peoples' expectations, virtually no app could not be written as a WinRT app. Many are imagining very simple, HTML-like apps, and while I'm sure there will be plenty of those, you need to reset your expectations up. WinRT is amazingly full-featured and not constrained to goofy utilities and simple games. The next "Call of Duty" could be a WinRT app, complete with support for Edge UIs and Charms.
And here's something interesting: Virtually all of the Microsoft WinRT apps--Mail, Calendar, People, Chat, and so on--are all written in HTML and JavaScript, not C# or another supposedly superior language.
And you laughed when they repeated "Windows reimagined over and over again in Tuesday's keynote. I'm starting to think they didn't push this point enough.
Our main aim for //build was to put forth the message of a bold reimagination of Windows from the chipset to the experience. That was what we wrote in the press release.
So many of the reviews of the pre-release product articulated the bold design, the attractiveness, the functionality across different types of PCs, and the compatibility with everything in Windows 7. The note of caution was always about the amount of change and how some users might be skeptical. Overall, the press and bloggers were excited and impressed with the leap we had taken, excepting those still debating the diagram.
After a month with the pre-release code, ArsTechnica in its detailed review had the following to say in “Turning to the past to power Windows’ future: An in-depth look at WinRT”:3
Microsoft is taking a risk with WinRT, as developers may not follow it, but it's a calculated risk, and it's a low risk. The re-use and modernization of existing technology gives WinRT instant familiarity for developers, but also an easy path for Microsoft to extend the reach and capabilities (and ease the restrictions) should it need to. It's at once the embodiment of Windows' future and the embracing of Windows' past.
I shared how I thought this event was Microsoft at its best. The press coverage following the event generally agreed. I recognize in hindsight this might seem to be a combination of delusional and revisionist. It was neither. There were over 1,000 original stories of which nearly 700 were what we called PRIME, an acronym defined by the PR agency for stories appearing by top writers in top publications. On average the stories were extremely positive. In a system the agency used to score the tone and message pick up of stories where 100 is neutral, we scored 124 in 386 news stories, 118 in 293 blogs, and 117 in 11 product reviews done in real time. Microsoft events routinely scored a negative sentiment during this era, meaning less than 100.
The agency put together an End of Event recap that ran for over 120 pages. These were tremendous results, not solely because of the content by any stretch. Achieving these results required an amazing marketing and communications effort around the world.
With no intention of shaming any writers who subsequently revised their views or chose to come to different conclusions later, some of the quotes that came along with the availability of code and the Samsung PC press loaners were positively effusive:
“I've never witnessed this much excitement in a Microsoft audience at a keynote before. It's electric.” –Tom Warren, WinRumors
“I might just become a developer considering how easy #Microsoft has made it to write things for Windows 8.” –@reese305
“my iPad suddenly became old fashioned #win8 #bldwin” –@martinsih
“Hello, Windows 8? This is iPad. You win." - @thurrott
“the Metro UI stuff is the best thing Microsoft has come up with in years.” @thurrott
“Here’s the real feather in Windows 8’s cap: Write once, run (mostly) everywhere software.”, PC World, Nate Ralph
“the experience still felt magic, and that’s what really counts. Well done Microsoft.”, RedMonk, James Governor
"Apple bloggers were apparently so flustered by the platform that they resorted to bombarding Twitter with jokes about cooling fans and Silverlight instead of stopping for a moment to realize that Microsoft is showing us the future of computing.", BGR, Zach Epstein
Obviously, it wasn’t all positive. Surprisingly, some still questioned whether we would release “on time” though we did not provide a date we knew we would hit the fall. The real lingering question, and one that did not come up all that much at the event, was the “two modes” of Windows. Speaking for “users” many press would rhetorically ask if users would be able to understand the two modes of using Windows, the desktop, and the new Metro experience. Owing to the developer audience, they were not yet concerned about ARM and simply saw it as an opportunity. They would be running Intel because that is where development tools existed.
The issue of “two modes” was the one we needed to tackle. I wasn’t sure of what else to do. Given the history of Windows “modes” and what we designed for, the complaint and answer were not easily reconciled. Would this become the focus of the release?
With all that, including the protestations around our box diagram, I had wrapped up one of my happiest weeks at Microsoft. It had been a long time since the whole of Microsoft came together as a team and delivered a strategy and produced an event with such clarity and developer excitement.
In under 24 hours we had 500,000 downloads of the Windows 8 Developer Preview Release. At the time there were perhaps three million professional software developers worldwide, total.4
It was Microsoft at its best, but the reactions turned out to be relatively fleeting. The developer community was but one audience. For all the dustup over .NET they were the home crowd at //build.
We had a nagging issue of competing with Apple not just on iPads but on laptops. Could we work with the ecosystem to muster something to compete with Apple’s MacBook Air, finally after years of failing to even try?
What would mainstream consumers say with a much more polished release? What would developers say about the new Windows Store which we had yet to show them? What would we tell developers waiting to see how Microsoft Office would build for Windows 8?
On to 105. New Ultrabooks, Old Office, and the Big Consumer Preview
Microsoft Corp.: Office Business Unit, Harvard Business School case study, Marco Iansiti, Geoffrey K. Gill, 1990
WinRT Is Replacing Win32, SuperSite for Windows, Paul Thurrott, 9/15/2011, http://www.winsupersite.com/blog/supersite-blog-39/windows8/winrt-replacing-win32-140605
Turning to the past to power Windows’ future: An in-depth look at WinRT by Ars Staff, 10/21/2012, https://arstechnica.com/features/2012/10/windows-8-and-winrt-everything-old-is-new-again/
Occupational Employment And Wages, May 2012, US Bureau of Labor Statistics, https://www.bls.gov/news.release/archives/ocwage_03292013.pdf. Microsoft had traditionally taken US numbers and roughly doubled them for worldwide numbers. This rule of thumb no longer applies.