I’ve been watching a lot of press response to the Windows 8 announcements yesterday. Steven Sinofsky first announced code-name “Windows 8” (Why the codename, guys? Put a line in the sand and name it.) with a new user interface (and the same old interface too) at D9 and Steve Guggenheimer discussed the future of hardware and ARM processors at Computex.

Discussing both on the same day in separate venues was actually quite a logical split – it didn’t defocus the software vision by talking about ARM or the inverse at Computex – the same reason why Microsoft used to split the Professional Developers Conference (PDC) and Windows Hardware Engineering Conference (WinHEC) into two events.

A lot of pundits are grumpy that Microsoft isn’t killing off the legacy Win32/explorer model. Others are sad that Office still won’t be touch optimized. More are grumpy that they didn’t go far enough with the app model overall.

Let’s answer a few questions.

1. What hardware/software that requires drivers will run on a Windows 8 system? Microsoft touted that any Windows 7 apps or hardware will just work. This isn’t true. Windows 8 will support three CPU architectures, x86, x64 and ARM. To encourage the migration to x64, Microsoft has long required hardware or software with signed drivers to support x64 and x86, even when many customers didn’t use x64. This helped prevent the failed experiment that was Windows XP x64 Edition, where little hardware, or even software that required drivers would run. In this sense, hardware and software seeking the Windows 8 logo (and perhaps stuff already certified for 7) will have to be (likely modified and) recompiled to support ARM hardware as well.
2. That’s hardware and drivers. What about Win32 applications? 32-bit applications will require recompilation to run on ARM-based systems. Windows 8 does not have a “WOW”  (Windows on Windows) layer as x64 versions of Windows do to let them run 32-bit Windows code (WOW64), or as x86 Windows has, to run 16-bit Windows code (WOW32), meaning it cannot run existing Windows applications as-is. Any existing application, from consumer applications, to line-of-business applications, to, well… malware, will have to be recompiled to run on Windows 8 on ARM. Like x64 Windows, I anticipate no 16-bit application support.
3. So it’s just a recompile? No, it’s not. ARM is a very different CPU architecture, and like x64 and IA64 (Itanium) before it, will likely take a fair bit of work for existing Win32 applications to be ported over. Throw in issues with existing 3rd-party COM or .NET components, no time/money/developers to do the port or a lack of understanding how the code even works, this could be quite a bit of work.
4. What then? What can we do if we want to use Windows 8 with our existing applications? A couple of options: 1) VDI/Citrix – like many projects are doing where iPads are the device in the conversation, run it on an x86 or x64 desktop or server dedicated to that role. 2) Use Intel SoC systems instead of ARM. Time and testing will show whether Intel can get x86 SoC systems to be as power conservative as ARM-based systems such as the iPad are. I’m also curious to see if Microsoft comes out with a new version of App-V for ARM-based Windows 8. It would be a lot of work, and would have limited return vs. just using a VDI solution instead (such as potentially high power consumption if it’s an inefficient app).
5. But Microsoft said it’s a single application that can run on either platform? Yes, that’s true. For new applications created for touch/the new user interface. Not for legacy applications.
6. So this all applies to an ARM-based tablet/system. What if I get an x86 System-on-a-chip tablet or system or upgrade to Windows 8 from my Windows 7 x86/x64 system? In that case, yes – existing applications, hardware, and software should run as-is.

As I mentioned, many have said that Microsoft didn’t make a clean enough break. I’ve made a graphic that emphasizes, especially when you’re talking about an ARM-based Windows 8 tablet, how clean of a break this actually is. See below.

I’ve added a new API, called “WinHAPI”, for either “Windows HTML API” or “Windows Haptic API”, your choice. Microsoft didn’t explicitly name this thing yesterday, though they surely will at the BUILD conference later this year. Note that that is the only API that works literally across all Windows client architectures as-is.

For x86 Windows 8, then, almost all 32-bit or 16-bit applications and most 32-bit drivers and hardware just work when upgrading from Windows 7 or even likely Vista. Windows XP, most likely. Earlier? Probably there too. If you have an x86 system, even if it’s a low-powered Intel System-on-a-Chip (SoC), most software will just just work.

For the next column, x64 Windows 8, note that 16-bit applications fatally died, and drivers had to be modified to support 64-bit. More than just a recompile, 64-bit added PatchGuard and other kernel attack mitigations never added to x86 most likely due to application   compatibility. Most 32-bit Win32 applications “just work” on x64 Windows, unlike Itanium and every other architecture port preceding it (and ARM following it). Microsoft has never been able to get the platform to cross this platform chasm to an entirely new     architecture – x64 is the closest they’ve come, and it has only worked because it is such a close cousin to x86, and Microsoft required drivers for it if you wanted them certified on x86. Don’t believe me? Ask any friend who ran x64 Windows XP how well hardware and applications supported it. Not well.

Finally, we have ARM. Nothing goes straight to ARM except apps written in this new “WinHAPI”. 32-bit Win32 applications will require a recompile at a minimum, significant work or even abandonment/VDI at a maximum. Win64 and Win16 code won’t ever run, but Win32 (and .NET, if all component requirements are there and the .NET platform makes it, which it surely will) applications will be able to migrate. ALL drivers will require work for developers, though consumers won’t likely feel this since Microsoft will be requiring them to support ARM in order to get certified for x86 as they did with x64.

So what does all this mean? Microsoft has never made an architectural shift like this work. But they’ve also never tried an entirely new app model as the primary app model for Windows before. Doing both at the same time may actually help make the jump to ARM possible, and actually help calve off a lot of legacy Win32 code as Win64 began to do.

The real question is how much consumers will get confused with the new app model. Ironically, as Microsoft does this, Apple prepares to launch Lion, which will promote it’s own new app model to do much the same. The reality is that while it appears Microsoft may have an advantage in the old app/new app side by side model, the reality is that the iPad has done just fine without supporting legacy Mac OS X applications or Win32 applications, and the Mac has enjoyed a broadening popularity even though it lacks the touch user interface the iPad and competitors are focusing on.

The question will be, in trying to appease two masters, consumers wanting a touch-screen tablet, and enterprises with a huge investment in Office and other line-of-business applications, has Microsoft done it, have they gone too far, or not gone far enough?

Time will tell – but I think that Microsoft has done a pretty good job of balancing the design. I recall, however, how aggravated enterprise customers were with the minor changes to the Start Menu in Windows XP. Not Vista, but XP. How will they take to a new front end for everything?

As to Office, Microsoft does need to make a touch-savvy version of Office, even if it’s feature limited. Realistically, an HTML version of it that is (optionally) hosted on the web as well wouldn’t be illogical. But this is a baby with the bathwater thing – businesses have spent millions on acquiring and training people to use Microsoft Office, and with a keyboard and mouse, it’ll still be a first-class citizen – but on a tablet w/o them, it will not be – I’ve tried using Office with a stylus-based PC in the past – that wasn’t even fun. With a finger? But that’s a peculiar scenario to have to explain to a consumer. I envision many conversations at Best Buy, “why doesn’t Office look like the other apps? Why isn’t it easier to use with my fingers?” Lots of questions, and perhaps a new revision of Office down the road will address that. But since I anticipate Windows 8 ARM users will be getting a revised version of Office 2010, not a new release, the timing is totally off to address all questions at once.

I think it was an interesting announcement, and begins to at least tell the world, “Microsoft isn’t standing still”, even though we now have to wait quite a while before we can use this everyday.