I have a strong C++ background and never really had a deep understanding of Java or C#. However, I am curious about the internal workings of the virtual machines. I've experimented with some windows exes and figured out that the actual virtual machines are the jvm and the clr dynamic libraries.
Now here is what bothers me: How do these libraries interact with the instructions in an exe file?
My only guess is that the bytecode is actually stored in the .data segment of the exe file. And it actually passes control to the .dll, which translates the bytecode instructions. Is that correct?
I was unable to find anything about the subject so any reference will be appreciated.
Your guess about where the IL is stored is addressed here:
http://en.wikipedia.org/wiki/Portable_Executable#.NET.2C_metadata.2C_and_the_PE_format
Your conjecture is basically correct for C#. The executable starts up the CLR and hands off the metadata and IL; the CLR then figures out where "Main" is, grabs the IL for that, jit-compiles it into x86 (or whatever) code, and runs that. Each method is compiled "just in time" before it runs for the first time, hence the term "jit compiler".
That is of course a greatly simplified overview. If you want more information about how .NET works, start with:
http://msdn.microsoft.com/en-us/library/a4t23ktk.aspx
Well, at the most basic level you got that right: There is a native application (the runtime, such as java.exe) that reads the bytecode and "runs" it by interpreting the instructions contained within.
The first adjustment you have to make to that picture is that for performance reasons, most VM now use JIT-compilation, which means that the bytecode is not interpreted, but compiled into native code on the fly.
My only guess is that the bytecode is actually stored in the .data segment of the exe file.
Depends. For Java, you usually just have a JAR file with the bytecode, separated from the native binary that gets launched. But, yes, you could combine that together into a single executable, that would then contain the native launcher code (but probably not all the shared libraries that depends on), and the bytecode "as data".
For instance Eclipse runs on JVM right? And still you launch it through an exe.
Yes. Eclipse has one of these "launch wrapper exe". But if you look at that, it is very small. All it does is put up a splash screen and launch the JVM (installed on your system, not part of the exe), and throws some JAR files at it (installed as part of Eclipse, but not inside the exe either).
Related
I hope that question would not mess with StackOverFlow FAQ rules
So ,when using Libraries which are written in C++ for example ,and that means we have some Code in these DLL's which is going to be executed ,when Software execution cames in that case ,will this Portion of code be executed by CLR ?
I need that because we plan to develop a Software and some Angry Algorithms i think will be better to program them in C++ ,but Visual C# serves us some tools that we cant find in c++ (Linq ,Anonymous etc) .
You can use DLLs created in C++ inside your C# project, and as you already know you have to make an interop call. This switches context to unsafe, so the code is probably executed outside the CLR. This means that you lose the portability options the CLR gives you. For example a C# based app would run on Windows and Windows Phone, but adding interop calls will only make it work on Windows (or whatever system the DLL was compiled for).
But normally this isn't much of an issue.
Also see this thread: http://forums.devshed.com/net-development-87/using-a-c-dll-in-c-107829.html
I have a WCF service accepting requests from our clients.
After analyzing the request I need to generate (compile + link) C++ EXE.
What is the best method to create an C++ EXE from a C# application???
10x
I can only guess what it is you want, but I assume your requirements are something like:
You run a WCF service on a server somewhere.
Upon receiving a certain call, the service must output a (binary) executable, based on the parameters it receives.
C++ should be used as the intermediate language.
Let's look at what you need. The obvious first requirement is a C++ compiler/linker that can be invoked programmatically. On Unix systems, that would be g++, and you can simply shell-out to invoke it; on Windows, g++ is also available (under the name MinGW), but the version is pretty outdated, so you might be better off using Microsoft's command-line C++ compiler.
Obviously, you'll also need to generate C++ source code somewhere; I assume most of the source code is more or less the same for each request, so you probably need some sort of templating system. If it's not too complicated, this can be as simple as running a regex search-and-replace over a bunch of template files; otherwise, you need a proper templating language (XSLT is built into .NET, although the syntax takes some getting used to).
And then the glue to make it work together; I suggest something like this:
Read request and create a suitable data structure (in a format that your template engine can consume)
Pass the data to the template engine, writing the output files to a temporary folder
Invoke the compiler on the temporary location
Read the executable back in, send it to the client
Delete the temporary folder
Since compiling is often a costly operation, consider caching the generated executables (unless they are practically guaranteed to be different every time).
By the way, there is one big caveat: If the client platform is not binary-compatible with the server platform (e.g., the server is running on x64 but the client is x86), the generated executable might not work.
And another one, which is security: By hacking the server, or tricking clients into sending "wrong" requests, an attacker can potentially malicious code through the generated executable; if this application is all but super-trivial, I imagine it's going to be pretty hard to properly secure this thing.
An executable is an executable, and is defined by the abiltity to be executed.
Whatever programming language was, once upon a time, used to write the source code that was fed to a compiler which produced the executable, that no longer matters. An executable looks the same regardless of which language (or languages) you used. (A .NET executable is just an executable with some fairly complex DLL dependencies)
So there is no such thing as a "C++ executable". Perhaps you mean an executable that doesn't depend on the .NET framework?
Or do you simply mean that you have a C++ application that needs to use a WCF service?
Or that you want to rewrite your C# code as C++?
Do you mean you want to compile c# to native machine code? in which case ngen may be some use
http://msdn.microsoft.com/en-us/library/6t9t5wcf%28v=vs.80%29.aspx
I'm always referencing DLLs in my C# code, but they have remained somewhat of a mystery which I would like to clarify. This is a sort of brain dump of questions regarding DLLs.
I understand a DLL is a dynamically linked library which means that another program can access this library at run time to get "functionality". However, consider the following ASP.NET project with Web.dll and Business.dll (Web.dll is the front end functionality and it references Business.dll for types and methods).
At what point does Web.dll dynamically link to Business.dll? You notice a lot in Windows HDD thrashing for seemingly small tasks when using Word (etc.) and I reckon that Word is going off and dynamically linking in functionality from other DLLs?
1a. Additionally, what loads and links the DLL - the OS or some run time framework such as the .NET framework?
1b. What is the process of "linking"? Are compatibility checks made? Loading into the same memory? What does linking actually mean?
What actually executes the code in the DLL? Does it get executed by the processor or is there another stage of translation or compilation before the processor will understand the code inside the DLL?
2a. In the case of a DLL built in C# .NET, what is running this: the .NET framework or the operating system directly?
Does a DLL from Linux work on a Windows system (if such a thing exists), or are they operating system specific?
Are DLLs specific to a particular framework? Can a DLL built using C# .NET be used by a DLL built with, for example, Borland C++?
4a. If the answer to 4 is "no" then what is the point of a DLL? Why dont the various frameworks use their own formats for linked files? For example: an .exe built in .NET knows that a file type of .abc is something that it can link into its code.
Going back to the Web.dll / Business.dll example - to get a class type of customer I need to reference Business.dll from Web.dll. This must mean that Business.dll contains some sort of a specification as to what a customer class actually is. If I had compiled my Business.dll file in, say, Delphi: would C# understand it and be able to create a customer class, or is there some sort of header info or something that says "hey sorry you can only use me from another Delphi DLL"?
5a. Same applies for methods; can I write a CreateInvoice() method in a DLL, compile it in C++, and then access and run it from C#? What stops or allows me from doing this?
On the subject of DLL hijacking, surely the replacement (bad) DLL must contain the exact method signatures and types as the one that is being hijacked. I suppose this wouldn't be hard to do if you could find out what methods were available in the original DLL.
6a. What in my C# program is deciding if I can access another DLL? If my hijacked DLL contained exactly the same methods and types as the original but it was compiled in another language, would it work?
What is DLL importing and DLL registration?
First of all, you need to understand the difference between two very different kinds of DLLs. Microsoft decided to go with the same file extensions (.exe and .dll) with both .NET (managed code) and native code, however managed code DLLs and native DLLs are very different inside.
1) At what point does web.dll dynamically link to business.dll? You
notice a lot in Windows HDD thrashing for seemingly small tasks when
using Word etc and I reckon that this Word going off and dynamically
linking in functionality from other DLL's?
1) In the case of .NET, DLLs are usually loaded on demand when the first method trying to access anything from the DLL is executed. This is why you can get TypeNotFoundExceptions anywhere in your code if a DLL can't be loaded. When something like Word suddenly starts accessing the HDD a lot, it's likely swapping (getting data that has been swapped out to the disk to make room in the RAM)
1a) Additionally what loads and links the DLL - the O/S or some
runtime framework such as the .Net framework?
1a) In the case of managed DLLs, the .NET framework is what loads, JIT compiles (compiles the .NET bytecode into native code) and links the DLLs. In the case of native DLLs it's a component of the operating system that loads and links the DLL (no compilation is necessary because native DLLs already contain native code).
1b) What is the process of "linking"? Are checks made that there is
compatibility? Loading into the same memory? What does linking
actually mean?
1b) Linking is when references (e.g. method calls) in the calling code to symbols (e.g. methods) in the DLL are replaced with the actual addresses of the things in the DLL. This is necessary because the eventual addresses of the things in the DLL cannot be known before it's been loaded into memory.
2) What actually executes the code in the DLL? Does it get executed by
the processor or is there another stage of translation or compilation
before the processor will understand the code inside the DLL?
2) On Windows, .exe files and .dll files are quite identical. Native .exe and .dll files contain native code (the same stuff the processor executes), so there's no need to translate. Managed .exe and .dll files contain .NET bytecode which is first JIT compiled (translated into native code).
2a) In the case of a DLL built from C# .net what is running this? The
.Net framework or the operating system directly?
2a) After the code has been JIT compiled, it's ran in the exact same way as any code.
3) Does a DLL from say Linux work on a Windows system (if such a thing
exists) or are they operating system specific?
3) Managed DLLs might work as-is, as long as the frameworks on both platforms are up to date and whoever wrote the DLL didn't deliberately break compatibility by using native calls. Native DLLs will not works as-in, as the formats are different (even though the machine code inside is the same, if they're both for the same processor platform). By the way, on Linux, "DLLs" are known as .so (shared object) files.
4) Are they specific to a particular framework? Can a DLL built using
C# .Net be used by a DLL built with Borland C++ (example only)?
4) Managed DLLs are particular to the .NET framework, but naturally they work with any compatible language. Native DLLs are compatible as long as everyone uses the same conventions (calling conventions (how function arguments are passed on the machine code level), symbol naming, etc)
5) Going back to the web.dll / business.dll example. To get a class
type of customer I need to reference business.dll from web.dll. This
must mean that business.dll contains a specification of some sort of
what a customer class actually is. If I had compiled my business.dll
file in say Delphi would C# understand it and be able to create a
customer class - or is there some sort of header info or something
that says "hey sorry you can only use me from another delphi dll".
5) Managed DLLs contain a full description of every class, method, field, etc they contain. AFAIK Delphi doesn't support .NET, so it would create native DLLs, which can't be used in .NET straightforwadly. You will probably be able to call functions with PInvoke, but class definitions will not be found. I don't use Delphi so I don't know how it stores type information with DLLs. C++, for example, relies on header (.h) files which contain the type declarations and must be distributed with the DLL.
6) On the subject of DLL hijacking, surely the replacement (bad) DLL
must contain the exact method signatures, types as the one that is
being hijacked. I suppose this wouldnt be hard to do if you could find
out what methods etc were available in the original DLL.
6) Indeed, it's not hard to do if you can easily switch the DLL. Code signing can be used to avoid this. In order for someone to replace a signed DLL, they would have to know the signing key, which it kept secret.
6a) A bit of a repeat question here but this goes back to what in my
C# program is deciding if I can access another DLL? If my hijacked DLL
contained exactly the same methods and types as the original but it
was compiled in another lanugage would it work?
6a) It would work as long as it's a managed DLL, made with any .NET language.
What is DLL importing? and dll registration?
"DLL importing" can mean many things, usually it means referencing a DLL file and using things in it.
DLL registration is something that's done on Windows to globally register DLL files as COM components to make them available to any software on the system.
A .dll file contains compiled code you can use in your application.
Sometimes the tool used to compile the .dll matters, sometimes not. If you can reference the .dll in your project, it doesn't matter which tool was used to code the .dll's exposed functions.
The linking happens at runtime, unlike statically linked libraries, such as your classes, which link at compile-time.
You can think of a .dll as a black box that provides something your application needs that you don't want to write yourself. Yes, someone understanding the .dll's signature could create another .dll file with different code inside it and your calling application couldn't know the difference.
HTH
1) At what point does web.dll dynamically link to business.dll? You
notice a lot in Windows HDD thrashing for seemingly small tasks when
using Word etc and I reckon that this Word going off and dynamically
linking in functionality from other DLL's?
1) I think you are confusing linking with loading. The link is when all the checks and balances are tested to be sure that what is asked for is available. At load time, parts of the dll are loaded into memory or swapped out to the pagefile. This is the HD activity you are seeing.
Dynamic linking is different from static linking in that in static linking, all the object code is put into the main .exe at link time. With dynamic linking, the object code is put into a separate file (the dll) and it is loaded at a different time from the .exe.
Dynamic linking can be implicit (i.e. the app links with a import lib), or explicit (i.e. the app uses LoadLibrary(ex) to load the dll).
In the implicit case, /DELAYLOAD can be used to postpone the loading of the dll until the app actually needs it. Otherwise, at least some parts of it are loaded (mapped into the process address space) as part of the process initilazation. The dll can also request
that it never be unloaded while the process is active.
COM uses LoadLibrary to load COM dlls. Note that even in the implicit case, the system is using something similar to LoadLibrary to load the dll either at process startup or on first use.
2) What actually executes the code in the DLL? Does it get executed by
the processor or is there another stage of translation or compilation
before the processor will understand the code inside the DLL?
2) Dlls contain object code just like .exes. The format of the dll file is almost identical to the format of an exe file. I have heard that there is only one bit that is different in the headers of the two files.
In the case of a DLL built from C# .net, the .Net framework is running it.
3) Does a DLL from say Linux work on a Windows system (if such a thing
exists) or are they operating system specific?
3) DLLs are platform specific.
4) Are they specific to a particular framework? Can a DLL built using
C# .Net be used by a DLL built with Borland C++ (example only)?
4) Dlls can interoperate with other frameworks if special care is taken or some additional glue code is written.
Dlls are very useful when a company sells multiple products that have overlapping capabilities. For instance, I maintain a raster i/o dll that is used by more than 30 different products at the company. If you have multiple products installed, one upgrade of the dll can upgrade all the products to new raster formats.
5) Going back to the web.dll / business.dll example. To get a class
type of customer I need to reference business.dll from web.dll. This
must mean that business.dll contains a specification of some sort of
what a customer class actually is. If I had compiled my business.dll
file in say Delphi would C# understand it and be able to create a
customer class - or is there some sort of header info or something
that says "hey sorry you can only use me from another delphi dll".
5) Depending on the platform, the capabilities of a dll are presented in various ways, thru .h files, .tlb files, or other ways on .net.
6) On the subject of DLL hijacking, surely the replacement (bad) DLL
must contain the exact method signatures, types as the one that is
being hijacked. I suppose this wouldnt be hard to do if you could find
out what methods etc were available in the original DLL.
6) dumpbin /exports and dumbin /imports are interesting tools to use on .exe and .dlls
I was reading about Singularity and it was developed in part with C#, but how can I develop a operatin system in part with C#?(because the boot loader needs to be in Assembly, that I know) the thing that I want to know is where to start(tutorial, library...)?
PS: Congratulations to the Singularity developers, very nice job! ;)
Renraku is an open source project to create an OS using .NET technologies as much as possible. This post has a link to the source on GitHub.
Just because you write your program in c# it doesn't have to be compiled to IL. Writing a c# to machine code compiler can be done and last time I saw an OS written in C# that was exactly what they had done
The major difference between an operating system that runs on managed code vs. one that runs directly on machine code is really nothing more than having a byte-code interpreter at a very low level that processes all byte code sent to it and translates to the corresponding machine code. Once that exists, the various operating system components would be implemented in pretty much the same way as they would in a traditional OS.
I've been writing C / C++ code for almost twenty years, and I know Perl, Python, PHP, and some Java as well, and I'm teaching myself JavaScript. But I've never done any .NET, VB, or C# stuff. What exactly does managed code mean?
Wikipedia describes it simply as
Code that executes under the management of a virtual machine
and it specifically says that Java is (usually) managed code, so
why does the term only seem to apply to C# / .NET?
Can you compile C# into a .exe that contains the VM as well, or do you have to package it up and give it to another .exe (a la java)?
In a similar vein,
is .NET a language or a framework, and what exactly does "framework" mean here?
OK, so that's more than one question, but for someone who's been in the industry as long as I have, I'm feeling rather N00B-ish right now...
When you compile C# code to a .exe, it is compiled to Common Intermediate Language(CIL) bytecode. Whenever you run a CIL executable it is executed on Microsofts Common Language Runtime(CLR) virtual machine. So no, it is not possible to include the VM withing your .NET executable file. You must have the .NET runtime installed on any client machines where your program will be running.
To answer your second question, .NET is a framework, in that it is a set of libraries, compilers and VM that is not language specific. So you can code on the .NET framework in C#, VB, C++ and any other languages which have a .NET compiler.
https://bitbucket.org/brianritchie/wiki/wiki/.NET%20Languages
The above page has a listing of languages which have .NET versions, as well as links to their pages.
I don't think you are alone in being confused about what .Net is. There are already other answers that should have you covered but I'll throw out this tidbit of info for others.
To see what .Net "really" is simply go to c:\Windows\Microsoft.Net\Framework
In there you'll see folders that are specfic to the version(s) you have installed. Go into the v2.0.xxxxx folder if you have it installed for example.
In that folder is the framework. You will basically see a bunch of .exe files and .dll files. All the DLL files that start with System.*.dll is essentially the .Net framework.
The .exe files you'll see in that folder are utilities for developers as well as compilers. You mentioned C#. Find the csc.exe file. That's your C# compiler.
Building a program is really simple. Throw the following code into a hello.cs file.
using System;
class Program
{
static void Main(string[] args)
{
Console.WriteLine("hello world");
}
}
Then on the command line type> csc hello.cs
That will generate you a .exe file. Run it and it will spit out 'hello world' obviously.
The line that says Console.WriteLine() is calling into the Framework. Console is an object that lives within the System namespace and WriteLine() is a static method.
This is the disassembled code for that Console.WriteLine() method:
[HostProtection(SecurityAction.LinkDemand, UI=true)]
public static void WriteLine(string value)
{
Out.WriteLine(value);
}
When people say things like, "Should I use PHP or .Net?", or "Should I use Python or .Net" you start to see how that's the wrong thing to be discussing. They are obviously comparing a language to a Framework. C# is a language and it is just one of the many languages that can be used to write code on top of the .Net platform. That same method of Console.WriteLine() can be invoked from C#, VB.Net, Pascal, C++, Ruby, Python, F# and any other language that has been made to work on top of the .Net platform.
I hope that helps.
-Keith
Mostly its referring to the fact that all of your memory allocations are "managed" for you. If you are using managed code you don't have to worry about freeing your objects when you are done with them. Simply allowing them to go out of scope will mean that the VM will eventually recognize that there are no longer any references to them and will Garbage collect them returning the memory to the system.
Unmanaged code on the other hand will simply "leak" unless you explicitly free your pointers before you discard the references.
It's primarily used to describe .NET because that's the term Microsoft chose to differentiate .NET from C/C++ and other older languages. Microsoft chose it because it wasn't a term that was usually associated with Java because they didn't want to emphasize the similarities between C#/.NET and Java (as opposed to calling it something like 'virtual machine code' which would make it sound much more Java like). Basically, the use of "managed code" is marketing driven, rather than technically driven, terminology.
Under .NET and Visual C++ specifically, you can have both Unmanaged and Managed code. The terms refer to the manner in which memory is allocated and 'managed'.
Unmanaged code would be the C++ stuff you're used to. Dynamic memory allocation and explicit freeing of the memory. The .NET runtime does not manage the memory for you, hence 'unmanaged'.
Managed code on the other hand IS managed by the run-time. You allocate memory where required (by declaring variables, not memory space) and the run-time garbage collector determines when it's no longer needed and cleans it all up. The garbage collector will also move memory around to improve efficiency. The run-time 'manages' it all for you.
As I mentioned above, it is possible to write code that is both managed and unmanaged.
Unmanaged:
class Bar : public Foo {
private:
int fubar;
public:
Bar(int i) : fubar(i) {}
int * getFubar() { return * fubar; }
}
Managed:
public ref class Bar : public Foo
private:
int fubar;
public:
Bar(int i) : fubar(i) {}
int ^ getFubar() { return ^ fubar; }
}
Notice the ref? That pretty much designates a Managed class. It gets very confusing when you mix the two kinds of code however. For instance, you want to save a reference pointer, (^) the managed equivalent of a pointer, to a Picture Box control within your unmanaged class. Since the garbage collector can move memory around, the next time you try to dereference the picture box it can not be found. The run-time does not tell your unmanaged code about it's memory changes.
Therefore you need to pin down the managed object in memory to allow your unmanaged code to keep track of it. Then there's unboxing and all kinds of other quirks that allow you to intermix the two. Code complexity is enormous!
Officially, managed/unmanaged might come down to the way code executes on the .NET stack. However, if you're coming from a c++ background, I hope this will be a little more relevant to you.
Managed means that the code is not compiled to native code, and thus runs under the auspices of a virtual machine. Java compiles to an intermediate format called bytecode, which the Java VM knows how to interpret and execute. All the .NET languages do a similar thing, compiling to IL (intermediate language) which the .NET runtime interprets. It's a little confusing because the .NET IL have .dll and .exe file endings.
The term managed is generally applied only to .NET because Microsoft uses the term. Microsoft generally doesn't use the term "virtual machine" in reference to a .NET managed execution environment.
.NET's "bytecode" (IL) is somewhat different from Java bytecode in that it was explicitly designed to be compiled into native code prior to execution in the managed environment, whereas Java was designed to be interpreted, but the concept of platform-independent code is similar.
The ".NET Framework" is basically a huge set of libraries provided by Microsoft, containing thousands of classes that can be used to develop applications.
A compiled C# .exe contains platform-independent code that can be run in any .NET-compatible environment, including Mono. However, the runtime is generally distributed separately from applications that use it.
At the risk of offending some, I suspect that the word managed was used so they could use the word unmanaged instead of compiled. While managed may mean more, the reality is it seems to be the used to distinguish mostly between what is pretty much just in time compiling (as the replacement for what was one once interpreted or pcode) and native compiled code.
Or put another way, which would you prefer to use:
a) Unmanaged code that may do uncontrollable things to the system.
b) Native compiled code that is fast, solid and is close to the OS.
Of course, they are actually the same thing.
In a similar vein, is .NET a language or a framework, and what exactly does "framework" mean here? <<
.NET is Microsoft's current enterprise software platform. It consists of:
• A single universal interface for accessing Windows functionality:
o The .NET Framework Class Library (FCL).
o The FCL provides a rich set of high-level functionality for developers.
• A single universal language and runtime for executing .NET applications:
o Common Language Runtime (CLR) executes Common Intermediate Language (CIL).
o The CLR is God: it runs, controls, and polices everything.
• The choice of multiple languages for developing .NET applications:
o Every development language is compiled to CIL, which is run by the CLR.
o C# and VB are the two main development languages.
.NET is a framework. The Common language Runtime (CLR) executes the Microsoft Intermediate Language (MSIL) code that is generated when a solution is compiled (i.e., it does not compile to machine code). You cannot contain the API within the exe, nor would you want to as it is quite large. The major benefit here is memory management (among some other security advantages and possibly others that I do not know about.)
I can answer the framework question. .NET is a framework, C#, VB.NET, etc are languages. Basically .NET provides a common platform of libraries to call (All the System.... dlls) that any language using .NET can call. All the .NET languages are compiled into MSIL (Microsoft Intermediate Language, better known as just IL) which can then be run on any PC with the appropriate .NET framework installed.
.NET is a framework.
It can be used from many languages (VB.NET, C#, IronPython, boo, etc)
.NET always executes as interpreted, and no you cannot include the 'VM' inside the .exe. Any user wishing to run your .NET app must have the framework installed.
It can refer to any code executed by a virtual machine rather than directly by the CPU.
I think this enables things like garbage collection and array bounds checking.
Personally, I think the word "framework" is a bit of a misnomer.
.NET is a "platform", consisting of an execution environment (the CLR virtual machine) and a set of libraries. It's exactly analogous to Java or Perl or Python (none of which are ever referred to as "frameworks").
In most cases, the word "framework" is used for projects like Spring or Struts or QT, which sit on top of a platform (ie, providing no execution environment of their own) like a library.
But unlike a "library", a framework seeks to re-define the fundamental operations of the underlying platform. (Spring's dependency injection defies the constructor-calling logic of ordinary Java code. QT's signals-and-slots implementation defies ordinary C++ code.)
I know I'm just being a pedantic bastard, but to me, .NET is not a framework. It's a platform.
Managed Code--MSIL and IL and Managed Code are same.When we build our application the .dll or .exe files are generated in the Bin folder.These files are called as Managed code.Later these files are given to CLR to generate Native code which would be understood by OS.