That is the time between our last major Mono release and the new hotness: Mono 2.10.

New in this release:

• Google Native Client Support
• New Profiler engine, it is beyond amazing.
• Faster socket stack
• Improved Parallel Framework
• Our SGen GC now supports Precise Stack Scanning and has been further fine tuned to increase our performance.
• Unified MonoTouch/Monodroid runtime support
• New Cecil/Light API is faster and lighter
• New C# Compiler backend (can now use any custom mscorlib)
• VB Compiler can now compile to both 2.0 and 4.0 profiles.
• Supports ASP.NET MVC3, Razor and new WebPages.
• New WebMatrix.Data database API.
• Improved OSX Mono
• F#, IronRuby and IronPython are now bundled in OSX and packaged for Linux.

Check out our Mono 2.10 release notes for all the details.

On Friday, Nokia announced that they were adopting WP7 as their operating system. Although some open source advocates might see this as a set-back for Linux, Android is already the best-selling Linux OS of all times. Meanwhile, as a Ben Zander student, all I see is possibility and the the world of opportunities that this opens to developers.

Although they will continue shipping Symbian for a while, they are effectively sun-setting it. Just like you can still purchase Itanium systems from HP, nobody really develops for those anymore.

Nokia had this chart to offer on Friday:

This is fascinating turn of events for C# developers as Nokia will make WP7 more relevant in the marketplace, making C# the lingua-franca of all major mobile operating systems. This astute chart explains why I am basking in joy:

C# and the ECMA CLI everywhere!

Now, certainly lots of developer houses can afford to build their software once for each platform. This is fine if your VC has a mandate to "spend that cash quickly" or if you have a surplus of interns at your disposal.

Now, if trollcats have taught us one thing is that users like the UI of their apps to be as native as possible. That is, mind-blowingly beautiful on iOS and try to match the carpet on the others.

Other snake oil vendors will tell you that you can use the same code across all platforms and still deliver an emotional experience to your users. I agree, you can deliver the same emotion of disgust when using a cross platform toolkit.

With Mono we have taken a different approach, based on our own failures from the past. We give developers access to all of the native APIs in the platform to create the best possible user experience, and exploit every single last bit of functionality available on the platform.

We advise our users to split their user interface code from the engine, or their business logic. Developers should create a native experience for their mobile apps: one per platform. For example, consider Angry Birds on iOS and Angry Birds on Blackberry. Each version adapts to provide the best user experience available on the platform.

This is a grand time to be a mobile developer. This chart illustrates the elegant balance of native experience and code sharing available to C# developers:

Update: As much as I have enjoyed responding to the comments on this blog post, the comments are now closed. I will make an exception with anyone that wants to follow up on an existing discussion. For everyone else, if you have something to share, write it on your blog.

Red Gate announced that their Reflector tool would soon become a paid-for app. A few years ago they bought the rights to Reflector from Lutz Roeder and started maintaining two editions of the product: a free version and a commercial version with extra features. Many people in the .NET community feel unhappy about that decision.

Whether Red Gate's decision is good or not for them is up to other blogs to discuss. I am grateful that over the years Reflector ran with Mono's Windows.Forms implementation and that the maintainers were careful to keep the code running with Mono.

Of course, I would always like more an open source equivalent to a proprietary tool, and while Reflector was a free download, it was never open source.

Some believe that in response to the announcement we created a competitor to Reflector. We did not.

We have had a decompiler in Mono for a few years now. First, we had a decompiler contributed to MonoDevelop by Andrea and we later replace it with the one that was developed by JB Evain:

The current decompiler in MonoDevelop actually originated not as a decompiler, but as a flow-analysis tool in 2005. It was part of db4Object's Native Queries. Native Queries were a way of getting some of the benefits of LINQ without any compiler support. It worked by reassembling the AST at runtime from a stream of IL instructions. For example, you could use the following C# code to query a database:

IList  pilots = db.Query  (delegate(Pilot pilot) {
	return pilot.Points == 100;
});
	

The Query method would decompile the code in the delegate and reconstruct the abstract syntax tree and determine that the expression to query was pilot.Points == 100.

JB Eventually expanded hi IL Manipulation library Cecil to contain a decompiler built based on the ideas of flow analysis. JB described this back in December of 2008 as part of a Hack Week followed by a hack-a-thon:

During the last Hack-Week, I started refactoring Cecil.FlowAnalysis, and since then, I’ve been working pretty seldom on it. It was last month that I decided to give it a kick, and even took a week of vacations to organize a CodeCamp with friends to give it a boost and have fun altogether

The decompiler is just one of the various tools built with Cecil and has been a standard component of MonoDevelop for a long time (it is part of MonoDevelop 2.4).

Although yesterday in response to the announcement, a WPF UI was created for the Cecil.Decompiler.dll, this is not the only effort. There is also an older Cecil Studio that uses Windows.Forms that was created a few years ago and of course, our own MonoDevelop assembly browser.

We welcome contributions to the decompiler for people interested in improving the core, regardless of their preference for a UI built on top of it:

That being said, JB has been working on a new system that goes beyond decompilation and will be demoed at QCon next month. Stay tuned for his demo.

A few days ago, John Perry Barlow twetted a series of Adult Principles, and I enjoyed reading them. When he was asked where they came from, he said:

They're from a list I assembled for myself on the eve of my 30th birthday. Many years ago.

This is the collected set from his twitter feed:

Adult Principle #1: Be patient. No matter what.

Adult Principle #2: Don’t badmouth: Assign responsibility, not blame. Say nothing of another you wouldn't say to him.

Adult Principle #3: Never assume the motives of others are, to them, less noble than yours are to you.

Adult Principle #4 Expand your sense of the possible.

Adult Principle #5 Don’t trouble yourself with matters you truly cannot change.

Adult Principle #6 Don't ask more of others than you can deliver yourself.

Adult Principle #7 Tolerate ambiguity.

Adult Principle #8 Laugh at yourself frequently.

Adult Principle #9 Concern yourself with what is right rather than who is right.

Adult Principle #10 Try not to forget that, no matter how certain, you might be wrong.

Adult Principle #11 Give up blood sports.

Adult Principle #12 Remember that your life belongs to others as well. Don't risk it frivolously.

Adult Principles #13 Never lie to anyone for any reason. (Lies of omission are sometimes exempt.)

Adult Principle #14 Learn the needs of those around you and respect them.

Adult Principle #15 Avoid the pursuit of happiness. Seek to define your mission and pursue that.

Adult Principle #16 Reduce your use of the first personal pronoun.

Adult Principle #17 Praise at least as often as you disparage.

Adult Principle #18 Admit your errors freely and quickly.

Adult Principle #19 Become less suspicious of joy.

Adult Principle #20 Understand humility.

Adult Principle #21 Remember that love forgives everything.

Adult Principle #22. Foster dignity.

Adult Principle #23. Live memorably.

Adult Principle #24. Love yourself.

Adult Principle #25. Endure.

A small detour, he also tweeted

If you want a new, improved mate, try treating the one you have better.

Andrew has just released the packages for our first preview of Mono 2.10, we published sources and packages for SLES, OpenSUSE, RHEL, Windows and MacOS X here:

http://mono.ximian.com/monobuild/preview/download-preview

From our draft release notes, here are some of the highlights in this release:

• SGen Precise Stack Scanning and many performance improvements.
• New Profiler engine
• Google Native Client Support
• Faster socket stack
• Improved Parallel Framework
• Cecil/Light
• New C# Compiler backend (can now use any custom mscorlib)
• VB Compiler can now compile to both 2.0 and 4.0 profiles.

As well as containing a pile of bug fixes.

As I mentioned last year, we are moving to a faster release schedule to get important features out for our users faster. For instance, our SGen garbage collector has been vastly improved and should perform better under load, and our ParallelFX got some real-life testing which helped us improve it significantly.

SGen Technical Discussion

Mark has been blogging the technical details about the architecture of the SGen garbage collector, you can read the documents here:

• Introduction to SGen
• SGen's Nursery
• SGen's Major Collectors

Since the beginning of time, men have sought to find a way of creating a sandbox for untrusted code running on their Mono virtual machine.

Those of you familiar with Silverlight's security system, commonly referred as CoreCLR Security, have wondered "how can I get me some of dat". Today Sebastien wrote a How-to guide for those of you interested in creating your own secure sandboxes like Moonlight or Unity3D have done.

From his blog:

So what was missing was not facts but orientation. It kind of make sense, most people are not doing an open source implementation of Silverlight, we are. However we're providing a lot of cool (yes it is ;-) stuff within - stuff, like coreclr, xaml, the cecil-based linker... that can be reused in other projects. So the missing piece is an how to for people wishing to enable CoreCLR when embeding mono in their own application. It does not bring a lot of new facts but, hopefully, it will order them in a more useful way.

During today's Nvidia press conference at CES, a the Monodroid-powered DeltaEngine was shown running the SoulCraft Tech Demo:
CES Video.

Although today's demo was powered by MonoDroid the engine is a cross-platform .NET game engine, it runs on on Mono-powered systems like Linux, MacOS X, MonoTouch and MonoDroid as well as Microsoft .NET powered systems like the XBox360, Windows Phone 7 and Windows:

If you have an iPad, you can try the Zombie Party game on the AppStore, it is the first game powered by DeltaEngine. ExDream is the group behind DeltaEngine.

For information on how the demo was built check out this blog post. The engine will be open sourced this year.

Now that we feel that we have fixed all the embarrassing bugs in Mono for Android, so we have opened up our Mono for Android preview program to anyone that wants to take it out for a spin.

Mono for Android brings the full Mono VM to Android. We use a library profile that is better suited for mobile devices, so we removed features that are not necessary (like the entire System.Configuration stack, just like Silverlight does).

In addition to bringing the core ECMA VM to Android, we bound the entire set of Android Dalvik APIs to C# and in the process C#-ified them. This includes using C# properties for metadata (less XML config file messing around), exposing C# events, C# properties, strongly typed generic types where necessary, implicit conversions where needed, using the C# API style, IEnumerable where appropriate (to let you LINQ over your Dalvik, and we turn IIterable into IEnumerables for you).

On the OpenGL front, we brought the same OpenTK library that is popular among .NET developers on both Windows, Linux and iPhone, so you can share the same OpenGL logic across all platforms.

Unlike iOS where the JIT is not supported, Mono on Android supports the full JIT, so you can use Reflection.Emit and dynamic code compilation as much as you want.

This initial release only comes with templates for C#, but other .NET compilers should work, as long as they reference Mono for Android's libraries (as we removed a few methods that make no sense on mobile devices).

Support for OSX

Through the lifetime of our preview program, Mono for Android only supported Windows development using Visual Studio. Today we are also releasing support for developing Android applications on MacOS X using MonoDevelop.

Getting Started

Please check our Welcome page, it contains installation instructions, links to tutorials, mailing lists, chat rooms and more.

I strongly advise our users to join our mailing list and to check the previous discussions on the mailing list for some tasty insights.

You can also browse the API that we expose to C# developers.

Upcoming Features

We are working as fast and as hard as we can to complete Mono for Android. This includes Linux support and bringing MonoDevelop to Windows, for users that can not run Visual Studio 2010 Professional.

Giving us Feedback

Please provide your feedback on the product directly on our mailing list, as this is what the MonoDroid developers monitor. Bug reports should be filed on Novell's Bugzilla.

Some developers, when faced with fixing, or adding a feature to an open source project are under the mistaken impression that the first step before any fixing takes place, or before adding a new feature takes place is to make the code "easier for them" to work on.

"Easier for them" usually is a combination of renaming methods, fields, properties, locals; Refactoring of methods, classes; Gratuitous split of code in different files, or merging of code into a single file; Reorganization by alphabetical order, or functional order, or grouping functions closer to each other, or having helper methods first, or helper methods last. Changing indentation, aligning variables, or parameters or dozen other smaller changes.

This is not how you contribute to an open source project.

When you contribute fixes or new features to an open source project you should use the existing coding style, the existing coding patterns and stick by the active maintainer's choice for his code organization.

The maintainer is in for the long-haul, and has been working on this code for longer than you have. Chances are, he will keep doing this even after you have long moved into your next project.

Sending a maintainer a patch, or a pull request that consists of your "fix" mixed with a dozen renames, refactoring changes, variable renames, method renames, file splitting, layout changing code is not really a contribution, it is home work.

The maintainer now has to look at your mess of a patch and extract the actual improvement, wasting precious time that could have gone to something else. This sometimes negates the effort of your "contribution".

If you really have an urge to refactor the code, first of all, discuss the changes with the maintainer with the rationale for the changes. If the maintainer agrees with the changes, make sure that you keep your refactoring and changes independent from code fixes, it makes reviewing the code a lot simpler.

The alternative, to keep your fork, is usually a guarantee that your effort will be wasted, and wont help other users. People have tried to do this. It is attempted every year, by hunders of developers who in tbe back of their minds are thinking "I can do better" and "I wont make the same mistakes". After 18 years doing open source I can probably think of a handful of project forks that have survived and flourished. Out of hundreds of such failures. So the odds are not good.

So respect the original coding style, and if you want to make refactoring changes, discuss this with the maintainer.

The staff at Groklaw has never really tolerated any dissent when it came to OOXML. They spent years advocating against OOXML only to have OOXML emerge not only stronger, but also with an ISO stamp of approval.

Today they tried to insinuate that my involvement and opinion on OOXML was somehow the result of the 2006 Microsoft/Novell agreement.

Their conspiracy theory falls apart as our active involvement on OOXML goes back to the year 2005, 11 months before there is any agreement between Microsoft and Novell.

My interest in the file format interop problem goes back to 1998-1999 when I wrote the Gnumeric spreadsheet and both Michael and his brother started contributing a plugin for reading and writing Excel files.

My involvement with OOXML started in 2005, when Jack Messman was still Novell's CEO and the company was in the middle of various legal disputes with Microsoft. Not the best environment for collaboration between companies.

ECMA was starting a new working group to look into standardizing OOXML, and since we were already members of ECMA (as part of our work on C# and CLI) I recommended that we should participate in the effort to come up with solid documentation that we sorely needed for improving OpenOffice's interoperability story. ECMA had been great in particular for the CLI, in large part thanks to Sam Ruby at IBM who pushed for the file format to be specified (the original drafts did not document the actual assembly file format, only the instruction set).

In 2005, one of our major goals was to make Linux suitable for enterprise desktop deployments, and interoperability with Microsoft protocols and file formats was key to this strategy. We were the major contributors to OpenOffice outside of Sun (and perhaps still are) and what mattered to us was to get a good spec we could use to fix customer issues that prevented us from deploying the Linux desktop to enterprise customers.

For years, we had been reverse engineering Word and Excel. This was our chance of getting important information on the file formats. Our work in this area today benefits every OpenOffice and Gnumeric users.

So we attended and participated in the ECMA OOXML meetings starting with the initial meeting on December 15th. I blogged about this publicly on November 2005, and so did Novell which on the same month Novell blogged about our participation on the Open Invention Network (we were founding members) and was actively promoting OpenOffice.. The minutes of this meeting and every other meeting ever since are available to all ECMA members.

It was our team that pushed to get the entire Formula Spec in OOXML back in 2006 (those 700 pages of formula specs, the ones that actually make spreadsheets work) as well as filing piles of issues as we prototyped the work with Gnumeric and OpenOffice. And all of this happened before any Novell-Microsoft agreement.

My involvement after setting up the initial participation was superficial, as the actual hackers working on OpenOffice and Gnumeric took over (Jody Goldberg and Michael Meeks). These were important years for Mono, and that is where my energy has been going since about 2002.

The 2006 agreement with Microsoft did not impact much of my work, despite Mono being something where interop could really be helped.

The ECMA work on OOXML brought hackers together and allowed our teams to interact as people looking for some shared goals instead of interacting as foes. In my experience face-to-face meetings, like the ECMA working groups, help smooth out human relationships that might have been poisoned by preconceived biases.

But the interop agreement certainly allowed other collaborations and meetings in other areas with Microsoft, for example, it lead to various components used by Mono to become open source, and to our Moonlight/Silverlight collaboration.

So two full months into having signed an agreement with Microsoft, I wrote my first pro-OOXML post, largely based on a news report that I felt was misguided. We had been working on this at this point for a year, and clearly people with no actual office experience had already formed an opinion.

In retrospect, had I known that double standards, hypocrisy and character assassination would become the tool of choice of the anti-OOXML crowd I would not have said a thing.

The energy that went into stopping OOXML could have been better used in actually completing the formula spec for ODF, which almost four years later is still not part of the ISO spec. In the eyes of the ISO world, it remains an "implementation specific" work. But "advocacy" is a little bit like watching the TV, it is relatively easy. While actually working on improving open source, or open standards is equivalent to going to work. It requires skills, time and longs hours of difficult work (particularly if you are working on the OpenOffice code base).

As for the March agreement of 2010, it is absolutely brilliant. Microsoft is funding our OpenOffice team to develop open source code that will improve the OOXML import and export capabilities and we help drive the OOXML standard forward based on the experience that we will gain from doing this work.

If you do not like us doing this work, there is an easy solution for you: do not open or save files in OOXML format with OpenOffice.

See what I did there Trevor? I found out what bothered you emotionally, decomposed the problem, and BAM! I provided you with a solution. It is called teamwork, Trevor.

Michael Meeks from our OpenOffice team provides more color as he was the one actively working on this.