Prototype Chrome For Win8 Metro About To Debut

A Thursday post at The Chromium Blog, Google's official blog tracking the development of its Chrome browser, announced the upcoming release of a version of Chrome that will support the Windows 8 Metro interface.

Details are still sketchy, but those trying out Windows 8 Release Preview who set Chrome as their default browser in the Dev channel for Windows--normally for testers and developers--will be able to try the next version of Chrome as a Metro app.

Chrome, shown above in its conventional desktop version, is the latest of a slew of common desktop applications, browsers included, to be reworked as Metro apps. Mozilla is currently working on an iteration of Firefox for Metro as part of its general plan to target Windows 8, and an Opera version might also be in the works.

Rewriting a "classic" Windows application for Metro isn't simply a matter of plugging into the Metro APIs to access things like the system charms. Browsers occupy a peculiar place in the Metro app ecosystem. Most Metro apps are allowed to behave only in certain restricted ways. But Microsoft's developer documentation for Windows 8 describes a whole subclass of Metro apps, which it calls "Metro style enabled desktop browsers," which aren't subject to the same restrictions. (See Microsoft's Developing a Metro style enabled Desktop Browser in the white papers for Metro style apps.)

These programs require being configured as the system default browser in order to work in Metro--so the reason Chrome needs to be set as the system browser to work in Metro is that Microsoft designed Windows 8 that way.

Another interesting wrinkle, one mentioned sidelong in Google's post, is how the upcoming release of Windows RT--Windows on ARM processors--imposes restrictions of its own on browser developers. RT, like conventional Windows 8, has both classic and Metro environments, so it seems natural that an app written for desktop Windows ought to be portable, albeit with some work, to RT. (Note that WinRT, the Metro app programming environment, should be recognized as being distinct from Windows RT, the full implementation of Windows on ARM.)

The bad news is that the range of functionality available to apps in the "classic" environment on Windows RT is heavily restricted. Mozilla claims this means the only browser allowed to run in that mode would be Internet Explorer; every other browser written for Windows RT would not be able to implement things like plugins unless--as Ed Bott explained--they were approved by Microsoft and delivered to users via the Windows app store. Hence, no Chrome on Windows RT, at least not yet.

Microsoft has been criticized in the past for having too many target platforms. Even if all of them have been a theoretical subset of Windows generally, the practical problems of such an ecosystem don't always appear in obvious ways. The differences between 16-, 32- and 64-bit editions of Windows, for instance, didn't affect software makers as much as it did hardware manufacturers. It was device drivers, rather than apps, that were in shortest supply during each bit-depth leap.

Microsoft seems on the verge of initiating a trifurcation with Windows: the "classic" Win32 application space, Metro apps, and Windows RT. App developers feel obliged to create Metro apps so they won't seem negligent--at least, for apps that are suited to Metro in the first place--and Win32 itself isn't going anywhere for some time. What's tougher to predict is if developers will need to commit to Windows RT, or if the success of architectures like the Intel Atom SoC will make Windows on ARM redundant.