A blog by Doug Seven, Executive Vice President at Telerik. (Original post here)
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.
- 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
- 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
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
- 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
You can leverage the skills you have in UI layout, and make calls
- 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.