§ ¶Metro style apps and the Win32 API

It's been way too long since I posted, hasn't it? Time to change that.

There's been a bit of discussion about the difference between "desktop apps" and "Metro style apps" on Windows 8, particularly as it pertains to Windows RT (previously Windows on ARM), which currently isn't going to allow third party development of desktop apps. Part of the confusion comes from the fact that you can use native C++ code in a Metro style app. Native C++ doesn't mean you can just recompile an existing C++ app written on top of Win32, though, and there are lots of misconceptions about what this means for converting existing apps to Metro.

I haven't actually written a Metro app, but I have looked a bit at what's involved out of curiosity. Looking at the documentation and the requirements, I'm of the opinion that most C++ apps will require a major rework to conform to Metro app requirements. This is based on the restrictions to Win32 API usage that will require invasive changes to either the C++ code itself or the frameworks that the C++ code is based on. Nevertheless, it's useful to actually look at the API lists and get an idea of where the trouble spots are, which is what I'm going to do here. Think of this as a what-if exercise, kind of what would happen if someone at work just asked you for a wild guess at what would need to change to retarget Metro.

Of course, in order to do this we'd need some guidelines, so we're going to assume:

• That you actually want to use Windows and a Metro style app. Yeah, I know, definitely not always true... just pretend for the sake of this exercise, then.
• That the application is appropriate for Metro conversion and doesn't have obviously crazy Win32 usage. Sysinternals Process Explorer is not likely to be a good target app for conversion.
• That the UI is going to be rewritten from scratch, so that it actually suits Metro and a tablet. The entire Win32 UI subsystem is gone, so there's no point in wondering about that.
• That we're mainly talking about a C++ core that's reasonably well architected, i.e. has the Win32 API calls reasonably wrapped and is decently modular, so that if an API call has a direct replacement it isn't a big deal to swap it out. We're looking for stumbling blocks here, like a lack of equivalent functionality.
• That the resultant app will be written to properly conform to requirements and won't try to do things like subvert the API restrictions.
• That you're using Visual C++ and can easily interface to WinRT through C++/CX when needed. Code only compiles under GCC? Uh, sorry, that's a whole other set of problems that I can't cover here. I think it's possible to use WinRT entirely through COM APIs, but it's likely to, uh, build character.

Our main reference is going to be "Win32 and COM for Metro style apps" from MSDN:
http://msdn.microsoft.com/en-us/library/windows/apps/br205757.aspx

...which, as of this writing, is preliminary and subject to change of course. I'm just going to go down this list, as well as lookup APIs to see if they're marked as "desktop only" or "desktop and Metro apps", and see what that means for existing code.

So, with all of this in mind, what stumbling blocks that we might encounter?