What are the difficulties of writing core os components in managed code?

Question

I know that some of the Microsoft employees are members of StackOverflow like the famous Raymond Chen to Larry Osterman (enginner of the Vista's audio stack and per-application sound controlling mechanism) and we know Jeff Atwood is here too. So maybe we can learn some lessons about managed code in core Windows componenets straight from the horse's mouth.

I have downloaded all leaked Windows Longhorn builds (from the "obvious" sources) and poked around to find managed code with tools like "dotPeek" and ".net OR not". I found that managed code was declining in every build after the august 2004 "longhorn reset". But i even find "windows movie maker" written in managed code.

So, here is the question: What are the diffuculties of writing core os components in managed code?

Answer 1

I'm sure there's other considerations, but this is a reasonably obvious one that springs to mind:

Managed code components require a specific version of the managed runtime, and, IIRC, a process can have only one instance of the managed runtime in it. Right off the bat, this rules out using managed code for shared components - since an app and one or more of its components could require different versions of the runtime, and limits its use to application-style components.

Also keep in mind that more parts of Windows are actually 'shared components' than might be immediately obvious. While you might think of Explorer as a form of application, as soon as an app opens a File/Open common dialog, it's now got a bunch of Explorer components within it, listing the available files and directories.