“With over 9,000 files, and including some 1300 public classes to pore through, the Shared Source CLI can teach you quite a bit about the internal workings of the CLR. But the sheer amount of source code included can make just starting your exploration a monumental task. This article discusses some of the things you can learn from the source code facsimile of the CLR, like how JIT compilation works. It will also help you understand how to control execution along with debugging and loading classes. A walk through the steps involved in setting up the runtime will let you become familiar with the process.” Read the article at MSDN, a reprint from June’s NetMagazine printed article.
Source Code for a FreeBSD Implementation of .NET
Submitted by Ian Smith 2002-10-28 .NET 7 Comments
About eight months ago there was a pre-announcement of a book on Rotor architecture by Microsoft’s Bob Stutz, who was either a technical lead or project manager. This sounded pretty interesting because a book would be much more digestible than trying to make sense of 1M lines of source code, and also would be less likely to place a developer in legal limbo with regards to similar projects (for example, word is that Ximian forbids Mono developers from examining Rotor source). But I haven’t heard anything about that book since. Maybe a higher up at MS put the kibosh on the project.
And doesn’t even support 1/10000000000th of the Windows .net functionality.
Yeap, this is typical MS lipservice at it again. If they really were committed to the development of .NET on alnernative OS’s, they would have licensed it via the BSD license and allow others to embrace.
“…And doesn’t even support 1/10000000000th of the Windows .net functionality.”
I would be interested in knowing which project is farther ahead in implementing the greatest portion of the .NET functionality and which is likely to become the better implementation, Mono or Rotor?
Microsoft isn’t really interested in making their rotor work too well on freebsd. So it doesn’t get ingral parts of the framework like asp.net and winforms(ugly shit). Mono on the other hand is storming ahead with supporting everything they can. I wouldn’t be surprised to see a lot of happy .net programmers migrating to unix 6 months from now. It gets better, since mono works on Windows too, it may become the platform of choice there..at least for testing for app compatibility.
And lets not forget about the DotGNU people. Even tho in the typical GNU fashion they wont get very far in their .NET implementation. their “lets do everything in c” motto will get us a nice c C# compiler to quickly compile apps so I can run them with mono!
From the article: The JIT compiler and garbage collection are simplified from the commercial product, but the Shared Source CLI is still very capable.
So, two of the keys to performance of the system have been hobbled, and there is no motivation yet to actually improve these components.
Since the Shared Source CLI is derived from the CLR, and the CLR is built on top of Win32®, some sort of layer is needed to abstract the OS details from the bulk of the code base. Rather than invent yet another abstraction layer, the Shared Source CLI code punts and relies on a subset of Win32.
This makes complete sense for MS, but it’s yet another step where Mono can make these assumptions up front and streamline the layers.
No, this implementation is just a reference platform, and also a platform for Microsoft’s server apps, if any. This is not what Microsoft meant as in cross platform. What is cross platform is the design itself. For example, hate COM? Dump it, and use can use CORBA or whatever component architecture that makes your day.
This is NOT similar to Sun’s Java where implementations for other platforms is based on Sun’s code.
Even if there is motivation to improve the product, under the license, IIRC, only Corel and Microsoft can. Just say the courts bans Microsoft from pursuing its .NET dreams and send them to hell…. ermm…. Sun, and Corel bankrupts when all the OEMs find yet another cheaper solution while all the graphics designers switch to Adobe or Macromedia, no one would support Rotor.