What IT should know about Windows 8

The three faces of Windows 8 herald tough choices and significant changes ahead for corporate IT

Page 2 of 4

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, shown in Figure 2.


  • 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

Figure 2: The three very different faces of Windows 8, from a corporate developer's perspective.

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. (See Figure 3.)

Win8 API Boxes.JPG
Figure 3: The way Windows 8 hangs together, from Ales Holecek's presentation at Build , approximately 8:30 into the demo.

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.)
| 1 2 3 4 Page 2