Remember that Microsoft is shipping Windows RT with Office 2010 included... as in the DESKTOP version of Office running in the "Desktop app"! Windows RT is truly the complete Windows 8 stack from top to bottom with Win32 and everything else. The big difference is that Windows RT will only run code that is signed by Microsoft. As Mozilla has pointed out to quite a bit of fanfare Microsoft refuses to sign any 3rd party ARM desktop application.

Windows RT has been intentionally nerfed in the name of boosting Metro application development. Why you ask? Because Microsoft wants to leverage their dominant position in the PC market to create an ecosystem of applications for Windows Phone and the upcoming Xbox.

Have you noticed that they have gone to painstaking lengths to make is so Metro applications that use the WinRT API cannot access the win32 API or the full featured preemptive multitasking OS which WinRT is implemented on top of? Check out the WinRT API reference sometime, it gives you access to a very limited subset of what the full operating system can do. This is intentional, Metro applications are designed to be boxed in to only what Windows Phone 8 supports. Also, all Metro applications must be distributed by Microsoft's app store. How much you want to bet that once Windows Phone 8 comes out Microsoft suddenly announces that all your Metro apps for Windows 8 will run be instantly be available for download and use on Windows Phone 8 via the Microsoft app store?

Microsoft is up to the same tricks as usual. Trying to leverage their core Windows/Office monopoly to gain a dominant position in emerging market segments.

Windows RT comes with a copy of Office 2010 bundled in. That's the reason for the $88 price tag.

While we are on the subject of Metro applications and traditional application development languages... As many others have pointed out, native code is not dead. If anything, WinRT represents a revival of native code. Microsoft has created a new language called C++/CX for WinRT just for the purpose of writing native code Metro applications. Metro applications written in C++/CX use the same APIs as Metro .Net applications, this has never been the case for desktop applications. This is the first time in over 10 years that native code developers have enjoyed feature parity with managed code developers on the Windows platform.

It still remains to be seen if lightpeak is vaporware or not. I suspect that Intel will find the power consumption of fiber optic interconnects to not be acceptable for a laptop battery.

I don't know much about this, but wouldn't you be able to use D3D10 in windowed mode for the same effect?

Using the MIL would give you access to the compositing engine, which you don't get with DirectX. Access to the compositing engine enables special effects that depend on the contents of multiple windows at once like glass. The MIL would enable someone to write a program that makes windows wobble for example.

If the answer to my earlier question is "no", then I guess it's true, but then you could just treat WPF as yet-another-Windows-API.

Well WPF isn't exactly meant to be a managed wrapper for the MIL, its meant to be a widget set. If one wanted to use it as such, one would likely need to dig in to WPF implementation details fairly deep.

For starters, all those frameworks that you've listed (and others which you did not) are layers on top of the core Win32 APIs, which can greatly simplify things, but don't really provide new capabilities.

Sadly that is not 100% true anymore. The MIL (Media Integration Layer) in Vista and later does not have a public API.

The MIL allows one to pass vertex data as well as pixel shaders instead of bitmaps to render a GUI. The MIL is used by the desktop window manager to create those pretty glass effects. WPF (a .NET only API) accesses the MIL directly and provides vertex data, there is no supported way of doing this from a native application. Thus you are forced to use Microsoft middleware to use that part of the OS.

The MIL is also used by Remote Desktop. Notice that if you remotely log in to a Vista/Win7 machine from another Vista/Win7 machine, you will still get the glass effects. This is because the MIL instance on the remote system is sending its data structures to the local system over the network, allowing your computer's MIL instance to render the content, including the pixel shaders for the glass effects. Because there is no public API for the MIL, VNC will never be able to copy this functionality, forcing you to buy the more expensive versions of Windows that have Remote Desktop for that feature.

First of all, between COM Interop and P/Invoke, it is very easy to inter operate with native code from managed. This can be very handy, it enabled easy ports of GTK, Win32 (via Windows.Forms), Qt, WxWidgets, SQLite and many others to .NET. But the biggest use for P/Invoke in typical .NET applications is to make calls to the Win32 API directly, because the framework doesn't have managed libraries for every Windows API. This of course creates applications that can only run under Windows. A lot of times .NET apps will run under Mono for Windows, but not Mono for Linux because of this.

Even of course there the fact that MS drives the direction of .NET, and the Microsoft implementation will always be ahead of the game because of that. Mono is missing most of the new features in .NET 3.5 WPF, WCF, etc. The main exception being an almost complete LINQ implementation. Moreover the DLR stuff will be coming with .NET 4.0 very soon, which will just put them even further behind. And Mono is likely to never have support for XNA applications.

In summary the total common feature set between both implementations is less than the total feature set, and a lot of what is missing is cool new stuff. So apps that only work on the MS implementation are common. This is exactly what they want, its technically an open platform, but not really in practice.

Microsoft sueing the mono project and forcing it underground through software patents would be an enormous shoot to the foot. Mono does nothing more and proliferate the .NET platform, often at the expense of Java. The thing that Microsoft likes so much about .NET is that while mono and Portable.NET provide a way to make true cross platform apps, there are many, many Microsoft specific extensions to the core, which makes it very easy to make a .NET app that is not portable. In the late 90s Java was the same way thanks to Microsoft's JVM with builtin COM support, and various other Microsoft technologies. The Java of today however is designed in such a way that it is difficult to make a Java app that is not cross platform, which is why that hate it so much. Mono makes .NET exactly what Microsoft wants it to be, technically open yet easily locked to thier platform.

You can't give EEStor any credit until they publicly demonstrate a working device.

The memristor could potentially add 10-20 years to Moore's Law and the iPhone app store is worth more than it? These idiots don't even know what it is, memory RESISTOR not transistor.