At the BUILD conference during the week of Sept. 12th, 2011, Microsoft stated many things; of course, they also didn’t state many things. Among the things that they stated was that WinRT was their vision of Windows apps in the future. By it’s very name, you can tell a lot about it – stay with me for a second.

So what didn’t Microsoft say at BUILD? They didn’t say much about Win32. More importantly, when people were declaring “the desktop” dead on ARM-based systems running Windows 8, Microsoft never corrected them.

Microsoft did say that “x86 applications” would not run on ARM, and they said “legacy apps won’t run”. This isn’t news. x86 applications can’t run on any other chipset (other than x64) without emulation (completely mimicking the instruction set of a CPU on top of another), and Microsoft clearly stated that emulation wasn’t in the cards for ARM. It’s computationally irrational for Microsoft to support applications compiled for x86 processors on ARM systems – supporting Win32 natively on ARM could be complex enough. Applications compiled for x64 systems are out of the cards entirely, as there is no production 64-bit ARM chipset, and if there were, Microsoft wouldn’t be supporting it (Windows 8 for ARM, from multiple sources, will be 32-bit). It’s also important to understand that virtualization is not an option here. Virtualization is the creation of a virtual machine that still relies on the underlying processor to natively process instructions. Virtualization on an ARM system only gets you yet another ARM system – no way to natively run applications designed and compiled to run on Intel or AMD x86 processors. So no, there is no Hyper-V for Windows on ARM (or x86 for that matter), only on x64 versions of Windows 8.

A common thread I saw during BUILD was reading articles where the author misunderstood the difference between x86 and Win32, and misstated accordingly in articles. The difference is critical to understand. One is a platform-specific instruction set, supported natively only on Intel and licensed x86 and x64 CPUs. The other is a Windows API, provided as a subsystem (win32k.sys). Actually. it is the Windows API. The Win32 API provides the “fundamentals” that any modern Windows application relies upon. Even current .NET applications at their most primitive level rely upon wrappers around Win32 APIs. WinRT is no different.

Why is this important? Because the press has been repeatedly stating that Windows on ARM won’t have x86 (which it won’t, as I explained earlier), and even those who technically understand it have been saying that it wouldn’t have Win32. That’s simply not true. Microsoft didn’t help things with the diagram they showed, which is included in the WinRT article cited earlier. If you read this diagram as it is laid out, Win32 is off to the side (next to several other desktop-focused APIs that Microsoft would also probably like deemphasized over time. But this graphic, while pretty, and somewhat informative, is technically, well… incorrect in several ways, due to the fact that it seems to try and focus on the API surface available for each language, not the actual technical dependencies. Apparently I’m not the only one who found issues here, Doug Seven, an EVP at telerik also took issue with the developer aspects of the stack as shown.

In that diagram, at the bottom is “Windows Kernel Services”, which is not technically an individual thing, but a collection of the Windows NT kernel and other native (read: sub-Win32) systems required to get Windows (NT) subsystems initialized. Above that, we see “Application Model”. This is where things go wrong. While the title to the left (System Services) is technically correct, there’s a layer missing in this burrito. Win32, which is shoved over to the right as I mentioned, shoud, technically, run all the way across this diagram at that level, and everything else currently at “level 2? should be up one. If all of my technical gibberish bores you, walk away understanding one critical thing: at this point, Win32, even on ARM systems, is not, and cannot be, gone, as it underlies everything else on this diagram. Microsoft partitioned it for this slide, most likely to make Win32 appear “old” and let “new” APIs that developers should be using in Win8 instead, shine through and be the pinnacle of the diagram.

Unfortunately this squishing of Win32 off to the side caused others, along with me, to get confused as to what exactly was trying to be portrayed with this slide. It looked as if Microsoft was trying to say that Win32 was “over there”, and not a part of, or even a dependency of, WinRT. However, the diagram makes the most sense if you think of how “low” each language developer can dive using their respective language and platform. For example, only a native C/C++ developer can make the most of the Win32 API, while HTML/JS developers in the traditional Windows environment are only able to exploit the (far narrower collection of) APIs surfaced by Internet Explorer itself.

Rather than trying to redefine every single aspect of the diagram, I should share my “reimagining” of this slide. I believe this is actually how Win8 functions:

Windows Metro apps rely upon the WinRT platform in each user’s interactive session (Session 1 or higher) on Windows. The Start Screen appears to reside in windows.immersiveshell.serviceprovider.dll, which is actually an in-process DLL inside of Explorer.exe. This makes sense given that many partners I spoke with at Build said they did not have access to Metro or the Start Page until almost the day of the show, and a simple Windows Explorer-related registry hack can, for now, disable the Start Screen and bring back the old Start Menu. It’s imperative to understand here that the dependency is reversed from what most people have guessed – the new shell depends on the old (Win32) shell, not vice versa. There isn’t any new magic, really, to render the old desktop, and Explorer certainly has not been rearchitected to use the far narrower WinRT API.

Compiled language apps (VB/C#) are compiled into their own binary (YourApp.exe in my example), and HTML/JS apps are executed by WWAHost.exe, in a manner not unlike web pages in IE or .HTA pages with MSHTA.exe if you are familiar with HTML Applications. WinRT applications, including services such as Windows Live sync appear to be created and managed by two in-process DLLs running on session 0 (the non-interactive, services, side of Windows). Since Session 0 is non-interactive, it would not make much sense for it to provide WinRT services such as Windows Live sync or management of app lifecycle in that session, as WinRT requires on the Windows interactive session side.

I hope that the image above provides a little bit more clarity around the role of Win32 in Windows 8. It’s not gone. Not even forgotten. It’s there and more critical than ever.

While at Build, I saw most of the prototype ARM tablets. While I wasn’t allowed to touch or handle those systems, performance seemed pretty good, but more importantly, the desktop icon was clearly visible on the Start Screen. Just as important, a simple tour through Windows 8 on my own system exposed the dozens of sharp edges that are there that require Win32, many of them retooled for Windows 8, and unlikely to be removed before the OS launches. Notepad, Wordpad, MMC.exe, many Control Panel applets, and any complex file I/O operations such as copying to or from a network or copying multiple files, that require Windows Explorer (Microsoft even demonstrated doing this at about 22 minutes here). Win32 isn’t going anywhere in the platform itself, and it is questionable how much Microsoft could work to completely eliminate the surfacing of Win32 “contact points” across the OS still present in the developer preview if they wanted to.

Outside of the platform with 3rd party apps, there are countless questions still to be answered by Microsoft. The primary question is outside of Win32 itself, what other dependencies will or won’t be there, and what kind of development tools/support will be provided by Microsoft (VS 11 will currently compile non HTML apps into ARM versions, but of course you can’t do anything with them yet, and this is just WinRT apps)? What version of .NET or any other redistributable libraries will be supported there? That question is pivotal as it determines how well Windows 8 ARM systems could function as full clients in enterprises in particular, where carrying legacy apps over – even if they require recompilation and likely retooling/refactoring – will enable acceptance of Windows 8 where WinRT won’t meet the entire needs of the enterprise in the near term.

Short story long, Win32 isn’t dead. Even on ARM. It’s still very much at the heart of Windows. It’s just not the focal point of discussion for Windows 8 evangelization – that’s WinRT.