Common Language Runtime

acronym: CLR

The core of the MicrosoftDotNet platform. The CLR is responsible for the inspection (i.e. some aspects of security and integrity), translation to native code in terms of JustInTimeCompilation, and execution of MicrosoftIntermediateLanguage.

The CLR does the following:

There is no longer:

CommonLanguageRuntime:

At present, MicroSoft has five languages running on the .NET platform: Other companies/research teams have announced approx. 12 other languages that will target the .NET platform, some of note: If you're familiar with the concept of the JavaVirtualMachine, then you can consider the CommonLanguageRuntime as a similar design; though designed with more than just Java in mind.

My reading of the Common Runtime was that it could be ported to any platform, whether this is smaller devices like cellphones or PDAs, or larger "devices" such as Linux, Solaris or OS/390. If inter-component communication is performed over SOAP that who cares what is the underlying platform. Win32/64 offers component transaction services which will be used initially by .NET components but that this would go away as the runtime is further developed. Your .NET component would use declarative, attribute based programming to get deployed to a number of managed component containers.

Using a massive over-simplification:

CeeSharp = Java ( + features we originally saw in J++ )

Common Runtime = JavaVirtualMachine ( + four years of additional knowledge on how to build and secure these things )

As far as security is concerned, the CLR seems to have gone backwards. Certainly the DotNet security model is many times more complicated than that of the JVM, and complexity is the enemy of security. Writing a secure JVM implementation was already too complicated. -- DavidSarahHopwood

ComPlus services = EJB/CORBA component services - need to define common services for assemblies

SimpleObjectAccessProtocol = DistributedCom/CORBA style transport protocol

Econo-JIT = Java Client VM

Standard-JIT = Java Server VM

Pre-JIT = No Java equivalent

So the missing pieces seem to be:

Seems to me that the industry is heading in the same direction. Differences appear to be less than the similarities. I then couldn't care what component model a developer used and the fight becomes one of who produces the best developer tools.

Interesting language features left out of the CLR include MultipleInheritance and CovariantTypes?. It makes me wonder how they are going to "implement" any modern OO language... -- JosephKiniry

Why do need MultipleInheritance for modern OO?

Because things in real life generally belong to more than one class, and OO should model that. The only advantage in SingleInheritance is that it is easier to implement - slots can stay in the one place when the class they belong to is subclassed. However, advocating SingleInheritance for that reason is an acceptance of WorseIsBetter. -- DonaldFisk

MultipleInheritance seems like the ideal method for implementing multiple independent interfaces. When I share an interface across multiple classes, I also usually want to share much of the implementation. Without MultipleInheritance, I can only contain the interface implementation and must then write a bunch of stupid function shims to call my contained class. -- WayneMack

However, MultipleInheritance of anything other than interfaces implies tight coupling between super- and sub-classes and hence exposure to the FragileBaseClassProblem (note that even having just concrete DataMembers? exposes you here). Based on my experience, DelegationInheritance is generally safer and simpler for non-trivial systems. So write the shims: it's not like it's going to overly strain your intellect... -- JonKale

Eiffel people use multiple inheritance to provide access to 'global' features. You simply define the features as class-based, then inherit that class into every other class that wants to access the feature. Examples include maths operators: in Java you call Math.random(); in Eiffel you'd use Math as a base class and then call self.random()). (Disclaimer: I'm not an Eiffel user, feel free to correct this if I've misunderstood things.) -- DaveWhipp.

They also use it to do so-called "marriage of convenience", which means, merging an ADT such as Stack with an effective type such as Array to obtain an ArrayedStack?.

A low-level byte-code protocol should not dictate whether things like multiple-inheritance is possible or practical. That is dictating too much in my opinion. That is almost like saying, "Sorry, your language cannot have two-dimensional arrays because the chip instruction set does not support it."

I don't think it outright prevents it, it is just that such has to be emulated instead of directly supported. Unless a CLR has a gigantic set of features, it probably has to favor some approaches over others with regard to direct support. Whether Microsoft lives with such limitations out of practicality of a manageable CLR size, or does it to hurt competitors is unknown.

HowDotNetLanguagesDiffer

XCOPY deployment: Most apps will require just copying files to a directory!

I will have to see this one to believe it. Will Microsoft continue their standard practice of constantly changing the OS? Will I be able to select the version of the CLR I want to use in Visual Studio or will I be forced to use the latest one? If so, I'm afraid I will still be forced to either update the CLR in all client machines on a yearly basis, or maintain a lab of development machines each running a different version of Visual Studio. I'm afraid I don't see what has changed, other than I now have to ship a service pack with a code update rather than a huge InstallShield file. -- WayneMack

I would seriously doubt it as that seems to be Microsoft's leverage. As is clearly evidenced by the sheer number of languages that are out now, the language really doesn't matter, IMHO, just the runtime and libs.

-- EtoffiPerson?

I might've missed this along the way, but I cannot see anywhere: What does the CLR have that the JVM doesn't have? Why do we need two "standard virtual machines on every computer"? -- JohannesBrodwall

Sun has forbid Microsoft from doing any Java development so they cannot even work on Visual J++. Sun will not cooperate with Microsoft, thus Microsoft has to also have a mechanism to solve the application distribution problem. The CLR has many things that the JVM does not, but one thing is really obvious: 14 languages instead of only one, with a common type system across all the languages and the ability to call a function in one language from another.

There are actually OtherLanguagesForTheJavaVm, but a difference is that the CLR was designed with this in mind, the JVM wasn't.

Actually, I don't think this statement on the Java VM is necessarily true, and is perhaps a result of the continuing confusion over Sun's insistence on naming the whole spectrum "Java". The Java VM was not issued with support for other languages, but I have this persistent impression that I've read somewhere (yeah, I know, this is unsubstantiated hearsay, I wish I could recall the reference) that the VM designers intended for other languages to run on it someday.

Incorrect. Sun never designed java to support multi languages. Looking at the bytecode you can see that is the case. The type system is tightly coupled to the Java language, rather than being independent. Also, the operation instructions in the jbc are type specific, so that non-java types aren't easily adapted. SimonPhipps? of Sun has recently (Feb 2001, at the O'Reilly XML conf) stated that Sun's position is "it's the bytecode, stupid!" not "it's the java syntax". Meaning - produce portable bytecode - that's what it's all about. But, two things: (1) in practice, the two are equivalent. The only practical way to produce java b/c is to use java syntax. The other projects out there that can produce java bytecode from alternative languages are (a) huge compromises, and (b) not commercially supported. They're science projects. (2) no-one has yet demonstrated that portable bytecode or IL delivers any real benefit. Portable data delivers real value. Portable code -- ? -- DinoChiesa

There's an interesting paper at http://research.microsoft.com/~emeijer/Papers/CLR.pdf comparing the CLR to the JVM. Quoting from the paper, "The JVM is a great target for Java, but even though the JVM designers hope to attract implementers of other languages, we will argue that the JVM is essentially a suboptimal multi-language platform. For a start, the JVM provides no way of encoding type-unsafe features of typical programming languages, such as pointers, immediate descriptors (tagged pointers), and unsafe type conversions. Furthermore, in many cases the JVM lacks the primitives to implement language features that are not found in JavaTM, but are present in other languages. Examples of such features include unboxed structures and unions (records and variant records), reference parameters, varargs, multiple return values, function pointers, overflow sensitive arithmetic, lexical closures, tail calls, fully dynamic dispatch, generics, structural type equivalence etc"

People seem to think that the CLR supports many things. It is true that everything running on the CLR (till now) has been shown as being C# in disguise or dog slow. IronPython runs 1.8 times faster than CPython, C# on the same VM runs something like 100 times faster than CPython. Bigloo and other SchemeLanguage dialects targeting the CLR do not have real CallWithCurrentContinuation (though there is research in this direction). Even VisualBasic 6 could not be made to run on it due to the different assignment semantics, and VB.net is C# with a different syntax.

CLR has "No AddRef/Release"

DistributedCom provides a primitive form of distributed GarbageCollection, based on AddRef/Release and keep-alive pings. Whether this is a good idea is debatable (and that debate, though interesting, is not on topic for this page).

How does the .NET platform approach distributed garbage collection? Or does it punt the problem up to the application designers?

It uses a leasing mechanism. When a remote object is created, it is associated with a lease object. When the lease expires, the remote object is freed for garbage collection. Leases can be renewed periodically, under the direction of a "sponsor" object, to keep the remote object alive past the original duration of the lease.

"Imitation is the sincerest form of flattery." JamesGosling responding to a question about C# (speaking at Sun TechDays?, London 5-6 Oct 2000).

Given the amount of stuff they're retrofitting onto java in 1.5, I'm sure AndersHejlsberg would say the same thing...

Imitation is how Microsoft finds profitable niches with lower R&D and road-testing costs.

The investment from MicrosoftCorporation into Corel in the beginning of October 2000 grants Microsoft the option to have Corel port the .NET to Linux. Look at http://www.freeedgar.com/EdgarConstruct/Data/890640/00-500007/techsupport.htm under '3. Option for Linux Port.' for the details. It is only an option, so it is not quite clear what will emerge from it. Some doubt that Corel has the expertise for such a hard job.

There's some more detail on this idea on the MicrosoftDotNet page... although recent events (as of Nov 27 2000 - Corel making noises that it will drop it's Linux division) seem to make it seem less likely... -- ChrisKovacs?

I reckon the recent events make it seem very likely indeed. Corel got rid of its Linux Distribution for cash and shares, and in the process freed up its Linux developers to port dotNet to Linux. -- AnonymousDonor

That's what it would seem

It looks like languages that run on the CLR will probably change (at least VB has and smalltalk had to). The VBers seem to up in arms about it. If the languages have to change does it still count as multilanguage support?

Interesting. What changes were made to smalltalk? Do you have a link? How does the smalltalk community feel about it?

No, they are not "up in arms", because the languages have not changed. They've gained additional features but that's different from the ground structure of the language changing. In contrast, the Java event model was 100% different from Java 1.0 to Java 1.1.

Actually it appears they are up in arms about it, to a significant extent: http://www.mvps.org/vb/rants/dotnot.htm. Just a sample: the default method for passing parameters to procedures has changed from ByRef to ByVal. That's a huge change for a mature language like VB, compared to something as minor as the AWT event model changing in a very early version of a language in response to clear concerns from the developer community over performance.

-- StevenNewton

http://www.devx.com/free/hotlinks/2001/ednote011901.asp

VB.NET Raises Hackles -- Some Experts .NOT Happy with .NET

Changes to VB in the .net transition were also due to the inability to implement them in the CLR, see: http://www.panopticoncentral.net/archive/2005/03/21/8041.aspx

Regarding language independence and how so many of the languages for the CLR have had to change so that they look like the same languages but aren't really: How about Ada for .NET? Now there's something I'd take my hat off to.

C++ has not had to change.

This is simply not true. C++ will not run under CLR without changes. Instead of making the CLR compatible with C++ or any other existing language, Microsoft chose to "extend" C++ (and all other languages as well) to make them run with the CLR. Rather than have linkable object files, the CLR also requires brand new compilers to generate the intermediate language. The end result is that Visual C++ continues to drift further and further from main stream C++.

But only for "managed mode", since C++ does not have GarbageCollection.

For any and all existing languages that want to run on CLR, the key change is support of the common type system - CTS. This is a common system across machines, languages, processor architectures, etc etc. So a lisp list has to be represented as a Something in CTS; a Float is a CTS Float, not a C++ float; the pre-.NET VB idea of variant disappears.

It is not true that "C++ will not run under CLR without changes." Lots of C++ code will compile for the CLR without any problem; just add the /CLR switch to your VS.NET compilation commands and recompile. Such code won't take advantage of CLR features, and other programming languages won't be able to call it, but it will run under the CLR.

The best reason to use the managed C++ extensions is as a bridge between existing unmanaged code and new managed code. C++ would be a terrible choice for developing complete .NET apps, but it is great for developing managed wrappers around unmanaged code.

Does the CommonLanguageRuntime have any concept of a security manager, i.e. something that will not allow an "untrusted" application to read/write files on the system, make connections to hosts other than the one it came with, etc.? As I was reading a story this morning on Sircam I got to thinking how this could be very, very useful (imagine that in the future, e-mail attachments needed to ask the user's permission to read their address book or read files on their system...)

Yes, DotNet includes a security manager. See http://msdn.microsoft.com/library/en-us/cpguidnf/html/cpconsecuringyourapplication.asp for Microsoft's docu on security in .NET. .NET features an "evidence-based" security manager, which allows decisions on whether to execute te code or not to be taken based on: author of the code, libraries the code is asking to execute (eg, file i/o), user id of the process, etc. See http://msdn.microsoft.com/library/en-us/cpguidnf/html/cpconintroductiontocodeaccesssecurity.asp for info on code access security in DotNet. Also, a single process may contain multiple ApplicationDomains, which are isolated from each other. For example, in a single browser process, you could run controls from several Web applications in such a way that the controls cannot access each other's data. For more on evidence, app domains, and security in .NET see http://msdn.microsoft.com/library/en-us/cpguidnf/html/cpconevidence.asp.

No memory leaks, over-writes, no un-initialized memory

Actually, the memory leak claim is about as true for CLR as it is for JVM. Yes, the problem of unreferenced objects hanging around goes away due to garbage collection - just as it does for the JVM. But objects which for one reason or another (some quite subtle) continue to have references even though they will never be used again continue to consume memory.

One obvious example is the object that is added to a collection but never removed from that collection. Others are objects referenced by static objects which are never discarded. Still other examples have to do with things like serialization, class loading, and marshalling.

The practical upshot of this is that one has fewer memory leaks than in an environment without garbage collection, but those leaks tend to be bigger. If I come across the research paper I read on this topic, I'll add a link to it here. -- DanHankins

One of the differences between the kind of leak Dan describes and a classic memory leak is that the exact location in the object model of the reference to a "leaked" object can be determined. The ideal way to track down this kind of leak is with an instrumented garbage collector. The Microsoft JVM certainly has this capability although the API may never have been made publicly available. It's possible that the CLR provides this kind of capability as well. Even in the absence of an instrumented garbage collector reflection can be used to implement a poor man's alternative. -- CurtisBartley

It is unclear to me how friendly CLR will be to dynamic typing and scriptish languages and/or techniques. It seems they targeted Java-istic languages more than say Perl or Python. Microsoft's products tend to mirror their perceived competitive threats rather than internal favorites or language philosophies.

Take a look at JScript .Net, which is the .Net-ized flavor of JScript / JavaScript. The syntax is virtually unchanged, and it DOES support the eval() function. Given that JScript .Net exists, and is supported as a first-level language by Microsoft, implementing Perl or any other scripting language should also be possible. -- ArlieDavis

The difficulty in compiling dynamic languages is a real one, which is why the PerlSix folks have come up with ParrotCode. There's also been talk of running Python/Ruby/PHP/Scheme on Parrot, and it's already the target for a few experimental languages. -- JonathanTang

If we want a common underlying instruction set, then why not settle on x86 instruction set? That way we get better speed on x86 machines, and CLR-like speed on non-x86 due to emulation. At least half the parties can run faster.

CLR seems like an unnecessary layer.

In a nutshell, x86 and MSIL (the CLR instruction language) exist at very different levels of abstraction. They are not in competition, they are in necessary unison. They are no more redundant than C++ and x86.

In MSIL, managed types are first-order objects; this includes object-oriented classes (and all the usual inheritance, polymorphism, etc.), as well as intrinsic types, and a handful of other types. So MSIL allows you to create instances of these types - "new" is one of the instructions in MSIL, and having it as a fundamental instruction in MSIL is very different from having a well-known function that can be called from x86 assembly code.

MSIL also completely describes the language constructs of the compiled code. MSIL describes all of the types (types are either classes, enums, delegates, or value types) in the code, including their methods, properties, fields, etc. This is very, very different from just raw x86 assembly code.

Also, MSIL defines a "verifiable" subset. Verifiable code does not violate type safety rules - verifiable code does not use unmanaged memory pointers, along with meeting several other constraints. This allows the CLR to safely run "partially trusted code", along with enforcing some very desirable constraints on memory safety. x86 assembly does not define any such subset - it is a much lower-level language.

-- ArlieDavis

The potential problem I see is that it is hard-wiring the flavor of certain programming paradigms and/or languages. It is in-between machine-code and a high-level language, and thus has some of the same lock-in risk that high-level languages do. What if in the late 60's IBM created a CLR standard that fit COBOL and "encouraged" all systems to use it. As later languages and paradigms came along, that CLR would look less and less relevant, and the work-arounds would get uglier. (Come to think of it, OS/360 did tend to fit COBOL types.) Microsoft is assuming that we have reached the pinnacle of languages it appears.

Refactored from JavaIsTheNewCobol:

I don't see how the following comment belongs on this page. .NET would seem to be a wild digression from the topic. (It's also true that .NET does not support *all* widely used languages/language features.) -- AnonymousDonor

Forget the language wars, code for .NET and choose your own language.

That's not an option, .NET, which I use quite heavily, isn't conducive to dynamic languages. .NET is not as language neutral as it makes itself out to be. .NET's runtime enforces rules that cripple advanced languages or make their implementations extremely slow. Language wars will continue until a platform comes around that can support them all, and currently no such platform exists.

The Mondrian for .NET developers, along with DavidSimmons? (s#), JimHugunin (IronPython), JohnBrant and DonRoberts (sharp smalltalk) might disagree with you. -- TomAyerst

I doubt they'd disagree considering the hoops they had to jump through to get those implementations to work. I said .NET doesn't make it easy, didn't say anything was impossible. Eiffel for example had to hack up multiple inheritance since .NET doesn't support it, and so will any other language. So I stand by my statement, "Language wars will continue until a platform comes around that can support them all, and currently no such platform exists."

Though JimHugunin and DavidSimmons? say their implementations are very fast (faster or nearly as fast as their native versions) (and s# has multiple inheritance and a MOP) so yes, their may be some features not directly supported but so what? MI on the CLR has been done so often now their are chapters about how to do it. I guess YMMV on what you consider adequate support for a feature. -- TomAyerst

If they are hacking up their own implementation, then .NET doesn't support it, so no such platform exists. If you consider absolutely 0 support adequate then I'd say you've redefined adequate. However, .NET is certainly the closest thing to a language neutral platform that I've seen and I'm quite pleased with it's progress. If we ever can make languages just a syntax choice I'd be thrilled. I wasn't dissing .NET, I work with it daily. I was just saying that it isn't as flexible and language neutral as Microsoft pretends it is.

Fair enough, though the CLR does support multiple interface inheritance, so 0 support is a little harsh. I remember talking to JosephPelrine about s# and he commented on how impressed DavidSimmons? was with the responsiveness of Microsoft CLR developers to requests for changes in the CLR to support more dynamic features. Maybe it will get there in the end (and maybe Mono will work out too and I can run IronPython all over the show!). -- TomAyerst

While we're talking about it, has anyone actually seen S# or used it in .NET. I'd love it, but it seems to be complete vapor ware and the site continually say's coming soon. I want to get my hands on it but the status doesn't seem to have changed in over 6 months! Could someone please AnswerMe?

See also: MicrosoftDotNet, MicrosoftIntermediateLanguage, CommonLanguageInfrastructure, SharedSourceCli

CategoryDotNet

EditText of this page (last edited October 3, 2009) or FindPage with title or text search