by Miguel de Icaza

As I upgraded the hard drive on my machine today --which took a few hours to copy the rats' nest that is my home directory-- I begun the process of assimilating the GDIPlus Flat API.

A few weeks ago, Alexandre Pigolkine, Jordi Mas and myself were discussing the development roadblocks that we had with System.Drawing (as part of the Windows.Forms effort). The problem is that we made one of the most common engineering mistakes: when faced with the issue of multiple choices, instead of choosing one, we chose them all.

Being seasoned C# developers, we created an internal interface, and had each backend implement the interface. Then the official System.Drawing API was implemented and it became a multiplexor for the various implementations. We had Win32, Xr and Gtk backends. Of course the issue is that improving the backends becomes fairly hard: a change has to be reflected in five places: three backends, the interface and the multiplexing call site. Not terribly hard for one or two API calls, but it starts to become hard with an API as big as this one. I take all the blame for the mistake.

After some discussion, we decided on a new strategy: System.Drawing would only have one implementation, and this implementation would be based on GDI+. On Windows, the implementation would just call into the real GDI+ library, and on Unix systems we would provide a full implementation of it. To implement GDI+ on Unix, we have based our implementation on Cairo which has pretty much the same imaging model that GDI+ (and PDF) have.

This has several advantages: we maintain and write less code; we can test against the real GDI+ implementation on Windows and remove a variable in the debugging process; and we can contribute this code back to the Wine project.

But plenty of assumptions we had made before do not apply necessarily now. Before we had a managed implementation of the image loaders: it was just as fast as the C code and by virtue of being C# code, by extension it was cooler. But now in this GDI+ world, we will move things like the image loaders into the C code API, and the C# code will become thin wrappers around it.

The above also explains why there is a regression in Windows.Forms and System.Drawing on CVS as opposed to the latest official Mono release. So now I should be able to assist the System.Drawing developers.

Mono Installers

The upcoming Mono not only will add Cairo as a depedency (if you care about System.Drawing), but our internationalization support will also require the International Components for Unicode library.

We will continue to provide packages on Red Carpet, and RPMs on the site for downloading, but we are seriously considering reusing the Ximian Desktop installer to install Mono on a machine. That means that instead of downloading a dozen packages from our site, you would only download one. This hopefully will reduce the number of problems that people have with installations and we would also ship the Apache module pre-configured in the distribution.

Duncan is researching this, and we will keep people posted.

Posted on 21 Oct 2003

Mono Meeting at the PDC

by Miguel de Icaza

Wondering about the organization of a meeting of Mono users at the PDC, it seems like Monday afternoon before the reception, or Thursday are good time slots for getting together.

Alternatively, the Mono folks will be wearing the cool Mono t-shirts, so if you are interested in discussing a Mono topic, feel free to come and join us.

Nat in Bangalore

Today's most beautiful blog update goes to Nat for his fantastic photographic update on the Bangalore trip and his insight on his trip to ramp up the new Novell open source hackers that will be working on improving Gnome, OpenOffice, Mozilla and Mono.

In other news, am going to Bangalore in early December, and I have to plan something with convenient stops in the middle. It has to involve a Paris stop, so I can meet the Mono hackers in Paris, and introduce myself to Fabrice Bellard.

Gnome Summit: New York City

In November the Gnome Hackers will descend into New York for the Gnome Summit where we will talk about the major problems facing the Linux desktop today. This event is a follow up to last years Boston Gnome Summit.

There are tons of new topics for this year that I am looking forward to discuss:

  • Hardware detection: Havoc has posted some initial thoughts on on how to hook hardware detection systems into the stack of applications in the desktop.
  • D-BUS is maturing as a system-wide broadcast and messaging system, and it will be nice to see it plugged into the desktop. We are still lacking Mono bindings for it though.
  • OpenOffice has changed massively since last year, and has a few killer features. It took Mozilla three years to go from open-source code base to best browser on the desktop. And developers are slowly, but steadily joining the OpenOffice project. Am looking forward to meet Michael and get an update on it.
  • Mozilla is now on its own, without their original corporate backing, a change of landscape, and am looking forward to meet the Galeon, Epiphany and Firebird developers.
  • Would love to find out what the OSAF guys are up to, and if they have demos, even better!

And of course, get everyone to adopt Mono for their projects, as we know it is the One True Runtime (bug reports, happily accepted

Posted on 18 Oct 2003

No Mono BOF at the PDC

by Miguel de Icaza

I just received a letter from the INETA PDC organizers informing me that the Mono BOF would not be happening. I was looking forward to discuss Mono. The BOF suggestion had a pretty good rating and hat plenty of voters, I guess it was a far stretch to have Microsoft have a BOF on Mono :-)

Notice that there is an estimated of 60 BOF talks, but only 48 were approved.

If there are people interested, we can still sit down and discuss Mono at the PDC, there will be at least three of us: Gonzalo, Lluis and myself.

Posted on 15 Oct 2003

Expanding the Mono team.

by Miguel de Icaza

I am looking to hire a full-time developer to work on the Mono JIT engine. This would include working on the code generation engine of the JIT (so compiler experience, low-level programming experience is a plus), advanced optimizations for the compilation engine (various SSA-based optimizations, array-bounds check elimination, fast-call conventions, loop optimizations), debugging interfaces and would involve dealing with a garbage collected, multi-threaded runtime environment.

We are porting the Mono JIT to various platforms, so you would be learning new assembly languages, new ABIs and more. If you are interested, drop me an email at

Posted on 14 Oct 2003

Problems on my machine

by Miguel de Icaza

I have been applying every one of those "Apply this patch immediately" updates that I have received on e-mail from, and my machine seems slower every time.

Update: I have received on last count 9 emails from people informing me that the above is a virus. Guys, it was a joke. Obviously I failed in my attempt to be funny.

Evolution and Mono

Chris Toshok today has been working on embedding Mono and Mono-based applications inside Evolution in their new UI branch.

Here is a screenshot embedding the Mono documentation browser in Evolution:

More Mono Bloggers

New mono bloggers, I think I should track them in in Monologue.

Posted on 13 Oct 2003

by Miguel de Icaza

Posted on 12 Oct 2003

Birthday Theme

by Miguel de Icaza

Some people have asked me about the theme for this year Birthday's present. This year theme is going to be `Nice and Expensive'. It is a repetition of an old-time favorite. But this year, lets try harder to stick to the theme.

Posted on 09 Oct 2003

Robert Fisk on the attack on Syria

by Miguel de Icaza

The article is here, and I had forgotten about the Syria Accountability Act that was making the news last year until I ran into Robert's article today.

Multi-threaded MonoLogue: Gonzalo has fixed all the runtime bugs

We modified the Monologue software to use multiple-threads to download the RSS feeds concurrently, and this exposed a couple of tricky bugs in the runtime and our DNS setup. Gonzalo was on a quest to track all of these problems down, and our abusive version of Monologue is now fully functional.

Now the major source of problems was not a Mono bug, but a dead-lock condition that was not obvious. Turns out that Monologue/threaded happened to fill the Threadpool queue (no surprises there: threadpool will just take care of things), but the Http code needed a thread from the pool to download things (the API is using the async version of this as well), and that caused a deadlock.

Posted on 07 Oct 2003

MonoLogue: Mono's aggregator is up and running

by Miguel de Icaza

Ben wrote an RSS aggregator that we are running now on to track the Mono blogs. You can now get all your Mono news in a single spot. This is similar in spirit to Jeff's Planet GNOME

If you are interested in running the aggregator in your machine for your own personal blog reading, just download the `monologue' module from our AnonCVS repository.

On RSS Aggregators

I have tried three kinds of RSS aggregators out there: desktop-based, mozilla-based and html-based. From my personal browsing experience I believe that the HTML-based aggregators are the best kind. Specially when we you are using Mozilla/Firebird with tab browsing.

There are plenty of desktop-based aggregators for both Windows and Linux (I tried them all in a quest for the perfect UI). The desktop-based aggregators typically embed a web browser in the browsing pane to render the news. And this is the source of most frustration with them.

The embedded HTML rendering engine has some very bizarre interaction glitches when you follow links, and you try to go back in history, or when you start following links inside the aggregator (which it is bound to happen).

Since it is not really possible to read comfortably the news inside the aggregator, you can either open a new window (uncomfortable) or hope that the aggregator can instruct your browser to open a new tab, but it is still annoying to use.

The obvious answer to the above problem is to put the aggregator inside the browser. Luckily Mozilla/Firebird have made plugin authoring a breeze, and there are a couple of options out there.

These aggregators today suffer from a problem shared by the desktop-based aggregators: they are based on the modern news-reading/mail-reading model. These present the user with a collection of folders with items old and new, and you read your feeds one by one. This model is ill-suited for blog reading because blogs do not produce large volumes of data per day, and you most likely want to read all the new things in the day at once. Not once per week, so the interaction model is basically to read a single post on each folder and move to the next one, and repeat this a number of times per day. Not very efficient.

The third kind, the one I like the most are the aggregators that generate an HTML page with the consolidated data. This in my opinion is the best model because you get to read HTML content on your main HTML browser and all the tools available on your browser are available to you and most important: there are no surprises on the behavior. Since it aggregates all the data at once, every time you visit it, you can get a snapshot of what is happening, rather than having to check 20 sources one by one.

Firebird users probably will like the last one the most, since its a feature packed browser, and with a rich set of extensions that make browsing more efficient. But in general any user of a tabbed-based browser will enjoy the later kind the most.

Escalation of Violence

Yesterday there was another suicide bombing in Israel. The reaction was an attack on an alleged terrorist training camp in Syria. Following the Bush doctrine of `destroy evidence first, cover-up with non-answers later'.

Been thinking this morning that it is time to write a Israeli-Palestine Conflict Primer. On second thought, maybe I should just strongly recommend reading John Pilger's Palestine Is Still The Issue an eight-parth documentary available online (wish they sold the video on DVD).

Edward Said passed away, his latest article and a tribute to his writing.

The Hamas group that has been striking at the civilian population was initially funded by Israel in the 70's to undermine the growing popularity of the PLO and Arafat. A policy that now has backfired. Some details here.

Posted on 05 Oct 2003

SouceGear is done!

by Miguel de Icaza

We completed the SouceGear project!

The project included adding a lot of functionality to Mono to support Web Services on the client (mostly having a full XmlSerializer implementation as well as its close family members) and making Mono robust.

To make sure that Mono was robust, SourceGear designed a series of extensive tests that Mono would be put under, and the acceptance criteria for the work we did included running the tests for a 24 hour period of time on a single instance of the virtual machine. Needless to say, making the Mono VM robust enough to run these tests for 24 hours was not easy, and we ran into all sorts of low-level interesting features, memory leaks, race conditions and other assorted small problems that would not have shown under normal circumstances. We are very happy about this.

In the meantime, while parts of the team were tracking down the elusive bugs in the runtime, Lluis took the time to implement the server side component of ASP.NET, so as part of the SourceGear effort, we also got our web services stack implement on the server, which was a nice plus.

More on exceptions

I was feeling that I should argue a bit more about exceptions, until I received a mail from Krzysztof Cwalina at Microsoft, he raises a good point about exceptions and the null return pattern: they do not allow an error to be propagated, nor details about the error.

He is absolutely right, and my example with files was not a good one. I had in mind APIs that did not need to propagate a rich error or details about the condition. Krzysztof said:

One problem with null is that you may get notified about the problem really far away from the point when the error occurred. Exception will be thrown right there at the point where the error occurs. The other problem is that null cannot tell you why the error occurred. Error codes have their own set of problems.

Of course (as with every design) it's a tradeoff. In this case a tradeoff between better error reporting (fail fast, rich error message) and performance (and other things). In general, we err on the side of better reliability, clarity of errors, etc. when designing the Framework. We have several exceptions to the general rule in explicitly identified performance-sensitive APIs.

IXmlSerializable explained

Lluis the man behind the Mono implementation of Remoting and Xml Serializer explains on his latest blog entry how the undocumented IXmlSerializable interface works. If you ever wondered how you could have precise control over the Xml mapping in XmlSerializer, this is the interface used internally by the framework.

Welcome Sebastien Pouliot and Duncan Mak!

Sebastien, the man behind the Mono cryptographic infrastructure now has his own blog.

Duncan also started his

Posted on 01 Oct 2003

« Newer entries | Older entries »