Although, it seems clear that some of the decisions with the "Metro" apps are built so that apps will be able to go between devices, I would like to see the System.Data namespace supported in them. An example, you want to connect to a "local" SQL Express database without having to run a middle tier web-site or application that can talk to the database. Why shouldn't a Metro app run on a desktop be able to connect in the same way that a WinForms app can? The framework was supposed to abstract us from hardware and other changes yet as time goes there become more and more one off's (e.g. Silverlight->WPF->WP7 Silverlight/Metro->W8 Metro).

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.

Currently the only way to take advantage of the direct manipulation in a XAML Windows store app is by using a ScrollViewer. However that isn't always appropriate. For example if one wanted to implemented a fixed columns Excel type functionality where the cells of the first column should not scroll horizontally but the cells should participate in the vertical smooth scrolling and where cells in the first row (and header) should scroll horizontally but not vertically. There really isn't a way to prevent some of those from scrolling since the ScrollViewer's Direct Manipulation implementation will animate/offset the rendering in the compositor thread well before the UI thread gets any notification (e.g. ViewChanged). There are other situations as well where a control may need custom handling of the direct manipulation (e.g. synchronizing scrolling of several disconnected elements).

In WPF/SL, we had the TypeConverter class. If you had a custom Type you could create a derived TypeConverter and handle the conversion from String and then you were able to use the attribute syntax in XAML to set the value of a property of that type. WinRT does not have such a concept. Instead internally MS handles parsing a limited number of built in types. In addition the auto-generated IXamlType has a CreateFromString but that only deals with enums. Even if one took the time to try and intercept/override that a compiler exception would be generated for any type it doesn't recognize.

Without this support 3rd party developers (and therefore all of their users) cannot set certain properties in XAML (without Binding which isn't appropriate/needed for many properties). For example if one needed to define a GridLength type struct in C# that was allowed to be set in XAML you couldn't do it. First, there is no support for custom string parsing. Second, the typical recommended workaround I've seen of using the Element syntax wouldn't work because you can't use the Element syntax to define an instance of a struct (that results in a compiler exception).

Create a new version of WPF that targets Windows 7 desktop apps, that provides much better alignment with WinRT. The provides a couple of major benefits:

Allow application developers to support dual code bases (desktop Win7 application and Win8 app)

Provide incentive for migration to Win8 and not be limited by the installed base

Provide a migration path for other XAML apps (like Silverlight)

Prepare applications for the sandbox restrictions in Win8

Use a single XAML across Win7 and Win8 (Win8 controls would be emulated as WPF controls in Win7)

The library could be community driven, but sponsored and supported by MS. Win8 features (such as share contract, search etc) could be simply no-oped out.