I’ve been reading a few interesting CLR related articles over the past few weeks.
The Windows 8 FAQ is a plausible set of answers to a set of questions around the history of Silverlight/Wpf and the forthcoming Windows RT, mainly concerned with the internal Microsoft power struggle between the two Microsoft divisions responsible for the implementation. One of the points of view (which I don’t agree with) is covered in a post on the code4k blog in the post Future of Winrt which argues about the inefficiency of managed code and how the CLR should be a lot closer to unmanaged code (for example, allowing replaceable memory management libraries to be included). It will be interesting to see where the CLR moves in the next few years.
The CLR implementation is still moving forwards though. There’s a good blog post, Evolving the Reflection API, that covers the re-architecting of the Reflection APIs, breaking type information into the Type and TypeInfo classes, which will allow a program to reflect on an assembly and its types without actually loading it. The trick is to have different representations of type references and type declarations. As in the Reflector API, the former don’t require the type itself to be loaded.
I also recently came across some Channel9 videos covering PerfView, a tool which assists with taking an ETW trace and then helps with decoding the contents. More and more of the operating system and other layered applications (like the CLR) can now provide ETW information which can be logged (in a high performance manner) and used later for analysis of performance or errors.