Save the Date: Monospace Conferece in Boston

by Miguel de Icaza

The dates for the MonoSpace conference have been announced: July 23rd to 25th, 2011. The event will take place at the Microsoft NERD Center.

The organizers have just made a call for speakers. If you have an interesting topic to discuss, please submit a talk, we would love to hear from you.

Posted on 18 Apr 2011

Save the Date: Monospace Conferece in Boston

by Miguel de Icaza

The dates for the MonoSpace conference have been announced: July 23rd to 25th, 2011. The event will take place at the Microsoft NERD Center.

The organizers have just made a call for speakers. If you have an interesting topic to discuss, please submit a talk, we would love to hear from you.

Posted on 18 Apr 2011

Mono Android and iPhone Updates

by Miguel de Icaza

Today we are happy to release Mono for Android 1.0 as well as MonoTouch 4.0.

Both products allow you to use the C# language to write applications that run on Android and iOS devices.

Both products are based on the latest Mono 2.10 core. The Parallel Frameworks can be used to write more elegant multi-threaded code across all devices, and automatically takes advantage of multiple cores available on the iPad2 and Xoom devices. The C# 4.0 is now the default as well as the .NET 4.0 APIs.

Mono for Android

Our Mono for Android debuts today after almost a year worth of development.

Perhaps the most important lesson that we got from MonoTouch's success was that we had to provide a completely enabled platform. What we mean by this is that we needed to provide a complete set of tools that would assist developers from creating their first Android application, to distributing the application to the market place, to guides, tutorials, API documentation and samples.

Mono for Android can be used from either Visual Studio Professional 2010 for Windows users, or using MonoDevelop on the Mac.

Mono code runs side-by-side the Dalvik virtual machine in the same process:

This is necessary since code running in Dalvik provides the user interface elements for Android as well as the hosting and activation features for applications on Android.


The Mono for Android API is made up of the following components: Core .NET APIs, Android.* APIs, OpenGL APIs and Java bridge APIs.

Let us start with the most interesting one: Android.* APIs. These are basically a 1:1 mapping to the native Java Android APIs but they have been C#-ified, for example, you will find C# properties instead of set/get method calls, and you will use C# events with complete lambda support (with variables being automatically captured) instead of Java inner classes. This means that while in Java you would write something like:

	// Java code
	button.setOnClickListener (new View.OnClickListener() {
             public void onClick(View v) {
		button.setText ("Times clicked: " + Integer.toString(counter));
	// C# code
	button.Click += delegate {
		button.Text = "Times clicked: " + counter;

In addition to the UI APIs, there are some 57 Android.* namespaces bound that provide access to various Android features like telephony, database, device, speech, testing and many other services.

In what is becoming the standard in the Mono world, OpenGL is exposed through the brilliant OpenTK API. OpenTK is a strongly typed, Framework Design Guidelines-abiding binding of OpenGL. The benefit is that both Visual Studio and MonoDevelop can provide intellisense hints as you develop for the possible parameters, values and their meaning without having to look up the documentation every time.

Finally, for the sake of interoperability with the native platform, we exposed many types from the Java.* namespaces (31 so far) that you might need if you are interoperating with third party libraries that might require an instance of one of those Java.* types (for example, a crypto stack might want you to provide a Javax.Crypto.Cipher instance. We got you covered.

Core Differences

Mono for Android has a few differences from MonoTouch and Windows Phone 7 when it comes to the runtime. Android supports JIT compilation while iOS blocks it at the kernel level and Windows Phone 7 has limitations.

This means that developers using Mono on Android have complete access to System.Reflection.Emit. This in turn means that generics-heavy code like F# work on Android as do dynamic languages powered by the Dynamic Language Runtime like IronPython, IronRuby and IronJS.

And of course, you can also use our own C# Compiler as a Service

Now, although those languages can run on Mono for Android, we do not currently have templates for them. The Ruby and Python support suffer due to Android limitations. The Dalvik virtual needs to know in advance which classes you customize, and since it is not really possible to know this with a dynamic language, the use of Iron* languages is limited in that they cant subclass Android classes. But they can still call into Android APIs and subclass as much .NET class libraries as they want.

Native User Interfaces

MonoTouch and MonoDroid share a common runtime, a common set of class libraries, but each provides different user interface and device specific APIs.

For example, this code takes advantage of iOS's UINavigationController and animates the transition to a new state in response to a user action:

void OnSettingsTapped ()
	var settings = new SettingsViewController ();
	PushViewController (settings, true);

This is an equivalent version for Mono for Android:

void OnSettingsTapped ()
	var intent = new Intent ();
	intent.SetClass (this, typeof (SettingsActivity));
	StartActivity (intent);

We chose to not follow the Java write-once-run-anywhere approach for user interfaces and instead expose every single bit of native functionality to C# developers.

We felt that this was necessary since the iOS and Android programming models are so different. We also wanted to make sure that everything that is possible to do with the native APIs on each OS continues to be possible while using Mono.

For instance, if you want to use CoreAnimation to drive your user interactions, you should be able to leverage every single bit of it, without being forced into a common denominator with Android where nothing similar to this is available.

Craig Dunn, one of the authors of the MonoTouch Programming Book, has written a nice Mosetta Stone document that compares side-by-side some of the key UI differences across platforms.

He also has written the Restaurant Guide Sample which sports a unique user interface for Android, iOS and Windows Phone 7:

You can take a look at this cross platform sample from GitHub.

Split your Presentation from your Engine

Faced with the diversity of platforms to support, both mobile and desktop, this is a good time to design, refactor and prepare your code for this new era.

Today developers can use C# to target various UIs:

To give your code the most broad reach, you should consider splitting your backend code from your presentation code. This can be done by putting reusable code in shared libraries (for example, REST clients) and shared business logic on its own libraries.

By splitting your presentation code from your business logic code for your application, not only you gain the ability to create native experiences in each platform, you also get a chance to test your business logic/shared libraries more easily.


In Mono for Android when you build an application for distribution, we embed the Mono runtime with your application. This is necessary so your application is entirely self-contained and does not take any external dependencies.

Mono for Android uses the Mono Linker to ensure that only the bits of Mono that you actually use end up in your package and that you do not pay a high tax for just using a handful of functions.

For example, if you want to just use a method from XElement, you would only pay the price for using this class and any of its dependencies. But you would not end up bringing the entire System.XML stack: you only pay for what you use.

During development a different approach is used: the Mono runtime is installed on your emulator or test device as a shared runtime. This minimizes both the build and deploy times.

Mono for Android References

Start with our documentation portal, there you will find our Installation Guide, a tutorial for your first C# Android application, our tutorials (many ported from their Java equivalents) and our How-To Guides and a large collection of sample programs.

You can also explore the documentation for the Mono for Android API in a convenient to remember url:

The first book of Mono for Android will be available on July 12th. In the meantime, we have created many tutorials and guides that will help you go

I also strongly suggest those interested in parallel programming to check out the Patterns for Parallel Programming: Understanding and Applying Parallel Patterns with the .NET Framework 4. This is a free PDF, and is a must-read for anyone building multi-core applications.

Thank You!

Mono for Android would not have been possible without the hard work of the MonoDroid team at Novell. The team worked around the clock for almost a year creating this amazing product.

The team was backed up by the Mono core team that helped us get C# 4.0 out, WCF, the linker, the LLVM support, improve the VM, extend the MonoDevelop IDE, scale Mono, improve our threadpool, support OpenTK, implement the Parallel Frameworks, ship dozens of betas for MonoDevelop, Mono and Mono for Android.

Posted on 06 Apr 2011

Mono and Google Summer of Code

by Miguel de Icaza

We have been lucky enough that Google accepted Mono as a mentoring organization for the Google Summer of Code 2011

This is a great opportunity for students to get involved with open source, contribute, learn and get paid for their work during the summer.

We have a lot of ideas to choose from in our student projects page, ranging from virtual machine hacking, MacOS X improvements, MonoDevelop extensions, language bindings and even improving the Manos web application framework.

Do not let our limited imagination stop you. Although there are plenty of ideas to choose from, students should feel free to come up with their own ideas. In the past years projects based on students' ideas have been very successful and we want to encourage more of those.

Proposal submission is open until Friday April 8, so now is the time to join our wonderful community, discuss your project ideas and start working on those proposals.

The Mono Summer of Code IRC channel is #monosoc on

Posted on 30 Mar 2011

Monospace Conference: Boston, July 2011

by Miguel de Icaza

The Mono community is organizing the Monospace conference to be held in July in Boston. This event is being organized by Dale Ragan, Louis Salin and Paul Bowden.

The organizers have just made a call for speakers.

If you have an interesting technology that you would like to talk about during this 3-day event, you should submit a talk.

Monospace is on a very aggressive schedule. The good news is that the entire Mono team will be participating in the event.

Once the dates are set in stone, we will open registration. Currently we are thinking of hosting an event for some 200 attendees.

Posted on 29 Mar 2011

Save your Cleverness

by Miguel de Icaza

Today, while discussing how @hipsterhacker reminds us some of our friends, Nat pointed me to this interview where Maciej has this beautiful nugget of wisdom:

Q: The Pinboard about page says: "There is absolutely nothing interesting about the Pinboard architecture or implementation; I consider that a feature!"

Can you explain why you think that's a feature?

I believe that relying on very basic and well-understood technologies at the architectural level forces you to save all your cleverness and new ideas for the actual app, where it can make a difference to users.

I think many developers (myself included) are easily seduced by new technology and are willing to burn a lot of time rigging it together just for the joy of tinkering. So nowadays we see a lot of fairly uninteresting web apps with very technically sweet implementations.

Too many people over-engineer their software to the point that you can no longer see what the software was supposed to do. Once people find a religion in one of the modern development fads, they tend to jump with both feet, and we end up with uninspiring user-facing software, but internally amazing.

This disease is widespread. From everyone trying to turn their program into a platform (current fad: dependency injection), to trying to force programming models, to compulsively writing unit tests while ignoring the basic principles that unit tests can not be used to prove the absence of bugs (update: this is my favorite book on the subject; Namedrop alert: Bertrand Meyer introduced me to it).

There is only one reason to throw away your life writing useless code and that is to train yourself. If you are writing this in a Karate Kid wax-on, wax-off kind of way, go ahead.

But if you are building a product, you end up spending all of your time designing your architecture, and very little time in delivering a great experience.

Premature architecture design is like premature optimization: you will be wrong about the things that actually mattered.

Take the shortcut. Build the product. And if later, it turns out you made a design mistake, refactor the code. But at least you will have a product that your users love.

Posted on 29 Mar 2011

Hardware Accelerated Video Playback in Moonlight

by Miguel de Icaza

David Reveman has just completed a series of optimizations in the Moonlight engine that allows Moonlight to take advantage of your GPU for the data intensive video rendering operations. This is in addition to the standard GPU hardware acceleration that we debuted a few weeks ago.

This is what the video rendering loop looks like in Moonlight:

Every one of those steps is an expensive process as it has to crunch to a lot of data. For example, a 720p video which has a frame size of 1280x720, this turns out to be 921,600 pixels. This frame while stored in RGB format at 8 bits per channel takes 2,764,800 bytes of memory. If you are decoding video at 30 frames per second, you need to at least move from the encoded input to the video 82 megabytes per second. Things are worse because the data is transformed on every step in that pipeline. This is what each step does:

The video decoding is the step that decompresses your video frames. This is done one frame at a time, the input might be small, but the output will be the size of the original video.

The decoding process generates images in YUV format. This format is used to store images and videos but and with previous versions of Moonlight, we had to convert this YUV data into an in-memory bitmap encoded in RGB format.

The final step is to transfer this image to the graphics card. This typically involves copying the data from the system memory to the graphics card, and in Unix this goes through the user process to the X server process, which eventually moves the data to the graphics card.

New Hardware Accelerated Framework

The new hardware acceleration framework now skips plenty of these steps and lets the GPU on the system take over, this is what the new pipeline looks like:

The uncompressed image in YUV format is sent directly to the GPU. Since OpenGL does not really know about YUV images, we use a custom pixel shader that runs on the graphics card to do the conversion for us and we also let the GPU take care of scaling the image.

The resulting buffer is composited with the rest of the scene, using the new rendering framework introduced in Moonlight 4.

Although native video playback solutions have been doing similar things for a while on Linux, we had to integrate this into the larger retained graphics system that is Moonlight. We might be late to the party, but it is now a hardware accelerated and smooth party.

And what does this looks like? It looks like heaven.

We were watching 1080p videos, running at full screen in David's office and it is absolutely perfect.

Getting the Code

The code is available now on Github and will be available in a few hours as a pre-packaged binary from our nightly builds.

Posted on 23 Mar 2011

Kid's Games on the iPad

by Miguel de Icaza

My eight month old daugther loves her iPad.

We have gotten a bunch of baby games, kids games and visualizations for her.

But many of these apps have one fundamental issue: the author adds one or more buttons with useless stuff like "Provide Feedback", "Info", "Visit Web Site", "Check my Other Apps" and other assorted buttons on the screen:

Now, perhaps the apps did great when used by a professional QA team in Daytona that reported back "yes, every animal in the app makes the proper sound, and the cows scroll as they are intended to".

In this case, the "Main" button, will bring up a convenient page with options to send feedback to the author, to visit his web site and check out his other apps.

This means that my daugther can not really enjoy her games without supervision, since every few seconds, she will end up visiting a web site in Safari.

Joseph has a similar problem, he has equipped both of his kids with iPads, and they routinely report "the iPad broke", every time one of their games ends up in some lame web site for the developer.

Developers for kid games should use slider switches if they really want to impose their hooks into their customers.

Some Games

On twitter Paul Hudson suggested a couple of games for 1-year olds: Uzu (my daughter also loves this one), BeBot and SoundTouch.

I have found that she likes GarageBand a lot (we just have to be around to make sure we can reset the screen when she changes instruments).

Posted on 23 Mar 2011

GDC 2011

by Miguel de Icaza

Three years ago, we were almost laughed out of the Game Developer Conference Show floor.

C# as the heir to C++ back then was mostly an academic discussion. And there were only a few anecdotal examples of developers using C# for fast and safe scripting in games such as Second Life and Unity.

Three years ago, C# as a scripting language for games had shared the reputation that Javascript had before the Ajax and Web 2.0 revolutions. It was a bad word. Anything short of C++ and assembly language was not up to the taste of most game developers. Ironically, developers were willing to take the hit of an interpreted languages to drive their games.

It was perhaps Unity Technologies that started to change this when they adopted Mono as their scripting engine, giving their developers a choice of C#, strongly typed Javascript and Boo as programming languages to author their game's logic, effects and behaviors. They got the benefits of high-level languages, with the added performance of being compiled:

A New Generation of Game Developers

In the past years, a new generation of game developers have entered the stage. These are developers that have cut their teeth with Unity, XNA and frameworks like PyGame.

They value malleability, rapid iteration and safe environments without crashing over raw performance. They have grown used to profiling their software and tuning the hot-spots instead of depending on hunches that lead to premature optimizing.

This year things were very different at our booth. Lots of happy Unity users came by to talk about MonoDevelop, about the new soft debugger, and about the joy of using C# to build applications with Unity. Lots of people are working on big and small game titles using Mono.

MonoTouch and MonoDroid also helped us gain visibility in this space. Lots of existing users, and users-to-be came to discuss Mono's state.

But Mono has now spread its wings from being a pure extension system for C++-based systems (like Unity or the Sims3), to be used as the main language for building game engines and game frameworks.

There is the 2D MonoGame (an open source effort previously known as XNAtouch) which supports iPhone, Android (and they are working on Windows and Mac backends).

At the show, both DeltaEngine and Silicon Studio were showing pure C#-based 3D game engines powered by Mono. There were as well a number of stealth-mode projects and startups using Mono either as their scripting engine or the main runtime.

Walking around the GDC show-floor, you could see Mono running in many booths thanks to Unity's overwhelming popularity.

Perhaps my favorite Unity game at the show was Rochard, an upcoming PS3 game with interesting puzzles and the level of polish that you expect from a game like Ratchet and Clank (videos, screenshots).

Helping Game Developers

In the past couple of years we have made some changes to Mono that help developers use Mono as either a scripting system for an existing C or C++ code base, or for those using Mono as their main runtime.

We still deliver all the bonus features that come from using C# and the CLI, like lambda functions, functional style-programming, garbage collection, type safety, iterators, generics and improve upon the basics to include:

  • Mobile profile: a minimal profile of class libraries that is better suited for mobile, embedded and console uses.
  • LLVM-based code optimizer: in addition to our standard code generator designed for JIT compilation, we now offer developers a choice to use the LLVM optimizing compiler to generate code. Modulo a handful of issues, the code generated is as good as the one you would get by doing low-level programming with C++.
  • SIMD intrinsics: we treat the various Vector data types in the Mono.Simd namespace as first-class types recognized by the JIT and mapped directly to hardware supported SIMD operations:
    		// This code:
    		using Mono.Simd;
    		Vector4f Add (Vector4f one, Vector4f two)
    			return one + two;
    		// Is inlined by our LLVM code generator when invoked
    		// with the two statics first and second:
    		mov    first,%eax
    		movups (%eax),%xmm0
    		mov    second,%eax
    		movups (%eax),%xmm1
    		addps  %xmm1,%xmm0
  • Unsafe execution: some of our users wanted to continue using Mono and C# for their code for compute intensive operations. We now offer an unsafe option that will remove all arrays bounds check from the code. This, needless to say, is incredibly unsafe as it would open the doors to the sort of bugs that are common in C++. But if you are dying to squeeze the last bit of performance and treat C# as a nicer C++ and are ready to make a commitment to debug memory-corruption bugs, we got you covered.
  • Runtime Continuations: to create lightweight co-routines that are not bound to threads and allow developers to suspend execution at any point without having to change their code, or require new compilers. Silicon Studio's Homei system uses it.

Additionally, many developers are doing a little bit of embrace-and-extending the Mono runtime in creative ways to extend the CLI in new ways.

We want for example to introduce both a [ForceInline] and a [UnsafeCode] attributes that can be applied to methods to hint the code generation engine to always inline a method, and to remove arrays-bounds-checking on a per-method basis.

Hot Topics

A hot topic at the GDC was when we would bring the new C# 5 "await" feature to Mono.

C#'s await is a perfect solution to many of the problems that game developers face. Although there are solutions like Unity's co-routines, Mono Continuations/microthreads and Michael Hutchinson's open sourced micro-threading framework these features require a particular set of programming practices and pattern or support in the VM to do this.

C# Await is beautiful in that it integrates directly into the language and allows developers to focus on the algorithm and not in the administrivia of suspending execution and the boilerplate involved.

Which leads me to F#. The C# await functionality is based on F#'s Asynchronous Workflows which is available to everyone (thanks to Microsoft open sourcing the F# compiler and runtime).

What is fascinating is what some people are doing with F# in games: they can use F# to express the game AI in more succinct terms than any other scripting language can do. Not being a game designer, I do not quite understand the domain space, but apparently F# is just what the doctor ordered for complicated AI behaviors.

This coupled with async execution is a game engine developer's dream. But F# is not for everyone, there is a learning curve for getting to express problems in F# that is not suitable for game developers that have simple needs for their in-game logic.

WPF: A Recurring Topic

Many tool vendors (animation, pipeline, version control) have used WPF for their software or are planning on using it for new projects. These vendors have historically only supported Windows and are now looking at adding either Mac or Linux. This became almost a FAQ at the Mono booth: when are you going to ship WPF on Mac/Linux.

We have no plans on building WPF. We just do not have the man power to build an implementation in any reasonable time-frame.

Today, we offer a few suggestions to developers. Feel free to pick and choose:

  • Use Gtk# if you want to share the same code across all three platforms.
  • Split your UI code from the non-UI code and build a UI per system. On Windows, use WPF, on Mac use MonoMac, on Linux Gtk#. Or use gtk# on Mac and Linux.
  • For tools that are mostly OpenGL/DirectX based, use Windows.Forms, keeping in mind that some bug fixing or work around on their part might be needed as our Windows.Forms is not actively developed.

If you can afford building two or three UIs

Those are the toolkits you can use today to get your .NET-based tools working on multiple platforms. There are a number of longer-term options in the horizon that could be useful, but would require a concerted effort by the community to complete:

    Monomac.Winforms: assist the effort to have a Winforms look-alike API that happens to be based entirely on MonoMac and provides a native experience at the expense of dropping compatibility with some Winforms features.

    Create an SWT-like toolkit, like Eclipse did for Java, but this time for .NET. Mapping UI components to Cocoa, Gtk+ or WPF depending on the platform.

    Use Silverlight on Windows. And then use a modified version of Moonlight on Linux (and assist porting Moonlight to Mac) to get enough support to integrate with the native OS (menus, file dialogs, file system access) and to access and embed OpenGL in their applications.

    WPF implementation: not impossible, but this will require someone to fund some 15-20 developers to implement this enormous stack and some 2-3 years of work.

Posted on 07 Mar 2011

Saturday Mono Update

by Miguel de Icaza

Following a long established tradition of doing a quick Mono update after we do a major release, we released Mono 2.10.1 to the world.

There are four big features in this release that we backported from our master branch in addition to some 25 fresh bug fixes:

  • Support for running OrchardCMS on Linux. We also wrote a PostgreSQL backend for it. You can find the patches in this discussion.
  • The Parallel Framework's Default task scheduler has been switched to use our new and improved internal threadpool that we introduced with Mono 2.10. Previously it used its own (and amazing) scheduler, but did not share the same properties as .NET as there were by default two active threadpools, now there is only one.
  • Plenty of updates to the WCF stack.
  • OSX is a fast growing OS for Mono, this release brings performance counters for OSX as well as adding debugging symbols to all of our libraries if you install the CSDK package from our download page.

There were also three important regressions from Mono 2.8 that have been fixed. We encourage everyone to use Mono 2.10.1.

Posted on 26 Feb 2011

« Newer entries | Older entries »