, DeadX07 wrote

This means that in the future if X feature was introduced in the Win32 layer, it could just be exposed through WinRT, and .NET customers wouldn't have to wait for the .NET team to make a wrapper. This is possible because WinRT uses what they call language projections, which allow WinRT to project its API's to specific languages, so you can use the API from your language of choice, and it still looks like you're using your language.

Which is terrific. What I do not understand is the shift to native over managed. I thought the thinking on performance had been that the next generation of hardware would solve that problem.

And I do not follow why the JITer and GC the .NET framework cannot smply be improved to address performance problems.  I am impressed with how quickly the shell namespace extension I wrote recently in C++ starts up. The preview handler I wrote starts instantly. But why would a .NET version have to be slower? Can there be prestarted .NET processes, which somehow are able to latch onto a set of preloaded .NET assemblies at process start ( if assembly loading is the cause of slow starting .NET apps. )?