Miguel de Icaza Explains How to "Get" Mono

It's perhaps the most controversial project in the open source world, but this mostly stems from misunderstanding: Mono, the open source development platform based upon Microsoft's .NET framework. Immediate reactions from many dubious Linux developers have ranged from confusion over its connection with .NET to wondering what the benefits of developing under it are.

Throughout the course of Mono's four years of intense development, sponsored by Novell, founder Miguel de Icaza has had to frequently clarify the .NET issue and sell the community on it. But the project's heart has always been, he explains, about making the lives of Linux developers easier: "One of the reasons that we developed Mono was because we wanted to have better tools to develop software." (Figure 1.)

Vice president of developer platform for Novell in Boston, de Icaza, 32, took a moment to discuss with us the primary legal concerns and technical issues with Mono, its current and near-future status, and why you should consider developing your next project with it. For those of you who are still unfamiliar with Mono, consider this interview a definitive, quick-and-dirty primer.

Figure 1. According to de Icaza, the Mono platform was devised to make software development easier. Here we see F-Spot, a photo management application for the GNOME desktop that was developed under Mono.

Oreilly.com: Let's clear this question up right off and get this out of the way. It's the one thing many people continue to misunderstand about Mono: What exactly is Mono's connection to Microsoft's .NET?

Miguel de Icaza: .NET was a company-wide branding effort at Microsoft that spanned multiple projects.

Mono is most similar to one component of it: the .NET framework. We are an open source implementation of the virtual machine, the C# language, the base class libraries, and we have a compatibility stack (ASP.NET, ADO.NET, and Windows.Forms). In addition to that, Mono has produced a very large set of extra libraries.

Oreilly.com: Let's say I'm a Linux developer but still have doubts. So tell me, why should I develop with Mono instead of going the traditional route (i.e., C++)? What are the advantages, technically?

de Icaza: I classify C# as a component-programming language: a language that is particularly well suited for medium-to-large applications, where multiple developers contribute; where having a strict compiler, strong typing, and contracts/visibility are tools that help developers reduce the bug counts and reduce mistakes.

Even if C# is not your favorite language, you can use other third-party languages [with Mono]--Java, Python, JavaScript, VB.NET, Fortran, Cobol--and you can reuse existing code from C and C++ very easily.

A few of the attributes that Mono [has] over traditional environments are:

• Easy to integrate with native libraries: The Platform/Invoke feature allows developers to call into native operating system libraries without having to write glue code.
• Automatic memory management: Using a language with a garbage collector is a great productivity gain, as developers can focus on real problems instead of fighting with the circuitry every time.
• A feature-full runtime: The runtime provides many features to applications running on it, from a thread-aware and thread-safe set of libraries to built-in garbage collection.
• Modern APIs: The industry has learned a lot about OO API design in the last few years; this are now available for developers to use in a nice package.

Oreilly.com: Could the code that the Mono team has been developing be reused for other projects?

de Icaza: All of our code is open source, so it can be used for other projects. The compilers are GPL. The virtual machine is LGPL, and the class libraries are MIT X11. I know of at least two uses of our C# compiler for research.

Our class libraries are regularly copied-and-pasted into other projects, as they fill a large void in the compact framework world, where the class libraries are fairly incomplete.

Oreilly.com: What are the inherent issues one needs to keep in mind when developing code under Mono?

de Icaza: If you are developing cross-platform code, it is always important to test your application on the target platforms that you are using (Windows, Linux, and Mac OS, for example). Mono is not able to hide all the details of each operating system, and details about it might bubble up (like the path-name separators, the case sensitivity of files, the behavior of deleting an open file, etc.). (See Figure 2.)

At Novell, we have set up a continuous build process for Mono and its tools that not only builds Mono, but also runs an extensive test suite. This is done in multiple platforms at once. Running the test suite like this allows us to catch problems when they are just introduced.

We have tremendously enjoyed user contributions in the form of bug reports. If you find a problem with Mono, we really want to know about it, so it can be solved.

Figure 2. Demonstrating the cross-platform versatility of the Mono development platform, the Mono-based IDE MonoDevelop is shown here running on Mac OS X

Oreilly.com: What is the current status of Mono?

de Icaza: Mono 1.0 was released last year. After releasing Mono 1.0, we started work on a new edition of Mono that will be released later in the year.

Mono [1.0] today consists of three groups of components:

1. Core components: Virtual machine, C# compiler, base class libraries. These are based on the ECMA 334 and 335 standards.
2. Mono/Linux/Gnome development stack: A set of class libraries that complement the core and provide a wide range of tools for developers.
   • GUI development tools with Gtk# that integrate natively with the GNOME desktop. This is our recommended path for developers creating GUI applications on Linux.
   • Mozilla libraries to allow people to create applications with the Gecko Rendering Engine (GRE) with Mono.
   • RelaxNG: A new and simplified XML schema language.
   • A complete security stack: This is a superset of the features available on the .NET framework.
   • Database providers for both open source and proprietary databases: Postgress, MySQL, Sqlite, DB2, Sybase, and ODBC.
   • Unix integration libraries: For people who want to use the low-level Unix system interface.
3. Microsoft compatibility stack: A stack of libraries that allow developers to port their existing software from Windows to Linux. This includes ADO.NET for database access and ASP.NET for SOAP and WebForms applications.

Oreilly.com: What do you have planned for the next version?

de Icaza: The new release of Mono is scheduled to improve upon Mono 1.0 in the following areas:

1. Windows.Forms API: This is part of the Microsoft-compatible stack. It is used by programmers on Windows to develop client applications with .NET. With Mono 1.2, we will allow people to bring their existing GUI applications to Linux.
2. C# 2.1: The new edition of the C# specification includes many new features that we now support: generic types, anonymous methods, iterators, fixed buffers, covariant/contravariant delegates, per-accessors access levels, and a few smaller changes.
3. 64 bits: At this point we have two full 64-bit ports: the SPARC v9 with Solaris and the AMD64 port.
4. New ports: S390, AMD64, and a few more variants of the PowerPC architecture are added to the list of back ends.
5. JScript and Visual Basic open source compilers: These compilers will only be available as beta compilers at the time of the release. These are just convenient tools to have a complete self-hosting system; developers can still use third-party compilers on the Windows platform to compile their existing code in the meantime.
6. Virtual machine upgrades: Mono 1.0 was about being as feature-complete as possible. In 1.2, we are tuning various key elements of the virtual machine:
   • A new, stronger code optimizer that offers many optimizations only found on advanced optimizing compilers, like SSAPRE/GVNPRE for redundancy elimination, arrays bounds checking, many peephole optimizations, and inlining of common operations.
   • Garbage collector tuning: we have tuned the garbage collector extensively, and it will now be operating in mostly-precise mode. The result is less memory consumption: long-running applications do not tend to bloat, and it is the first step in the way of having a compacting collector.
   • Memory consumption reduction: Mono's memory consumption is lower than ever, and for GUI applications, it actually consumes less than the equivalent programs written in Perl or Python. It has been an important goal of us to reduce memory usage in Mono. Java, in particular, made people afraid of large virtual machines, and we are working very hard to avoid giving anyone that impression.
   • Ahead-of-time compilation: Although present in the Mono 1.0 release, this feature that is used to basically pre-compile all of your bytecode into native executable code has been vastly improved. In Mono 1.2, we redesigned it not only to minimize the run time, it is now designed to minimize memory usage by having multiple Mono processes share the same pre-compiled code by using position-independent code. This is important when people are running multiple Mono applications on their desktop.
7. Java support: The IKVM runtime for Java is now part of the Mono 1.1. x releases. Thanks to the help of Jeroen Frijters and Zoltan Varga, the support for IKVM in Mono is now superb. It is possible to mix Java code and C# code in the same application and consume the most exciting pieces of Java components from Mono applications today.
8. Gtk# improvements: The binding has been improved and now also supports new versions of Gtk+. The improvements are too many to list, but we are using it actively on some projects, like MonoDevelop and Stetic.
9. Documentation: We continue to consider documentation as key to Mono, and our Wiki-like documentation system has been great in allowing developers to correct and update the documentation we ship.
10. Cocoa#: This is an application stack for OS X developers that want to use the C# and the CLI to develop native OS X applications, very much in the same spirit that Gtk# is used to develop native Linux applications.
11. Another effort we are working on is a certification program of third-party components and compilers. This will help potential users pick components for their applications and have their components supported by the producing companies.

Oreilly.com: What have been the biggest development challenges the Mono team has faced?

de Icaza: I think every aspect of the system was fairly hard. Nobody in the team had built something of this size and scope before. It has been four years of very intense activity.

The code generator was a large project. The batch compiler was another one. The web services stack, the Gtk# binding, the WebForms framework, our Apache integration, our C# compiler, the Tds and database providers have challenges of their own.

Oreilly.com: What would you like others to pay notice to the most about Mono?

de Icaza: We are making Linux a fertile ground for third-party developers: we are allowing developers with Windows/.NET expertise to use and distribute software for Linux, easing the adoption of Linux.

Oreilly.com: Personally, what motivates you to keep working on Mono?

de Icaza: A fantastic community of developers, users, and friends that make up Mono today. Many products at Novell are now using Mono: iFolder, ZenWorks, F-Spot, and Stetic. [Knowing that] seven of the 20 top-rated applications on GnomeFiles are Mono-based. (Figure 3.)

Figure 3. Muine, a music player, is another GNOME application that was developed with Mono

Oreilly.com: What about the legal concerns/patent issues with Microsoft's .NET? How do you clarify these issues and questions that many developers still have about Mono's connection to .NET?

de Icaza: Every piece of software written today is likely going to infringe on someone else's patent. Sometimes the infringement is serious; sometimes it is not. This depends on whether the patent that was granted was valid (i.e., it did not exist before, and it was not an obvious extension to something existing). The software patent problem is not limited to Mono. Software patents affect everyone writing software today.

Our strategy in dealing with patents in Mono is the same strategy that any other software developer would take. In the event of a patent claim, we will try to find prior art to the claim of the patent. If no prior art can be found, we will try to find an alternative implementation that will not infringe the patents. If none of the above can be done, we will remove the infringing code from Mono.

Dealing with the last bit, what happens if we have to remove functionality from Mono? One option is to have the compiler recommend the use of a different set of APIs [or] ship tools that can convert existing code to use a different set of cross-platform APIs.

At this point there are no concrete, validated patent claims that we are aware of [with Mono].

Howard Wen is a freelance writer who has contributed frequently to O'Reilly Network and written for Salon.com, Playboy.com, and Wired, among others.

Related Reading Mono: A Developer's Notebook By Edd Dumbill, Niel Bornstein Table of Contents Index Sample Chapter Read Online--Safari Search this book on Safari:   Only This Book All of Safari Code Fragments only

Return to ONDotnet.com.