The big new of the day: Microsoft and Novell are set to collaborate. You can read all about it here, you can also go straight to:

• The press release
• The FAQ
• Watch the webcast with the announcement.
• Joint Letter to the Open Source Community.

But the question on everyone's mind regarding today's announcement is what is the position regarding Mono, from the Q&A:

Q: What are you announcing?

...

Under a patent cooperation agreement, Microsoft and Novell provide patent coverage for each others customers, giving customers peace of mind regarding patent issues.

Q: What does the patent agreement cover with regard to Mono and OpenOffice?

Yes, under the patent agreement, customers will receive coverage for Mono, Samba, and OpenOffice as well as .NET and Windows Server. All of these technologies will be improved upon during the five years of the agreement and there are some limits on the coverage that would be provided for future technologies added to these offerings. The collaboration framework we have put in place allows us to work on complex subjects such as this where intellectual property and innovation are important parts of the conversation.

And from our joint letter:

Mono, OpenOffice and Samba:

• Under the patent agreement, customers will receive coverage for Mono, Samba, and OpenOffice as well as .NET and Windows Server.
• All of these technologies will be improved upon during the 5 years of the agreement and there are some limits on the coverage that would be provided for future technologies added to these offerings.
• The collaboration framework we have put in place allows us to work on complex subjects such as this where intellectual property and innovation are important parts of the conversation.
• Novell customers can use these technologies, secure in the knowledge that Microsoft and Novell are working together to offer the best possible joint solution.

So today we have secured a peace of mind for Novell customers that might have been worried about possible patent infringements open source deployments. This matters in particular for Mono, because for a long time its been the favorite conversation starter for folks that find dates on Slashdot.

Anyways, now that we got that out of the way, I wanted to point to Michael Meeks' blog entry on the OfficeXML collaboration, which one of the major areas of collaboration, his blog entry is here, regarding the general question around why support Office XML, Michael says:

This should not be a surprise - Jody Goldberg (on my team) has been working hard for months with Microsoft and others on the ECMA process. At one stage there around 1/2 the open 'issues' wrt. improving disclosure (and hence the spec.) came from Jody. I for one am proud of the job that he did there, an (ongoing) investment that will yield better interoperability for years to come.

Anecdotally, I would like to point out that the work that happened through the ECMA TC45 has proved very fruitful, as things that were completely left out of the Oasis specification and in the original TC45 submission were put in there because Jody and Michael that have previously worked on Gnumeric and OpenOffice managed to get these things into the spec.

Read Michael's blog for more details, as he has many nice things to say about Open Office and Office XML.

I have a longer blog entry in the works, I promise I will post later more of the details on the various areas of collaboration on the business angle, and the technical angle

If you have some questions about this, please email me at [email protected] and I will include answers to your questions on my updated blog entry.

XNA is a new set of tools for assisting in game design, development and mangement (see the XNA Wikipedia page).

One of the components is the "XNA Framework" a set of .NET APIs for actually building the applications. It does not expose DirectX which makes it simpler to be ported to other platforms.

Rob Loach has started a project to do an open source implementation using the TaoFramework (Tao provides bindings for all things OpenGL and a few other media libraries).

Rob's implementation is being developed here. Currently most of the development is happening on Windows, but the project on SVN has support for building this on Linux with Mono as well.

Jordi Mas has organized for me to talk in Barcelona on November 8th at 19:30 in the Aula Magna at the Universitat de Barcelona at Gran Via de les Corts Catalanes, 585.

Will talk about Mono, developing with Mono, will likely introduce the work from Jordi (Workflow) and Lluis (MonoDevelop and Stetic) and talk about our plans for Mono 2.0 and beyond.

At the Microsoft TechEd

Frank Rego and myself will be at TechEd Developers in Barcelona from the 7th to the 10th. If you are attending TechEd, we will be in the Novell booth.

F-Spot finally has a feature that I have been waiting for. It is now possible to scale pictures before sending them:

Preparing Images for Email

Alan McGovern the developer of the BitSharp libraries (Bittorrent APIs for the CLI) started blogging.

Alan has continued his work from the Summer of Code, here are a few updates from him:

• On some challenges he is facing.
• Performance improvements: downloads went from 30k/s to 4.5MB/s and memory consumption is under 10 MB.
• GUI for BitSharp.

From his blog:

So it looks like i well achieved my aim of creating a cross platform client that uses less than 1/3 the ram that Azureus uses.

Here are a few screenshots of the updated GUI (Piotr did the GUI originally, and it has now been updated to the latest BitSharp API changes):

GUI running on Windows (This is Gtk# on Windows).

Alan keeps a To-Do list here, which should make it simple for people to help in the effort.

a few more screenshots are available here and here.

The Mono Meeting is over, it was a couple of very intensive days, and I managed to get very little sleep.

The slides for the presentations are here:

• Mono Roadmap, opening presentation.
• The db4o embedded database.
• DekiWiki and the Dream Framework
• The Cecil CIL Manipulation Library.
• Grasshopper: running .NET applications on J2EE servers.
• Indigo and Infocard in Mono.
• Security, CAS, Monoxide and Crimson.
• Mono's Compacting GC work.
• Visual Studio and Mono integration
• Gtk# Roadmap.
• Mono Code Generation and Performance.
• Mono Debugger.
• NUnit and Mono.

Olive: Infocard and Indigo

On Monday Atsushi checked into the olive module the initial implementation of Indigo and Infocard.

The status of the module is kept here and contains a human readable report of where we are standing. It is only the beginning, but some simple applications are able to run now.

Hopefully in the next few days I will have time to write down a few more lines about everything we talked about in the public Mono meeting and in our internal discussions.

For those of you coming to the Mono Meeting early today (the "early-arrivers"), we will be having brunch at noon in Casa Romero.

Sergey Tikhonov has been working for a few months on an Alpha port of the Mono JIT. The port can currently bootstrap itself (a sanity test that is used by all Mono ports), and the port is able to build the usual Mono GUI libraries (Gtk# and the Gtk# apps).

Currently the port still lacks varargs support, debugger support, global register usage and some peephole optimizations.

All of this code is now on SVN, and will appear shortly on the Mono 1.1.18 release.

Mark Mason has been working on a MIPS port, and he said this morning that the port is now "limping along". Not quite sure what that means until we see the patch.

Now all we need is a m68k to conquer the Atari ST world and a VAX port for all of you that still run an 11/780 in your basement.

Today Jon pointed me to C#'s "??" operator, this is really the kind of thing that I should know. The operator is part of the nullable-type family of operators, but I did not know that you could use this with regular expressions.

Its lovely, the expression: a ?? b evaluates to a if a is not null, or to b if a is null.

Very handy, replaces the idiom: a == null ? b : a.

This is only available in the gmcs compiler.

Mono's C# compiler was forked a few years ago (mid 2003) when we started developing the generic extensions to the language. We did this because the generic specification at the time was still in flux, and this new compiler was sort of a research compiler for us. We did not want to destabilize our production compiler (mcs) with generics at the time, so we kept the new compiler on its own tree (gmcs).

The downside is that ever since, we have had to merge all the improvements and bug fixes done to the generics which required a considerable effort.

Things have luckly changed. The C# generics specification is complete and gmcs is now stable.

This past week Martin and Harinath completed the merging of mcs with gmcs. Now we have a unified source code base, the only place where we have kept the code base divided is the tokenizer and the parser. This is ok, as we are considering writing a hand-written parser instead of the yacc generated parser that we use today.

This effort started because Martin did some major architectural changes in the anonymous method and iterator support.