Related Topics: Java EE Journal, Apache Web Server Journal

J2EE Journal: Article

Linux - Mono - .NET: An Exclusive SYS-CON.TV Interview With Miguel de Icaza

Mono is the leading non-Microsoft implementation of the Common Language Infrastructure (CLI) specification

Mono is the leading non-Microsoft implementation of the Common Language Infrastructure (CLI) specification. The CLI is the foundation of .NET. Because Mono runs on a number of platforms, it is the main choice today for people who want to run .NET applications on non-Microsoft platforms such as Linux.

 .NETDJ's editor in chief recently interviewed Mono's creator, Miguel de Icaza,  directly at the Microsoft headquarters in Redmond, Washington!

.NETDJ: How did Mono come about?

MI: I have been working on open source for a very long time. I don't remember exactly how long - maybe since 1992. The genesis of Mono lay in the creation of the Gimp project, which was intended to bring usability to Linux. This was around 1997.

Mono was initially a response to all of the needs that we saw in trying to implement our desktop software. Today Mono has morphed into its own thing. It is still all about a desire to make Linux successful on the desktop.

.NETDJ: How will Mono make Linux successful on the desktop?

MI: With the Gimp project, we were coming from a background where we were building applications using C. We had a strong feeling that we really wanted to raise the programming level so that developers wouldn't need to bother about things like allocating their own memory. In figuring out how to raise the language level, we really wanted to be language agnostic.

.NETDJ: How did you think you could manage that in 1997?

MI: We tried two different directions. First, we did language bindings so that every time we created an API we would bind those to it in all of our supported programming languages. We had this idea that a platform shouldn't mandate the languages people have to use in order to leverage it.

The other approach was that - as we wrapped large APIs (course APIs) - we tried to define them using CORBA IDL. There was CORBA support available for a bunch of different languages so, by exposing our APIs via CORBA, we were able to support a bunch of different languages.

.NETDJ: What was wrong with that approach?

MI: The problem with the CORBA approach was that -- while CORBA is very good for course-grained interfaces - it is not very good for fine-grained interfaces.

The problem with the other approach was that doing manual bindings was very cumbersome. If we stayed with the manual language bindings approach, an API introduced today wouldn't be available on all supported languages for six months!

.NETDJ: So, how did this lead to Mono?

MI: We had just completed an application called Evolution (very similar to Outlook), that was completely written in C and which used a lot of CORBA. During development we found that it was extremely painful to debug a multithreaded process using C and CORBA.

As we were about ready to ship version 1.0 of Evolution, we wanted to see what we could do to improve our process for its next version. This was about when Microsoft came out with .NET and Microsoft had put a lot of focus on making sure that their platform would work with multiple languages. They had actually gone through the time and trouble of writing down everything that people needed to do in order to have full language interoperability.

.NETDJ: In what ways did you feel that .NET could help your development process at that point?

MI: The major thing that we felt would bring productivity to our development efforts was its automatic garbage collection and support for multithreading. Beyond basic support for multithreading, most of the indigenous .NET APIs were meant for multithreading, unlike the other platforms we had tried.

There were also a couple of cute things like properties and events, which turn out to be very useful for user interface developers.

C# as a language had a very fun feeling - like Java, but with some additional features.

.NETDJ: Why didn't you just develop on Microsoft's existing implementation of .NET?

MI: We needed this thing on Linux, so we couldn't do that.

.NETDJ: Why not Java, then?

MI: Java was almost there, but it always felt as though there were things missing - C# had these!

Also, if you are going to build completely open source software, there are some distribution complications inherent in using Java.

.NETDJ: Once you decided to build an open source implementation of .NET, how did it progress?

MI: The first six months were the most interesting because a lot of projects die just in this initial proposal phase. People have good intentions but they don't have the time or the skills needed to get the work done.

We needed to get at least the basics done so that we could involve a larger community, but the responsibility fell mostly on Ximian. One of our groups started building an interpreter for CIL. This team worked 100 percent on Linux. They began, of course, by building everything necessary to interpret the standard "Hello World" application.

Our other group (which was at the time just me, and then a friend of mine named Raj) started working on a C# compiler. Our intention was to get the C# compiler to compile itself - "bootstrapping," it's called. This group worked mostly on Windows.

Once we got the compiler to compile itself, the guys on Linux were almost ready to run our stuff. In fact, they finished a little early, so they started building out some additional class libraries.

After approximately the first nine months, other people started contributing. Some people did the ADO.NET stack, and a lot of different people did database providers, which is why Mono has so many providers even today.

.NETDJ: Did you keep all of those initial bits, then?

MI: Historically we have had to go back to scratch on some things - like the XML portion. One of the lessons we learned from this process is that it was much better to write our tests first so that we had something to measure against and to see if we had introduced a regression error. Today, we require test cases for all fixes and bugs that are submitted. Currently we have about 60,000 tests for Mono.

.NETDJ: How did you wind up getting together with Novell?

MI: That was actually really interesting. It turns out that they were interested in three things from Ximian. First, we had this desktop product called Evolution.

Second, when we first started building Evolution, Linux didn't have an install system. So, we had had to develop one in order to properly distribute Evolution. This actually became one of the most important products for Linux, called Red Carpet. Novell was probably most interested in this because they wanted to enter the Linux market with their own suite of desktop applications.

We were having engineering meetings about this with them and - because they were doing their due diligence - it turned out that a couple of their products (particularly iFolder, a product for doing desktop file synchronization) were starting to use .NET. They really wanted to continue using .NET, but also wanted to offer these products on Linux. So, the people who were doing due diligence on Ximian got really excited about Mono, and that was the third thing in which they were interested.

It was basically a pretty good match between our two companies. After our acquisition, our team of about six people grew into 20.

More Stories By Derek Ferguson

Derek Ferguson, founding editor and editor-in-chief of .Net Developer's Journal, is a noted technology expert and former Microsoft MVP.

Comments (1)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.