In July 2001 we announced the launch of the Mono Project ­ an effort to build an open-source implementation of the Microsoft .NET Framework using the technical documents that Microsoft submitted to ECMA (the European Computer Manufacturers Association) for standarization.

Eighteen months later, we have achieved quite a bit: we have an implementation of the Common Language Infrastructure (CLI), a C# compiler, and roughly 3,500 classes at various degrees of completion.

In this magazine it is not necessary to rave about the greatness of .NET and how it simplifies the development process, nor the pleasure you receive from writing new code in the C# language and being able to morph and model your code rapidly to improve it, and to quickly expand it.

The original team at Ximian that set out to build Mono and create its vibrant community was interested in bringing this pleasure and these programming improvements to the Unix world, where we have spent the past few years building a platform, a desktop, and a set of desktop productivity tools for Unix.

Mono was initially led by Ximian, and has since grown up to be a team effort by many international programmers and contributors. To date, roughly 200 people have contributed code, documentation, patches, and their time to the project, and a little more than a hundred have direct write access to our shared source code repository.

Mono is useful today to create a wide range of applications, but it is not yet a complete drop-in replacement to .NET. (For more details about the current efforts, please read Dennis Hayes' article in this issue of .NET Developer's Journal.)

As I often discover, different people on the Mono team contribute to the effort for different reasons. From the beginning, the Ximian team was interested in bringing better development tools to the Unix world, and the Microsoft .NET technology was the best match with our vision: component software, reusable software, increased productivity, raising of the programming level, and cross-language interoperation.

Other motivations to join the effort come from those who want to use Linux or Unix as a deployment system. Some people have existing non-Intel servers; others like the price features of Linux or the BSD operating system and would like to deploy applications on those systems for both clients and servers (the Linux client market is stronger in markets where desktop computers became affordable only recently).

Since Linux and Unix are relatively strong on the server market, it makes sense to bring the .NET technologies to them, and developers who in the past have been excited about .NET and have built .NET server applications want to bring their products to Unix. A few companies have announced that they will use Mono for distributing their products. At the time of this writing, OpenLink, Tipic, and Winfessor have done so. These companies contribute to the Mono effort with new code, improvements, and bug fixes.

Also, we foresee that many developers in the Windows world will be drawn to .NET as it vastly simplifies their problems. We would love these developers to be able to make their code cross-platform by adding Mono into the mix. This compatibility has also brought a fraction of the developer base. Today many .NET applications work out of the box on Mono. As long as you use only classes that have been implemented, you will be fine (we track those classes on our Web site, and you can check whether your particular class has been implemented or not. A tool that does this programatically would not only be possible, but certainly useful, and a great chance for anyone who wants to get involved to start with).

And there are also enthusiasts: people who love .NET, people who want to implement things on their own to learn, people who like to see a new little universe created, and people who like the community that has been built around Mono. These people are examples of who makes up the Mono community.

I want to stress this point, because more than a technological project, Mono is a people project; without the help of a very enthusiastic team and a fascinating community, Mono would not exist. Of course, the willingness of Microsoft to publish and standarize the core specifications plays a significant role, as well as the readily available documentation for most of the .NET components.

Mono-Specific Developments
Although the core of the project focuses on a reimplementation of the .NET Framework classes, various developers have used Mono to create their own class libraries both cross-platform and with a Unix focus.

The Gtk# team (pronounced GTK-sharp) has built bindings for most of the GTK and Gnome APIs for Unix and Windows. These bindings let people build GTK and GNOME applications, but they also take advantage of the .NET Framework to simplify deployment (we can use embedded resources, for example) or coding (like using attributes, events, and delegates to write code) ­ a truly welcome improvement to the Unix developer toolkit.

The Mono.Data team has not only produced plenty of database providers beyond those provided by the framework (which work on Unix and Windows), but has also produced a database multiplexer to simplify the development of cross-database applications.

Recently, a module for Apache has also been built: this module embeds the Mono ASP.NET runtime into Apache, which will ease the deployment of Mono-based Web applications for those using this server.

There are more examples, but I won't go into the details. Check the project Web site for further information on the OpenGL bindings, Vorbis bindings, guile/scheme bindings, and mPhoto. The Mono runtime also provides a number of features, such as profiling, memory usage profiling, and coverage analysis.

New Developments
We continue to work on stabilization and conformance with the .NET Framework, and we will be closely tracking the upcoming changes to the C# language as well as the generics extensions to the CLI to bring these new features to our platform.

A couple of major developments are currently under way: a managed/unmanaged debugger written in C# and a new just-in-time (JIT) compiler engine for Mono.

The debugger is unique for us because it allows the debugging of managed, unmanaged, and managed/unmanaged mixed applications. Theoretically the debugger should also be easy to port to more architectures and operating systems, as everything has been cleanly isolated.

Although the current JIT engine is sufficient, and has done a good job, we are interested in improving its performance. We had implemented some optimizations on it: constant folding, inlining (a bit limited), and some per-CPU optimizations. To implement the more agressive optimizations that people expect from compilers we needed to make many changes to our code. We did not want to complicate the existing JIT design, as it was not really designed as an optimizing compiler, so we chose to build a new one with performance in mind.

The new JIT engine has two levels of intermediate representation (and due to some optimization on this representation, it is faster at the regular optimization level than the current JIT). This new representation lets us perform different kinds of optimizations at both levels. A couple of optimizations have already been implemented with a pluggable architecture, but this new design was driven by the desire to make static-single-assign form optimizations.

The new JIT engine may be released by the time you read this.

Joining the Effort
Mono is not finished and can use more help at various levels. You can find the details on how to contribute at our site: www.go-mono.com/contributing.html.

Contributing to Mono spans pretty much all aspects of software design and implementation; it is not limited to writing new classes, fixing bugs, or doing performance and memory tuning. If you have time to volunteer, and you want to join a vibrant community, we would like to help you join the project.

The Mono mailing list (mono-list@ximian.com) is a good place to get involved with the project, or if you prefer a more interactive approach, you can try the #mono chat room on the irc.gnome.org IRC server.

References