In the two weeks since Microsoft unveiled its Windows 8 Developer Preview at Build, more than a million people have downloaded the bits, leaving the vast majority of IT pros wondering what in the world their organizations may someday be getting into.
Here, Microsoft has been characteristically mum, except for the targeted and highly vetted postings of the Windows engineering team on its Building Windows 8 blog. That dearth of substantial information, not to mention reams of unanswered questions, has not prevented Preview users from providing meaningful observations on Windows 8 for the end-user's perspective.
But getting an understanding of the client-side nitty-gritty in the corporate world is no easy matter, especially when looking at pre-release code. Microsoft is not answering questions, and Windows 8 is no doubt a year away, meaning that nothing is set in concrete. But even with the usual pre-beta admonitions, from an IT and developer perspective there's still a lot to chew on -- most notably, how Windows 8's bifurcated interface and support for both Intel and ARM signal tough choices ahead for supporting corporate end-users in the post-PC era.
Shift in surface, change in architecture support
The first major change introduced in Windows 8 is its bifurcated interface. Terminology varies, but I'll call one interface "Metro," to refer to the UI with the tiles, and the other "Desktop," because it looks and acts much like the Windows 7 desktop, except for the black hole in the lower-left corner. (For a more extensive look at Metro, see InfoWorld's Windows 8 Metro visual tour.)
The other major factor for Windows 8 is that it is designed to run on both Intel/AMD hardware and the newer ARM-based offerings. Intel tablets coming out in the near term will be comparatively heavy, and the batteries won't last as long. ARM tablets will likely be lighter, longer-lived, and probably cheaper. Some day, Intel will catch up. But for the near future, at least, the most popular tablets will be based on ARM architectures.
If you've watched the demos and keynotes and read the glib reports, you may be under the impression that Microsoft has created one operating system that works on desktops, laptops, and both Intel and ARM tablets -- "Intel and ARM, not Intel or ARM," to quote Microsoft CEO Steve Ballmer. While that may be literally true, at least in a marketing sense, the devil is in the details, and we're beginning to see some gnarly problems that result from mixing architectures and OSes -- especially issues that corporate developers and IT departments will encounter.
The three faces of Windows 8
Instead of looking at Windows 8 as a unified operating system running on two different sets of hardware -- along the lines of, say, Windows NT, which ran on several different platforms -- IT and developers should think of Windows 8 as having three distinct flavors.
Metro
- Highly biased toward touch interface
- Can't use the Windows API; must use WinRT
- APIs look a lot like the old COM objects
- Restricted API -- no local file or database access
- Subset of .Net 4.5 libraries available
- No shared user libraries; each app is an island unto itself
- No interapp comm, except through "contracts"
- No GDI; can only get to the screen thru DirectX
- No plug-ins for IE -- no Flash, no Silverlight
- Corporate app distribution mechanism unknown
- Differences between ARM and Intel unknown
Desktop on Intel
- Appears to be fully binary compatible with Windows 7 applications
- If it worked on Win7, it'll likely work here
Desktop on ARM
- Very little is known about it
- There is no ARM version of .Net 4.5 available right now
- Microsoft has committed to porting .Net 4.5 to ARM, but there are no guarantees about source code compatibility
- Non-.Net programs are an unknown at this point
Based on the Developer Preview, it's very likely that Microsoft will maintain near-100 percent compatibility with Windows 7 apps, running on the Windows 8 Desktop with Intel/AMD hardware. All of the development tools IT uses with Windows 7, including Silverlight, should work with Windows 8, unchanged, as long as the target is the Windows 8 Desktop on Intel/AMD hardware.
But if you're aiming for the Desktop on ARM machines, it's a completely different can of worms. There's a reason why the tablets given away at the Build conference were Intel-based.
If you keep those three different scenarios in mind (Metro vs. Desktop on Intel vs. Desktop on ARM), Microsoft's official box chart, describing the highest-level interactions in Windows 8, makes some sense.
Now you see the flip side of Steve Sinofsky's statement during last week's financial analyst Q&A session: "We've been very clear ... that the ARM product won't run any X86 applications. What we announced yesterday for the first time was that when you write a Metro-style application, all the tools are there to enable you in any of the languages that we support to automatically support ARM or X86."
Corporate developers' concerns about Metro
In reality, there are only three ways to write Metro applications:
- In C++, writing directly to the Metro Windows Runtime (WinRT) API. (There's a trick for making a native C++ project accessible to WinRT components, described in this Social MSDN thread.)
- In the pared-down .Net 4.5, using C# or VB. (Your program can't call any of the "disallowed" APIs.)
- In HTML5 and JavaScript, run in the "Chakra" IE engine. (It appears as if these apps actually run inside Internet Explorer 10, with the IE10 interface made inaccessible, but Microsoft hasn't yet elaborated.)
In spite of appearances and great presentations, writing for Metro isn't as easy as redesigning an app to use a touch interface, then having a .Net guru go at it. There are all sorts of new restrictions.
For example, apps can't get at the data stored on the computer. There's a way around the restriction on accessing databases: You can create a Web service and get to it via a WinRT call. You can store and retrieve data inside the application, but there's no way to get into the computer's local file system. At least until it's hacked, there's no way to crawl outside the data sandbox.
By design, Metro is locked down -- emphasis on "down." It's great for security. It's hell for any but the most straightforward corporate apps.
Creating a Metro app for your users brings up another thorny issue: distribution. In its Primer for current Windows developers, Microsoft makes no bones about the fact that all Metro apps have to come from the Windows Store: "Apps must pass certification so that users download and try apps with confidence in their safety and privacy. Side-loading is available for enterprises and developers." At this point, there are no details about the side-loading.
For months, people in the know at Microsoft have hinted broadly that they're working on adapting the Office suite to the Metro interface. It will be very, very interesting to see how Microsoft can pull that rabbit out of the tiled hat. Certainly, the Metro version of Office won't have access to the PC's data files. Will Metro Office do more than simply bring the Office Web Apps onto the tablet -- a trick Google pulled off with Google Docs, using Chrome and HTML5, just a few weeks ago?
Corporate developers' concerns about ARM
There's a reason why you haven't heard any details about "the third box": Microsoft hasn't released anything resembling the .Net 4.5 Framework for ARM machines.
The .Net Micro Framework, which runs on ARM devices, has been around since 2007. Microsoft released this ".Net for small and resource-constrained devices" to support smart watches, sensors, and industrial automation. .Net Compact Framework was popular with ARM-based Windows Mobile 6 phones, but Windows Phone 7 development has primarily turned to Silverlight, XML, and XNA. Those are the only versions of .Net available for the ARM architecture right now, and they're both miles away from .Net on the Windows 7 desktop.
Although Microsoft promises to make an ARM version of .Net 4.5 available at some point, there's no guarantee that programs written for .Net 4.5 on the Intel Desktop will work in .Net 4.5 on the ARM Desktop. Quite the contrary -- every indication at this point is that the two flavors of .Net 4.5 will be substantially different.
There's absolutely no indication that Microsoft will support any other development environment for ARM architecture, although we're promised that Silverlight will run on the ARM Desktop's version of Internet Explorer 10. Compatibility between IE10 on Intel and ARM is an unknown; thus, Silverlight may not work exactly the same way on both.
That's a tough pill for IT developers to swallow. Think of it this way: If IT has to make two different versions of its Windows 8 tablet apps to run on the Desktop on Intel and ARM processors anyway, why not go with an OS that's well known -- pick your poison, Android or iOS -- and forget about Windows on the tablet entirely?
If you're planning for next year, you can commit your company to just Intel tablets, or you can take the pig-in-a-poke approach and bet on the ARM Desktop. Or you can wait to see what shakes out. But if you, as an IT developer, choose to jump ship right now and go with Android or iOS, you can get your tablet apps up and running a year before Windows 8 is ready.
No matter how you slice it, that's a compelling option.
The writing on the wall
When Microsoft presenters start calling Windows 7 applications "legacy apps" and Metro apps "the future," you should take note. The times are changing.
Make no mistake. Whether it's a Windows 7 desktop or an Intel Windows 8 desktop, the Desktop, like Windows XP, will be around forever.
Come to think of it, that's what everyone said about CICS and Cobol.
Two years ago, when Windows 7 was young, the iPad didn't exist, and tablets were like luggable Oldsmobiles, few people would have dreamed we'd come to this point. The same tide that swept PCs into corporations 25 years ago has returned, and it's stronger this time. Windows 8's design simply confirms that observation.
IT can fight the tablet tide tooth and nail. Or corporate developers can run out in front of the parade and pretend they're leading it. The biggest question is whether IT can afford to wait another year before they start waving the banner.