Metro is just the Start menu of Win7. MC can be a Metro tile.
Metro on Windows 8 x86/64 will be used, by most people, much like the Start Menu in Windows 7. You'll pin favorite applications, but when you launch them, they'll switch you over into the traditional desktop and run the same x86 code that the developer would have written for Windows 7 (and the developer can still develop for Windows 7 customers too, simultaneously).
Windows RT (on ARM) is different. You cannot do this. At all. All third party code must run entirely "within" the Metro UI. It cannot access the Windows Desktop, or the associated APIs, at all.
So, yes, if you port the entire thing over as a Metro application, then you can offer MC as a Metro application and run it on ARM devices. However, if you want to continue to support the existing user base on Windows 7 PCs, or "desktop users" on Windows 8, you will need to maintain two very different applications with two completely separate user interfaces. It will almost certainly be a major undertaking.
Stephen Sinofsky outlined it
in this widely reported blog post, and then Jason Zander
expanded on it earlier this month. The Sinofsky post in particular is a dense read, and it is hard to get the important nuggets buried in all the glowing marketing-speak, but
Paul Thurrott boiled it down:
Application (in)compatibility. Third party Win32/Explorer style applications--that is, all applications sold and made today, will not work on WOA systems. They cannot be ported to WOA, and cannot be made available in any way to WOA users. In WOA, Microsoft is only providing the basic desktop features from Windows 8 (file management, task manager and so on), the desktop version of Internet Explorer 10, and special versions of key Office 15 applications (see below).
Furthermore, WOA systems will not support running x86-based applications in emulation or virtualization (and Hyper-V is not part of the WOA versions of Windows . Get the message? Only a tiny subset of desktop applications will work on WOA, and all of those will ship with WOA systems, from Microsoft only.
From Sinofsky's post:
Previously we have detailed that WOA will not support any type of virtualization or emulation approach, and will not enable existing x86/64 applications to be ported or run. Supporting various forms of emulation runs counter to the goal of delivering a product that takes a modern approach to system reliability and predictability—by definition, existing code has not been optimized for the platform the way WOA has. Virtualized or emulated software will consume system resources, including battery life and CPU, at unacceptable levels. Emulation and virtualization of existing x86/64 software also require the traditional PC environment of mouse and keyboard, which is not a good assumption for WOA PCs.
If we enabled the broad porting of existing code we would fail to deliver on our commitment to longer battery life, predictable performance, and especially a reliable experience over time. The conventions used by today’s Windows apps do not necessarily provide this, whether it is background processes, polling loops, timers, system hooks, startup programs, registry changes, kernel mode code, admin rights, unsigned drivers, add-ins, or a host of other common techniques.
...
Developers wanting to reach WOA with existing apps have two options. Many apps will be best served by building new Metro style front ends for existing data sources or applications, and communicating through a web services API. This approach will be quite common for line-of-business applications and many consumer web properties, and represents the best way to tap into the power of a rich user interaction model where you can also interact across and share information with other new apps. Of course, these do not need to be just front-ends, but could operate on local data too, since WOA provides full access to files and peripherals. Other existing applications will be well served by reusing large amounts of engine or runtime code, and surrounding that with a Metro style experience. This will take some time, and represents a way for applications that are composed of significant intellectual property to move to WOA and WinRT. In all cases, WinRT represents the new set of Windows OS services that developers can use to build software that is Designed for Windows 8.
So, you either write a separate little Metro "front end applet" which communicates with an
external data source using the web services API (which cannot be running on the actual the same physical machine, but external: think Twitter apps and apps like Instapaper);
or you can re-write the entire application as a Metro app. Metro applications will NOT run on the Windows desktop environment or switch to it. They cannot be run on previous versions of Windows. You
can re-use engine code (stuff behind the scenes) but the entire application must be re-written, and the entire UI has to be re-imagined. The API is totally different. Plus, the only way to get apps on Windows RT devices will be, just like Apple, via the Microsoft App Store (or whatever they call it):
WOA PCs will be serviced only through Windows or Microsoft Update, and consumer apps will only come from the Windows Store, so you never have to worry if a program will run because you are not downloading or installing from a DVD outside of the store experience.
That's essentially the same exact thing as iOS development (developers can, after all, re-use Objective C "engine" code from a MacOS application in the same way). The only difference is that Microsoft "cheated" themselves, because
they are using the Desktop environment for Office, desktop IE, the Control Panel, Windows Explorer, and the other "desktop applets" that Windows comes with now. But they're not letting
you cheat. If you want to run on Windows on Arm, you have to do it with a Metro-only app, distributed through the Windows Store, approved by Microsoft, and they must follow the "Metro style guidelines" (much like the iOS platform rules regarding backgrounding and whatnot). These new Metro applications will be separate from any "legacy" applications you continue to develop for your other customers who haven't moved to Windows 8.
It is, essentially, a clone of the iOS development environment. Sure, you can write in C++ if you want to (they do seem to discourage even that somewhat), and you can access peripherals and the filesystem without as much of iOS's stupidity, but... That's a far cry from:
If Microsoft did the Win RT version well, it could just be a recompile.
I think you might be in for a surprise. I've talked to our developers here in house. They've looked at it in a fair bit of detail. Even though we generally
do only write applications that target external databases, they felt this was going to be as major an undertaking as porting to an entirely new platform. They certainly could be wrong, and maybe so much of your engine is "isolated" that you can disable the parts you're "not allowed" to do, whip up a Metro-only UI quickly, and staple it to a modified version of the existing back-end. But I'd be pretty surprised with something as deep and complex as MC.