CLR, Win32, WinRT in Windows architecture
.net, architecture, clr, winapi, windows-runtime
Solution
I'll assume this question is about WinRT, it is otherwise entirely too vague to answer.
The diagram at the bottom is very misleading. It shows the point of view from what you need to know as a programmer. And if you create a WinRT app then the olden winapi is not something you ever deal with directly. It was replaced by the WinRT api and you are only supposed to use it to obtain operating system services.
The implementation is very different. The CLR still very much runs on top of the winapi, just like it does in a desktop app. And it interoperates with unmanaged code, Windows is fundamentally an unmanaged operating system. Also the case for WinRT, it is an unmanaged api that's based on COM.
Every WinRT app is in reality an out-of-process COM server, much like such servers were used 30 years ago. It does run in a special mode, Microsoft added an extra layer to the plumbing that makes UAC work. It is called the "app container", it works like a sandbox. Just like UAC prevents a program from accessing certain directories or registry keys if the user didn't get elevated by a UAC prompt, the app container prevents a program from using winapi functions that are troublesome. The kind that creates usability or security problems or drain a battery too fast. WinRT has replacements for such winapi functions.
COM is a bit notorious, it is the universal interop solution used by Microsoft but it is not particularly easy to program. Microsoft did a lot of work to make COM more usable, mostly by completely hiding it. Notable are that type libraries were replaced with .winmd files, a much enhanced version that can express a lot more details. They used the data format for .NET metadata.
And a pivotal way they hid COM is the language projection built into various runtime support libraries. For C++ it is hidden in the C++/CX language extensions and the runtime library. For Javascript it is hidden inside the Chakra execution engine. And for managed code it is hidden inside the .NET framework with [TypeForwardedTo] in the reference assemblies. The language projection translates from WinRT types and behavior to types specific to the language. Basic stuff, like a COM error code gets translated to an exception. And the WinRT HSTRING type gets translated to System.String. Etcetera.
There are a few places where the language projection peeks through the cracks, visible in oddly seeming restrictions. Like a WinRT component must always be a sealed class, a side effect of COM not supporting implementation inheritance. Or you can expose a DateTimeOffset in a component but not a DateTime. And some WinRT types don't map well to .NET types, IBuffer is notorious.
Problem
I have browsed around and found similar questions to which all responses have been unclear and blurry at best and it annoys me to not have a clear picture of the Windows architecture. There are layers in Windows which in my head has always looked something like this (from top to bottom): [.NET] [Win32] [Microkernel] [HAL] [Hardware] Recently I have seen images like this: I am confused, especially about the fact that it seems that CLR is running in parallell with WinAPI. I guess my question is this: UPDATE Q: Where can I find clear and explanatory resources that describe the OS architecture in recent versions of Windows (7,8, Server 2012 etc)?