Mono Versioning

by Miguel de Icaza

A common problem that I face is explaining to people the current situation of Mono. This is a problem of our own creation when we sketched the major milestones for Mono.

When we originally plotted the course for the Mono Roadmap things looked pretty simple, they were roughly like this:

Mono 1.0:

  • Ship the VM 1.0
  • Ship the C# 1.0 compiler
  • Ship System, Xml, Data, Drawing Web and Web.Services
  • Gtk# and friends.

Mono 2.0:

  • Upgrade VM to 2.0
  • Upgrade compiler to 2.0
  • Upgrade libraries to 2.0
  • Add Windows.Forms
  • Ship Gtk# 2
  • Favorite extra stuff (debugger, compacting GC, internal embedding API upgrade)

As you can see, we intended our versioning scheme to track the major Microsoft releases to expedite explanations of what level of APIs Mono supported. So Mono 1.x would be roughly .NET 1.x, Mono 2.x would be roughly .NET 2.x, Mono 3.x would be roughly 3.x and so on.

There is a bit more than just tracking the API, as you can see, there are really two dimensions to what we wanted to call Mono 2.0:

One dimension is the 2.0 compatibility with .NET, and another one has some internal goals of ours. For example, we considered that 2.0 was a good time to break the embedding API for the runtime and also to release the compacting collector.


There were a few factors that started to complicate our numbering scheme:

  • Our Windows.Forms implementation was lagging behind other class libraries (as writing a Winforms control requires much more work than say a Web Control).
  • Our desire to implement some major optimizations and improvements in the VM (improved code generation, AOT for 2.x, compacting garbage collection, switch to eglib-based public APIs, change in the embedding API).
  • Generics being a requirement for a lot of the 2.0 work that was necessary.
  • Microsoft releasing .NET 3.0 which was really just a new set of libraries that just ran on top of 2.0 (we track these in a separate project, called project Olive).
  • Microsoft releasing .NET 3.5 which is the actual upgrade to 2.0.
  • Some areas would be developed faster than others: sometimes this was due to planning, lack of planning, or big boosts in external contributions (for example, Mainsoft contributed extensively to making ASP.NET 2.0 and ADO.NET 2.0 happen, and they have been shipping their Grasshopper product since ~May).
  • We might not support the full API for a given assembly: there might be some features that do not make sense on Linux or features that will never be implemented (like System.Management).

By the time we shipped our Mono 1.2 last year, the problems with the simple versioning numbers started to show. Mono 1.2 included many features from 2.0:

  • C# 2.0.
  • Generics support in the VM.
  • A lot of the 2.0 support in the class libraries. (core, XML, Data and ASP.NET was almost done).
  • Support for Windows.Forms 1.0.

Almost a year has passed and we are about to release Mono 1.2.6, six releases after Mono 1.2. Compared to last year's Mono, this upcoming release is a major upgrade, we have since:

  • Completed most of the 2.0 support, including:
    • Completed C# 2.0.
    • Completed ASP.NET 2.x (modulo WebParts).
    • Completed ADO.NET 2.x.
    • Most of Windows.Forms 2.0 (about 80% of it at this point).
  • Implemented most of C# 3.0 (few tidbits missing).
  • Implemented LINQ, and LINQ to XML (.NET 3.5).
  • Implemented some other bits from .NET 3.5
  • A Visual Basic.NET compiler, and its runtime.
  • Added a Silverlight toolchain (.NET 2.1).
  • Added COM/XPCOM support to Mono.

From an API perspective, with the exception of Windows.Forms 2.0 we have pretty much completed the 2.0 support (what remains to be done is tracked here for the core and here for winforms).

In addition, some bits from 3.5 are being shipped in this upcoming version.

Since we continue to ship updated versions of Mono every 8 to 10 weeks we have only felt that we needed to update the smallest version number (1.2.6 is our upcoming release) each time.

My concern is that 1.2.xx does not really convey the feature set in Mono and some people get the wrong impression of where Mono is at. This problem is made worse because we have been using the simplified numbering scheme for years.

Just today someone emailed me asking when ASP.NET 2.0 will be released, another person asked about ASP.NET AJAX (supported in SVN, and in the upcoming 1.2.6).


We are looking for a creative solution to this problem.

Without using Mono versions, these are roughly the upcoming milestones:

  • Mono A: Estimated 3-4 months of work.
    • The core 2.0 done + ASP.NET 2.
    • 2.0 profile (minus Winforms) becomes officially supported.
  • Mono B: Estimated 6-9 months of work.
    • Windows.Forms 2.0 complete.
  • Mono C: 9+ months.
    • When the Compacting GC is done.
    • Make the runtime embedding API changes here.
  • Mono D: 9+ months.
    • When the new IR/optimization framework is ready
  • Mono E: 6-9 months of work.
    • When System.Core and other 3.5 libraries are finished; maybe we could even split this up in chunks.
  • Mono F: 12 months of work, Silverlight security features:
    • New security system (done).
    • StackOverflow protection (done).
    • Complete the Verifier.
    • Harden the Mono loader (for Silverlight).
    • Full runtime security audit.

    The order of the above releases is not necessarily the one listed above, and I used letters to avoid discussing the actual release numbers. Three of those (C, D and F) are difficult to come up with an estimate now.

    Massi advocate a model where for large Mono upgrades (ABI changes, like the GC and the runtime API change) we change the major version.

    This would mean that we could ship a Mono 1.4 at the time that the "core" 2.0 is done; A Mono 1.6 when Winforms 2.0 is done; A Mono 1.8 when the 3.5 APIs are ready; and Mono 2.0 when we do the GC changes. This proposal does not fix the confusion problem with "1.x" though.

    Marek has a slightly modified proposal: when we ship 2.0 minus winforms we call it Mono 1.8; Mono 2.0 includes Winforms, GC, ABI breakage; Mono 2.2 includes new optimization framework;

    Jonathan suggest that we could use the major version number to document what is the version number that we feel we can officially support. 2.0 means "2.0 minus Winforms" with an upcoming 2.2 version with Winforms support and 3.5 thrown in the middle at some point (you will notice that the Olive/3.0 discussion is not part of this decision making).

    Thoughts? email them to the devel group and CC me (

Posted on 29 Oct 2007


by Miguel de Icaza

George Moudry from the DB_LINQ team has just emailed me to inform me that his multi-database LINQ implementation for .NET is now MIT X11 licensed!

Posted on 28 Oct 2007

Rob Conery Joins Microsoft

by Miguel de Icaza

Wow. Rob Conery, the author of SubSonic has accepted a job to work for Microsoft. These are the highlights:

  • He will continue to work on Subsonic, paid by Microsoft.
  • Subsonic will remain open source.
  • Rob will continue doing his SonicCasts.
  • Subsonic will be playing an important role on ASP.NET's new MVC framework.


Now only Jon and Jeff remain independent after Mix 07.

[from Phil Haack].

Posted on 27 Oct 2007

OpenSource LINQ providers

by Miguel de Icaza

Microsoft upcoming .NET 3.5 and C# 3.0 have support for Language Integrated Queries (LINQ). This gives C# and VB users a SQL-like syntax right in the language to access databases directly. For example, this is now valid C#:

public void Linq1() {
    int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 };

    var lowNums =
        from n in numbers
        where n < 5
        select n;

    Console.WriteLine("Numbers < 5:");
    foreach (var x in lowNums) {

For more samples, check the 101 LINQ Samples.

There are a number of LINQ providers for different kinds of sources. For example, there is a built-in provider for things like arrays, collections and IEnumerables.

A more useful sample comes from Don Box, this is a program to extract the top ten read articles from an Apache log file file:

	var regex = new Regex(@"GET /ongoing/When/\d\d\dx/(\d\d\d\d/\d\d/\d\d/[^ .]+)");

        var grouped = from line in ReadLinesFromFile("logfile.txt")
                      let match = regex.Match(line)
                      where match.Success
                      let url = match.Value
                      group url by url;

        var ordered = from g in grouped
                      let count = g.Count()
                      orderby count descending
                      select new { Count = count, Key = g.Key };

        foreach (var item in ordered.Take(10))
            Console.WriteLine("{0}: {1}", item.Count, item.Key);

There is another provider for creating and consuming XML data: LINQ to XML. The LINQ distribution comes with a nice sample where many of the samples from the XQuery specification have been rewritten into C# with LINQ with code that is roughly the same size (which sadly, I can not find online to point to).

Luckily, we have implementations for both of these in Mono.

And finally there are providers for databases. Microsoft ships one that will integrate natively with Microsoft SQL.

Unlike the XML and in-memory providers, the SQL providers are more complicated as they need to turn high-level operations into optimized SQL statements. Unlike many object to database mapping systems that produce very verbose SQL statements LINQ is designed to provide a very efficient representation.

The Db_Linq is an open source project to create a LINQ provider for other databases. The project is lead by George Moudry and so far has providers for PostgreSQL, Oracle and Mysql.

George keeps a blog here where you can track the development of DbLinq.

Thanks to Bryan for pointing me out to this fantastic piece of code.

Mono users on Linux will now be able to use LINQ with open source databases from C# (in addition to our in-memory and XML providers).

Currently we are still missing some support in our compiler and our class libraries for this to work in Mono, but this will be a great test case and help us deliver this sooner to developers.

Update: A nice blog entry talks about Parallel LINQ. A version of LINQ that can be used to parallelize operations across multiple CPUs:

	IEnumerable data = ...;
	// Regular code:
	var q = data.Where(x => p(x)).
		Orderby(x => k(x)).Select(x => f(x));
	foreach (var e in q) a(e);

	// Parallelized version, add the "AsParallel" method:
	var q = data.AsParallel().Where(x => p(x)).
		Orderby(x => k(x)).Select(x => f(x));

See more details about the above in the Running Queries On Multi-Core Processors article.

Update2: Am not up to speed in the databases vs object databases wars, but am told that there is also a LINQ binding for NHibernate. A sample is here.

Posted on 24 Oct 2007

Cardboard Regatta

by Miguel de Icaza

Today, before lunch Aaron, David, Jeff, Michael and myself went to the Carboard Regatta at MIT, the Head of the Zesiger competition.

A perfect complement for the Head of the Charles this weekend. Here are some cell-phone pictures of the event:

The Black Pearl:

The winner was a cardboard boat called "Ship Happens" that looped the swimming pool twice without sinking. All other boats sank. The "Titanic" award was given to the "Unsinkable 2" ship.

Here is "Ship Happens":

Everything sank, except for "Ship Happens". I suspect that the cleaning crew was as surprised as I was to see one of the boats disintegrate so quickly into so many little pieces that went to the bottom of the pool.

Posted on 19 Oct 2007

JIT Updates

by Miguel de Icaza

For people interested in JIT technology, there are two great posts this weekend from folks in my team.

JIT engines have some great properties, but unlike batch compilation they suffer from having to cope with code generated dynamically. Paolo talks about the memory reduction tricks that he has implemented in Mono.

The tricks are related to the temporary thunks that are generated during JITing ("trampolines"), and some future directions to reduce memory usage in the JIT even more.

Mark talks about his ongoing work to implement generic code sharing. Unlike Java generics that are a language feature, .NET generics are a virtual machine feature. Each approach has its pros and cons. In Java you only JIT the code once, and every generic instantitation reuses that implementation (because it is really a language feature); The .NET approach makes for simpler use or generics and better performance, but it comes with a price: new instantiations of the generics class need to be re-JITed.

Mark discusses his ongoing work to share generics JITed code (when two instantiations of a generic type would generate the same code, say when the sizes and semantics of the types are compatible).

Posted on 15 Oct 2007

Moonlight at the Boston Remix Conference

by Miguel de Icaza

On Monday I joined Brad on stage at the Boston Remix conference to show a preview of Moonlight.

As you can imagine, after years of working on Mono, I was pretty excited to be able to show our work at a Microsoft event.

Brad blogged a summary of all the things that he showed on his keynote here. I was familiar with some of the stuff there, but there were various new things, like the ComponentOne controls for Silverlight 1.1 (they are similar in spirit to Flex: you get some high-level controls that you can use with your Silverlight applications).

Videos of the keynote have been posted, see this page for the videos. The Moonlight section is covered here.

I was running development versions of both Mono and Moonlight (SVN as of 24 hours or so) and you can see that some of the performance tuning that has been going into the Mono runtime (Paolo has not blogged about it, but Mono 1.2.6 will have plenty of performance improvements in the JIT and the memory consumption keeps going down).

I showed the Chess game and you can see from the numbers that Mono running Chess is now getting similar scores as the .NET runtime gets on similar hardware.

Brad also gave us a copy of TopBanana in advance, and everyone in the team worked hard to get it ready for the show:

Lastly, I got a chance to show the Compiz Cube to the audience while playing some videos with Moonlight from the Halo web site.

It was the old cube, the one that we shipped with SLED, but still it makes for a good demo. On my Tuesday session, I borrowed a machine that had more up-to-date software to show the latest Compiz.

Q and A on Moonlight

On Tuesday I had a session on Moonlight (the slides are here).

One of the problems that I face with my presentations is that am not good at transitioning from the presentation to the questions and answer part of it. I always enjoy the questions and answers more than the presentation, and somehow I always botch it by reaching the end and asking "Questions?".

This presentation was quite fun, because the audience asked a lot of questions as I did the presentation which made the presentation a lot more interesting than the slide deck shows.

This was mostly a Windows audience, and I took the chance to show them the Linux desktop, the Mono/.NET compatibility, the MonoDevelop IDE, showed internationalization on Unix, the automatic right-to-left support and automatic layout of desktop apps and a few other features of Mono-based apps on Linux.

Silverlight Performance

On Sunday I had the chance to meet Seema Ramchandani who is a performance PM on Silverlight. On her blog she has some useful hints on how to improve the performance of your Silverlight apps (here and here).

Posted on 11 Oct 2007


by Miguel de Icaza

Mark Pilgim shares his opinion on his managed expectations on the iPhone.

Love the post, worth reading from top to bottom.

But what is really interesting is that the majority of the replies to that post are incredibly insightful, worth reading as well. How does Mark manage to get this much of an educated audience?

Update: correction, as you keep reading the blog, the crazies come out of the woodworks. I guess we are doomed.

Posted on 05 Oct 2007

Mono Summit, Spain

by Miguel de Icaza

We will be holding the Mono Summit in Madrid Spain, from the 26th to the 30th of November. Five days of Adventures in Open Source Managed Code and tapas sampling.

The first two days are focused on project planning and discussion among the active contributors to the Mono and Moonlight projects (contributors and employees).

The second three days are more general, these are for users of the Mono project: the application developers. In these days we will have some talks and tutorials on what we have been doing, what is available since the last year, meet-the-experts discussions and to present our roadmap and plans that we discussed in the first two days.

This is a good time to introduce a gorgeous Moonlight logo that was designed by Tony Alexander and Miguel Liberero on the Mono-Olive mailing list.

I will be working on an agenda in the next few days and post it next week on the Mono web site.

Alejandro Sanchez and Juantomas worked very hard to look for our venue, it was tricky to schedule in the original dates that I had planned ("sometime in October"). Thanks Alejandro and Juantomas!

Update Booking: Jonathan suggests that booking Sunday-to-Sunday gives you good prices, better than Saturday-to-Saturday, I have not checked.

I have been using myself to book trips recently, and it is my favorite so far.

Posted on 05 Oct 2007

A Journey Into the Dumb-o-Sphere

by Miguel de Icaza

It did not take long for the IT pundits to declare that having the source code available for .NET is either "a trap for Mono", "the end of Mono" or some similarly low accuracy per bit arguments.

It is amazing though, as some of these pundits are supposed to be covering "free software" and "open source" and yet, they know very little about history and how open source software is actually developed. More worrying is the fact that they could have researched this instead of sticking their foot in their mouth.

I was not going to blog about this, hoping that this would just go away, but I keep getting emails asking about these articles (which am not going to link to, you can google them up):

Lets look at Pundit #1:

Thanks to Mono, we now have the popular Linux programs such as the Banshee music player, Beagle search tool and F-spot photography program. With Mono, you can also now run Visual Basic programs on Linux. Mono is also working on porting Microsoft's Silverlight 1.0, a cross-browser, cross-platform plug-in for delivering richer Web user experiences in a project called Moonlight.

All of these programs are now in danger from Microsoft.

I know, I know, if you just look at the headline, the executive summary, "Microsoft opens up .NET," it sounds great for Mono open-source developers. It's actually a death trap for Mono.

No, it is not a death trap for Mono.

It seems that Pundit #1 needs a history lesson on free software.

When GNU was launched in 1983 there were concerns similar to this one. In particular, a concern was what would happen to people that contributed code, but the code came from the wildly available proprietary source code?

To put things in perspective, at the time, Universities were getting source code licenses to ATT's Unix and it was wildly available (by the 1980's standards of availability). It was important that contributions to GNU were not tainted by proprietary code that belonged to someone else.

I quote section 2.1 of the GNU Standards document on this matter:

2.1 Referring to Proprietary Programs

Don't in any circumstances refer to Unix source code for or during your work on GNU! (Or to any other proprietary programs.)

If you have a vague recollection of the internals of a Unix program, this does not absolutely mean you can't write an imitation of it, but do try to organize the imitation internally along different lines, because this is likely to make the details of the Unix version irrelevant and dissimilar to your results.

For example, Unix utilities were generally optimized to minimize memory use; if you go for speed instead, your program will be very different. You could keep the entire input file in memory and scan it there instead of using stdio. Use a smarter algorithm discovered more recently than the Unix program. Eliminate use of temporary files. Do it in one pass instead of two (we did this in the assembler).

Or, on the contrary, emphasize simplicity instead of speed. For some applications, the speed of today's computers makes simpler algorithms adequate.

Or go for generality. For example, Unix programs often have static tables or fixed-size strings, which make for arbitrary limits; use dynamic allocation instead. Make sure your program handles NULs and other funny characters in the input files. Add a programming language for extensibility and write part of the program in that language.

Or turn some parts of the program into independently usable libraries. Or use a simple garbage collector instead of tracking precisely when to free memory, or use a new GNU facility such as obstacks.

(Emphasis added).

Now, Mono is an open source project and follows those rules (and I have followed those rules myself since 1992 when I first started writing free software).

If only reporters had a way to find out this information, some kind of wizard that they could use to fact check their pieces...

[Ziing!] Hi! Am the Great Gazoogle!

Oh hi, Great Gazoogle. Say, what’s this?

Mono Project -- Contributing -- Important Rules
  • If you have looked at Microsoft's implementation of .NET or their shared source code, you will not be able to contribute to Mono.
  • In general, be careful when you are implementing free software and you have access to proprietary code. We need to make sure that we are not using someone else's copyrighted code accidentally.
  • Do not use the ildasm, reflector or other equivalent tools program to disassemble proprietary code when you are planning to reimplement a class for Mono. If you have done this, we will not be able to use your code.
  • Please stick to published documentation for implementing any classes; when in doubt, post to the mailing list and discuss the possible approaches with others.

This text was originally added before the launch of the project, as indicated by the Great Gazoogle:

[Zeerp!] "I looked it up, this horse was beat to death on the mailing lists!" says the Great Gazoogle.

The Great Gazoogle can be used to identify other times when we the issue of Rotor, SSCLI and Mono has come up in the past.

We go even further than that. We do not even accept LGPL contributions to our own class libraries, we use the MIT X11 license for that, and as such we are unable to incorporate changes that were developed as LGPL or GPL with exceptions (which is why we could not work together or accept patches from pnet folks unless they relicensed their code).

So we do not take proprietary code, and we do not take open source code that is not suitably licensed to be included in Mono itself.

A similar situation existed forever for Java. Java was only open sourced less than a year ago, but before it became open source, the source code for Java was wildly available for anyone that wanted to look at it under a non-open source license.

Obviously open source efforts --GNU Classpath, the older class library project and the various open source Java VMs-- could not accept contributions from people that had looked at Sun's code.

And of course, there was Rotor. Rotor was Microsoft's first attempt at giving developers some access to the source code of .NET. Rotor used a Shared Source license instead of MS-RL that prevented people from using its source for commercial purposes (so just like this new release, it is a non-stater for Mono).

Rotor differs also from the upcoming release in that Rotor contained the source to the C# compiler and the virtual machine and this release does not. But Rotor did not include the "major" class libraries like ASP, ADO and Winforms that are included in the upcoming release.

So the doomsday scenario has existed for as long as 24 years for free software, but Pundit #1 just thought of this scenario all by himself:

If you ever, and I mean ever, want to write open-source code, I recommend you not come within a mile of Microsoft's .NET Framework code or any other similar projects that the boys from Redmond "open" up.

To be fair though, it is an important warning, and it is good that this is kept in mind by anyone contributing to open source software.

Now lets look at Pundit with an Axe to Grind (referred to from now on as Pundit #2). Pundit #2 likes to setup a strawman, but he does so in a careful way, with plausible deniability, look at this carefully crafted piece:

If you believe some of the headlines, Microsoft just open sourced a bunch of software related to its .Net libraries. Don't be fooled. The definition of open source is very clear. This is not open source. Not even a little bit. In fact, this may actually be an insidious trap (more on that below).

Microsoft never claimed they were open sourcing anything in .NET. They do not even use that language. Am not sure where the rumor that it was open source started, but clearly people did not even bother reading the actual announcements from Microsoft, because such text is nowhere to be found. You would think that in this day an age they could have done a quick check. But alas, when you got an Axe to Grind the axe comes first. Facts and research come last.

Some creative uses of the Axe (I had to use the great Gazoogle to get the "joke"):

Far-fetched? Well, not if you look at Microsoft's history. Microsoft is playing to win, and it seems to believe the only way to win is if open source loses. This is myopic, but the company refuses to get LASIK.

Do you get it? LASIK: so you can fix the myopic view!

So this is a pundit that repeats and quotes the claims from Pundit #1 (the guy that did not know history) and invokes history. To be fair, he is a pundit, his depth of knowledge is razor thin.

In my opinion, Pundit #2 is failing at both punditry and humor.

Credits: Great Gazoogle artwork and concept originally from Gavin M. at Sadly, No!.

Posted on 05 Oct 2007

« Newer entries | Older entries »