This comes off of the ARM Desktop post here:
http://blogs.msdn.com/b/b8/archive/2012/02/09/building-windows-for-the-arm-processor-architecture.aspx#10266574

As stated in the article, ARM devices can't install desktop apps other than Office 15. Here is an idea to provide desktop apps via the windows store using WinRT instead of Win32:

* I agree totally with not allowing users to install applications for ARM hardware outside of the windows store. At least for the first generation of ARM PCs, this will greatly help reduce consumer confusion and improve their experience with these PCs. They find software for their PC in one place and everything they see in the windows store is guaranteed to be compatible with their ARM device. That's a very good thing from a consumer's perspective.

* I agree totally with the idea that it will be IMPOSSIBLE to get developers of win32 applications to do the same work Microsoft has done to Office, to get them to work well on low-power systems. The win32 API is simply not designed with those concerns in mind and probably never will be.

* I agree totally with the idea that ARM devices will tend to be low-power, resource-constrained devices. In these circumstances, it is VERY important to users that they be given control over what applications can do on their device, when they run, etc... That control is not something people generally have when win32 applications are involved, as every other application installs some background service, updater, etc... Every application has its own kind of installer and uninstaller, and they don't work consistently. The windows store, WinRT app model is consistent, and WinRT apps are predictable in what resources they use and in how they are installed or uninstalled, and users have centralized control over what background services these applications run (and there are limitations in how much resources those services can take up).

Where I DISAGREE with the direction the windows team is going (at least as far as I am interpreting it, I could be wrong about their intent) is in restricting altogether the ability for third parties to create some form of desktop "productivity" app for ARM devices. The fact that you are bringing the Office suite to ARM as a desktop app is a perfect example of why third parties need to be able to do this too. But how would you allow this, while still protecting users and not going against all of the above points?

The solution, in my opinion, is NOT to allow developers to port WIN32 applications to the desktop ARM environment, but to allow developers to create WinRT applications, which are distributed through the Windows Store just like other Metro applications, but which can run in the Desktop environment. This would be a slightly extended version of WinRT - a sort of "WinRT Desktop App Profile".

The extended features of the desktop profile might include additional controls for productivity apps, Load and Save dialogs that resemble the traditional Load and Save dialogs we're used to (but still allow you to go into the full-screen versions, for instance to access metro load/save dialog extensions), and any other functionality that is specific to the desktop, like the ability to manage multiple windows and modal dialogs.

However, unlike win32 apps, WinRT Desktop Apps would use the same API, with some few extensions, as the full-screen metro apps, and thus would generally run well on low-power systems and use the same kind of application lifecycle events that Metro apps use. The only difference is in how the UI is **** out, with more of a focus on the kind of dense productivity app layout that you see in developer tools, photoshop, office, etc.. Although they could be made touch friendly, they don't necessarily need to be touch-centric (just like the new Office is touch friendly but not touch-centric).

Another idea is that it would be interesting if part of the extended Desktop App profile included the ability for an app to support plugins. These plugins would be distributed on the windows store itself and would ALSO target the WinRT API. So for example, let's say Adobe released Photoshop as a WinRT desktop app. Part of the app meta-data would say that plugins for the app are supported, so that when the user downloaded Photoshop from the store, plugins for Photoshop would also appear in the store. Adobe would of course control who would be allowed to publish plugins for the app.