Managed vs Un-Managed Code

I recently had a customer who was interested in the development environment and platform used for the development of the solution I was presenting. The question was simply this: Is thus product developed in managed or un-managed code (sometimes referred to as native code). At the time, I had to park the question with a commitment to come back to the customer at a later date. I didn’t really know the difference between the two, more importantly, I didn’t understand the motivation behind the question.

To understand the differences, I decided to take a cursory look at Microsoft’s C# language(an example of managed code, pronounced C Sharp) and also revised some of my old C++ (example of unmanaged/native- mostly) books. Using Visual Studio from Microsoft it’s possible to create applications in both languages. To see C# in action, I created a small app to read and manipulate some local windows registry settings.

To summarize, managed code (like C# and Java) is generally executed through some kind of management framework and not directly on the operating system. This may be a Java Virtual Machine or the CLR (Command Line Runtime in the Microsoft .net environment).  The framework provides a protective shell which will manage memory and other hardware resources, so the code never has to deal with accessing those resources directly.  This makes it much more difficult for the application code to perform an action which will compromise the system.  It also makes the code portable.  The code will run anywhere where the framework can run.  To achieve this the source code is sort of, partially, complied into an intermediate langauge that can be understood by  and fully compiled by the framework at run-time. This is referred to JIT compiling (Just-In-Time)

Un-managed code runs directly on the OS.  It can manage memory and other hardware directly. It is compiled for the specific processor on which it runs. Bypassing the aforementioned frameworks and working directly with the operating system gives a major boost in power and performance. The same can not be achieved with managed code, but this also sacrifices portability.

This really gives us a clear distinction between the two one representing performance and the other portability. Their are other issues to consider such as the ease of development. Managed code is often easier to learn, produce and understand. From a customer’s perspective they are probably less concerned about how easy something was to produce and more concerned that it performs it’s function correctly.

So, in summary, if a customer asks this question it is likely that they have some requirement regarding either performance or portability.  In high-performance mission critical applications they are likely to have an expectation that the code will be un-managed. In a disparate, multi-platform environment, portability may be there hot spot.

If you would like to learn more about C#, I’d recommend the following book: Rob Miles’ C# Yellow Book – It gives an excellent overview.

If you believe, like many, that using c# managed code ties you to the windows platform you should check out the Mono VES project, an open source project promoting cross-platform .net development capability.

A Brief History of Programming – Assembly to Framework

Development of the technologies, functionality, features and value proposition is fundamental to the sucess of any product within the InfoTech market place.  Although Pre-Sales rarely delve deeper than the occasional script, it’s worth having an understanding of what’s going on under the bonnet of your products and solutions.

In this blog we’ll chronologically examine a brief history of the development of programming.  I’ll be writing this with-out reems of reference books around the desk, so please take the dates, claims and details as generally correct (this blog is not written to be used as a reference).  There are hundreds of different languages out there, most of which aren’t covered here. It’s purpose is to give you a general idea of how your developers are creating the functionality that you are ultimately trying to sell.

Before we start, I’ll pay quick homage to Charles Babbage. He’s pretty much the Grandfather of modern computing and you can read about him by clicking his name above.

Ok, Let’s start.

I’m going to start with Binary.. yes, binary.  I remember when I was around 10 years old. I bought a computer game magazine which had in bold letters on the cover.. “Write your own game!”. After asking my dear old Mum to buy the mag. I started reading and realized that the mechanism for writing the game was to literally write the binary 0’s and 1’s into a text file which would later be run as the game.  After several hours of type 1010110110101001010010010110101, my long suffering Mother stepped in with her superior typing skills and finished the job.  Unfortunately, it didn’t work.  Somewhere amongst those 1000’s of 0’s and 1’s there was a mistake.  Were we going to go back and check each one?  I think not. This was my first ever failed attempt at coding.  You’ll see as we continue that the development of code has somewhat improved since then.


Assembly was one of the first primitive languages to be created to allow developers to create code.  Continue reading