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:

  1. 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.
  2. 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.
  3. 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.
  4. 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

About these ads

Comments

  1. 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 :-).

  2. Great post – thxs for the explanation! Was really worried for a while there. This is why I love Telerik even more :)

  3. 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.

  4. Any word on what is planned for Windows Phone 8?

  5. 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.

    http://stackoverflow.com/questions/7442844/how-winrt-metro-style-html5-javascript-applications-are-packaged-and-protected , http://stackoverflow.com/questions/7443482/how-to-share-windows-8-winrt-metro-style-libaries-components

  6. 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?

  7. 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.

  8. 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

  9. 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

  10. 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

  11. macalmecemow says:

    ¡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 !

  12. Marcos Silva says:

    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?

  13. warnov@gmail.com says:

    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

  14. Detailed picture must be futher corrected. On the desktop side, IE and CLR rely on Win32.

    • True. Nearly everything still has some dependence on Win32. This slide is far from completely technically accurate, but it does show the basics of how WIndows 8 is architected.

      D7

  15. And lets not forget: we can even build hybrid C#/VB and Javascript Apps as Anders Hejlsberg is showing in his great demo http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-816T#
    Now, anyone wants to create a simple slide that will also include that capability :-) ?

  16. I didn’t see and still can’t see any reference to XNA in either slides? Is it because of the “marketecture” nature of the two slides or does this mean I can’t use XNA (C#) to develop a game or port my existing Windows Phone game to Windows 8?
    I’m sure XNA is still supported in Desktop mode, but what about Metro mode, especially if we put into consideration that Windows on ARM won’t support Desktop application?

    • I haven’t done a full investigation, but I don’t believe XNA is supported in Desktop mode, and I know it is not supported in Metro style apps.

      D7

  17. Hi Doug7,
    Thanks for the great article.

  18. Joseph Ficara says:

    Hi Doug,

    I am in the process of writing a course that I am teaching in the spring of 2013. Could I use your architecture diagram in my course material? I will of course provide attribution and links back this blog entry as the origin of the diagram.

    Best,

    Joe

Trackbacks

  1. [...] Style Apps without any reference to the CLR… Doug Steven did a pretty great job (blog post is here) by discussing with key people from the engineering team of Microsoft and creates this new more [...]

  2. [...] Seven adds a couple of new elements to his rendition of the Windows 8 architecture slide. First, notice the appearance of DirectX — something I’ve had a few folks ask me about [...]

  3. [...] former Microsoft exec and now Telerik Executive VP Doug Seven):(click on slide to enlarge)Doug Seven adds a couple of new elements to his rendition of the Windows 8 architecture slide. First, notice the appearance of DirectX — something I’ve had a few folks ask me about (as in, [...]

  4. [...] A bad picture is worth a thousand long discussions – Doug Seven discusses the difficulty in creating a good marketing info graphic, exploring the Windows 8 Platform and Tools slide, sharing some details from discussions with members of the .NET Team and re-drawing the diagram to better reflect the intended reality. [...]

  5. [...] Apparently I’m not the only one who found issues here, Doug Seven, an EVP at telerik also took issue with the developer aspects of the stack as [...]

  6. [...] on my C++?  The answers to these and many more questions remain unanswered but the following article by Doug Seven goes a long way to helping me push past the marketing hype.  His article is worth a read if [...]

  7. [...] one from Doug Seven (former Microsoft employee) who clarified the original diagram last week.  Read his post on why the original diagram was so [...]

  8. [...] Seven adds a couple of new elements to his rendition of the Windows 8 architecture slide. First, notice the appearance of DirectX — something I’ve had a few folks ask me about (as in, [...]

  9. [...] A bad picture is worth a thousand long discussions. Doug Seven éclaircit un peu la “séparation” entre les applications Metro et Desktop pour nous développeurs .NET. [...]

  10. [...] A bad picture is worth a thousand long discussions – Doug Seven discusses the difficulty in creating a good marketing info graphic, exploring the Windows 8 Platform and Tools slide, sharing some details from discussions with members of the .NET Team and re-drawing the diagram to better reflect the intended reality. [...]

  11. [...] Doug Seven’s blog post about a more accurate [...]

  12. מאחורי הקלעים של חלונות 8 – WinRT וטכנולוגיות הפיתוח החדשות…

    פוסט זה הוא חלק מסדרת הפוסטים “תכנות לחלונות 8 בHTML5”. הרבה דובר על ממשק המשתמש החדש של חלונות 8 – מטרו…

  13. [...] במהלך הרצאת המליאה הראשית בכנס בילד, וזכתה כמעט מיד לביקורת על היותה לא מדויקת. מהדיאגרמה לא ברור האם ה-CLR עדיין כאן. DirectX נעלם לגמרי [...]

  14. Windows 8 XAML Metro Apps with OData – Part 1…

    So, you have heard the buzz about the brave new world of Windows 8 from MSFT’s BUILD Conference…

  15. [...] a disconnect, the official diagram didn’t seem to tell the story in the accurate way.  Others felt the same way and posted "improved" [...]

  16. [...] I felt a disconnect, the official diagram didn’t seem to tell the story in the accurate way.  Others felt the same way and posted “improved” [...]

  17. [...] For the record as we all know now, .NET is of course still there. Telerik’s Doug Seven released a more accurate diagram of the Windows 8 architecture that you should check out here if you’re still a bit fuzzy on this [...]

  18. [...] have been using the architecture images Microsoft releases at Build 2011 & that awesome one Doug Seven created. However I have still found a lot of discussion exists even with those and they are showing their [...]

  19. How to call WinRT APIs in Windows 8 from C# Desktop Applications – WinRT Diagram…

  20. [...] le billet Doug Seven’s blog post pour une image plus [...]

  21. [...] Why? Because the HTML/JavaScript is compiled through the CLR just like XAML/etc. This is important because it means you get the comfort of picking a language and it is treated [...]

  22. […] WinRT & .NET – How a bad picture is worth a thousand long discussions – Doug Seven […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: