A bad picture is worth a thousand long discussions.
While here at Build I’ve been in lots of conversations with customers, other attendees, Microsoft MVP’s, Microsoft Regional Directors, and Microsoft engineering team members. One of the recurring topics that I’ve been talking about ad nausium is the “boxology” diagram of the Windows 8 Platform and Tools (shown here).
Now let me tell you, I have drawn a lot of these “marketecture” diagrams in my time and its not easy. These kind of diagrams are never technically accurate. There is simply no easily digestible way to make a technically accurate diagram for a complex system that renders well on a slide and is easy to present and explain. The end result is that you create a diagram that is missing a lot of boxes – missing a lot of the actual technology that is present in the system. Unfortunately that is exactly what has happened here – the Windows 8 boxology is missing some of the actual technology that is present.
One of the conversations that has come up is around the missing box in the “green side” (aka Metro style apps) for the .NET Framework and the CLR. Do VB and C# in Metro style apps compile and run directly against the WinRT? Is this the end of the .NET Framework?
Others who have done some digging into the bits are wondering if there are two CLRs. What the heck is going on in Windows 8?
I spent some time with key members of the .NET CLR team last night (no names, but trust me when I say, these guys know exactly how the system works), and here’s the skinny.
Basic Facts:
- There is only one CLR. Each application or application pool (depending on the app type) spins up a process and the CLR is used within that process. Meaning, a Metro style app and a Desktop Mode app running at the same time are using the same CLR bits, but separate instances of the CLR.
- The .NET Framework 4.5 is used in both Desktop Mode apps and in Metro style apps. There is a difference though. Metro style apps use what is best described as a different .NET Profile (e.g. Desktop apps use the .NET Client Profile and Metro style apps use the .NET Metro Profile). There is NOT actually a different profile, but the implementation of .NET in Metro style apps is LIKE a different profile. Don’t go looking for this profile – its basically rules built into the .NET Framework and CLR that define what parts of the framework are available.
- Whether a Desktop Mode app or a Metro style app, if it is a .NET app, it is compiled to the same MSIL. There isn’t a special Windows 8 Metro IL – there is, like the CLR, only one MSIL.
A More Accurate Picture
A more correct (but still marketecture that is not wholly technically accurate) would look like this:
In this diagram you can see that the CLR and the .NET Framework 4.5 are used for C# and Visual Basic apps in either Desktop Mode apps (blue side) or Metro style apps (green side). Silverlight is still only available in Desktop Mode as a plug-in to Internet Explorer (yes, out of browser is still supported in Desktop Mode). Another addition in this diagram is DirectX, which was strangely absent from the original diagram. DirectX is the defacto technology for high-polygon count applications, such as immersive games. DirectX leverages the power of C++ and can access the GPU.
This biggest confusion, as I mentioned, has been around the use of the .NET Framework across the blue side and green side. The reason for the, as I call it, .NET Metro Profile is because the Metro style apps run in an app container that limits what the application can have access to in order to protect the end user from potentially malicious apps. As such, the Metro Profile is a subset of the .NET Client Profile and simply takes away some of the capabilities that aren’t allowed by the app container for Metro style apps. Developers used to .NET will find accessing the WinRT APIs very intuitive – it works similarly to having an assembly reference and accessing the members of said referenced assembly.
Additionally, some of the changes in the Metro Profile are to ensure Metro style apps are constructed in the preferred way for touch-first design and portable form factors. An example is File.Create(). Historically if you were using .NET to create a new file you would use File.Create(string fileLocation) to create the new file on the disk, then access a stream reader to create the contents of the file as a string. This is a synchronous operation – you make the call and the process stalls while you wait for the return. The idea of modern, Metro style apps is that ansychronous programming practices should be used to cut down on things like IO latency, such as that created by file system operations. What this means is that the .NET Metro Profile doesn’t provide access to FileCreate() as a synchronous operation. Instead, you can still call File.Create() (or File.CreateNew()…I can’t recall right now) as an asynchronous operation. Once the callback is made you can still open a stream reader and work with the file contents as a string, just like you would have.
Ultimately all of this means that you have some choice, but you don’t have to sacrifice much if anything along the way. You can still build .NET and Silverlight apps the way you are used to, and they will run on Windows for years to come. If you want to build a new Metro style app, you have four options to choose from:
- XAML and .NET (C# or VB)You don’t have to giving up too much in the .NET Framework (remember, you only give up what is forbidden by the Application Container), and you get access to WinRT APIs for sensor input and other system resources.
- XAML and C++You can use your skills in XAML and C++ in order to leverage (or even extend) WinRT. Of course you don’t get the benefit of the .NET Framework, but hey….some people like managing their own garbage collection.
- HTML and JavaScriptYou can leverage the skills you have in UI layout, and make calls from JavaScript to WinRT for access to system resources, and sensor input.
- DirectX and C++If you’re building an immersive game you can use DirectX and access the device sensors and system resources through C++ and WinRT.
Hopefully this adds some clarity to the otherwise only slightly murky picture that is the Windows 8 boxology.
Don’t forget to check out Telerik.com/build.
D7
Comments
Thanks for this update. It clears things up quite a bit.
I wonder if managed C++ is supported. I would think so — so C++ programmers can have garbage collection after all
.
Great post – thxs for the explanation! Was really worried for a while there. This is why I love Telerik even more
On your green side I think you need a box called “Chakra”, the JavaScript engine that handles the calls to WinRT for JS, just like the CLR does for .NET languages. I think C/C++ is the only “direct”way to get to WinRT.
Any word on what is planned for Windows Phone 8?
Great deep-dive into the Windows 8 bits … good to know !
Since all the stuff look quite great for what’s in Win 8 … I’m mostly concerned on several things:
(1) How the HTML5/JavaScript Metro apps will be packaged and protected (just obfuscation will not be enough to avoid reversing)
(2) How I can reuse/create libraries/components (since DLL’s/ActiveX are not permitted under Metro)
I also put these questions on SO so hopefully some answers will popup but please “move your antennas” and get some straight details from the source.
stackoverflow.com/questions/7442844/how-winrt-metro-style-html5-javascript-applications-are-packaged-and-protected , stackoverflow.com/questions/7443482/how-to-share-windows-8-winrt-metro-style-libaries-components
Thanks for this article, great set of clarifications. I do still see a small ambiguity with whether there is one CLR or two. You both write
Meaning, a Metro style app and a Desktop Mode app running at the same time are using the same CLR bits
There is NOT actually a different profile, but the implementation of .NET in Metro style apps is LIKE a different profile
The second sentence would make me think that there is a specific implementation of the CLR for Metro, whereas the first sentence mentions unique CLR bits.
So is that a single CLR which knows dynamically what to expose depending on whether the running environment is Metro or Desktop?
Its a single CLR, but Metro uses a subset of the .NET Framework 4.5.
D7
in the right blue desktop section , should not win32 be under both IE and CLR ? i think it is since .net is a wrapper around win32
True. Nearly all of Windows still uses Win32 in some way. This is not a detailed technical diagram, but rather it is intended to show you how Windows 8 apps work – e.g. HTML and Silverlight apps run within IE (or the IE engine for out-of-browser Silverlight). Sure IE has downstream dependencies, but they are not represented here.
D7
Thanks Bassam. That was what I had in mind too.
There’s another confusion here. What happens if Win32 is under CLR in general?
I mean in a MetroStyle app, is it under CLR too or CLR in MetroStyle uses only WinRT? Does WinRT use Win32?
I think They should show an accurate diagram.
“it’s only to show how Windows 8 apps works”
And it only doesn’t show that. I don’t think this is a right excuse because the diagram is not inaccurate, it’s wrong.
Another confusion in the diagram is about the win32, i keep learning winRT is a replacement to win32 and this may be technically incorrect.
WinRT doesn’t define a new “Environment subsystem” on top of the kernel layer but is running as part of the Win32 subsystem (you can see that running a native Metro app still load win32 dlls like kernel32)
So while winRT doesn’t use the “legacy” win32 windowing system (this is to verify) it’s still technically a win32 applications
There is some confusion here about .NET languages (C#, VB) which can be used to build Metro applications and the .NET framework. Metro apps do not use .NET, they have adapted few classes from .NET – you can see the new classes in the Windows.Xaml.UI namespace in WinRT. But it still doesn’t mean that it is using .NET.
You can use XAML with “code behind” in C# or VB and reference and use the WinRT classes. There is a good example of building a Feed Reader app with XAML and .NET in the getting started docs.
D7
Hi Doug,
Thanks for the great info.
My main problem is not the way Win 8 is architected, it’s with the public trashing of Silverlight by Microsoft managers on their blogs.
There is obviously a perception that Microsoft is deprecating Silverlight and Microsoft is doing zero to counter it which makes new Silverlight projects extremely difficult to get approved.
David Roh
¡Hola!
Nombre muy interesante por el freedirectorybg.net foro
Que cometer un error.
La posesión de un poder ilimitado hará un déspota de casi cualquier hombre.
Comprar -comprar !
This post was great and you have talked about details I was discussing with some colleagues last week, trying to figure things out, like the absence of CLR on Metro side of the chart, in order to support C# and VB (back end development). I would like to ask you about Silverlight, though. Besides it still will be out there, Silverlight is History? One can still use C# and .Net on the server side, but we should consider start using HTML5/CSS/Javascript on the client side, right now?
You are still missing lots of stuff in your slide.
With your argument, ASPX and MVC should be death too.
And you are saying also that Silverlight is only available as a plugin for IE; but there are other platforms too.
Finaly, THERE IS a profile for MetroStyle Apps and it is called: “Windows Tailored
Yes, this is a “marketecture” diagram, so lots of bits are missing, and some of the representation is not 100% technically accurate. The concepts are right though.
In WIndows 8, Silverlight is an IE plug-in in Desktop mode (which also enables out-of-browser SL apps). There is no Silverlight in Metro style apps.
The SIlverlight plug-ins for other platfomrs will be available with SL5 as far as I know. Uncertain of the future past that.
D7
Detailed picture must be futher corrected. On the desktop side, IE and CLR rely on Win32.