"Virtually all of the Microsoft WinRT apps--Mail, Calendar, People, Chat, and so on--are all written in HTML and JavaScript"

This suggests to me that all the grown-ups have left Microsoft.

And the app store, going by what people here are saying about it, just sounds downright insane. Guess what one of the biggest reason's I've never considered getting an iOS device is? That's right, Orwell's App Store.

I never agreed with the people who claimed Win95 was too Mac-like, but even I'm finding that ever since Vista, Microsoft has been trying more and more to turn into Apple. At this point, each new step makes me more and more serious about choosing Debian with Trinity (or something along those lines) as my next primary OS after XP.

"I bet there will be zero difference between JavaScript, c#, c++ in benchmarking against the WinRT."

If that's the case, it can *only* be due to something in Win8 getting in the way of native executables and hampering their speed. Possibly the sandboxing.

Hey, Paul - The statement from your article that caught my eye was "virtually no app could not be written as a WinRT app". I was not at BUILD; I'm going on what I've read and what my co-worker who *was* at BUILD has relayed. If your application relies heavily on multiple overlapping Windows, are you saying it could be written as a WinRT app because you could redesign it to not need multiple overlapping Windows? If your application offers a COM Automation interface, how does one achieve that in WinRT?

WinRT excites me because it looks like a runtime that will have much lower overhead than .NET. The application I develop is mostly native code, and we managed to bolt WPF on to it, but it was a bit like oil and water. Seeing XAML sitting on top of C++ on top of WinRT with no .NET is intriguing to say the least. But what does that really mean? Is all of the cool data binding of WPF available?

And what exactly is the future of desktop applications? Is WinRT going to grow up so much that we'll forget we needed desktop applications? Are the desktop application stacks like WPF going to continue to get material enhancements? Or are they effectively deprecated? As exciting as WinRT is, my big disappointment from BUILD is that companies that have bet heavily on desktop applications received no clarity whatsoever about what the future holds for them.

Eric

Hey, Paul - The statement from your article that caught my eye was "virtually no app could not be written as a WinRT app". I was not at BUILD; I'm going on what I've read and what my co-worker who *was* at BUILD has relayed. If your application relies heavily on multiple overlapping Windows, are you saying it could be written as a WinRT app because you could redesign it to not need multiple overlapping Windows? If your application offers a COM Automation interface, how does one achieve that in WinRT?

WinRT excites me because it looks like a runtime that will have much lower overhead than .NET. The application I develop is mostly native code, and we managed to bolt WPF on to it, but it was a bit like oil and water. Seeing XAML sitting on top of C++ on top of WinRT with no .NET is intriguing to say the least. But what does that really mean? Is all of the cool data binding of WPF available?

And what exactly is the future of desktop applications? Is WinRT going to grow up so much that we'll forget we needed desktop applications? Are the desktop application stacks like WPF going to continue to get material enhancements? Or are they effectively deprecated? As exciting as WinRT is, my big disappointment from BUILD is that companies that have bet heavily on desktop applications received no clarity whatsoever about what the future holds for them.

Eric

Well, technically WinRT *does* site on top of Win32, specifically User32. When you run a Metro app, WinRT creates a single always-on-top Win32-based window, adds a DirectX surface to it, then paints everything through that surface. This ensures Metro apps are hardware accelerated by DirectX, but still able to play alongside existing Win32 windows.

For example, if you tell Task Manager to run Always On Top, it is possible to go back to Metro and have Task Manager appear over the Metro window. You couldn't do this if Win32 wasn't in play.

That said, MS is clearly de-emphasizing Win32, but it won't ever go away. Just like you can still run 16-bit Windows apps and DOS apps, Win32 will be here for many many years to come.

And of course, the biggest apps such as Microsoft Office, Adobe's Creative Suite, etc. will all stay running on Win32 for the foreseeable future. Windows 7 install based only just overtook Windows XP - a 10 year old OS.

Also, as a point of comparison, its taken Apple 10 years to get folks off of Carbon and onto Cocoa, and that transition is still far from complete.

@ Paul
with trepididation, this change is big. Win32 is still there on the stack, and one can wrap win32 calls in a metro style dll and include the new dll in your metro app.

But make no mistake, the winRT is totally isolated from Win32. I had a conversation with Visual Studio people because a canned MVVN app was not compiling against Win32 (the new API was missing a reflection call). With the VS2011 Ultimate build, I can run 4.5 client but not the metro style app. OK, how does one include the 4.5 client .Net assemblies in the metro app.

Can't be done.

OK, if you compile against .Net 4.5 client, can I convert the app to Metro?

No.

simply put, there is a sandbox between metro apps and standard .net 4.5 apis calling win32.

So back to wrapping win32 with a metro dll.

Well, only way to distribute metro apps is through the ms store. ms has to approve both the app and the win32 wrapper. what if the wrapper is calling a no-no api?

Then again, there is no way win32 api will be ported to ARM. So you got this wrapper that may be killed by the ms store but regardless will not run on Arm or whatever ms ports to, killing half your market.

Conclusion: Metro is a mind set change both how it works and to what one develops against. I too loath working with JS/HTML, and actually thank ms they are keeping languages I am comfortable with as an alternative. But understanding the metro interface will take many mood altering sessions to glimpse the panorama of its implications. If ms keeps their "fast and fluid" contract, and now it looks like they can, I can buy in.