Link to home
Start Free TrialLog in
Avatar of John500
John500Flag for United States of America

asked on

Understanding Microsoft's Virtual Machine Component - Common Language Runtime (CLR)

Greetings:

I'm trying to understand just how flexible Visual Studio .Net C++ 2005 is when it comes to executing programs compiled on Windows and running them elsewhere.

Here is the definition I have of the CLR:

The Common Language Runtime (CLR) is the virtual machine component of Microsoft's .NET initiative.... Developers using the CLR write code in a language such as C# or VB.Net. At compile-time, a .NET compiler converts such code into CIL code. At runtime, the CLR's just-in-time compiler (JIT compiler) converts the CIL code into code native to the operating system.

My questions are:

1)  As with the definition above and the diagram below, why in these examples do they always leave out C++?
2)  The definition above mentions the JIT which enables execution across platforms.  Does this mean something compiled on Windows XP will run on UNIX?
3)  Additionally, does this mean that an executable compiled on Windows can only run on a different platform if all the code is considered to be managed?  What if the project mixes both managed and unmanged code?
4)  If the project is compiled on windows and intended to run on UNIX, is it necessary to set some compiler option to specify this?  If so, what menu item is this?

Thanks!
CLI.JPG
Avatar of Joel Coehoorn
Joel Coehoorn
Flag of United States of America image

1) C++ is left out because C++ skips this model.  It is compiled all the way to native code.  Visual Studio can do 'managed' C++, or C++.Net, but that's really a different language with new constructs just as ^ pointers.
2) Sort of. The UNIX machine would need to have the .Net runtime installed.   Microsoft doesn't have a .Net runtime for UNIX.  There is a project called mono (www.mono-project.net) that will work, but it is far from perfect and you still have to account for things like file system differences (for example: /bin vs C:\Program Files)
3) Yes.  If a project has both managed and unmanaged code, it is Windows only.
4) I haven't played with it myself, but on the compile page of the project options there is an options for x86, x64, or Any.  I'm not sure if that is generic enough to cross operating system platforms, though.   But I *think* that mono on linux will just use a dll built on windows, assuming problems like what I outlined in #2 have been addressed.
SOLUTION
Avatar of ZachSmith
ZachSmith
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of John500

ASKER

>> Visual Studio can do 'managed' C++, or C++.Net

I thought managed C++ was tightly meshed with C++ .Net so that you can't differentiate.  Here's more of the definition:

The virtual machine aspect of the CLR allows programmers to ignore many details of the specific CPU that will execute the program. The CLR also provides other important services, including the following:

Memory management
Thread management
Exception handling
Garbage collection
Security

Those 'other' services are the 'managed' aspect of .Net C++

>> Sort of. The UNIX machine would need to have the .Net runtime installed...

If the virtual machine component wasn't designed for such major differences in platforms why go to all the trouble to create such a thing?  Are we talking about differences primarily intended to address Server 2003 verses, XP verses Vista??

"If the virtual machine component wasn't designed for such major differences in platforms why go to all the trouble to create such a thing?  Are we talking about differences primarily intended to address Server 2003 verses, XP verses Vista??"

Because that way Microsoft can say that the framework is cross-platform which helps them compete against Java.
managed C++ *is* C++ .Net.  Visual Studio can do that.  But it will also do native C++, and native C++ is really a completely different language from it's managed counterpart.

There are a lot of things that are abstracted away.  Sockets, for instance, will work the same on either platform, where before you had to at least know which header file to include and whether or not to use WSAStartup.  The trick is that some things don't have a 1 to 1 translation, and in those scenarios the conversion is best left to the individual developer.  It would be up to the mono team to decide how to map various things, and I imagine some of that has been done.  But if a developer hard-codes something like "C:\Program Files" or "C:\Windows" (an admittedly bad idea) into an app, no amount of cross-platform library code will save him.
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of John500

ASKER

Thanks to both of you.  I have definitely have a better handle on things now.

If you get the urge, please take a look at another question I have posted.  I can't seem to get anywhere with it:

https://www.experts-exchange.com/questions/23201031/How-to-create-virtual-functions-that-will-demonstrate-object-oriented-polymorphism.html