At the bottom of pg 86 in Pro .NET Performance - Optimize Your C# Applications, it talks about the implementaton of ValueType.Equals() and says this:
The definition of CanCompareBits and FastEqualsCheck is deferred to the CLR, they are "internal calls", not implemented in IL
What exactly are "internal calls" and what language are they implemented in if not IL?
Methods, like mentioned CanCompareBits or FastEqualsCheck are marked with [MethodImpl(MethodImplOptions.InternalCall)], which informs clr that it needs to find implementation in it's internals. In terms of CLR it's called FCall, see Calling from managed to native code
Since coreclr is opensourced it's easy to find actual implementation on github.
For FastEqualsCheck see comutilnative.cpp.
CoreCLR is written with C++ as well as Mono, so all code for all such internal calls is C/C++.
In runtime, in opposite to regular .net code which will produce IL (Intermediate language), such internal calls is platform-dependent assember instructions
The language the Common Language Runtime is written in or compiled into. Unfortunately as there are many different Runtimes/Interpreters for IL Code, I can not tell you any more precise without you telling me wich specific one we are talking about.
.NET Programms are compiled into the Intermediate Language. The IL is then run by the CLR. If you think that sounds like Java Bytecode being executed by the Java Application - you are damn right! It was most definitely an inspiration. It is a step up too, however.
For several points of view, .NET Programms are as interpreted as a Batch File, Java ByteCode, JavaScript or PHP/Python script. There are some things all of those can do, that they will not make available for Programms running in them.
When reading about the basics of .NET like Managed and Unmanaged code, the code which runs under CLR and developed in .NET framework is managed while unmanaged does not run under CLR and developed outside the .NET framework. Moreover, thinking and knowing about the practicalities about the codes and how they run and how the compiler knows the type of code was a bit confusing. So, to get rid of this confusion, felt to ask this on here.
Please let me know about this.
Thanks in advance!! :)
If you're talking about the compilers for languages such as C#, VB(.NET) etc, then: from the compiler's perspective they are always managed. Everything they output is managed code, i.e. IL. There are places where C# etc get close to directly unmanaged - for example:
when using unsafe code and "unmanaged pointers", C# can talk directly to unmanaged memory - but it always expresses how to do that via IL (IL contains operators for dealing with raw pointers)
P/Invoke layers can express boundaries for talking to external unmanaged code
However, in both cases it is the JIT compiler at runtime (or the AOT compiler if using a non-JIT target platform) that interprets these unmanaged intents expressed in IL, and outputs the CPU intrinsics to implement them. But... that's exactly what the JIT / AOT does for all IL, so ... nothing different there.
So: from the perspective of a compiler for a language such as C# / VB(.NET), there is no actual question here: it is always working 100% managed in terms of the output - and since the compilers are (since Roslyn) also .NET code, they are 100% managed in terms of their actual execution too.
If you meant something different, it would be worth clarifying the question, being really, really specific about what scenario(s) you have in mind, preferably with examples.
When I was learning .NET I saw it as a platform that runs my .NET programs which has its own Stack & Heap.
But now after learning more about things, I see a .NET application as just like any other C/C++ native application. It is in Portable Executable (PE) file format with new data directory & .text section is filled with MSIL code instead of machine code. The only difference is few DLLs (which are considered as .NET platform) (like any other Dll dependency) are loaded.
I guess at the very entry point there is some machine code which calls into the loaded DLL(.net platform) and functions of those DLL read the MSIL from .text section (segment to be more correct) and generate equivalent machine code and put it in some kind of buffer (I don't know which area would it be it. I cannot be .text & .data as they are readonly. will they be stack or heap?). Then make the EIP point to this buffer of instructions. Last few instructions again call back into DLLs to repeat the process for rest of MSIL.
As of Managed Heap & Managed Stack they are just some portion of the processes heap & stack. its just that few functions (referred to as GC) will keep track of the memory allocations & deallocations from this portions of memory.
I like this realistic view. I don't know how far I'm true. I'm just guessing these things. Please correct me & tell me more about this. How far will is it similar to this view? Where can I learn more about .NET platform from this point of view?
You missed one very important point - CIL code (formerly MSIL) is safe code. You cannot do arbitrary pointer voodoo, type casting or similar evil things (except for some in unsafe code regions). This is probably the most important difference to other languages like C(++), Pascal and so on. This safety guarantees are deeply build into the language, type system and runtime design.
For CLR check : CLR via C#.
It is really a great book especially if you are interested in "low level" .NET/CLR.
For JVM check : Java Virtual Machine
CLR via C# describes some internal .NET things, including PE load process and hosting of CLR in your own process.
Your description is missing one thing: most code in a .NET assembly is just-in-time (JIT) compiled, meaning that the MSIL isn't converted into machine code until the moment just before the method is called for the first time, at which point it's cached for the future. This greatly speeds up startup time, at the cost of a minor slowdown the first time each method is called. (I omit details like the fact that the JIT compiler may re-optimize the function after it's been called a few times.)
The JIT-compiled code lives on the heap, from the perspective of the OS. The JIT compiler will mark the code as executable and do whatever other voodoo is necessary to make it run correctly.
It's not 100% accurate, but I'd say you've got a decent overview of certain portions of the framework down.
If you'd like to know more, I suggest you take a look first at the .NET Framework FAQ and when you're done with that read the .NET 1.1 Inside the .NET Framework series of articles. These articles won't cover many of the advances that have occurred over the last 4 versions, but they'll give a good, solid foundation of what the .NET Framework is all about.
Lately I have been reading Pro C# 2008 and the .NET 3.5 Platform (there's now a VS2010/.NET 4.0 version, too), and it does a great job explaining how the .NET bytecode works on the back-end, and how you can learn about what's really being called by using the reflector, etc. It's dense and long (and sometimes more info than I wanted), but it's good informative reading.
You might find this MSDN article interesting: http://msdn.microsoft.com/en-us/magazine/cc163791.aspx
As well as these books:
http://www.amazon.com/Expert-NET-2-0-IL-Assembler/dp/1590596463/ref=pd_bbs_sr_1/104-0844985-7433557?ie=UTF8&s=books&qid=1175791950&sr=8-1
http://www.amazon.com/CLR-via-Dev-Pro-Jeffrey-Richter/dp/0735627045/ref=sr_1_1?ie=UTF8&s=books&qid=1277838859&sr=1-1
I'm trying to understand my options for calling a C# library implementation from unmanaged C++.
My top level module is an unmanaged C++ COM/ATL dll. I would like to integrate functionality of an existing managed C# dll. I have, and can recompile the source for both libraries.
I understand from reading articles like this overview on MSDN and this SO question that it might be possible to create a "mixed-mode" dll which allows the native C++ code to call into the C# library.
I have a couple of questions about this approach:
How do I go about setting this up?
Can I simply change some properties
on the existing COM/ATL project to
allow use of the C# modules?
How will these mixed-mode calls
differ in performance from COM interop
calls? Is there a common string
format that may be used to prevent
conversion or deep copies between
the modules?
If this dll is created
mixed-mode, can it still be
interfaced/used in the same way by
its COM clients, or do they need to
be mixed mode aware?
Will inclusion of the CLR impose substantial
overhead when loading this COM object?
I'm new to Windows development, so please comment if anything in the question statement needs clarification or correction.
Thanks in advance.
How do I go about setting this up? Can I simply change some properties on the existing COM/ATL project to allow use of the C# modules?
If you fully control that project, so changing such settings isn't an issue, then sure. All you need is to enable /clr for this project (In project properties, open the "General" page, and look for "Common Language Runtime" support). Now you can use managed handles (^) and other C++/CLI bits in your project as needed. All existing code written in plain C++ should just keep working (it will be compiled to MSIL now, inasmuch as possible, but its semantics will remain unchanged).
How will these mixed-mode calls differ in performance from COM interop calls? Is there a common string format that may be used to prevent conversion or deep copies between the modules?
A mixed-mode call will be faster, because it uses faster calling conventions, and doesn't do any marshaling the way COM interop does (you either use types that are inherently compatible, or do your own explicit conversions).
There's no common string format - the problem is that System::String both allocates and owns its buffer, and also requires it to be immutable; so you can't create a buffer yourself and then wrap it as String, or create a String and then use it as a buffer to output text to.
If this dll is created mixed-mode, can it still be interfaced/used in the same way by its COM clients, or do they need to be mixed mode aware?
It can be interfaced the same, but if it's entered via an native entry point, it will try to load the CLR into the process, unless one is already loaded. If the calling client had already loaded CLR prior to the call (or the client was itself called from managed code), then you'll get the CLR that is already loaded, which may be different from the CLR that your code requires (e.g. client may have loaded 1.1, and your code needs 2.0).
Will inclusion of the CLR impose substantial overhead when loading this COM object?
It depends on what you define by overhead. Code size? Runtime penalties? Memory footprint?
In any case, loading the CLR means that you get all the GC and JIT machinery. Those aren't cheap. That said, if you need to call managed code ultimately anyways, there's no way around this - you will have to load CLR into some process to do this. The penalties aren't going to differ between COM Interop and mixed-mode C++/CLI assemblies.
I can't say much about the details like e.g. the string issues, since I never actively used this approach.
But you can easily consume any COM interface from any C# code by simply letting a VS wizard create a proxy for you, there is no performance overhead to it except the one that you always have when invoking COM and .NET.
The other direction, you just have to set your C# assemblies' ComVisibleAttribute to true (in VS it's a simple check box in the project properties), and then the compiler will automatically create COM interfaces for you. Again, there's no additional performance penalty.
HTH!
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.