CLR, Win32, WinRT in Windows architecture

Question

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)?

Answer 1

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.

Answer 2

WinRT is primarily a set of APIs to build Metro apps for all Metro-supported platforms (including for Windows 8 for ARM). The Windows Runtime provides a large set of new APIs to Windows Experience developers.

From http://arstechnica.com/features/2012/10/windows-8-and-winrt-everything-old-is-new-again/5/:

The WinRT name stands for "Windows Runtime." However, this isn't a runtime in the same way that Microsoft's .NET Runtime was a runtime, or the way Oracle's Java Runtime Environment is a runtime. In the .NET and Java cases, the runtime is a relatively large software component that provides a virtual machine environment, garbage-collected memory, various kinds of code safety verification, and more. The .NET and Java runtimes are intimately involved in virtually everything a .NET or Java program does, providing extensive infrastructure to software developers.

WinRT offers nothing quite like those runtimes. WinRT is a set of software libraries that provides an API offering a range of services—graphics, networking, storage, printing. In addition to this, there is a relatively small infrastructural component.

When you develop a metro style app, the .NET Framework and the Common Language Runtime (CLR) are integrated with the WinRT. The CLR 4.5, which ships as part of the Microsoft .NET Framework 4.5 in Windows 8, enables developers writing managed code to use the Windows Runtime APIs in a natural way (http://msdn.microsoft.com/en-us/library/hh694558.aspx). WinRT is not available in Windows 7 or previous version of windows.

There is an awesome article at http://arstechnica.com/features/2012/10/windows-8-and-winrt-everything-old-is-new-again/ ....in 7 parts it describes in deep with history from COM > .NET > WinRT. To jump into WinRT look into 5th part of it.

Hope it will clarify your doubts. Please let me know in case of further questions.