

Discover more from Bitesized Engineering
Hi!
Last time I opened up a story on Managed and Unmanaged code and I mentioned that I believed it was a nice intro before jumping into Stacks and Heaps. I also mentioned that along the way I realized that what I thought was “Managed Code” was not in check with what it really was. This article is supposed to be the ultimate explanation and clarification on WHAT it really is.
If you are a newcomer, this article is a continuation of my Deep-dive into CLR (i.e. .NET’s runtime) series. If you haven’t read any of the past articles - I’d recommend you start from the beginning.
As per usual, we go with infographic first and then we’ll discuss the inner details afterwards:
Okay, cool. I hope you found that useful :)
Here’s the deal - as I mentioned in previous article - I was under impression that “Managed Code” and “Managed Languages” refer to languages that have Garbage Collection. Then I learned it’s more than that - it refers to languages that have a “manager” that manages the stuff for you. But WHAT kind of stuff? And WHO is this manager? Too many questions started popping up to the point that I thought about giving up this whole idea altogether and skipping right to memory management itself.
Thankfully, I persisted. And I eventually learned that the term “Managed Code” got coined by Microsoft. And not just that, but I eventually started putting together the whole puzzle with Common Language Infrastructure (CLI), Common Intermediate Language (CIL), Common Language Runtime (CLR), Common Language Specification (CLS), Virtual Execution System (VES), etc. I won’t bother you much with it as there will be a separate dedicated article that will cover all of these. But I’ll just give you the essence that might be useful for the topic.
“Managed Code” refers to the code that compiles to something called “Intermediate Language”, which is just a fancy way of saying “a code that is not native machine code”. That’s what Intermediate Language is - a middle-man. And it’s officially called Common Intermediate Language (CIL; not to be confused with CLI).
To give you an example - C# code compiles to Intermediate Language. So does VB.NET. So does a version of C++ that is usually called C++/CLI or Managed C++. And I wrote a lot about Intermediate Language in previous articles, so do make sure to check them out if you’ve never seen how it looks like.
But how does the code move from Intermediate Language to Native CPU instructions? This is yet another thing defined by Common Language Infrastructure - runtime engine. CLI defines a thing called Virtual Execution System (VES) which describes how you go from Intermediate Language to Native architecture where your program is executing. And this is where it becomes funny - CLR (Common Language Runtime) is JUST ONE of the concrete implementations of VES. But there are others as well! There’s Mono, there’s .net nanoFramework, and I guess there are others as well. But CLR is rather popular one because it’s what usually executes your .NET code :)
So let’s try and answer the “What is Managed Code?” question again - Managed Code is any code that conforms to Common Language Infrastructure standard and that compiles to Intermediate Language. After that, the runtime engine (e.g. CLR) takes over and ensures that your code converts into actual CPU instructions, which is a process known as JIT Compilation (Just-in-Time Compilation). But more about that in future!
By now I’m sure that you’ve figured that calling Java, or any other languge a “Managed one” is wrong? Unless you have a compiler that turns Java into Common Intermediate Language, then it’s not “Managed”. Simple as that, I guess? :)
And that pretty much concludes today’s story. I’m going to dedicate a separate article to the whole “CLI, CIL, CLR, CTS, CLS, VES, etc.” chaos, but until then, I hope this thing here gives you a bit of clarity :) Until then, if you haven’t subscribed already, now’s probably a good time to do so:
I’d also appreciate if you share this article with your network:
Thanks for reading!
Other articles from the CLR series: