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).

Clearly much work has gone into making multithreaded programming a natural part of modern Windows development. However, there appears to be a crucial bit of information that is not available to the WinRT/Metro developer. Specifically, I have no means of detecting the number of physical CPU cores in the user’s machine.

A simple RunAsync will satisfy the needs of many multithreading goals. But that is not a universal solution. It does not satisfy the needs of all architectures. Consider for example a compute-intensive application that does most of its work as tasks dispatched to a concurrent work pool. That pool will contain N number of threads, ideally equal to the number of physical CPU cores in the user’s machine. The problem is that the quantity N is simply not available to the Metro developer.

The Win32 API function GetNativeSystemInfo is allowed in Metro apps. However, this function only returns the total number of logical processors; it does not distinguish between physical cores and HT. If it says for example 8, I have no idea what that really means. For all I know that could be 2 cores and 6 Hyperthreads. The Win32 function GetLogicalProcessorInformation was designed to return exactly this info, but for some reason this function is off-limits to Metro. WinRT itself does not appear to offer any alternative.

To understand why this is a problem, I refer you to Microsoft’s own documentation on the matter. Specifically, the Core Detection sample of the DirectX SDK has this to say:

"...More significantly, SMT or HT Technology threads share the L1 instruction and data caches. If their memory access patterns are incompatible, they can end up fighting over the cache and causing many cache misses. In the worst case, the total performance for the CPU core can actually decrease when a second thread is run.

...On Windows, the situation is more complicated. The number of threads and their configuration will vary from computer to computer, and determining the configuration is complicated. The function GetLogicalProcessorInformation gives information about the relationship between different hardware threads, and this function is available on Windows Vista, Windows 7, and Windows XP SP3.

...The safest assumption is to have no more than one CPU-intensive thread per CPU core."

So you see, if I create a thread pool equal in size to the value returned to me in the SYSTEM_INFO structure, dwNumberOfProcessors, I am virtually guaranteed that this is the wrong number of threads to create for the optimal use of a SMT/Hyperthreading CPU.

I cannot envision how to support Metro as a developer of modern video games; and by modern I mean multithreaded, parallel, and compute-intensive. How many threads shall I create to suit the user’s CPU? I don’t know, because the new API won’t tell me, and because I will fail certification if I use the Win32 function that was created specifically to answer this question.

Please either add equivalent functionality to WinRT or lift the ban on Win32 GetLogicalProcessorInformation. This is information that I must have.

I have brought this topic up already in the Metro development forums and there was no resolution. For reference see here:
http://social.msdn.microsoft.com/Forums/en-US/tailoringappsfordevices/thread/8e035ad1-10fc-465b-b930-d38edc875272