Windows 8 includes a new API, the Windows Runtime, that allows you to use HTML for the same purpose as XAML and JavaScript for the same purpose as C#. Win32 is still used for Aero, but WinRT must be used for Metro. This is actually an evolution of COM. Object activation does not require registry entries, and natively supports reflection, metadata, asynchronous calls, and dynamic languages.
Powerful processors and displays with low power consumption and advanced batteries allow you to build tablets that can run a classic desktop operating system. However, because tablets are handled more like phones, the style of user interface known as Metro is carried over from Windows Phone to Windows 8.
Multi touch
Multi touch was introduced for the first time on the Windows platform on the Microsoft Surface. It ran Windows Vista and applications were written in WPF. A large number of touch-related events have been added to the control. These were also captured by an infrared camera. Today, they are taken care of by a touch-sensitive display. Multi touch can therefore be used from .NET Framework 4.
Metro
Windows 7 has Aero, Windows Phone 7 Metro, and Windows 8 will have both. In Visual Studio 11, another domain has been added for which the application is created – Windows Metro Style. Support for WPF has been rewritten in native code, so that applications written in C++ can now also use XAML.
When the user interface of an application is designed inappropriately, there are situations where many windows are open on top of each other, which is very confusing. And because Metro is designed for small displays, it brings a nice limitation – you can't create overlay windows like MessageBox. This is also related to the removal of Message Loop, which already goes back to the history of Win32.
HTML5 / JavaScript
A major change is the transfer of the code responsible for HTML5, CSS and JavaScript from Internet Explorer directly to WinRT. HTML5 can be used to declare controls just like XAML. JavaScript must be used as Code Behind.
And because it’s commonplace in the .NET world today to use assemblies no matter what language they're written in, WinRT directly (without a DLR) supports dynamic languages, reflection, and metadata.
async / await
C# 5 will come with support for asynchronous method calls, but this allows you to write code as if the call were synchronous. If a method executed in the UI thread synchronously accesses a file, such as one stored on SkyDrive, it blocks the entire application. Executing the method in another thread is wrong, because the thread is just waiting most of its time anyway and allocates resources unnecessarily. A deterrent case is, for example, the dialog for opening a file, which uses 12 threads for this purpose.
Don Syme once over the weekend extended F# with the option to interrupt the execution of a command and return to it in another thread only when the result is known. Therefore, the call does not block the thread and it is not necessary to divide one method into two because of it. This functionality was later implemented into C# by a team of about thirty people. WinRT is adapted to this API approach. So if the file opening dialog was programmed on WinRT today, it would not be a problem to perform everything in the UI thread without any delayed response.