|Miguel de Icaza,
As the new open-source implementations of the .NET platform take shape, developers targeting .NET face an extremely welcome challenge?creating applications that run on multiple platforms. As developers, we wanted to know what you can expect from each of these implementations. How are they alike? How are they different? What are their goals and problems?
To help answer these questions, we contacted several key members of Ximian’s Mono, Corel’s Rotor and the Free Software Foundation’s Portable .NET projects, and also Microsoft itself. To make the results comparable, we asked all the open-source representatives the same set of questions. Microsoft’s questions were slightly different, to cover both the commercial and the Shared Source CLI (SSCLI) versions of .NET.
The results are both fascinating and problematic. Depending on your interests, you may wish to compare the answers to questions across projects, or you may wish to read the answers for a specific project. Therefore, we’ve arranged the interviews both by question, with each project spokesperson responding, in turn, to each question, and also by project, which is the way we originally conducted the interviews. You can view either version by selecting a preferred view from the list below. You can switch views at any time by selecting a view from the right-hand column.
Its roots are on the GNOME project, and the need to have a better development platform for end-user desktop applications. Here is more detail [on GNOME]:
The GNOME project’s goal was to bring missing technologies to Unix and make it competitive in the current marketplace for desktop applications. We also realized early on that language independence was important, and that is why GNOME APIs were coded using a standard that allowed the APIs to be easily wrapped for other languages. Our APIs are available to most programming languages on Unix (Perl, Python, Scheme, C++, Objective-C, Ada).
Later on, we decided to use better methods for encapsulating our APIs, and we started to use CORBA to define interfaces to components. We complemented it with policy and a set of standard GNOME interfaces for easily creating reusable, language-independent components, controls, and compound documents. This technology is known as Bonobo. Interfaces to Bonobo exist for C, Perl, Python, and Java.
CORBA is good when you define coarse interfaces, and most Bonobo interfaces are coarse. The only problem is that Bonobo/CORBA interfaces are not good for small interfaces. For example, an XML-parsing Bonobo/CORBA component would be inefficient compared to a C API.
I also wrote at some point:
|My interest in .NET comes from the attempts that we have made before in the GNOME project to achieve some of the things .NET does:
And on top of these things, I always loved various things about Java. I just did not love the Java combo that you were supposed to give or take.
We tried APIs exposed to many languages by having a common object base (GtkObject) and then following an API contract and a format that would allow others to wrap the APIs easily for their programming language. We even have a Scheme-based definition of the API that is used to generate wrappers on the fly. This solution is sub-optimal for many reasons.
The cross-language integration we have been doing with CORBA, is sort of like COM, but with an imposed marshalling penalty. It works pretty well for non-inProc components. But for inProc components the story is pretty bad; since there was no CORBA API that we could use, the result is so horrible, that I have no words to describe it.
On top of this problem, we have a proliferation of libraries. Most of them follow our coding conventions pretty accurately. Every once in a while they either wouldn’t or we would adopt a library written by someone else. This lead to a mix of libraries that, although powerful in result, implement multiple programming models and sometimes different allocation and ownership policies. After a while you are dealing with five different kinds of “ref/unref” behaviors (CORBA local references, CORBA object references on Unknown objects, reference count on object wrappers) and this was turning into a gigantic mess.
We have, of course, been trying to fix all these issues, and things are looking better. The GNOME 2.x platform does solve many of these issues, but still .
.NET seemed to me like an upgrade for Win32 developers: they had the same problems we had when dealing with APIs that have been designed over many years?a great deal of inconsistency. So I want to have some of this new “fresh air” available for building my own applications.
A: During 2000, I was doing a lot of experiments with different virtual machine implementation techniques, and the CLI seemed a natural place to apply those techniques starting in January 2001. That, and I find VMs fun. My company, Southern Storm Software, Pty Ltd, is just myself, so there is no [bickering over] decisions. The company exists as a legal structure only; it isn’t a money-making exercise. I work on this full time, and fund it out of my own pocket. It would be nice to find a sponsor for this work, so that I can hire some more people locally.
A: As you may know, Microsoft teamed with Corel to build the Shared Source CLI. Our company is a development partner to Corel, and as a firm with considerable cross-platform and porting experience our team also got involved in the development as a contractor to Corel.
NET, and more specifically, the .NET frameworks, started as a purely commercial effort. However, early on, we recognized that having a standards-based foundation for the CLI and C# would be a great thing for both customers and our own product teams?the commercial product has benefited immensely from the standard, and vice versa.
Well, I do not know what you are comparing things to, so it is hard to tell you what it is that you are looking for. I can give you some “attributes” of Mono:
- A self-hosting C# compiler written in C#, which is clean and easy to maintain.
- A multiplatform runtime engine: both a JIT engine and an interpreter exist. The JIT engine runs currently on x86 systems, while the interpreter works on Sparc, StrongARM, and PowerPC systems.
- Supports Linux, Windows, and Solaris at this point.
- The JIT engine is written using a portable instruction selector that not only generates good code (we are told that we are faster than Rotor, but it is hard to tell) but is also the foundation to retarget the JIT engine to other systems. The system employed is described in various compiler books and it is very similar to what is described in the book that covers LCC, the Ansi C retargetable C compiler.
- The JIT engine supports inlining, constant folding, and propagation.
- There is full support for remoting in the runtime, but the class libraries are still behind.
- The C# compiler, the JIT engine, and the class libraries are mature enough that the whole system is self-hosting, i.e., that it can be fully developed with itself at this point.
- We are not yet done, and there is a lot of work left to be done
- We have a great community of developers, without which Mono would not be possible.
- We will provide an ahead-of-time compilation mode in the future.
Our interpreter design is radically different from anything done by anyone else before. Rather than interpreting IL directly, I first convert it into a more efficient bytecode format called CVM (Converted Virtual Machine). I then interpret this with a highly-efficient bytecode interpreter.
The beauty of this design is that 95 percent of the code is identical to what is needed to build a native code JIT. So, when I get around to building a JIT, it will be quite trivial. The reason I haven’t done a JIT yet is that it isn’t time yet. Until the rest of the engine works, and has good internal data structures, there’s no point wasting time trying to make it run fast.
Another unique feature of PNET [Portable .NET] is in the implementation of the C# compiler. I developed a new tool called “treecc” that vastly simplifies the task of developing compilers. More information about this can be found on my Web site: http://www.southern-storm.com.au/treecc.html.
[This question is] not really applicable; the Shared Source CLI is meant in part as a blueprint from which to build other implementations, as stated by Microsoft here:Shared source CLI Beta (See the last point under “What can I do with the Shared Source CLI?”)
I’ll let the other implementers speak for themselves, but it is interesting to know that Microsoft alone has three distinct implementations of the ECMA CLI: the “Compact Framework,” the “CLR,” and the “Shared Source CLI” (“Rotor”). Each has features that are quite unique; Rotor is designed for teaching and learning about the CLI, while the commercial product and the Compact Framework are geared to support the development and deployment of high-quality commercial software. In the case of the Compact Framework, the runtime environment is small form-factor devices, while for the .NET framework (CLR), it is PCs and servers with plenty of RAM and disk.
The CLR, as a commercial runtime, has a number of features that are designed to support commercial software vendors, enterprise customers, and Microsoft-specific initiatives such as COM. These are not found in either Rotor or the Compact Framework.
The Shared Source CLI, which is the one that I currently work on, is designed for non-commercial teaching, learning, and experimenting with the CLI?it is distributed in source code form and is both portable and easy to modify. It has a different JIT strategy, and a more approachable garbage collection implementation. There are other differences, but I think that this will help you to understand the differences between our implementations at a high level.
Ideally, on all platforms. Ximian will make sure we run at a reasonable speed on x86 systems, so a lot of our work is on optimizing our code generator for the JIT engine. Third parties have contributed ports to other systems, and we will likely be working on a SPARC or PowerPC JITer ourselves in the future. We have not decided yet which platform will be next.
Portability has been designed in from Day 1. It already runs on GNU/Linux, Windows, FreeBSD, Solaris, 64-bit Solaris, and (soon) MacOS X, among other OSs. (MacOS X is held up by a bug in a third-party package, not my code). Basically, if you can get GCC (Gnu C Compiler) on the platform, then porting my engine and C# compiler should take no more than a few days. Portability is fundamental to me; I try to build it in rather than leave it for someone else to tackle.
Currently, FreeBSD 4.5 and Windows 2000/XP. It can be ported to other platforms by changing the Platform Adaptation Layer (PAL).
Yes. Many developers use Mono purely, while others are still using a combination of Microsoft and Mono. Sometimes to isolate bugs it helps to be able to pinpoint where the problem originates: our compiler, our JIT engine, our class libraries. So we try to keep things fully compatible. As soon as we can point out an incompatibility, we file a bug report to fix it later on.
Of course. Interoperability demands that I do. Currently, because my C# compiler isn’t finished yet, I’m building my C# library with Microsoft’s compiler, and it runs fine on my engine. I’ve also tested (simple) programs built by my compiler on Microsoft’s engine and they work.
We compiled and ran simple applications that don’t rely on legacy (native) libraries, and we found those applications were binary portable between Windows and FreeBSD, so long as all the classes and methods they used were defined in the SSCLI Base Class Libraries (BCL).
This is an interesting question, because the CLI itself was designed with a philosophy that embraces platform differences. Unlike some virtual execution environments that try to sweep significant platform differences under the rug, the CLI specification is meant to allow for fantastic interop with “unmanaged” native platform features. What this means is that people that want to build portable frameworks are able to implement by depending only upon the core CLI, while people who want to exploit the features of a specific platform are able to implement using these features directly. Both kinds of framework can be used seamlessly together?programmers have access to the entire spectrum of solutions.
With that in mind, it is definitely true that the “Windows Forms” framework makes extensive use of native Windows as a substrate. If there were a CLI implementation on the Macintosh, for example, I’d imagine that as a programmer I’d want to see a great Cocoa framework available to me. I’d rather not see Windows Forms. Likewise, on Unix I’d rather see KDE or GNOME widgets than Windows. “Universal” client-side UI frameworks fill a role, but only one of several. I hope to see people who currently make such frameworks make them interoperable with the CLI. It is certainly possible; we have a very rudimentary TCL/TK sample framework built on top of TCL/TK that is part of the Rotor distribution, for example.
Think of the CLI in the same way that you think about the C runtime; it contains a small set of important facilities for which it makes sense to have universal access. But it does not try to hide the things that differentiate platforms from each other.
Mono will be the equivalent of the .NET framework: compiler tools and runtime environment for applications (Console, WinForms, ASP.NET). We will work with third parties to integrate the development environment into their product. Some people like SharpDevelop because it is a light-weight IDE written in C#. Other people like Eclipse/WebSphere and NetBeans/Forte, which are both in the Visual-Studio kind of realm: larger systems, but with a more complete set of tools for professional developers.
Eclipse and NetBeans both have open-source communities built around those and big companies backing the code (IBM and Sun, respectively), so you can see a fairly large amount of development going on there as well as many plug-ins and extensions that are available both commercially and freely.
This is a big difference from Visual Studio, because anyone can write IDE extensions with these projects (even with their proprietary brothers). Eclipse also has a Gtk2 user interface, which means that it is accessible and fully Unicode aware, and integrates nicely with GNOME. And finally, GNOME has its own Anjuta IDE, which is based around Bonobo components. Its goal is to integrate with the various existing GNOME components. It’s a lot more focused on building GNOME desktop applications though.
Eclipse and NetBeans are both cross-platform products, and in the case of Eclipse, the user interface matches perfectly the user interface in your target system, which makes it a lot more pleasant to start using it.
Being a Unix guy, I’m a command-line junkie. The Unix design philosophy is to have a large number of small things that can be used in combination, rather than one great big monolithic system. There are already several good IDEs for developing under Unix (e.g. Emacs, kdevelop). My tools can be used with them with no trouble. I expect that my tools will also be usable with the “SharpDevelop” IDE with a minimum of fuss.
There’s really no point in me wasting time developing an IDE, since the rest of the Free Software [Foundation] community has already done a better job than I ever could.
Because the SSCLI consist of command-line tools, any good text editor will do the job.
We have started work on all those three major components, but nothing is finished at this point. Windows Forms will be based on Gtk# [the language binding for .NET] for Unix systems, and on Cocoa for MacOS X. ASP.NET is something that we just started looking at, but with the help of Patrik [Patrik Torstensson, a Mono contributor] we got a long way.
I am not directly supporting these, but Mono will be. The DotGNU Steering Committee recently made the decision to write low-level C# class libraries for use with our engine, but to use the upper-level Mono class libraries for everything else; i.e., PNET is focusing on building a solid foundation, and then we will share the burden of developing the higher-level stuff with Mono.
The ECMA specification of .NET BCL (Base Class Libraries) is a subset of the BCL found in the commercial Microsoft .NET platform. SSCLI only implements these ECMA specifications, therefore .NET features such as Window Forms, COM Interoperability, ASP.NET and ADO.NET aren’t currently available in the framework.
Sure are! We will continue to improve and enhance our .NET commercial offerings. I know that the ECMA standards group is continuing forward as well. We are still polishing the first release of the Shared Source CLI as well?it is currently a beta-quality implementation.
Although Ximian has one specific concern?to ease the development of applications for Linux and to ease the migration of developers from Windows to Linux?other contributors (which are responsible for a large body of the code in Mono) might have different interests. So it is hard to answer your question briefly; as with any other open-source/free software project, the interests of the groups are wide and different.
Right now, developers and academics who wish to work on and study the implementation of CLI systems. The CVM and treecc systems are particularly interesting to academics because they take a new and novel approach to designing this kind of system. Eventually, anyone who needs to develop and run CLI apps on non-Windows platforms will find Portable.Net useful. I’m building the best possible CLI I can, for the benefit of the whole community. I’m using my extensive experience in VMs and compilers to do a good job.
This is best described on this page on MSDN, which says ” Microsoft has built the Shared Source CLI so that researchers, students, professors and other interested developers…”
A certification program of some form might prove to be useful in the future, but it seems to me that this would be best addressed from ECMA with Microsoft participation, rather than from Microsoft unilaterally.
We do not have any dates to announce at this point.
I am notoriously bad at giving such estimates. Free software doesn’t really work to a fixed schedule anyway. I’m hoping to have the runtime and compiler “feature complete” this year, with most of the basic libraries in place. Then I can focus on performance (e.g. JITs).
Right now, it is like a big jigsaw puzzle with a lot of parts put together on the edges and in the middle. What I need is a “bridge” across the gap and it will go much quicker after that.
It’s already been released.
Ximian has five full-time developers working on various Mono components. And about 90 people have contributed code to the Mono project during the time it has been under development. Contributions have perked up as Mono has advanced, as the project becomes more useful for other people, and the full open-source effect [is coming] into play.
Most of the work has been done by myself, with about three to four other people donating time when they can. Things are starting to pick up, with more people becoming interested in contributing to the project. It’s important to note that the number of people on a project doesn’t necessarily equate to quality of implementation.
We were part of a larger team. For an official number, ask Microsoft.
All of the various CLI-based efforts at Microsoft come from the same team, which is quite large. The team working on the Shared Source CLI itself is small, but we stand on the shoulders of our colleagues, many of whom have done a lot of heavy lifting for us!
The compiler is under the GPL license, the runtime is under the LGPL license, and the class libraries under the X11 license. We have considered re-licensing the runtime and the compiler under licenses that are more suitable for commercial/embedded developers if they wish us to do so, but so far everyone seems pleased with our licensing choice.
GNU General Public License, with a special linking exception to allow non-GPL apps to be run on the platform. The GPL protects both freedom and the intellectual property of the authors much better than any other license. DotGNU is currently looking into perhaps using the LGPL on some parts, but whatever license we use, it must protect the authors’ and the users’ freedoms.
Microsoft released it under its own Shared Source License. A copy of the license can be found here: http://msdn.microsoft.com/msdn-files/027/001/901/ShSourceCLIbetaLicense.htm.
It has been an extremely fun project to work on, and everyone who has contributed to Mono has made every minute of it a worthwhile project: from the people writing code, to the people providing CVS mirrors, to the people who have set up the daily builds/snapshots, to the people teaching you new assembly tricks, to those answering questions on the mailing lists. So, it is hard to tell what is frustrating.
Lack of resources, mainly. We need more good people to donate their time, or a sponsor to help pay to hire some good people. The technical side doesn’t bug me.
We’ve been quite happy with this [SSCLI] project in general; my biggest frustration has been the guarded attitude with which some people in the open-source community have taken towards our project. We are sincerely trying to promote adoption of the CLI. That seems straightforward.
Well, I have made some friends at Microsoft, but I do not know if they are acting as official Microsoft representatives or just plain good friends. So far those people I have met have been very nice and helpful.
I haven’t gotten any support from them, and the ECMA is closed off to non-paying parties, so (on a scale of 1 to 10), 1 out of 10.
Not applicable, because we were part of the team with Corel.
In addition, many users of the commercial product have downloaded the Shared Source CLI in order to understand the commercial product better.
I cannot think of something right now.
The ECMA spec is definitely vague. There are some things that it doesn’t describe at all (e.g., how to use PInvoke under non-Windows systems). I implement the most plausible version, check what Mono has done (if anything), and sometimes write test programs to probe the other implementations to get a feel for how they operate.
The team developing the ECMA spec tried very hard to ensure that this is not the case, and I know that they would welcome feedback and questions from people who are trying to build their own implementations. The Shared Source CLI and Mono are also great resources to use for discovering more about implementation choices.
Yes, as detailed above.
PInvoke for non-Windows, as I described above. Also, ECMA only describes a tiny subset of the .NET framework SDK. To interoperate with Microsoft, it will be necessary to implement a large number of non-ECMA classes. This is Microsoft’s fault for not building a complete specification. I have no plans to deliberately “embrace and extend” the CLI, except where it is absolutely essential due to platform differences.
The Shared Source CLI is an implementation of the ECMA specification, plus some other tools.
We made a number of purely practical choices regarding frameworks that are not part of the spec. In some cases, we included additional code because our implementation started from the commercial codebase, and would not work without these pieces. In other cases, we knew that the ECMA standards team had thought about adding support for something (regular expressions, for example), and that it would be useful to have these features in the distribution.
Mostly Cobol, especially for the JIT engine.
C for the runtime engine and compiler, C# for the library. Writing the compiler in C gives me a system that performs very well, and is “self-bootstrapping.” That is, it will not be necessary to bootstrap myself off another CLI implementation. I will be able to release the entire product in source form, and users can build from there. There’s more information on this in the PNET FAQ.
Microsoft used C#, C++, and C. C# is used for the BCL; C++ is mostly used for the CLR and C for the PAL (Platform Abstraction Layer).
[The SSCLI] implementation is written in a combination of C++ and C#, with a small but important smattering of assembler. Large portions of the BCL are written C#, as is the JScript compiler that is part of the distribution. I’ve not tried all of the CLI-based languages against our implementation, but I know anecdotally that at least some of them run without modification.
I am certainly not the right person to ask on this question, and even if I were, I would be unlikely to be able to answer, since the Microsoft patent portfolio is large and constantly changing, and many patents aren’t granted for years after they are submitted.
It is important to point out that the reason that Microsoft participated in creating ECMA 334 and 335 is precisely so that others will be able to create their own commercial CLI implementations. Microsoft is very interested in seeing many CLI implementations succeed. To this end, Microsoft has said (for literally years now) that implementers of the spec will have royalty-free access to Microsoft intellectual property that might otherwise stand in the way of their implementing these standards.