by Miguel de Icaza

SwiftTermApp: SSH Client for iOS

For the past couple of years, programming in Swift has been a guilty pleasure of mine - I would sneak out after getting the kids to sleep to try out the latest innovations in iOS, such as SwiftUI and RealityKit. I have decided to ship a complete app based on this work, and I put together an SSH client for iOS and iPadOS using my terminal emulator, which I call “SwiftTermApp.”

What it lacks in terms of an original name, it makes up for by having solid fundamentals in place: a comprehensive terminal emulator with all the features you expect from a modern terminal emulator, good support for international input and output, tasteful use of libssh2, keyboard accessories for your Unix needs, storing your secrets in the iOS keychain, extensive compatibility tests, an embrace of the latest and greatest iOS APIs I could find, and is fuzzed and profiled routinely to ensure a solid foundation.

While I am generally pleased with the application for personal use, my goal is to make this app generally valuable to users that routinely use SSH to connect to remote hosts - and nothing brings more clarity to a product than a user’s feedback.

I would love for you to try this app and help me identify opportunities and additional features for it. These are some potential improvements to the app, and I could use your help prioritizing them:

To reduce my development time and maximize my joy, I built this app with SwiftUI and the latest features from Swift and iOS, so it won't work on older versions of iOS. In particular, I am pretty happy with what Swift async enabled me to do, which I hope to blog about soon.

SwiftTermApp is part of a collection of open-source code built around the Unix command line that I have been authoring on and off for the past 15 years. First in C#, now also in Swift. If you are interested in some of the other libraries, check out my UI toolkits for console applications (gui.cs for C#, and TermKit for Swift) and my xterm/vt100 emulator libraries (XtermSharp for C# and SwiftTerm for Swift). I previously wrote about how they came to be.

Update: Join the discussion

For later:

For a few months during the development of the SwiftTerm library, I worked to ensure great compatibility with other terminal emulators using the esctest and vttest. I put my MacPro to good use during the evenings to run the Swift fuzzer and tracked down countless bugs and denial of service errors, used Instruments religiously to improve the performance of the terminal emulator and ensured a good test suite to prevent regressions.

Original intro: For the past few years, I have been hacking on assorted terminal tools in both C# and Swift, including a couple of UI toolkits for console applications (gui.cs for C#, and TermKit for Swift) and xterm/vt100 emulators (XtermSharp for C# and SwiftTerm for Swift). I previously wrote about how they came to be.

Posted on 06 Apr 2022

AppStore Reviews Should be Stricter

by Miguel de Icaza

Since the AppStore launched, developers have complained about the review process as too strict. Applications are mostly rejected either for not meeting requirements, not having enough functionality or circumventing Apple’s business model.

Yet, the AppStore reviews are too lax and they should be much stricter.

Let me explain why I think so, what I believe some new rules need to be, and how the AppStore can be improved.

Prioritizing the Needs of the Many

Apple states that they have 28 million registered developers, but I believe that only a fraction of those are actively developing applications on a daily basis. That number is closer to 5 million developers.

I understand deeply why developers are frustrated with the AppStore review process - I have suffered my fair share of AppStore rejections: both by missing simple issues and by trying to push the limits of what was allowed. I founded Xamarin, a company that built tools for mobile developers, and had a chance to become intimately familiar with the rejections that our own customers got.

Yet, there are 1.5 billion active Apple devices, devices that people trust to be keep their data secure and private. The overriding concern should be the 1.5 billion active users, and not the 0.33% (or 1.86% if you are feeling generous).

People have deposited their trust on Apple and Google to keep their devices safe. I wrote about this previously. While it is an industry sport to make fun of Google, I respect the work that Google puts on securing and managing my data - so much that I have trusted them with my email, photographs and documents for more than 15 years.

I trust both companies both because of their public track record, and because of conversations that I have had with friends working at both companies about their processes, their practices and the principles that they care about (Keeping up with Information Security is a part-time hobby of minex).

Today’s AppStore Policies are Insufficient

AppStore policies, and their automated and human reviews have helped nurture and curate the applications that are available. But with a target market as large and rich as iOS and Android these ecosystems have become a juicy target for scammers, swindlers, gangsters, nation states and hackers.

While some developers are upset with the Apple Store rejections, profiteers have figured out that they can make a fortune while abiding by the existing rules. These rules allow behaviors that are in either poor taste, or explicitly manipulating the psyche of the user.

First, let me share my perspective as a parent, and

I have kids aged 10, 7 and 4, and my eldest had access to an iPad since she was a year old, and I have experienced first hand how angering some applications on the AppStore can be to a small human.

It breaks my heart every time they burst out crying because something in these virtual worlds was designed to nag them, is frustrating or incomprehensible to them. We sometimes teach them how to deal with those problems, but this is not always possible. Try explaining to a 3 year old why they have to watch a 30 seconds ad in the middle of a dinosaur game to continue playing, or teach them that at arbitrary points during the game tapping on the screen will not dismiss an ad, but will instead take them to download another app, or direct them another web site.

This is infuriating.

Another problem happens when they play games defective by design. By this I mean that these games have had functionality or capabilities removed that can be solved by purchasing virtual items (coins, bucks, costumes, pets and so on).

I get to watch my kids display a full spectrum of negative experiences when they deal with these games.

We now have a rule at home “No free games or games with In-App Purchases”. While this works for “Can I get a new game?”, it does not work for the existing games that they play, and those that they play with their friends.

Like any good rule, there are exceptions, and I have allowed the kids to buy a handful of games with in-app purchases from reputable sources. They have to pay for those from their allowance.

These dark patterns are not limited applications for kids, read the end of this post for a list of negative scenarios that my followers encountered that will ring familiar.

Closing the AppStore Loopholes

Applications using these practices should be banned:

  • Those that use Dark Patterns to get users to purchase applications or subscriptions: These are things like “Free one week trial”, and then they start charging a high fee per week. Even if this activity is forbidden, some apps that do this get published.

  • Defective-by-design: there are too many games out there that can not be enjoyed unless you spend money in their applications. They get the kids hooked up, and then I have to deal with whiney 4 year olds, 7 year olds and 10 year old to spend their money on virtual currencies to level up.

  • Apps loaded with ads: I understand that using ads to monetize your application is one way of supporting the development, but there needs to be a threshold on how many ads are on the screen, and shown by time, as these apps can be incredibly frustrating to use. And not all apps offer a “Pay to remove the ad”, I suspect because the pay-to-remove is not as profitable as showing ads non-stop.

  • Watch an ad to continue: another nasty problem are defective-by-design games and application that rather than requesting money directly, steer kids towards watching ads (sometimes “watch an ad for 30 seconds”) to get something or achieve something. They are driving ad revenue by forcing kids to watch garbage.

  • Install chains: there are networks of ill-behaved applications that trick kids into installing applications that are part of their network of applications. It starts with an innocent looking app, and before the day is over, you are have 30 new scammy apps installed on your machine.

  • Notification Abuse: these are applications that send advertisements or promotional offers to your device. From discount offers, timed offers and product offerings. It used to be that Apple banned these practices on their AppReview guidelines, but I never saw those enforced and resorted to turning off notifications. These days these promotions are allowed. I would like them to be banned, have the ability to report them as spam, and infringers to have their notification rights suspended.

  • ) Ban on Selling your Data to Third Parties: ban applications that sell your data to third parties. Sometimes the data collection is explicit (for example using the Facebook app), but sometimes unknowingly, an application uses a third party SDK that does its dirty work behind the scenes. Third party SDKs should be registered with Apple, and applications should disclose which third party SDKs are in use. If one of those 3rd party SDKs is found to abuse the rules or is stealing data, all applications that rely on the SDK can be remotely deactivated. While this was recently in the news this is by no means a new practice, this has been happening for years.

One area that is grayer are Applications that are designed to be addictive to increase engagement (some games, Facebook and Twitter) as they are a major problem for our psyches and for our society. Sadly, it is likely beyond the scope of what the AppStore Review team can do. One option is to pass legislation that would cover this (Shutdown Laws are one example).

Changes in the AppStore UI

It is not apps for children that have this problem. I find myself thinking twice before downloading applications with "In App Purchases". That label has become a red flag: one that sends the message "scammy behavior ahead"

I would rather pay for an app than a free app with In-App Purchases. This is unfair to many creators that can only monetize their work via an In-App Purchases.

This could be addressed either by offering a free trial period for the app (managed by the AppStore), or by listing explicitly that there is an “Unlock by paying” option to distinguish these from “Offers In-App Purchases” which is a catch-all expression for both legitimate, scammy or nasty sales.

My list of wishes:

  • Offer Trial Periods for applications: this would send a clear message that this is a paid application, but you can try to use it. And by offering this directly by the AppStore, developers would not have to deal with the In-App purchase workflow, bringing joy to developers and users alike.

  • Explicit Labels: Rather than using the catch-all “Offers In-App Purchases”, show the nature of the purchase: “Unlock Features by Paying”, “Offers Subscriptions”, “Buy virtual services” and “Sells virtual coins/items”

  • Better Filtering: Today, it is not possible to filter searches to those that are paid apps (which tend to be less slimy than those with In-App Purchases)

  • Disclose the class of In-App Purchases available on each app that offers it up-front: I should not have to scroll and hunt for the information and mentally attempt to understand what the item description is to make a purchase

  • Report Abuse: Human reviewers and automated reviews are not able to spot every violation of the existing rules or my proposed additional rules. Users should be able to report applications that break the rules and developers should be aware that their application can be removed from circulation for breaking the rules or scammy behavior.

Some Bad Practices

Check some of the bad practices in this compilation

Posted on 24 Sep 2020

Some Bad App Practices

by Miguel de Icaza

Some bad app patterns as some followers described them

You can read more in the replies to my request a few weeks ago:

Posted on 23 Sep 2020

Apple versus Epic Games: Why I’m Willing to Pay a Premium for Security, Privacy, and Peace of Mind

by Miguel de Icaza

In the legal battle over the App Store’s policies, fees, and review processes, Epic Games wants to see a return to the good old days – where software developers retained full control over their systems and were only limited by their imaginations. Yet those days are long gone.

Granted, in the early 90s, I hailed the Internet as humanity’s purest innovation. After all, it had enabled a group of global developers to collaboratively build the Linux operating system from the ground up. In my X years of experience as a developer, nothing has come close to the good will, success, and optimistic mood of those days.

Upon reflection, everything started to change the day I received my first spam message. It stood out not only because it was the first piece of unsolicited email I received, but also because it was a particularly nasty piece of spam. The advertiser was selling thousands of email addresses for the purposes of marketing and sales. Without question, I knew that someone would buy that list, and that I would soon be on the receiving end of thousands of unwanted pieces of mail. Just a few months later, my inbox was filled with garbage. Since then, the Internet has become increasingly hostile – from firewalls, proxies, and sandboxes to high-profile exploits and attacks.

Hardly a new phenomenon, before the Internet, the disk operating system (DOS) platform was an open system where everyone was free to build and innovate. But soon folks with bad intentions destroyed what was a beautiful world of creation and problem solving, and turned it into a place riddled with viruses, trojans, and spyware.

Like most of you alive at the time, I found myself using anti-virus software. In fact, I even wrote a commercial product in Mexico that performed the dual task of scanning viruses and providing a Unix-like permission system for DOS (probably around 1990). Of course, it was possible to circumvent these systems, considering DOS code had full access to the system.

In 1993, Microsoft introduced a family of operating systems that came to be known as Windows NT. Though it was supposed to be secure from the ground up, they decided to leave a few things open due to compatibility concerns with the old world of Windows 95 and DOS. Not only were there bad faith actors in the space, developers had made significant mistakes. Perhaps not surprisingly, users began to routinely reinstall their operating systems following the gradual decays that arose from improper changes to their operating systems.

Fast-forward to 2006 when Windows Vista entered the scene – attempting to resolve a class of attacks and flaws. The solution took many users by surprise. It’s more apt to say that it was heavily criticized and regarded as a joke in some circles. For many, the old way of doing things had been working just fine and all the additional security got in the way. While users hated the fact that software no longer worked out of the box, it was an important step towards securing systems.

With the benefit of hindsight, I look back at the early days of DOS and the Internet as a utopia, where good intentions, innovation, and progress were the norm. Now swindlers, scammers, hackers, gangsters, and state actors routinely abuse open systems to the point that they have become a liability for every user.

In response, Apple introduced iOS – an operating system that was purpose-build to be secure. This avoided backwards compatibility problems and having to deal with users who saw unwanted changes to their environment. In a word, Apple managed to avoid the criticism and pushback that had derailed Windows Vista.

It’s worth pointing out that Apple wasn’t the first to introduce a locked-down system that didn’t degrade. Nintendo, Sony, and Microsoft consoles restricted the software that could be modified on their host operating systems and ran with limited capabilities. This resulted in fewer support calls, reduced frustration, and limited piracy.

One of Apple’s most touted virtues is that the company creates secure devices that respect user’s privacy. In fact, they have even gone to court against the US government over security. Yet iOS remains the most secure consumer operating system. This has been made possible through multiple layers of security that address different threats. (By referring to Apple’s detailed platform security, you can get a clear sense of just how comprehensive it is.)

Offering a window into the development process, security experts need to evaluate systems from end-to-end and explore how the system can be tampered with, attacked, or hacked, and then devise both defense mechanisms and plans for when things will inevitably go wrong.

Consider the iPhone. The hardware, operating system, and applications were designed with everything a security professional loves in mind. Even so, modern systems are too large and too complex to be bullet-proof. Researchers, practitioners, hobbyists, and businesses all look for security holes in these systems – some with the goal of further protecting the system, others for educational purposes, and still others for profit or to achieve nefarious goals.

Whereas hobbyists leverage these flaws to unlock their devices and get full control over their systems, dictatorships purchase exploits in the black market to use against their enemies and gain access to compromising data, or to track the whereabouts of their targets.

This is where the next layer of security comes in. When a flaw is identified – whether by researchers, automated systems, telemetry, or crashes – software developers design a fix for the problem and roll out the platform update. The benefits of keeping software updated extend beyond a few additional emoji characters; many software updates come with security fixes. Quite simply, updating your phone keeps you more secure. However, it’s worth emphasizing that this only works against known attacks.

The App Store review process helps in some ways; namely, it can:

  • Force applications to follow a set of guidelines aimed at protecting privacy, the integrity of the system, and meet the bar for unsuspecting users

  • Reduce applications with minimal functionality – yielding less junk for users to deal with and smaller attack surfaces

  • Require a baseline of quality, which discourages quick hacks

  • Prevent applications from using brittle, undocumented, or unsupported capabilities

Still, the App Store review process is not flawless. Some developers have worked around these restrictions by: (1) distributing hidden payloads, (2) temporarily disabling features while their app was being tested on Apple’s campus, (3) using time triggers, or (4) remotely controlling features to evade reviewers.

As a case in point, we need look no further than Epic Games. They deceptively submitted a “hot fix,” which is a practice used to fix a critical problem such as a crash. Under the covers, they added a new purchasing system that could be remotely activated at the time of their choosing. It will come as no surprise that they activated it after they cleared the App Store’s review process.

Unlike a personal computer, the applications you run on your smartphone are isolated from the operating system and even from each other to prevent interference. Since apps run under a “sandbox” that limits what they can do, you do not need to reinstall your iPhone from scratch every few months because things no longer work.

Like the systems we described above, the sandbox is not perfect. In theory, a bad actor could include an exploit for an unknown security hole in their application, slip it past Apple, and then, once it is used in the wild, wake up the dormant code that hijacks your system.

Anticipating this, Apple has an additional technical and legal mitigation system in place. The former allows Apple to remotely disable and deactivate ill-behaved applications, in cases where an active exploit is being used to harm users. The legal mitigation is a contract that is entered into between Apple and the software developer, which can be used to bring bad actors to court.

Securing a device is an ongoing arms race, where defenders and attackers are constantly trying to outdo the other side, and there is no single solution that can solve the problem. The battlegrounds have recently moved and are now being waged at the edges of the App Store’s guidelines.

In the same way that security measures have evolved, we need to tighten the App Store’s guidelines, including the behaviors that are being used for the purposes of monetization and to exploit children. (I plan to cover these issues in-depth in a future post.) For now, let me just say that, as a parent, there are few things that would make me happier than more stringent App Store rules governing what applications can do. In the end, I value my iOS devices because I know that I can trust them with my information because security is paramount to Apple.

Coming full-circle, Epic Games is pushing for the App Store to be a free-for-all environment, reminiscent of DOS. Unlike Apple, Epic does not have an established track record of caring about privacy and security (in fact, their privacy policy explicitly allows them to sell your data for marketing purposes). Not only does the company market its wares to kids, they recently had to backtrack on some of their most questionable scams – i.e., loot boxes – when the European Union regulated them. Ultimately, Epic has a fiduciary responsibility to their investors to grow their revenue, and their growth puts them on a war path with Apple.

In the battle over the security and privacy of my phone, I am happy to pay a premium knowing that my information is safe and sound, and that it is not going to be sold to the highest bidder.

Posted on 28 Aug 2020

Yak Shaving - Swift Edition

by Miguel de Icaza

At the TensorFlow summit last year, I caught up with Chris Lattner who was at the time working on Swift for TensorFlow - we ended up talking about concurrency and what he had in mind for Swift.

I recognized some of the actor ideas to be similar to those from the Pony language which I had learned about just a year before on a trip to Microsoft Research in the UK. Of course, I pointed out that Pony had some capabilities that languages like C# and Swift lacked and that anyone could just poke at data that did not belong to them without doing too much work and the whole thing would fall apart.

For example, if you build something like this in C#:

class Chart {
  float [] points;
  public float [] Points { get { return points; } }

Then anyone with a reference to Chart can go and poke at the internals of the points array that you have surfaced. For example, this simple Plot implementation accidentally modifies the contents:

void Plot (Chart myChart)
   // This code accidentally modifies the data in myChart
   var p = myChart.points;
   for (int i = 0; i < p.Length; i++) {
       Plot (0, p [i]++)

This sort of problem is avoidable, but comes at a considerable development cost. For instance, in .NET you can find plenty of ad-hoc collections and interfaces whose sole purpose is to prevent data tampering/corruption. If those are consistently and properly used, they can prevent the above scenario from happening.

This is where Chris politely pointed out to me that I had not quite understood Swift - in fact, Swift supports a copy-on-write model for its collections out of the box - meaning that the above problem is just not present in Swift as I had wrongly assumed.

It is interesting that I had read the Swift specification some three or four times, and I was collaborating with Steve on our Swift-to-.NET binding tool and yet, I had completely missed the significance of this design decision in Swift.

This subtle design decision was eye opening.

It was then that I decided to gain some real hands-on experience in Swift. And what better way to learn Swift than to start with a small, fun project for a couple of evenings.

Rather than building a mobile app, which would have been 90% mobile design and user interaction, and little Swift, I decided to port my gui.cs console UI toolkit from C# to Swift and called it TermKit.

Both gui.cs and TermKit borrow extensively from Apple’s UIKit design - it is a design that I have enjoyed. It notably avoids auto layout, and instead uses a simpler layout system that I quite love and had a lot of fun implementing (You can read a description of how to use it in the C# version).

This journey was filled with a number of very pleasant capabilities in Swift that helped me find some long-term bugs in my C# libraries. I remain firmly a fan of compiled languages, and the more checking, the better.

Dear reader, I wish I had kept a log of those but that is now code that I wrote a year ago so I could share all of those with you, but I did not take copious notes. Suffice to say, that I ended up with a warm and cozy feeling - knowing that the compiler was looking out for me.

There is plenty to love about Swift technically, and I will not enumerate all of those features, other people have done that. But I want to point out a few interesting bits that I had missed because I was not a practitioner of the language, and was more of an armchair observer of the language.

The requirement that constructors fully initialize all the fields in a type before calling the base constructor is a requirement that took me a while to digest. My mental model was that calling the superclass to initialize itself should be done before any of my own values are set - this is what C# does. Yet, this prevents a bug where the base constructor can call a virtual method that you override, and might not be ready to handle. So eventually I just learned to embrace and love this capability.

Another thing that I truly enjoyed was the ability of creating a typealias, which once defined is visible as a new type. A capability that I have wanted in C# since 2001 and have yet to get.

I have a love/hate relationship with Swift protocols and extensions. I love them because they are incredibly powerful, and I hate them, because it has been so hard to surface those to .NET, but in practice they are a pleasure to use.

What won my heart is just how simple it is to import C code into Swift

  • to bring the type definitions from a header file, and call into the C code transparently from Swift. This really is a gift of the gods to humankind.

I truly enjoyed having the Character data type in Swift which allowed my console UI toolkit to correctly support Unicode on the console for modern terminals.

Even gui.cs with my port of Go’s Unicode libraries to C# suffers from being limited to Go-style Runes and not having support for emoji (or as the nerd-o-sphere calls it “extended grapheme clusters”).

Beyond the pedestrian controls like buttons, entry lines and checkboxes, there are two useful controls that I wanted to develop. An xterm terminal emulator, and a multi-line text editor.

In the C# version of my console toolkit my multi-line text editor was a quick hack. A List<T> holds all the lines in the buffer, and each line contains the runes to display. Inserting characters is easy, and inserting lines is easy and you can get this done in a couple of hours on the evening (which is the sort of time I can devote to these fun explorations). Of course, the problem is cutting regions of text across lines, and inserting text that spans multiple lines. Because what looked like a brilliant coup of simple design, turns out to be an ugly, repetitive and error-prone code that takes forever to debug - I did not enjoy writing that code in the end.

For my Swift port, I decided that I needed something better. Of course, in the era of web scale, you gotta have a web scale data structure. I was about to implement a Swift version of the Rope data structure, when someone pointed to me a blog post from the Visual Studio Code team titled “Text Buffer Reimplementation”. I read it avidly, founds their arguments convincing, and in the end, if it is good enough for Visual Studio Code, it should be good enough for the gander.

During my vacation last summer, I decided to port the TypeScript implementation of the Text Buffer to Swift, and named it TextBufferKit. Once again, porting this code from TypeScript to Swift turned out to be a great learning experience for me.

By the time I was done with this and was ready to hook it up to TermKit, I got busy, and also started to learn SwiftUI, and started to doubt whether it made sense to continue work on a UIKit-based model, or if I should restart and do a SwiftUI version. So while I pondered this decision, I did what every other respected yak shaver would do, I proceeded to my xterm terminal emulator work.

Since about 2009 or so, I wanted to have a reusable terminal emulator control for .NET. In particular, I wanted one to embed into MonoDevelop, so a year or two ago, I looked for a terminal emulator that I could port to .NET - I needed something that was licensed under the MIT license, so it could be used in a wide range of situations, and was modern enough. After surveying the space, I found “xterm.js” fit the bill, so I ported it to .NET and modified it to suit my requirements. XtermSharp - a terminal emulator engine that can have multiple UIs and hook up multiple backends.

For Swift, I took the XtermSharp code, and ported it over to Swift, and ended up with SwiftTerm. It is now in quite a decent shape, with only a few bugs left.

I have yet to built a TermKit UI for SwiftTerm, but in my quest for the perfect shaved yak, now I need to figure out if I should implement SwiftUI on top of TermKit, or if I should repurpose TermKit completely from the ground up to be SwiftUI driven.

Stay tuned!

Posted on 24 Mar 2020

Scripting Applications with WebAssembly

by Miguel de Icaza

The Unity3D engine features a capability where developers can edit the code for their program, hit “play” and observe the changes right away, without a visible compilation step. C# code is compiled and executed immediately inside the Unity editor in a seamless way.

This is a scenario where scripted code runs with full trust within the original application. The desired outcome is to not crash the host, be able to reload new versions of the code over and over, and not really about providing a security boundary.

This capability was built into Unity using .NET Application Domains: a code isolation technology that was originally built in .NET that allowed code to be loaded, executed and discarded after it was no longer needed.

Other developers used Application Domains as a security boundary in conjuction with other security technologies in .NET. But this combination turned out to have some holes, and Application Domains, once popular among .NET developers, fell from grace.

With .NET Core, Application domains are no longer supported, and alternative options for code-reloading have been created (dynamic loading of code can be achieved these days with AssemblyLoadContext).

While Unity was ahead of the industry in terms of code hot reloading, but other folks have used embedded runtimes to provide this sort of capability over the years, Javascript being one of the most popular ones.

Recently, I have been fascinated by WebAssembly for solving this particular scenario and solve it very well (some folks are also using WebAssembly to isolate sensitive code).

WebAssembly was popularized by the Web crowd, and it offers a number of capabilities that neither Javascript, Application Domains or other scripting languages solve very well for scripting applications.

Outside of the Web browser domain, WebAssembly checks all of the boxes in my book:

  • Provides great code isolation and memory isolation
  • Easily discard unused code and data
  • Wide reach: in addition to being available on the Web there are runtimes suitable for almost every scenario: fast JIT compilation, optimizing compilers, static compilation and assorted interpreters. One of my favorites is Wasmer
  • Custom operations can be surfaced to WebAssembly to connect the embedded code with the host.
  • Many languages can target this runtime. C, C++, C#, F#, Go, Rust and Swift among others.

WebAssembly is low-level enough that it does not come with a garbage collector, which means that it will not pause to garbage collect your code like .NET/Mono or JavaScript would. That depends entirely on the language that you run inside WebAssembly. If you run C, Rust or Swift code, there would be no time taken by a garbage collector, but if you run .NET or Go code there would be.

Going back to the Unity scenario: the fascinating feature for me, is that IDEs/Editors/Tools could leverage WebAssembly to host their favorite language for scripting during the development stage, but for the final build of a product (like Unity, Godot, Rhino3D, Unreal Engine and really any other application that offers scripting capabilities) they could bundle the native code without having to take a WebAssembly dependency.

For the sake of the argument, imagine the Godot game engine. Today Godot has support for GodotScript and .NET. But it could be extended to support for Swift for scripting, and use WebAssembly during development to hot-reload the code, but generate Swift code directly for the final build of a game.

The reason I listed the game engines here is that users of those products are as happy with the garbage collector taking some time to tidy up your heap as they are with a parent calling them to dinner just as they are swarming an enemy base during a 2-hour campaign.

WebAssembly is an incredibly exciting space, and every day it seems like it opens possibilities that we could only dream of before.

Posted on 02 Mar 2020

by Miguel de Icaza

Blog: Revisting the gui.cs framework

12 years ago, I wrote a small UI Library to build console applications in Unix using C#. I enjoyed writing a blog post that hyped this tiny library as a platform for Rich Internet Applications (“RIA”). The young among you might not know this, but back in 2010, “RIA” platforms were all the rage, like Bitcoin was two years ago.

The blog post was written in a tongue-in-cheek style, but linked to actual screenshots of this toy library, which revealed the joke:

First gui.cs application - a MonoTorrent client

This was the day that I realized that some folks did not read the whole blog post, nor clicked on the screenshot links, as I received three pieces of email about it.

The first was from an executive at Adobe asking why we were competing, rather than partnering on this RIA framework. Back in 2010, Adobe was famous for building the Flash and Flex platforms, two of the leading RIA systems in the industry. The second was from a journalist trying to find out more details about this new web framework, he was interested in getting on the phone to discuss the details of the announcement, and the third piece was from an industry analyst that wanted to understand what this announcement did for the strategic placement of my employer in their five-dimensional industry tracking mega-deltoid.

This tiny library was part of my curses binding for Mono in a time where I dreamed of writing and bringing a complete terminal stack to .NET in my copious spare time. Little did I know, that I was about to run out of time, as in little less than a month, I would start Moonlight - the open source clone of Microsoft Silverlight and that would consume my time for a couple of years.

Back to the Future

While Silverlight might have died, my desire to have a UI toolkit for console applications with .NET did not. Some fourteen months ago, I decided to work again on gui.cs, this is a screenshot of the result:

Sample app

In many ways the world had changed. You can now expect a fairly modern version of curses to be available across all Unices and Unix systems have proper terminfo databases installed.

Because I am a hopeless romantic, I called this new incarnation of the UI toolkit, gui.cs. This time around, I have updated it to modern .NET idioms, modern .NET build systems, and embraced the UIKit design for some of the internals of the framework and Azure DevOps to run my continuous builds and manage my releases to NuGet.

In addition, the toolkit is no longer tied to Unix, but contains drivers for the Windows console, the .NET System.Console (a less powerful version of the Windows console) and the ncurses library.

You can find the result in GitHub and you can install it on your favorite operating system by installing the Terminal.Gui NuGet package.

I have published both conceptual and API documentation for folks to get started with. Hopefully I will beat my previous record of two users.

The original layout system for gui.cs was based on absolute positioning - not bad for a quick hack. But this time around I wanted something simpler to use. Sadly, UIKit is not a good source of inspiration for simple to use layout systems, so I came up with a novel system for widget layout, one that I am quite fond of. This new system introduces two data types Pos for specifying positions and Dim for specifying dimensions.

As a developer, you assign Pos values to X, Y and Dim values to Width and Height. The system comes with a range of ways of specifying positions and dimensions, including referencing properties from other views. So you can specify the layout in a way similar to specifying formulas in a spreadsheet.

There is a one hour long presentation introducing various tools for console programming with .NET. The section dealing just with gui.cs starts at minute 29:28, and you can also get a copy of the slides.

Posted on 22 Apr 2019

by Miguel de Icaza

First Election of the .NET Foundation

Last year, I wrote about structural changes that we made to the .NET Foundation.

Out of 715 applications to become members of the foundation, 477 have been accepted.

Jon has posted the results of our first election. From Microsoft, neither Scott Hunter or myself ran for the board of directors, and only Beth Massi remains. So we went from having a majority of Microsoft employees on the board to only having Beth Massi, with six fresh directors joining: Iris Classon, Ben Adams, Jon Skeet, Phil Haack, Sara Chipps and Oren Novotny

I am stepping down very happy knowing that I achieved my main goal, to turn the .NET Foundation into a more diverse and member-driven foundation.

Congratulations and good luck .NET Board of 2019!

Posted on 29 Mar 2019

by Miguel de Icaza

.NET Foundation Changes

Today we announced a major change to the .NET Foundation, in which we fundamentally changed the way that the foundation operates. The new foundation draws inspiration from the Gnome Foundation and the F# Foundation.

We are making the following changes:

  • The Board of Directors of the Foundation will now be elected by the .NET Foundation membership, and they will be in charge of steering the direction of the foundation. The Board of Directors will be elected annually via direct vote from the members of the Foundation, with just one permanent member from Microsoft.

  • Anyone contributing to projects in the .NET Foundation can become a voting member of the Foundation. The main benefit is that you get to vote for who should represent you in the board of directors. To become a member, we will judge contributions to the projects in the foundation, which can either be code contributions, documentation, evangelism or other activities that advance .NET and its ecosystem.

  • Membership fee: we are adding a membership fee that will give the .NET Foundation independence from Microsoft when it comes to how it chooses to promote .NET and the ecosystem around it. We realize that not everyone can pay this fee, so this fee can be waived. But those that contribute to the Foundation will help us fund activities that will expand .NET.

  • We intend to have elections every year, so individuals will campaign on what they intend to bring to the board.

  • There is a limit in the number of members on the board representing a single company, which prevents the board from being stacked up by contributors for a single company, and will encourage our community to vote for board members with diverse backgrounds, strengthening the views of the board.

  • Companies do not vote. The only way to vote is for contributors to the .NET ecosystem, which could be affiliated with a company to vote, but the companies themselves have no vote. Our corporate sponsors are sponsors that care as much as we care as the growth and health of our ecosystem.

These changes are very close to my heart and took a lot of work to make them happen and make sure that Microsoft the company was comfortable with giving up the control over the .NET Foundation.

I want to thank Jon Galloway, the Executive Director of the current .NET Foundation to help make this a reality.

Going from the idea to the execution took a long time. Martin Woodward did some of the early foot work to get various people at Microsoft comfortable with the idea. Then Jon took over, and had to continue this process to get everyone on board and get everyone to accept that our little baby was ready to graduate, go to college and start its own independent life.

I want to thank my peers in the board of directors that supported this move, Scott Hunter, Oren Novotny, Rachel Reese as well as the entire supporting crew that helped us make this happen, Beth Massi, Jay Schmelzer and the various heroes in the Microsoft legal department that crossed all the t’s and dotted all the i’s.

See you on the campaign trail!

Posted on 04 Dec 2018

Startup Improvements in Xamarin.Forms on Android

by Miguel de Icaza

With Xamarin.Forms 3.0 in addition to the many new feature work that we did, we have been doing some general optimizations across the board, from compile times to startup times and wanted to share some recent results on the net effect on one of our larger sample apps.

These are the results when doing a cold start for the SmartHotel360 application on Android when compiled for 32bits (armeabi-v7a) on a Google Pixel (1st gen).

Release Release/AOT Release/AOT+LLVM
Forms 2.5.0 6.59s 1.66s 1.61s
Forms 3.0.0 3.52s 1.41s 1.38s

This is independent of the work that we are doing to improve Android's startup speed, that both brings additional benefits today, and will bring additional benefits in the future.

One of the areas that we are investing on for Android is to remove any dynamic code execution at startup to integrate with the Java runtime, instead all of this is being statically computed, similar to what we are doing on Mac and iOS where we completely eliminated reflection and code generation from startup.

Posted on 18 May 2018

How we doubled Mono’s Float Speed

by Miguel de Icaza

My friend Aras recently wrote the same ray tracer in various languages, including C++, C# and the upcoming Unity Burst compiler. While it is natural to expect C# to be slower than C++, what was interesting to me was that Mono was so much slower than .NET Core.

The numbers that he posted did not look good:

  • C# (.NET Core): Mac 17.5 Mray/s,
  • C# (Unity, Mono): Mac 4.6 Mray/s,
  • C# (Unity, IL2CPP): Mac 17.1 Mray/s,

I decided to look at what was going on, and document possible areas for improvement.

As a result of this benchmark, and looking into this problem, we identified three areas of improvement:

  • First, we need better defaults in Mono, as users will not tune their parameters
  • Second, we need to better inform the world about the LLVM code optimizing backend in Mono
  • Third, we tuned some of the parameters in Mono.

The baseline for this test, was to run Aras ray tracer on my machine, since we have different hardware, I could not use his numbers to compare. The results on my iMac at home were as follows for Mono and .NET Core:

Runtime Results MRay/sec
.NET Core 2.1.4, debug build dotnet run 3.6
.NET Core 2.1.4, release build, dotnet run -c Release 21.7
Vanilla Mono, mono Maths.exe 6.6
Vanilla Mono, with LLVM and float32 15.5

During the process of researching this problem, we found a couple of problems, which once we fixed, produced the following results:

Runtime Results MRay/sec
Mono with LLVM and float32 15.5
Improved Mono with LLVM, float32 and fixed inline 29.6


Chart visualizing the results of the table above

Just using LLVM and float32 your code can get almost a 2.3x performance improvement in your floating point code. And with the tuning that we added to Mono’s as a result of this exercise, you can get 4.4x over running the plain Mono - these will be the defaults in future versions of Mono.

This blog post explains our findings.

32 and 64 bit Floats

Aras is using 32-bit floats for most of his math (the float type in C#, or System.Single in .NET terms). In Mono, decades ago, we made the mistake of performing all 32-bit float computations as 64-bit floats while still storing the data in 32-bit locations.

My memory at this point is not as good as it used to be and do not quite recall why we made this decision.

My best guess is that it was a decision rooted in the trends and ideas of the time.

Around this time there was a positive aura around extended precision computations for floats. For example the Intel x87 processors use 80-bit precision for their floating point computations, even when the operands are doubles, giving users better results.

Another theme around that time was that the Gnumeric spreadsheet, one of my previous projects, had implemented better statistical functions than Excel had, and this was well received in many communities that could use the more correct and higher precision results.

In the early days of Mono, most mathematical operations available across all platforms only took doubles as inputs. C99, Posix and ISO had all introduced 32-bit versions, but they were not generally available across the industry in those early days (for example, sinf is the float version of sin, fabsf of fabs and so on).

In short, the early 2000’s were a time of optimism.

Applications did pay a heavier price for the extra computation time, but Mono was mostly used for Linux desktop application, serving HTTP pages and some server processes, so floating point performance was never an issue we faced day to day. It was only noticeable in some scientific benchmarks, and those were rarely the use case for .NET usage in the 2003 era.

Nowadays, Games, 3D applications image processing, VR, AR and machine learning have made floating point operations a more common data type in modern applications. When it rains, it pours, and this is no exception. Floats are no longer your friendly data type that you sprinkle in a few places in your code, here and there. They come in an avalanche and there is no place to hide. There are so many of them, and they won’t stop coming at you.

The “float32” runtime flag

So a couple of years ago we decided to add support for performing 32-bit float operations with 32-bit operations, just like everyone else. We call this runtime feature “float32”, and in Mono, you enable this by passing the --O=float32 option to the runtime, and for Xamarin applications, you change this setting on the project preferences.

This new flag has been well received by our mobile users, as the majority of mobile devices are still not very powerful and they rather process data faster than they need the precision. Our guidance for our mobile users has been both to turn on the LLVM optimizing compiler and float32 flag at the same time.

While we have had the flag for some years, we have not made this the default, to reduce surprises for our users. But we find ourselves facing scenarios where the current 64-bit behavior is already surprises to our users, for example, see this bug report filed by a Unity user.

We are now going to change the default in Mono to be float32, you can track the progress here:

In the meantime, I went back to my friend Aras project. He has been using some new APIs that were introduced in .NET Core. While .NET core always performed 32-bit float operations as 32-bit floats, the System.Math API still forced some conversions from float to double in the course of doing business. For example, if you wanted to compute the sine function of a float, your only choice was to call Math.Sin (double) and pay the price of the float to double conversion.

To address this, .NET Core has introduced a new System.MathF type, which contains single precision floating point math operations, and we have just brought this [System.MathF]( to Mono now.

While moving from 64 bit floats to 32 bit floats certainly improves the performance, as you can see in the table below:

Runtime and Options Mrays/second
Mono with System.Math 6.6
Mono with System.Math, using -O=float32 8.1
Mono with System.MathF 6.5
Mono with System.MathF, using -O=float32 8.2

So using float32 really improves things for this test, the MathF had a small effect.

Tuning LLVM

During the course of this research, we discovered that while Mono’s Fast JIT compiler had support for float32, we had not added this support to the LLVM backend. This meant that Mono with LLVM was still performing the expensive float to double conversions.

So Zoltan added support for float32 to our LLVM code generation engine.

Then he noticed that our inliner was using the same heuristics for the Fast JIT than it was using for LLVM. With the Fast JIT, you want to strike a balance between JIT speed and execution speed, so we limit just how much we inline to reduce the work of the JIT engine.

But when you are opt into using LLVM with Mono, you want to get the fastest code possible, so we adjusted the setting accordingly. Today you can change this setting via an environment variable MONO_INLINELIMIT, but this really should be baked into the defaults.

With the tuned LLVM setting, these are the results:

Runtime and Options Mrays/seconds
Mono with System.Math --llvm -O=float32 16.0
Mono with System.Math --llvm -O=float32 fixed heuristics 29.1
Mono with System.MathF --llvm -O=float32 fixed heuristics 29.6

Next Steps

The work to bring some of these improvements was relatively low. We had some on and off discussions on Slack which lead to these improvements. I even managed to spend a few hours one evening to bring System.MathF to Mono.

Aras RayTracer code was an ideal subject to study, as it was self-contained, it was a real application and not a synthetic benchmark. We want to find more software like this that we can use to review the kind of bitcode that we generate and make sure that we are giving LLVM the best data that we can so LLVM can do its job.

We also are considering upgrading the LLVM that we use, and leverage any new optimizations that have been added.


The extra precision has some nice side effects. For example, recently, while reading the pull requests for the Godot engine, I saw that they were busily discussing making floating point precision for the engine configurable at compile time (

I asked Juan why anyone would want to do this, I thought that games were just content with 32-bit floating point operations.

Juan explained to that while floats work great in general, once you “move away” from the center, say in a game, you navigate 100 kilometers out of the center of your game, the math errors start to accumulate and you end up with some interesting visual glitches. There are various mitigation strategies that can be used, and higher precision is just one possibility, one that comes with a performance cost.

Shortly after our conversation, this blog showed up on my Twitter timeline showing this problem:

A few images show the problem. First, we have a sports car model from the pbrt-v3-scenes **distribution. Both the camera and the scene are near the origin and everything looks good.

** (Cool sports car model courtesy Yasutoshi Mori.) Next, we’ve translated both the camera and the scene 200,000 units from the origin in xx, yy, and zz. We can see that the car model is getting fairly chunky; this is entirely due to insufficient floating-point precision.

** (Thanks again to Yasutoshi Mori.) If we move 5×5× farther away, to 1 million units from the origin, things really fall apart; the car has become an extremely coarse voxelized approximation of itself—both cool and horrifying at the same time. (Keanu wonders: is Minecraft chunky purely because everything’s rendered really far from the origin?)

** (Apologies to Yasutoshi Mori for what has been done to his nice model.)

Posted on 11 Apr 2018

Fixing Screenshots in MacOS

by Miguel de Icaza

This was driving me insane. For years, I have been using Command-Shift-4 to take screenshots on my Mac. When you hit that keypress, you get to select a region of the screen, and the result gets placed on your ~/Desktop directory.

Recently, the feature stopped working.

I first blamed Dropbox settings, but that was not it.

I read every article on the internet on how to change the default location, restart the SystemUIServer.

The screencapture command line tool worked, but not the hotkey.

Many reboots later, I disabled System Integrity Protection so I could use iosnoop and dtruss to figure out why screencapture was not logging. I was looking at the logs right there, and saw where things were different, but could not figure out what was wrong.

Then another one of my Macs got infected. So now I had two Mac laptops that could not take screenshots.

And then I realized what was going on.

When you trigger Command-Shift-4, the TouchBar lights up and lets you customize how you take the screenshot, like this:

And if you scroll it, you get these other options:

And I had recently used these settings.

If you change your default here, it will be preserved, so even if the shortcut is Command-Shift-4 for take-screenshot-and-save-in-file, if you use the TouchBar to make a change, this will override any future uses of the command.

Posted on 04 Apr 2018


by Miguel de Icaza

Mono has a pure C# implementation of the Windows.Forms stack which works on Mac, Linux and Windows. It emulates some of the core of the Win32 API to achieve this.

While Mono's Windows.Forms is not an actively developed UI stack, it is required by a number of third party libraries, some data types are consumed by other Mono libraries (part of the original design contract), so we have kept it around.

On Mac, Mono's Windows.Forms was built on top of Carbon, an old C-based API that was available on MacOS. This backend was written by Geoff Norton for Mono many years ago.

As Mono switched to 64 bits by default, this meant that Windows.Forms could not be used. We have a couple of options, try to upgrade the 32-bit Carbon code to 64-bit Carbon code or build a new backend on top of Cocoa (using Xamarin.Mac).

For years, I had assumed that Carbon on 64 was not really supported, but a recent trip to the console shows that Apple has added a 64-bit port. Either my memory is failing me (common at this age), or Apple at some point changed their mind. I spent all of 20 minutes trying to do an upgrade, but the header files and documentation for the APIs we rely on are just not available, so at best, I would be doing some guess work as to which APIs have been upgraded to 64 bits, and which APIs are available (rumors on Google searches indicate that while Carbon is 64 bits, not all APIs might be there).

I figured that I could try to build a Cocoa backend with Xamarin.Mac, so I sent this pull request to let me do this outside of the Mono tree on my copious spare time, so this weekend I did some work on the Cocoa Driver.

But this morning, on twitter, Filip Navarra noticed the above, and contacted me:

He has been kind enough to upload this Cocoa-based backend to GitHub.

Going Native

There are a couple of interesting things about this Windows.Forms backend for Cocoa.

The first one, is that it is using sysdrawing-coregraphics, a custom version of System.Drawing that we had originally developed for iOS users that implements the API in terms of CoreGraphics instead of using Cairo, FontConfig, FreeType and Pango.

The second one, is that some controls are backed by native AppKit controls, those that implement the IMacNativeControl interface. Among those you can find Button, ComboBox, ProgressBar, ScrollBar and the UpDownStepper.

I will now abandon my weekend hack, and instead get this code drop integrated as the 64-bit Cocoa backend.

Stay tuned!

Posted on 20 Feb 2018

Why I am excited about Unity in 2018

by Miguel de Icaza

While I had promised my friend Lucas that I would build a game in Unity for what seems like a decade, I still have not managed to build one.

Recently Aras shared his excitement for Unity in 2018. There is a ton on that blog post to unpack.

What I am personally excited about is that Unity now ships an up-to-date Mono in the core.

Jonathan Chambers and his team of amazing low-level VM hackers have been hard at work in upgrading Unity's VM and libraries to bring you the latest and greatest Mono runtime to Unity. We have had the privilege of assisting in this migration and providing them with technical support for this migration.

The work that the Unity team has done lays down the foundation for an ongoing update to their .NET capabilities, so future innovation on the platform can be quickly adopted, bringing new and more joyful capabilities to developers in the platform.

With this new runtime, Unity developers will be able to access and consume a large portion of third party .NET libraries, including all those shiny .NET Standard Libraries - the new universal way of sharing code in the .NET world.

C# 7

The Unity team has also provided very valuable guidance to the C# team which have directly influenced features in C# 7 like ref locals and returns

  • In our own tests using C# for an AR application, we doubled the speed of managed-code AR processing by using these new features.

When users use the new Mono support in Unity, they default to C# 6, as this is the version that Mono's C# compiler fully supports. One of the challenges is that Mono's C# compiler has not fully implemented support for C# 7, as Mono itself moved to Roslyn.

The team at Unity is now working with the Roslyn team to adopt the Roslyn C# compiler in Unity. Because Roslyn is a larger compiler, it is a slower compiler to startup, and Unity does many small incremental compilations. So the team is working towards adopting the server compilation mode of Roslyn. This runs the Roslyn C# compiler as a reusable service which can compile code very quickly, without having to pay the price for startup every time.

Visual Studio

If you install the Unity beta today, you will also see that on Mac, it now defaults to Visual Studio for Mac as its default editor.

JB evain leads our Unity support for Visual Studio and he has brought the magic of his Unity plugin to Visual Studio for Mac.

As Unity upgrades its Mono runtime, they also benefit from the extended debugger protocol support in Mono, which bring years of improvements to the debugging experience.

Posted on 20 Feb 2018

Interactive Line Editing in .NET

by Miguel de Icaza

Even these days, I still spend too much time on the command line. My friends still make fun of my MacOS desktop when they see that I run a full screen terminal, and the main program that I am running there is the Midnight Commander:

Every once in a while I write an interactive application, and I want to have full bash-like command line editing, history and search. The Unix world used to have GNU readline as a C library, but I wanted something that worked on both Unix and Windows with minimal dependencies.

Almost 10 years ago I wrote myself a C# library to do this, it works on both Unix and Windows and it was the library that has been used by Mono's interactive C# shell for the last decade or so.

This library used to be called getline.cs, and it was part of a series of single source file libraries that we distributed with Mono.

The idea of distributing libraries that were made up of a single source file did not really catch on. So we have modernized our own ways and now we publish these single-file libraries as NuGet packages that you can use.

You can now add an interactive command line shell with NuGet by installing the Mono.Terminal NuGet package into your application.

We also moved the single library from being part of the gigantic Mono repository into its own repository.

The GitHub page has more information on the key bindings available, how to use the history and how to add code-completion (even including a cute popup).

The library is built entirely on top of System.Console, and is distributed as a .NET Standard library which can run on your choice of .NET runtime (.NET Core, .NET Desktop or Mono).

Check the GitHub project page for more information.

Posted on 12 Jan 2018

Default ColorSpaces

by Miguel de Icaza

Recently a user filed a bug where the same RGB color when converted into a UIColor, and later into CGColor is different that going from the RGB value to a CGColor directly on recent versions of iOS.

You can see the difference here:

What is happening here is that CGColors that are created directly from the RGB values are being created on kCGColorSpaceGenericRGB colorspace. Starting with iOS 10, UIColor objects are being created with a device specific color space, in my current simluator this value is kCGColorSpaceExtendedSRGB.

You can see the differences in this workbook

Posted on 07 Dec 2017

Mono's TLS 1.2 Update

by Miguel de Icaza

Just wanted to close the chapter on Mono's TLS 1.2 support which I blogged about more than a year ago.

At the time, I shared the plans that we had for upgrading the support for TLS 1.2.

We released that code in Mono 4.8.0 in February of 2017 which used the BoringSSL stack on Linux and Apple's TLS stack on Xamarin.{Mac,iOS,tvOS,watchOS}.

In Mono 5.0.0 we extracted the TLS support from the Xamarin codebase into the general Mono codebase and it became available as part of the Mono.framework distribution as well as becoming the default.

Posted on 20 Nov 2017

Creating .NET Bindings for C Libraries with ObjectiveSharpie

by Miguel de Icaza

We created the ObjectiveSharpie tool to automate the mapping of Objective-C APIs to the .NET world. This is the tool that we use to keep up with Apple APIs.

One of the lesser known features of ObjectiveSharpie, is that it is not limited to binding Objective-C header files. It is also capable of creating definitions for C APIs.

To do this, merely use the "bind" command for ObjectiveSharpie and run it on the header file for the API that you want to bind:

	sharpie bind c-api.h -o binding.cs

The above command will produce the binding.cs that contains the C# definitions for both the native data structures and the C functions that can be invoked.

Since C APIs are ambiguous, in some cases ObjectiveSharpie will generate some diagnostics. In most cases it will flag methods that have to be bound with the [Verify]. This attribute is used as an indicator on your source code that you need to manually audit the binding, perhaps checking the documentation and adjust the P/Invoke signature accordingly.

There are various options that you can pass to the bind command, just invoke sharpie bind to get an up-to-date list of configuration options.

This is how I quickly bootstrapped the TensorFlowSharp binding. I got all the P/Invoke signatures done in one go, and then I started to do the work to surface an idiomatic C# API.

Posted on 18 Jan 2017

TLS 1.2 Comes to Mono: Update

by Miguel de Icaza

Update to the Update: See Nov 20th, 2017 Update for further updates.

Short version: the master branch of Mono now has support for TLS 1.2 out of the box. This means that SslStream now uses TLS 1.2, and uses of HttpWebRequest for HTTPS endpoints also uses TLS 1.2 on the desktop.

This brings TLS 1.2 to Mono on Unix/Linux in addition to Xamarin.{Mac,iOS,tvOS} which were already enabled to use TLS 1.2 via the native Apple TLS stack.

To use, install your fresh version of Mono, and then either run the btls-cert-sync command which will convert your existing list of trusted certificates to the new format (if you used cert-sync or mozroots in the past).

In Detail

The new version of Mono now embeds Google's Boring SSL as the TLS implementation to use.

Last year, you might remember that we completed a C# implementation of TLS 1.2. But we were afraid of releasing a TLS stack that had not been audited, that might contain exploitable holes, and that we did not have the cryptographic chops to ensure that the implementation was bullet proof.

So we decided that rather than ship a brand new TLS implementation we would use a TLS implementation that had been audited and was under active development.

So we picked Boring TLS, which is Google's fork of OpenSSL. This is the stack that powers Android and Google Chrome so we felt more comfortable using this implementation than a brand new implementation.

Linux Distributions

We are considering adding a --with-openssl-cert-directory= option to the configure script so that Linux distributions that package Mono could pass a directory that contains trusted root certificates in the format expected by OpenSSL.

Let us discuss the details in the [email protected]

Posted on 30 Sep 2016

Asset Previewer

by Miguel de Icaza

Mobile developers are working with all kinds of graphics assets and until now, to preview them, we would use an external tool to browse them.

We have developed a plug-in for both Visual Studio and Xamarin Studio that will provide live previews of various assets right into the IDE. It works particularly well for UrhoSharp projects.

The previewer can display in the IDE previews of the following asset types.

  • Static Models (*.mdl files)
  • Materials, Skyboxes, Textures (*.dds)
  • Animations (*.ani)
  • 2D and 3D Particles (*.pex)
  • Urho Prefabs (*.xml if the XML is an Urho Prefab)
  • Scenes (*.xml if the XML is an Urho Scene)
  • SDF Fonts (*.sdf)
  • Post-process effects (*.xml if the XML is an Urho RenderPath)
  • Urho UI layouts (*.xml if the XML is an Urho UI).

For Visual Studio, just download the previwer from the Visual Studio Gallery.

For Xamarin Studio, go to Xamarin Studio > Add-ins go to the "Gallery" tab, and search for "Graphics asset previewer" and install.

Posted on 28 Jul 2016

The Evolution of Interactive C#

by Miguel de Icaza

The Early Days

Years ago, in 2008 we introduced an interactive C# shell, at the time a challenge was to adjust the syntax to be suitable for interactive use, to provide a usable decent command line editing API for .NET and to turn our compiler as a service into a tool that could provide code completion.

A few months later, we added a UI shell for this on Linux and used Gtk's text widget to add support for embedding rich content into the responses. It was able to render images inline with the responses:

This was inspired at the time by the work that Owen Taylor at Red Hat had done on Re-interact. You can still watch a screencast of what it looked like.

Like Owen, I added a plot command:

At the time, Re-interact took some ideas from IPython and it seems like they are both inspired to some extent by Mathematica's interactive window.

Re-interact in particular introduced a brilliant idea, which was that users could go back in history, edit the previous expressions and the entire buffer would be re-evaluated. This idea lives on in Apple's Playgrounds for Swift.

In the meantime, the IPython project grew and they added one of my favorite features: it was now possible to blend text, explanations and code into workbooks. You can see a sample of this here. For years, I have desired an IPython for C#.

The Xamarin Years

In the meantime, at Xamarin, we experimented with the idea of bringing sometehing like Re-interact/Playgrounds to Xamarin Studio and we shipped Sketches:

But while these were interesting for trying out ideas and learning C#, they are not very useful for day to day work. We found that what our developers needed was a full C# REPL that was connected to the application they were running on, so they could experiment with their UI live. This is when we introduced Xamarin's Inspector. We took the existing engine and changed the way you interacted with C#.

The inspector was originally planned as a debugging aid, one that you could use to attach to a live Android/iOS/WPF process and use to examine:

We wrote several backends to provide some visual representation of the running app:

While Sketches used the IDE editing surface and a custom renderer view for results, with the Inspector we took a different route. Our interactive surface was an HTML canvas, and our results are rendered using HTML. This allowed us to do some pretty visualizations for results.

We have only started to explore what is possible in this space, and our last release included various data renderers. In particular, we added support for pretty printing collections and a handful of native Android and iOS results.

Up until now, we had been powered by Mono's C# compiler and while it has served us well for many years, it pales in comparison with the services that we could get out of Microsoft's Roslyn. Our code completion and error reporting were limited and the model did not translate too well to F#.

We recently switched the inspector to use Roslyn:

With this release, we ended up with an Inspector that can now be used either to debug/analyze a running app (very much like a web inspector), or one that can be used to experiment with APIs in the same spirit as other shells.


In the meantime, Frank Krueger took the iOS support that we introduced for the compiler as a service, and wrote Continuous, a plug-in for Xamarin Studio and Visual Studio that allowed developers to live-code. That is, instead of using this as a separate tool, you can modify your classes and methods live and have your application update as you change the code:

Frank also added support for evaluating values immediately, and showing some values in comments, similar in spirit to his Calca app for iOS:

The Glorious Future

But now that we have a powerful HTML rendering engine to display our results and we upgraded our compiler engine, we are ready to take our next steps.

One step will be to add more visualizers and rendering capabilties to our results in our Inspector.

The second step is to upgrade Sketches based on this work. We will be changing the Sketches UI to be closer to IPython, that is, the ability of creating workbooks that contain both rich HTML text along with live code.

To give you a taste of what is coming up on our next release, check out this screenshot:

Developers will still have a few options of richly interacting with C# and F#:

  • With our inspector experiment with APIs like they do with many other interactive shells, and to poke and modify running apps on a wide spectrum of environments.
  • With Frank Krueger's Continuous engine to see your changes live for your C# code.
  • With our revamped Sketches/workbook approach to use it for creating training, educational materials.

Posted on 17 Feb 2016

Shared Projects or PCL?

by Miguel de Icaza

My colleague Jason Smith has shared his views on what developers should use when trying to share code between projects. Should you go with a Shared Project or a Portable Class Library (PCL) in the world of Xamarin.Forms?

He hastily concludes that you should go with PCLs (pronounced Pickles).

For me, the PCL is just too cumbersome for most uses. It is like using a canon to kill a fly. It imposes too many limitations (limited API surface), forces you to jump through hoops to achieve some very basic tasks.

PCLs when paired with Nugets are unmatched. Frameworks and library authors should continue to deliver these, because they have a low adoption barrier and in general bring smiles and delight to their users.

But for application developers, I stand firmly on the opposite side of Jason.

I am a fan of simplicity. The simpler the technology, the easier it is for you to change things. And when you are building mobile applications chances are, you will want to make sweeping changes, make changes continously and these are just not compatible with the higher bar required by PCLs.

Jason does not like #if statements on his shared code. But this is not the norm, it is an exception. Not only it is an exception, but careful use of partial classes in C# make this a non issue.

Plugging a platform specific feature does not to use an #if block, all you have to do is isolate the functioanlity into a single method, and have each platform that consumes the code implement that one method. This elegant idea is the same elegant idea that makes the Linux kernel source code such a pleasure to use - specific features are plugged, not #ifdefed.

If you are an application developer, go with Shared Projects for your shared code. And now that we support this for F#, there is no reason to not adopt them.

Posted on 22 Jan 2016

getline.cs update: Partying like it is 1992

by Miguel de Icaza

Back in 2008, I wrote about getline.cs, a single-file command line editor for shell application. It included Emacs key bindings, history, customizable completion and incremental search. It is equivalent to GNU's readline library, except it is implemented in a single C# file.

I recently updated getline.cs to add a popup-based completion and C# heuristics for when to automatically trigger code completion. This is what it looks like when using in Mono's C# REPL in the command line:

Posted on 14 Jan 2016

Mono's Cooperative Mode for SGen GC

by Miguel de Icaza

Mono's master tree now contains support for a new mode of operation for our garbage collector, we call this the cooperative mode. This is in contrast with the default mode of operation, the preemptive mode.

This mode is currently enabled by setting the MONO_ENABLE_COOP environment variable.

We implemented this new mode of operation to make it simpler to debug our GC, to have access to more data on the runtime during GC times and also to support certain platforms that do not provide the APIs that our preemptive system needed.

Behind Preemptive Mode

When we started building Mono back in 2001, we wanted to get something up and running very quickly. The idea was to have enough of a system running on Linux that we could have a fully self-hosting C# environment in a short period of time, and we managed to do this within eight months.

We were very lucky when it came to garbage collection that the fabulous Boehm GC existed. We were able to quickly add garbage collection to Mono, without having to think much about the problem.

Boehm is fabulous because it does not really require the cooperation of the runtime to work. It is a garbage collector that was originally designed to add garbage collection capabilities to programs written in C or C++. It performs garbage collection without much developer intervention. And it achieves this for existing code: multi-threaded, assembly-loving, low-level code.

Boehm GC is a thing of beauty.

Boehm achieves its magic by pulling some very sophisticated low-level tricks. For example, when it needs to perform a garbage collection it relies on various operating system facilities to stop all running threads, examine the stacks for all these threads to gather roots from the stack, perform the actual GC job then resume the operation of the program.

While Boehm is fantastic, in Mono, we had needs that would be better served with a custom garbage collector. One that was generational and reduced collection times. One fit more closely with .NET. It was then that we built the current GC for Mono: SGen.

SGen has grown by leaps and bounds and has been key in supporting many advanced scenarios on Android and iOS as well as being a higher performance and lower latency GC for Mono.

When we implemented SGen, we had to make some substantial changes to Mono's code generator. This was the first time that Mono's code generator had to coordinate with the GC.

SGen kept a key feature of Boehm: most running code was blissfully unaware that it could be stopped and resumed at any point.

This meant that we did not have to do too much work to integrate SGen into Mono [1]. There are two main downsides with this.

The first downside is that we still required the host platform to support some mechanism to stop, resume and inspect threads. This alone is pretty obnoxious and caused much grief to developers porting Mono to strange platforms.

The second downside is that code that runs during the collection is not really allowed to use many of the runtime APIs or primitives, because the collector might be running in parallel to the regular code. You can only use reentrant code.

This is a major handicap for development and debugging of the collector. One that is just too obnoxious to deal with and one that has wasted too much of our time.

Cooperative Mode

In the new cooperative mode, the generated code is instrumented to support voluntarily stopping execution

Conceptually, you can think of the generated code as one that basically checks on every back-branch, or every call site that the collector has requested for the thread to stop.

The supporting Mono runtime has been instrumented as well to deal with this scenario. This means that every API that is implemented in the C runtime has been audited to determine whether it can run in a finite amount of time, or if it is a blocking operation and adjusted to participate accordingly.

For methods that run in a finite amount of time, we just wait for them to return back to managed code, where we will stop.

For methods that might potentially block, we need to add some annotations that inform our GC that it is safe to assume that the thread is not running any mutating code. Consider the internal call that implements the CreateDirectory method. It now has been decorated with MONO_PREPARE_BLOCKING and MONO_FINISH_BLOCKING to delimit blocking code.

This means that threads do not stop right away as they used to, but they stop soon enough. And it turns out that soon enough is good enough.

This has a number of benefits. First, it allows us to support platforms that do not have enough system primitives to stop, resume and examine arbitrary threads. Those include things like the Windows Store, WatchOS and various gaming consoles.

But selfishly, the most important thing for us is that we will be able to treat the garbage collector code as something that is a first class citizen in the runtime: when the collector works, it will be running in such a state that accessing various runtime structures is fine (or even using any tasty C libraries that we choose to use).


As of today, Mono's Coop engine can either be compiled in by default (by passing --with-cooperative-gc to configure), or by setting the MONO_ENABLE_COOP environment variable to any value.

We have used a precursor of Coop for about 18 months, and now we have a fully productized version of it on Mono master and we are looking for developers to try it out.

We are hoping to enable this by default next year. [1] Astute readers will notice that it still took years of development to make SGen the default collector in Mono.

Posted on 22 Dec 2015

David Brooks, Op-Ed for All Trades, Master of None

by Miguel de Icaza

I first heard about David Brooks' article criticizing Most Likely to Succeed from a Mom at school that told me it was a rebuttal to the movie, and I should check it out.

I nodded, but did not really expect the article to change my mind.

David Brooks is an all-terrain commentator which dispenses platitudes and opinions on a wide range of topics, usually with little depth or understanding. In my book, anyone that supported and amplified the very fishy evidence for going to war with Iraq has to go an extra mile to prove their worth - and he was specially gross when it came to it.

Considering that the best part about David Brook's writing is that they often prompt beautiful take downs from Matt Taibbi and that his columns have given rise to a cottage industry of bloggers that routinely point out just how wrong he is, my expectations were low.

Anyways, I did read the article.

While the tone of the article is a general disagreement with novel approaches to education, his prescription is bland and generic: you need some basic facts before you can build upon those facts and by doing this, you will become a wise person.

The question of course is just how many facts? Because it is one thing to know basic facts about our world like the fact that there are countries, and another one to memorize every date and place of a historic event.

But you won't find an answer to that on Brooks piece. If there is a case to be made to continue our traditional education and continue relying on tests to raise great kids, you will not find it here.

The only thing that transpires from the article is that he has not researched the subject - he is shooting from the hip. An action necessitated by the need to fill eight hundred words a short hour before lunch.

His contribution to the future of education brings as much intellectual curiosity as washing the dishes.

I rather not shove useless information into our kids. Instead we should fill their most previous years with joy and passion, and give them the tools to plot their own destinies. Raise curious, critical and confident kids.

Ones that when faced with a new problem opt for the more rewarding in-depth problem solving, one that will have them research, reach out to primary sources, and help us invent the future.

Hopefully we can change education and raise a happier, kinder and better generation of humans. The road to get there will be hard, and we need to empower the teachers and schools that want to bring this change.

"Most Likely to Succeed" represends Forward Motion, and helps us start this discussion, and David's opinions should be dismissed for what they are: a case of sloppy stop energy.

Do not miss Ted Dintersmith's response to the article, my favorite part:

I agree with Brooks that some, perhaps even many, gain knowledge and wisdom over time. We just don’t gain it in school. It comes when we’re fully immersed in our careers, when we do things, face setbacks, apply our learning, and evolve and progress. But that almost always comes after our formal education is over. I interview a LOT of recent college graduates and I’m not finding lots of knowledge and wisdom. Instead, I find lots of student debt, fear of failure, and formulaic thinking. And what do I rarely see? Passion, purpose, creativity, and audacity.

So, game on, David Brooks and others defending the 19th Century model of education.

Posted on 19 Oct 2015

Roslyn in MonoDevelop/XamarinStudio

by Miguel de Icaza

As promised, we now have a version of our IDE powered by Roslyn, Microsoft's open sourced C# compiler as a service

When we did the port we found various leaks in the IDE that were made worse by Roslyn, so we decided to take the time and fix those leaks, and optimize our use of Roslyn.

Next Steps

We want to get your feedback on how well it works and to let us know what problems you are running into. Once we feel that there are no regressions, we will make this part of the default IDE.

While Roslyn is very powerful, this power comes with a memory consumption price tag. The Roslyn edition of Xamarin Studio will use more memory.

We are working to reduce Roslyn's and Xamarin Studio memory usage in future versions.

Posted on 21 Sep 2015

Mono and LLVM's BitCode

by Miguel de Icaza

This past June, Apple announced that WatchOS 2 applications would have to be submitted using LLVM BitCode. The idea being that Apple could optimize your code as new optimizations are developed or new CPU features are introduced, and users would reap the benefits without requiring the developer to resubmit their applications.

BitCode is a serialized version of the low-level intermediate representation used by LLVM.

WatchOS 2 requires pure BitCode to be submitted. That is, BitCode that does not contain any machine code blobs. iOS supports mixed mode BitCode, that is, BitCode that contains both the LLVM intermediate representation code, and blobs of machine code.

While Mono has had an LLVM backend for a long time, generating pure BitCode posed a couple of challenges for us.

First, Mono's LLVM backend does not cover all the generated code. There were some corner cases that we handled with Mono's old code generator. Also, Mono uses hand-written assembly language code in various places (lots of small optimizations involving generics code sharing, method dispatch and other things like that). This poses a problem for WatchOS.

Secondly, Mono uses a modified version of LLVM that adds support for many .NET idioms. In particular, our changes to LLVM produce the necessary information to support .NET-style exception handling [1].

We spent the summer adapting Mono to produce Vanilla LLVM bitcode support. This includes the removal of our hand-tuned machine code, as well as devising a new system for exception handling that works in this context. Sadly, the exception handling is not as efficient as the one that we got with our modified LLVM.

Hopefully, we will be able to upstream our changes for better exception handling for .NET-like languages to LLVM in the future and get some of the performance back.


[1] Vanilla LLVM exception support requires exceptions to be explicit. In .NET some exceptions happen implicitly, for example, when dereferencing a null pointer, or dividing by zero.

Posted on 02 Sep 2015

Xamarin Release Cycles

by Miguel de Icaza

There are four major components of Xamarin's platform product: the Android SDK, the iOS SDK, our Xamarin Studio IDE and our Visual Studio extension.

In the past, we used to release each component independently, but last year we realized that developing and testing each component against the other ones was getting too expensive, too slow and introduced gratuitous errors.

So we switched to a new style of releases where all the components ship together at the same time. We call these cycles.

We have been tuning the cycle releases. We started with time-based releases on a monthly basis, with the idea that any part of the platform that wanted to be released could catch one of these cycles, or wait for the next cycle if they did not have anything ready.

While the theory was great, the internal dependencies of these components was difficult to break, so our cycles started taking longer and longer.

On top of the cycles, we would always prepare builds for new versions of Android and iOS, so we could do same-day releases of the stacks. These are developed against our current stable cycle release, and shipped when we need to.

We are now switching to feature-based releases. This means that we are now waiting for features to be stable, with long preview periods to ensure that no regressions are introduced.

Because feature based releases can take as long as it is needed to ship a feature, we have introduced Service Releases on top of our cycles.

Our Current Releases

To illustrate this scenario, let me show what our current platform looks like.

We released our Cycle 5 to coincide with the Build conference, back in April 29th. This was our last timed release (we call this C5).

Since then we have shipped three service releases which contain important bug fixes and minor features (C5-SR1, SR2 and SR3), with a fourth being cooked in the oven right now (C5-SR4)

During this time, we have issued parallel previews of Android M and iOS 9 support, those are always built on top of the latest stable cycle. Our next iOS 9 preview for example, will be based on the C5-SR4.

We just branched all of our products for the next upgrade to the platform, Cycle 6.

This is the cycle that is based on Mono 4.2.0 and which contains a major upgrade to our Visual Studio support for iOS and plenty of improvements to Xamarin Studio. I will cover some of my favorite features in Cycle 6 in future posts.

Posted on 01 Sep 2015

State of TLS in Mono

by Miguel de Icaza

This is an update on our efforts to upgrade the TLS stack in Mono.

You can skip to the summary at the end if you do not care about the sausage making details.

Currently, TLS is surfaced in a few places in the .NET APIs:

  • By the SslStream class, which is a general purpose class that can be used to turn any bidirectional stream into an TLS-powered stream. This class is what currently powers the web client in Mono.
  • By the HttpWebRequest class, which provides .NET's HTTP client. This in turn is the foundation for the modern HttpClient, both the WCF and WebServices stacks as well as the quick and dirty WebClient API.

HttpClient is in particular interesting, as it allows for different transports to be provided for it. The default implementation in .NET 4.5 and Mono today is to use an HttpWebRequest-based implementation. But on Windows 10, the implementation is replaced with one that uses WinRT's HTTP client.

Microsoft is encouraging developers to abandon HttpWebRequest and instead adopt HttpClient as it both async-friendly and can use the best available transport given on a specific platform. More on this in a second.

Mono's Managed TLS

Mono currently only supports TLS 1.0.

This is the stack that powers SslStream and HttpWebRequest.

Last year we started an effort to bring managed implementations of TLS 1.2 and TLS 1.1. Given how serious security has become and how many holes have been found in existing implementation, we built this with an extensive test suite to check for conformance and to avoid common exploits found in implementation mistakes of TLS. This effort is currently under development and you can see where it currently lives at mono-tls module.

This will give us complete TLS support for the entire stack, but this work is still going to take a few months to audit.

Platform Specific HttpClients

Most of the uses for TLS today is via the HTTP protocol, and not over custom TLS streams. This means that it is more important to get an HTTP client that supports a brand new TLS stack, than it is to provide the SslStream code.

We want to provide native HttpClient handlers for all of Mono's supported platforms: Android, iOS, Mac, Linux, BSD, Unix and Windows.

On iOS: Today Xamarin.iOS already ships a native handler, the CFNetworkHandler. This one is powered by Apple's CFNetwork stack. In recent years, Apple has improved their networking stack, and we now I strongly recommend using Paul Bett's fantastic ModernHttpClient which uses iOS' brand new NSUrlSession and uses OkHttp on Android.

On Android: in the short term, we recommend adopting ModernHttpClient from Paul Betts (bonus points: the same component works on iOS with no changes). In the long term, we will change the default handler to use the Android Java client.

In both cases, you end up with HTTP 2.0 capable clients for free.

But this still leaves Linux, Windows and other assorted operating systems without a regular transport.

For those platforms, we will be adopting the CoreFX handlers, which on Unix are powered by the libcurl library.

This still leaves HttpWebRequest and everything built on top of it running on top of our TLS stack.

Bringing Microsoft's SslStream and HttpWebRequest to Mono

While this is not really TLS related, we wanted to bring Microsoft's implementations of those two classes to Mono, as they would fix many odd corner cases in the API, and address limitations in our stack that do not exist in Microsoft's implementation.

But the code is tightly coupled to native Windows APIs which makes the adoption of this code difficult.

We have built an adaptation layer that will allow us to bring Microsoft's code and use Mono's Managed TLS implementation.

SslStream backends

Our original effort focused on a pure managed implementation of TLS because we want to ensure that the TLS stack would work on all available platforms in the same way. This also means that all of the .NET code that expects to control every knob of your secure connection to work (pinning certificates or validating your own chains for example).

That said, in many cases developers do not need this capabilities, and in fact, on Xamarin.iOS, we can not even provide the functionality, as the OS does not give users access to the certificate chains.

So we are going to be developing at least two separate SslStream implementations. For Apple systems, we will be implementing a version on top of Apple's SSL stack, and for other systems we will be developing an implementation on top of Amazon's new SSL library, or the popular OpenSSL variant of the day.

These have the advantage that we would not need to maintain the code, and we benefit from third parties doing all the hard security work and will be suitable for most uses.

For those rare uses that like to handle connections manually, you will have to wait for Mono's new TLS implementation to land.

In Summary

Android, Mac and iOS users can get the latest TLS for HTTP workloads using ModernHttpClient. Mac/iOS users can use the built-in CFNetworkHandler as well.

Soon: OpenSSL/AppleSSL based transports to be available in Mono (post Mono 4.2).

Soon: Advanced .NET SSL use case scenarios will be supported with Mono's new mono-tls stack

Soon: HttpWebRequest and SslStream stacks will be replaced in Mono with Microsoft's implementations.

Posted on 27 Aug 2015

Roslyn and Mono

by Miguel de Icaza

Hello Internet! I wanted to share some updates of Roslyn and Mono.

We have been working towards using Roslyn in two scenarios. As the compiler you get when you use Mono, and as the engine that powers code completion and refactoring in the IDE.

This post is a status update on the work that we have been doing here.

Roslyn on MonoDevelop/XamarinStudio

For the past year, we have been working on replacing the IDE's engine that gives us code completion, refactoring capabilities and formatting capabilities with one powered by Roslyn.

The current engine is powered by a combination of NRefactory and the Mono C# compiler. It is not as powerful, comprehensive or reliable as Roslyn.

Feature-wise, we completed the effort, and we now have a Roslyn-powered branch that uses Roslyn for code completion, refactoring, suggestions and code formatting.

In addition, we ported most of the refactoring capabilities from NRefactory to work on top of Roslyn. These were quite significant. Visual Studio users can try them out by installing the Refactoring Essentials for Visual Studio extension.

While our Roslyn branch is working great and is a pleasure to use, it also consumes more memory and by extension, runs a little slower. This is not Roslyn's fault, but the side effects of leaks and limitations in our code.

Our original plan was to release this for our September release (what we internally call "Cycle 6"), but we decided to pull the feature out from the release to give us time to fix the leaks that affected the Roslyn engine and tune the performance of Roslyn running on Mono.

Our revisited plan is to ship an update to our tooling in Cycle 6 (the regular feature update) but without Roslyn. In parallel, we will ship a Roslyn-enabled preview of MonoDevelop/XamarinStudio. This will give us time to collect your feedback on performance and memory usage regressions, and time to fix the issues before we make Roslyn the default.

Roslyn as a Compiler in Mono

One of the major roadblocks for the adoption of Roslyn in Mono was the requirement to generate debugging information that Mono could consume on Unix (the other one is that our C# batch compiler is still faster than Roslyn).

The initial Roslyn release only had support for generating debug information through a proprietary/native library on Windows, which meant that while Roslyn could be used to compile code on Unix, the result would not contain any debug information - this prevented Roslyn from being useful for most compilation uses.

Recently, Roslyn got support for Portable Program Database (PPDB) files. This is a fully documented, open, compact and efficient format for storing debug information.

Mono's master release contains now support for using PPDB files as its debug information. This means that Roslyn can produce debug information that Mono can consume.

That said, we still need more work in the Mono ecosystem to fully support PPDB files. The Cecil library is used extensively to manipulate IL images as well as their associated debug information. Our Reflection.Emit implementation will need to get a backend to generate PPDBs (for third party compilers, dynamic code generators) and support in IKVM to produce PPDB files (this is used by Mono's C# compiler and other third party compilers).

Additionally, many features in Roslyn surfaced bloat and bugs in Mono's class libraries. We have been fixing those bugs (and in many cases, the bugs have gone away by replacing Mono's implementation with implementations from Microsoft's Reference Source).

Posted on 21 Jul 2015

In Defense of the Selfie Stick

by Miguel de Icaza

From the sophisticated opinion of the trendsetters to Forbes, the Selfie Stick is the recipient of scorn and ridicule.

One of the popular arguments against the Selfie Stick is that you should build the courage to ask a stranger to take a picture of you or your group.

This poses three problems.

First, the courage/imposition problem. Asking a stranger in the street assumes that you will find such a volunteer.

Further, it assumes that the volunteer will have the patience to wait for the perfect shot ("wait, I want the waves breaking" or "Try to get the sign, just on top of me"). And that the volunteer will have the patience to show you the result and take another picture.

Often, the selfista that has amassed the courage to approach a stranger on the street, out of politeness, will just accept the shot as taken. Good or bad.

Except for a few of you (I am looking at you Patrick), most people feel uncomfortable imposing something out of the blue on a stranger.

And out of shyness, will not ask a second stranger for a better shot as long as the first one is within earshot.

I know this.

Second, you might fear for the stranger to either take your precious iPhone 6+ and run, or even worse, that he might sweat all over your beautiful phone and you might need to disinfect it.

Do not pretend like you do not care about this, because I know you do.

Third, and most important, we have the legal aspect.

When you ask someone to take a picture of you, technically, they are the photographer, and they own the copyright of your picture.

This means that they own the rights to the picture and are entitled to copyright protection. The photographer, and, not you, gets to decide on the terms to distribute, redistribute, publish or share the picture with others. Including making copies of it, or most every other thing that you might want to do with those pictures.

You need to explicitly get a license from them, or purchase the rights. Otherwise, ten years from now, you may find yourself facing a copyright lawsuit.

All of a sudden, your backpacking adventure in Europe requires you to pack a stack of legal contracts.

Now your exchange goes from "Can you take a picture of us?" to "Can you take a picture of us, making sure that the church is on the top right corner, and also, I am going to need you to sign this paper".

Using a Selfie Stick may feel awkward, but just like a condom, when properly used, it is the best protection against unwanted surprises.

Posted on 22 Jan 2015

.NET Foundation: Advisory Council

by Miguel de Icaza

Do you know of someone that would like to participate in the .NET foundation, as part of the .NET Foundation Advisory Council?

Check the discussion where we are discussing the role of the Advisory Council.

Posted on 01 Dec 2014

Microsoft Open Sources .NET and Mono

by Miguel de Icaza

Today, Scott Guthrie announced that Microsoft is open sourcing .NET. This is a momentous occasion, and one that I have advocated for many years.

.NET is being open sourced under the MIT license. Not only is the code being released under this very permissive license, but Microsoft is providing a patent promise to ensure that .NET will get the adoption it deserves.

The code is being hosted at the .NET Foundation's github repository.

This patent promise addresses the historical concerns that the open source, Unix and free software communities have raised over the years.

.NET Components

There are three components being open sourced: the .NET Framework Libraries, .NET Core Framework Libraries and the RyuJit VM. More details below.

.NET Framework Class Libraries

These are the class libraries that power the .NET framework as it ships on windows. The ones that Mono has historically implemented in an open source fashion.

The code is available today from Mono will be able to use as much a it wants from this project.

We have a project underway that already does this. We are replacing chunks of Mono code that was either incomplete, buggy, or not as fully featured as it should be with Microsoft's code.

We will be checking the code into by the end of the week (I am currently in NY celebrating :-)

Microsoft has stated that they do not currently plan on taking patches back or engaging into a full open source community style development of this code base, as the requirements for backwards compatibility on Windows are very high.

.NET Core

The .NET Core is a redesigned version of .NET that is based on the simplified version of the class libraries as well as a design that allows for .NET to be incorporated into applications.

Those of you familiar with the PCL 2.0 contract assemblies have a good idea of what these assemblies will look like.

This effort is being hosted at and is an effort where Microsoft will fully engage with the community to evolve, develop and improve the class libraries.

Today, they released the first few components to github; the plan is for the rest of the redesigned frameworks to be checked in here in the next few months.

Xamarin and the Mono project will be contributing to the efforts to bring .NET to Mac, Unix, Linux and other platforms. We will do this as Microsoft open sources more pieces of .NET Core, including RyuJIT.

Next Steps

Like we did in the past with .NET code that Microsoft open sourced, and like we did with Roslyn, we are going to be integrating this code into Mono and Xamarin's products.

Later this week, expect updated versions of the Mono project roadmap and a list of tasks that need to be completed to integrate the Microsoft .NET Framework code into Mono.

Longer term, we will make the Mono virtual machine support the new .NET Core deployment model as well as the new VM/class library interface

We are going to be moving the .NET Core discussions over to the .NET Foundation Forums.

With the Mono project, we have spent 14 years working on open source .NET. Having Microsoft release .NET and issue a patent covenant will ensure that we can all cooperate and build a more vibrant, richer, and larger .NET community.

Posted on 12 Nov 2014

Mono for Unreal Engine

by Miguel de Icaza

Earlier this year, both Epic Games and CryTech made their Unreal Engine and CryEngine available under an affordable subscription model. These are both very sophisticated game engines that power some high end and popular games.

We had previously helped Unity bring Mono as the scripting language used in their engine and we now had a chance to do this over again.

Today I am happy to introduce Mono for Unreal Engine.

This is a project that allows Unreal Engine users to build their game code in C# or F#.

Take a look at this video for a quick overview of what we did:

This is a taste of what you get out of the box:

  • Create game projects purely in C#
  • Add C# to an existing project that uses C++ or Blueprints.
  • Access any API surfaced by Blueprint to C++, and easily surface C# classes to Blueprint.
  • Quick iteration: we fully support UnrealEngine's hot reloading, with the added twist that we support it from C#. This means that you hit "Build" in your IDE and the code is automatically reloaded into the editor (with live updates!)
  • Complete support for the .NET 4.5/Mobile Profile API. This means, all the APIs you love are available for you to use.
  • Async-based programming: we have added special game schedulers that allow you to use C# async naturally in any of your game logic. Beautiful and transparent.
  • Comprehensive API coverage of the Unreal Engine Blueprint API.

This is not a supported product by Xamarin. It is currently delivered as a source code package with patches that must be applied to a precise version of Unreal Engine before you can use it. If you want to use higher versions, or lower versions, you will likely need to adjust the patches on your own.

We have set up a mailing list that you can use to join the conversation about this project.

Visit the site for Mono for Unreal Engine to learn more.

(I no longer have time to manage comments on the blog, please use the mailing list to discuss).

Posted on 23 Oct 2014

.NET Foundation: Forums and Advisory Council

by Miguel de Icaza

Today, I want to share some news from the .NET Foundation.

Forums: We are launching the official .NET Foundation forums to engage with the larger .NET community and to start the flow of ideas on the future of .NET, the community of users of .NET, and the community of contributors to the .NET ecosystem.

Please join us at We are using the powerful Discourse platform. Come join us!

Advisory Council: We want to make the .NET Foundation open and transparent. To achieve that goal, we decided to create an advisory council. But we need your help in shaping the advisory council: its role, its reach, its obligations and its influence on the foundation itself.

To bootstrap the discussion, we have a baseline proposal that was contributed by Shaun Walker. We want to invite the larger .NET community to a conversation about this proposal and help us shape the advisory council.

Check out the Call for Public Comments which has a link to the baseline proposal and come join the discussion at the .NET Forums.

Posted on 14 Oct 2014

Markdown Style Guide

by Miguel de Icaza

Markdown is as a file format for easily producing text that can be pleasantly read both on the web and while using command line tools, or plain text editors.

Recently, a crop of tools have emerged that deliver some form of WYSIWYG or side-by-side authoring tools to assist writers to visualize the final output as they work.

Authors are turning to these tools to produce documentation that looks good when authoring the document, yet the tools are not true to the spirit and goals of markdown. And in some cases, authors are not familiar with the essence of what makes markdown great, nor the philosophy behind it:

Readability, however, is emphasized above all else. A Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions.

Using these editors is the modern equivalent of using Microsoft Word to produce HTML documentation.

The generated markdown files very easy to produce, but are not suitable for human consumption. They likely violate a number of international treaties and probably will be banned by the EU.

This short post is a set of simple rules to improve your markdown.

They will help you deliver delight to all of your users, not just those using a web browser, but also those casually reading your documentation with a file manager, their console, and most importantly, potential contributors and copy editors that have to interact with your text.

Wrap Your Text

The ideal reading length for reading prose with a monospaced font is somewhere between 72 and 78 characters.

This is text snippet is from Mark Twain's Adventures of Tom Sawyer, with text wrapped around column 72, when reading in an 80x25 console:

It wont matter if you are using a larger console, the text will still be pleasant to read.

But if you use some of these markdown editors that do not bother wrapping your text, this is what the user would get:

And this is what is more likely to happen, with big consoles on big displays:

There is a reason why most web sites set a maximum width for the places where text will be displayed. It is just too obnoxious to read otherwise.

Many text editors have the ability of reformatting text your text when you make changes.

This is how you can fill your text in some common editors:

  • Emacs: Alt-Q will reformat your paragraph.
  • Vim: "V" (to start selection) then "gq" will reformat your selection.
  • TextMate: Control-Q.

Considering Using Two Spaces After a Period

When reading text on the console, using two spaces after a period makes it easier to see where phrases end and start.

While there is some debate as to the righteouness of one vs two spaces in the word of advanced typography these do not apply to markdown text. When markdown is rendered into HTML, the browser will ignore the two spaces and turn it into one, but you will give your users the extra visual cues that they need when reading text.

If you are interested in the topic, check these posts by Heraclitean River and DitchWalk.

Sample Code

For small code snippets, it is best if you just indent your code with spaces, as this will make your console experience more pleasant to use.

Recently many tools started delimiting code with the "```". While this has its place in large chunks of text, for small snippets, it is the visual equivalent of being punched in the face.

Try to punch your readers in the face only when absolutely necessary.


Unless you have plans to use multiple-nested level of headers, use the underline syntax for your headers, as this is visually very easy to scan when reading on a console.

That is, use:

Chapter Four: Which iPhone 6 is Right For You.

In the previous chapter we established the requirement to buy iPhones
in packs of six.  Now you must choose just whether you are going to go
for an apologetically aluminum case, or an unapologetically plastic

Instead of the Atx-style headers:

# Chapter Four: Which iPhone 6 is Right For You.

The second style can easily drown in a body of text, and can not help as a visual aid to see where new sections start.


While markdown allows you to only set the first character for a blockquote, like this:

> his is a blockquote with two paragraphs. Lorem ipsum dolor sit amet,
consectetuer adipiscing elit. Aliquam hendrerit mi posuere lectus.
Vestibulum enim wisi, viverra nec, fringilla in, laoreet vitae, risus.

Editors like Emacs, can reformat that text just fine, all you have to do is set the "Fill Prefix", by positioning your cursor after the "> " and use Control-x ., then you can use the regular fill command: Alt-Q, and this will produce:

> This is a blockquote with two paragraphs. Lorem ipsum dolor sit amet,
> consectetuer adipiscing elit. Aliquam hendrerit mi posuere
> lectus. Vestibulum enim wisi, viverra nec, fringilla in, laoreet
> vitae, risus.


Again, while Markdown will happily allow you to write things like:

*   Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Aliquam hendrerit mi posuere lectus. Vestibulum enim wisi,
viverra nec, fringilla in, laoreet vitae, risus.
*   Donec sit amet nisl. Aliquam semper ipsum sit amet velit.
Suspendisse id sem consectetuer libero luctus adipiscing.

You should love your reader, and once again, if you are using something like Emacs, use the fill prefix to render the list like this instead:

*   Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
    Aliquam hendrerit mi posuere lectus. Vestibulum enim wisi,
    viverra nec, fringilla in, laoreet vitae, risus.
*   Donec sit amet nisl. Aliquam semper ipsum sit amet velit.
    Suspendisse id sem consectetuer libero luctus adipiscing.	

Posted on 30 Sep 2014

Three Tricks in Xamarin Studio

by Miguel de Icaza

I wanted to share three tricks that I use a lot in Xamarin Studio/MonoDevelop.

Trick 1: Navigate APIs

Xamarin Studio's code completion for members of an object defaults to showing all the members sorted by name.

But if you press Control-space, it toggles the rendering and organizes the results. For example, for this object of type UIWindow, it first lists the methods available for UIWindow sorted by name, and then the cluster for its base class UIView:

This is what happens if you scroll to the end of the UIWindow members:

Trick 2: Universal Search

Use the Command-. shortcut to activate the universal search, once you do this and start typing it will find matches for both members and types in your solution, as well as IDE commands and the option to perform a full text search:

Trick 3: Dynamic Abbreviation Completion

This is a feature that we took from Emacs's Dynamic Abbrevs.

If you type Control-/ when you type some text, the editor will try to complete the text you are typing based on strings found in your project that start with the same prefix.

Hit control-/ repeatedly to cycle over possible completions.

Posted on 20 Aug 2014

Five Cross Platform Pillars

by Miguel de Icaza

The last couple of years have been good to C# and .NET, in particular in the mobile space.

While we started just with a runtime and some basic bindings to Android and iOS back in 2009, we have now grown to provide a comprehensive development stack: from the runtime, to complete access to native APIs, to designers and IDEs and to a process to continuously deliver polish to our users.

Our solution is based on a blend of C# and .NET as well as bindings to the native platform, giving users a spectrum of tools they can use to easily target multiple platforms without sacrificing quality or performance.

As the industry matured, our users found themselves solving the same kinds of problems over and over. In particular, many problems related to targeting multiple platforms at once (Android, iOS, Mac, WinPhone, WinRT and Windows).

By the end of last year we had identified five areas where we could provide solutions for our users. We could deliver a common framework for developers, and our users could focus on the problem they are trying to solve.

These are the five themes that we identified.

  • Cross-platform UI programming.
  • 2D gaming/retained graphics.
  • 2D direct rendering graphics.
  • Offline storage, ideally using SQLite.
  • Data synchronization.

Almost a year later, we have now delivered four out of the five pillars.

Each one of those pillars is delivered as a NuGet package for all of the target platforms. Additionally, they are Portable Class Libraries, which allows developers to create their own Portable Class Libraries on top of these frameworks.

Cross Platform UI programming

With Xamarin 3.0 we introduced Xamarin.Forms, which is a cross-platform UI toolkit that allows developers to use a single API to target Android, iOS and WinPhone.

Added bonus: you can host Xamarin.Forms inside an existing native Android, iOS or WinPhone app, or you can extend a Xamarin.Forms app with native Android, iOS or WinPhone APIs.

So you do not have to take sides on the debate over 100% native vs 100% cross-platform.

Many developers also want to use HTML and Javascript for parts of their application, but they do not want to do everything manually. So we also launched support for the Razor view engine in our products.

2D Gaming/Retained Graphics

Gaming and 2D visualizations are an important part of applications that are being built on mobile platforms.

We productized the Cocos2D API for C#. While it is a great library for building 2D games -and many developers build their entire experiences entirely with this API- we have also extended it to allow developers to spice up an existing native application.

We launched it this month: CocosSharp.

Offline Storage

While originally our goal was to bring Mono's System.Data across multiple platforms (and we might still bring this as well), Microsoft released a cross-platform SQLite binding with the same requirements that we had: NuGet and PCL.

While Microsoft was focused on the Windows platforms, they open sourced the effort, and we contributed the Android and iOS ports.

This is what powers Azure's offline/sync APIs for C#.

In the meantime, there are a couple of other efforts that have also gained traction: Eric Sink's SQLite.Raw and Frank Krueger's sqlite-net which provides a higher-level ORM interface.

All three SQLite libraries provide NuGet/PCL interfaces.

Data Synchronization

There is no question that developers love Couchbase. A lightweight NoSQL database that supports data synchronization via Sync gateways and Couchbase servers.

While Couchbase used to offer native Android and iOS APIs and you could use those, the APIs were different, since each API was modeled/designed for each platform.

Instead of writing an abstraction to isolate those APIs (which would have been just too hard), we decided to port the Java implementation entirely to C#.

The result is Couchbase Lite for .NET. We co-announced this development with Couchbase back in May.

Since we did the initial work to bootstrap the effort, Couchbase has taken over the maintenance and future development duties of the library and they are now keeping it up-to-date.

While this is not yet a PCL/NuGet, work is in progress to make this happen.

Work in Progress: 2D Direct Rendering

Developers want to have access to a rich API to draw. Sometimes used to build custom controls, sometimes used to draw charts or to build entire applications based on 2D rendered API.

We are working on bringing the System.Drawing API to all of the mobile platforms. We have completed an implementation of System.Drawing for iOS using CoreGraphics, and we are now working on both an Android and WinPhone implementations.

Once we complete this work, you can expect System.Drawing to be available across the board as a NuGet/PCL library.

If you can not wait, you can get your hands today on the Mac/iOS version from Mono's repository.

Next Steps

We are now working with our users to improve these APIs. But we wont stop at the API work, we are also adding IDE support to both Xamarin Studio and Visual Studio.

Posted on 20 Aug 2014

Mono Performance Team

by Miguel de Icaza

For many years a major focus of Mono has been to be compatible-enough with .NET and to support the popular features that developers use.

We have always believed that it is better to be slow and correct than to be fast and wrong.

That said, over the years we have embarked on some multi-year projects to address some of the major performance bottlenecks: from implementing a precise GC and fine tuning it for a number of different workloads to having implemented now four versions of the code generator as well as the LLVM backend for additional speed and things like Mono.SIMD.

But these optimizations have been mostly reactive: we wait for someone to identify or spot a problem, and then we start working on a solution.

We are now taking a proactive approach.

A few months ago, Mark Probst started the new Mono performance team. The goal of the team is to improve the performance of the Mono runtime and treat performance improvements as a feature that is continously being developed, fine-tuned and monitored.

The team is working both on ways to track performance of Mono over time, implemented support for getting better insights into what happens inside the runtime and has implemented several optimizations that have been landing into Mono for the last few months.

We are actively hiring for developers to join the Mono performance team (ideally in San Francisco, where Mark is based).

Most recently, the team added a new and sophisticated new stack for performance counters which allows us to monitor what is happening on the runtime, and we are now able to export to our profiler (a joint effort between our performance team and our feature team and implemented by Ludovic). We also unified both the runtime and user-defined performance counters and will soon be sharing a new profiler UI.

Posted on 23 Jul 2014

Better Crypto: Did Snowden Succeed?

by Miguel de Icaza

Snowden is quoted on Greenwald's new book "No Place to Hide" as wanting to both spark a debate over the use of surveillance and to get software developers to adopt and create better encryption:

While I pray that public awareness and debate will lead to reform, bear in mind that the policies of men change in time, and even the Constitution is subverted when the appetites of power demand it. In words from history: Let us speak no more of faith in man, but bind him down from mischief by the chains of cryptography.


The shock of this initial period [after the first revelations] will provide the support needed to build a more equal internet, but this will not work to the advantage of the average person unless science outpaces law. By understanding the mechanisms through which our privacy is violated, we can win here. We can guarantee for all people equal protection against unreasonable search through universal laws, but only if the technical community is willing to face the threat and commit to implementing over-engineered solutions.

Last week Matthew Green asked:

Only time will be able to answer whether as a community the tech world can devise better and simpler tools for normal users to have their privacy protected by default.

Snowden has succeeded in starting an important discussion and having software developers and their patrons react to the news.

At Xamarin we build developer tools for Android and iOS developers. It is our job to provide tools that developers use on a day to day basis to build their applications, and we help them build these mobile applications.

In the last year, we have noticed several changes in our developer userbase. Our customers are requesting both features and guidance on a number of areas.

Developers are reaching to us both because there is a new understanding about what is happening to our electronic communications and also response to rapidly changing requirements from the public and private sectors.

Among the things we have noticed:

  • Using Trusted Roots Respectfully: For years, we tried to educate our users on what they should do when dealing with X509 certificates. Two years ago, most users would just pick the first option "Ignore the problem".
    Today this is no longer what developers do by default.
  • Certificate Pinning: more than ever, developers are using certificate pinning to ensure that their mobile applications are only talking to the exact party they want to.
  • Ciphersuite Selection: We recently had to extend the .NET API to allow developers to force our networking stack to control which cipher suites the underlying SSL/TLS stack uses. This is used to prevent weak or suspected ciphersuites to be used for the communications.
  • Request for more CipherSuites: Our Mono runtime implements its own SSL/TLS and crypto stacks entirely in C#. Our customers have asked us to support new cipher suites on newer versions of the standards.

Sometimes developers can use the native APIs we provide to achieve the above goals, but sometimes the native APIs on Android and iOS make this very hard or do not expose the new desired functionality, so we need to step in.

Posted on 21 May 2014

News from the .NET World

by Miguel de Icaza

Some great announcements today from the Microsoft world.

#1 Open Source ASP.NET stack

The first one is that Microsoft's next generation web stack (ASP.NET vNext) is open source from the ground up, and runs on Mono on both Linux and Mac.

There are plenty of other design principles in this new version of ASP.NET. I provide a translation from Microsoft speak into Unix speak in parenthesis:

  • Cloud-ready out of the box (this is code name for "can run with different versions of .NET side by side").
  • A single programming model for Web sites and services
  • Low-latency developer experience (Refresh on browser recompiles)
  • Make high-performance and high-productivity APIs and patterns available - enable them both to be used and compose together within a single app.
  • Fine-grained control available via command-line tools and standard file formats.
  • Delivered via NuGet (package manager, similar to Node's NPM or Ruby Gems).
  • Release as open source via the .NET Foundation.
  • Can run on Mono, on Mac and Linux.

Update: And the software is live at

Client Libraries to Microsoft Services

They are shipping a number of new components to talk to their online services, and they all have a license suitable for being used from platforms other than Windows.

Posted on 12 May 2014

Roslyn Update

by Miguel de Icaza

As promised, we are now tracking the Unix-friendly Roslyn port on Mono's GitHub Organization.

We implemented a few C# 6.0 features in Mono's C# compiler to simplify the set of patches required to compile Roslyn.

So you will need a fresh Mono (from git).

Posted on 28 Apr 2014

Mono on PS4

by Miguel de Icaza

We have been working with a few PlayStation 4 C# lovers for the last few months. The first PS4 powered by Mono and MonoGame was TowerFall:

We are very excited about the upcoming Transistor, by the makers of Bastion, coming out on May 20th:

Mono on the PS4 is based on a special branch of Mono that was originally designed to support static compilation for Windows's WinStore applications [1].

[1] Kind of not very useful anymore, since Microsoft just shipped static compilation of .NET at BUILD. Still, there is no wasted effort in Mono land!

Posted on 14 Apr 2014

Documentation for our new iOS Designer

by Miguel de Icaza

The team has put together some beautiful getting started documentation for our iOS User Interface Designer.

In particular, check a couple of hot features on it:

Posted on 14 Apr 2014

Mono and Roslyn

by Miguel de Icaza

Last week, Microsoft open sourced Roslyn, the .NET Compiler Platform for C# and VB.

Roslyn is an effort to create a new generation of compilers written in managed code. In addition to the standard batch compiler, it contains a compiler API that can be used by all kinds of tools that want to understand and manipulate C# source code.

Roslyn is the foundation that powers the new smarts in Visual Studio and can also be used for static analysis, code refactoring or even to smartly navigate your source code. It is a great foundation that tool developers will be able to build on.

I had the honor of sharing the stage with Anders Hejlsberg when he published the source code, and showed both Roslyn working on a Mac with Mono, as well as showing the very same patch that he demoed on stage running on Mono.

Roslyn on Mono

At BUILD, we showed Roslyn running on Mono. If you want to run your own copy of Roslyn today, you need to use both a fresh version of Mono, and apply a handful of patches to Roslyn [2].

The source code as released contains some C# 6.0 features so the patches add a bootstrapping phase, allowing Roslyn to be built with a C# 5.0 compiler from sources. There are also a couple of patches to deal with paths (Windows vs Unix paths) as well as a Unix Makefile to build the result.

Sadly, Roslyn's build script depends on a number of features of MSBuild that neither Mono or MonoDevelop/XamarinStudio support currently [3], but we hope we can address in the future. For now, we will have to maintain a Makefile-based system to use Roslyn.

Our patches no longer apply to the tip of Roslyn master, as Roslyn is under very active development. We will be updating the patches and track Roslyn master on our fork moving forward.

Currently Roslyn generates debug information using a Visual Studio native library. So the /debug switch does not work. We will be providing an alternative implementation that uses Mono's symbol writer.

Adopting Roslyn: Mono SDK

Our goal is to keep track of Roslyn as it is being developed, and when it is officially released, to bundle Roslyn's compilers with Mono [6].

But in addition, this will provide an up-to-date and compliant Visual Basic.NET compiler to Unix platforms.

Our plans currently are to keep both compilers around, and we will implement the various C# 6.0 features into Mono's C# compiler.

There are a couple of reasons for this. Our batch compiler has been fine tuned over the years, and for day-to-day compilation it is currently faster than the Roslyn compiler.

The second one is that our compiler powers our Interactive C# Shell and we are about to launch something very interesting with it. This functionality is not currently available on the open sourced Roslyn stack.

In addition, we plan on distributing the various Roslyn assemblies to Mono users, so they can build their own tools on top of Roslyn out of the box.

Adopting Roslyn: MonoDevelop/Xamarin Studio

Roslyn really shines for use in IDEs.

We have started an effort to adopt Roslyn in MonoDevelop/Xamarin Studio. This means that the underlying NRefactory engine will also adopt Roslyn.

This is going to be a gradual process, and during the migration the goal is to keep using both Mono's C# compiler as a service engine and bit by bit, replace with the Roslyn components.

We are evaluating various areas where Roslyn will have a positive impact. The plan is to start with code completion [4] and later on, support the full spectrum of features that NRefactory provides (from refactoring to code generation).

C# Standard

While not related to Roslyn, I figured it was time to share this.

For the last couple of months, the ECMA C# committee has been working on updating the spec to reflect C# 5. And this time around, the spec benefits from having two independent compiler implementations.

Mono Project and Roslyn

Our goal is to contribute fixes to the Roslyn team to make sure that Roslyn works great on Unix systems, and hopefully to provide bug reports and bug fixes as time goes by.

We are very excited about the release of Roslyn, it is an amazing piece of technology and one of the most sophisticated compiler designs available. A great place to learn great C# idioms and best practices [5], and a great foundation for great tooling for C# and VB.

Thanks to everyone at Microsoft that made this possible, and thanks to everyone on the Roslyn team for starting, contributing and delivering such an ambitious project.


[1] Roslyn uses a few tracing APIs that were not available on Mono, so you must use a newer version of Mono to build Roslyn.

[2] We even include the patch to add french quotes that Anders demoed. Make sure to skip that patch if you don't want it :-)

[3] From Michael Hutchinson:

  • There are references of the form: <Reference Include="Microsoft.Build, Version=$(VisualStudioReferenceAssemblyVersion), Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
    This is a problem because our project system tries to load project references verbatim from the project file, instead of evaluating them from the MSBuild engine. This would be fixed by one of the MSBuild integration improvements I've proposed.
  • There's an InvalidProjectFileException error from the xbuild engine when loading one of the targets files that's imported by several of the code analysis projects, VSL.Settings.targets. I'm pretty sure this is because it uses MSBuild property functions, an MSBuild 4.0 feature that xbuild does not support.
  • They use the AllowNonModulatedReference metadata on some references and it's completely undocumented, so I have no idea what it does and what problems might be caused by not handling it in xbuild.
  • One project can't be opened because it's a VS Extension project. I've added the GUID and name to our list of known project types so we show a more useful error message.
  • A few of the projects depend on Microsoft.Build.dll, and Mono does not have a working implementation of it yet. They also reference other MSBuild assemblies which I know we have not finished.

[4] Since Roslyn is much better at error recovery and has a much more comprehensive support for code completion than Mono's C# compiler does. It also has much better support for dealing with incremental changes than we do.

[5] Modulo private. They use private everywhere, and that is just plain ugly.

[6] We will find out a way of selecting which compiler to use, either mcs (Mono's C# Compiler) or Roslyn.

Posted on 09 Apr 2014


by Miguel de Icaza

Herb Sutter from the ISO C++ group, reached out to the Cairo folks:

We are actively looking at the potential standardization of a basic 2D drawing library for ISO C++, and would like to base it on (or outright adopt, possibly as a binding) solid prior art in the form of an existing library.

And also:

we are focused on current Cairo as a starting point, even though it's not C++ -- we believe Cairo itself it is very well written C (already in an OO style, already const-correct, etc.).

Congratulations to the Cairo guys for designing such a pleasant to use 2D API.

But this would not be a Saturday blog post without pointing out that Cairo's C-based API is easier and simpler to use than many of those C++ libraries out there. The more sophisticated the use of the C++ language to get some performance benefit, the more unpleasant the API is to use.

The incredibly powerful Antigrain sports an insanely fast software renderer and also a quite hostile template-based API.

We got to compare Antigrain and Cairo back when we worked on Moonlight. Cairo was the clear winner.

We built Moonlight in C++ for all the wrong reasons ("better performance", "memory usage") and was a decision we came to regret. Not only were the reasons wrong, it is not clear we got any performance benefit and it is clear that we did worse with memory usage.

But that is a story for another time.

Posted on 04 Jan 2014

Debugging Remote Mono Targets

by Miguel de Icaza

Few guys have approached us recently about doing remote debugging of a Mono process. Typically this involves an underpowered system, or some kind of embedded system running Mono, and a fancy Mac or PC on the other end.

These are the instructions that Michael Hutchinson kindly provided on how to remotely debug your process using either Xamarin Studio or MonoDevelop:

Remote debugging is actually really easy with the Mono soft debugger. The IDE sends commands over TCP/IP to the Mono Soft Debugger agent inside the runtime. Depending how you launch the debuggee, you can either have it connect to the IDE over TCP, or have it open a port and wait for the IDE to connect to it.

For simple prototyping purposes, you can just set the MONODEVELOP_SDB_TEST env var, and a new "Run->Run With->Custom Soft Debugger" command will show up in Xamarin Studio / MonoDevelop, and you can specify an arbitrary IP and port or connect or or listen on, and optionally a command to run. Then you just have to start the debuggee with the correct --debugger-agent arguments (see the Mono manpage for details), start the connection, and start debugging.

For a production workflow, you'd typically create a MonoDevelop addin with a debugger engine and session subclassing the soft debugger classes, and overriding how to launch the app and set up the connection parameters. You'd typically have a custom project type too subclassing the DotNetProject, so you could override how the project was built and executed, and so that the new debugger engine could be the primary debugger for projects of that type. You'd get all the default .NET/Mono project and debugger functionality "for free".

You can get some inspiration on how to build your own add-in from the old MeeGo add-in. It has bitrotted, since MeeGo is no more, but it is good enough as a starting point.

Posted on 29 Oct 2013

Hiring Developers

by Miguel de Icaza

I am hiring software developers.

We are growing our Xamarin Studio/MonoDevelop, Visual Studio, iOS and Android teams.

Ideally, you are a C# programmer and ideally, you relocate to Boston, MA. But we can work with remote employees

Posted on 22 Aug 2013


by Miguel de Icaza

Those of you that saw my What is in Mono presentation at MonkeySpace know that there is a new language in the .NET world being developed by Zynga called PlayScript.

Check their home page on GitHub with cute videos!

PlayScript is a superset of ActionScript and it was based on Mono's C# 5.0 compiler. PlayScript is ActionScript augmented with C# 5.0 features.

Zynga's PlayScript allows developers that have some ActionScript/Flash code to bring their code to any platform that supports the ECMA Intermediate Language (Microsoft .NET and Mono) and blend it with other .NET languages.

But the PlayScript has a fabulous feature, it allows mixing code in both C# and PlayScript in the same compilation unit. For example, you can use the compiler like this:

	# Compile the C# source foo.cs into foo.exe
	$ mcs foo.cs

	# Compile the Playscript source into bar.exe
	$ mcs

	# Compile both C# and Playscript into a single executable
	$ mcs foo.cs

On a larger scale, you can see this in action in the pscorlib library. This library contains a blend of PlayScript and C# source code compiled into a single binary.

They have implemented the accelerated 3D APIs from Flash and ported some popular ActionScript libraries to PlayScript, like the Starling framework and Away3D.

They have also an add-on for Xamarin Studio that you can use to get IDE support for it.

At Xamarin we are working to integrate their language changes into Mono directly. You can track the integration work in the playscript-mono branch at GitHub.

Just like Unity's UnityScript, developers will be encouraged to use strong types to improve the performance of their applications.

You can join the PlayScript forum to track the progress of the project. And you can keep up with exciting developments.

Update: Some background on Playscript.

Posted on 20 Aug 2013

What is new on Mono

by Miguel de Icaza

Slides from my MonkeySpace "What is new in Mono?" talk:

Monkey space 2013 from Miguel de Icaza

Posted on 20 Aug 2013

Callbacks as our Generations' Go To Statement

by Miguel de Icaza

This week, as I was preparing my presentation on C# sung on iOS and Android, I came to the realization that callback-based programming has somehow become an acceptable programming model.

It has become an acceptable programming model, in the same way that using IF/GOTO to write programs was an acceptable model back in the 60's. They are acceptable because we did not have anything better to replace them.

Today, both C# and F# support a programming model that will do to our generation what structured programming, high-level languages and control flow primitives did to the developers in the 60's.

Sadly, many developers when they hear the word "C# async" immediately think "I have callbacks in my language already". Variations of this include "Promises are better", "Futures is the way to go", "Objective-C has blocks" and "the operating system provides that". All of these statements are made by people that have yet to study C# async or to grasp what it does.

This is my attempt at explaining why the C# async model is such a leap forward for developers.

Callbacks are a Band Aid

Callbacks have improved significantly over the years. In the pure C days, if you wanted to use callbacks, you would have to write code like this:

void cback (void *key, void *value, void *user_state)
	// My data is stored in the user_state, fetch it
	// in this case, just a simple int.

	int *sum = (int *) user_state;

	*sum = *sum + *(int *)value;

int sum_values (Hashtable *hash)
	int sum = 0;

	hash_table_foreach (hash, cback, &sum);
	return sum;

Developers would have to pass around these pointers to the state that they managed manually, which is just very cumbersome.

Today with languages that support lambdas, you can write code instead that can capture the state, so things like the above become:

int sum_values (Hashtable hash)
	int sum = 0;
	hash.foreach ((key, value) => { sum += value; });
	return sum;

Lambdas have made writing code a lot simpler, and now we see this on UI applications that use events/lambdas to react to user input and Javascript apps on the browser and the client that use callbacks to get their job done.

In Node.js's case the original idea was to scale a server by removing blocking operations and instead offering a pure callback-driven model. For desktop applications, often you want to chain operations "on response to a click, download a file, then uncompress it, then save it to the location specified by the user", all while interleaving some bits of user interface and background operation.

This leads to nested callbacks after callbacks, where each indentation level is executing at some point in the future. Some people refer to this as Callback Hell.

During this week preparation, Marco Arment happened to tweet this:

This is a common idiom. On our web site, when we launched Async, we shared this sample:

private void SnapAndPost ()
    Busy = true;
    UpdateUIStatus ("Taking a picture");
    var picker = new Xamarin.Media.MediaPicker ();
    var picTask = picker.TakePhotoAsync (new Xamarin.Media.StoreCameraMediaOptions ());
    picTask.ContinueWith ((picRetTask) => {
        InvokeOnMainThread (() => {
            if (picRetTask.IsCanceled) {
                Busy = false;
                UpdateUIStatus ("Canceled");
            } else {
                var tagsCtrl = new GetTagsUIViewController (picRetTask.Result.GetStream ());
                PresentViewController (tagsCtrl, true, () => {
                    UpdateUIStatus ("Submitting picture to server");
                    var uploadTask = new Task (() => {
                        return PostPicToService (picRetTask.Result.GetStream (), tagsCtrl.Tags);
                    uploadTask.ContinueWith ((uploadRetTask) => {
                        InvokeOnMainThread (() => {
                            Busy = false;
                            UpdateUIStatus (uploadRetTask.Result.Failed ? "Canceled" : "Success");
                    uploadTask.Start ();

The problem with these nested callbacks is that you can see very quickly that these are not code bases you want to be working with. Currently it does some basic error handling, but it does not even attempt to do some better error recovery.

Thinking about extending the above functionality makes me pause, perhaps there is something else I can do to avoid patching the above function?

And if I wanted to do better error recovery or implement a better workflow I can see myself annoyed at both the bookkeeping that I need to do, make sure that "Busy" value is property updated on every possible exit (and possible exits I add).

This is ugly to the point that your mind starts to wander "perhaps there is a new article on hacker news" or "did a new cat get posted on".

Also notice that in the sample above there is a context switching that takes place on every lambda: from background threads to foreground threads. You can imagine a real version of this function being both larger, getting more features and accumulating bugs in corner cases that were not easily visible.

And the above reminded me of Dijkstra's Go To Statement Considered Harmful. This is what Dijkstra's had to say in the late 60's about it:

For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce. More recently I discovered why the use of the go to statement has such disastrous effects, and I became convinced that the go to statement should be abolished from all "higher level" programming languages (i.e. everything except, perhaps, plain machine code). At that time I did not attach too much importance to this discovery; I now submit my considerations for publication because in very recent discussions in which the subject turned up, I have been urged to do so.

My first remark is that, although the programmer's activity ends when he has constructed a correct program, the process taking place under control of his program is the true subject matter of his activity, for it is this process that has to accomplish the desired effect; it is this process that in its dynamic behavior has to satisfy the desired specifications. Yet, once the program has been made, the "making" of the corresponding process is delegated to the machine.

My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.

And this is exactly the kind of problem that we are facing with these nested callbacks that cross boundaries.

Just like in the Go To days, or the days of manual memory management, we are turning into glorified accountants. Check every code path for the proper state to be properly reset, updated, disposed, released.

Surely as a species we can do better than this.

And this is precisely where C# async (and F#) come in. Every time you put the word "await" in your program, the compiler interprets this as a point in your program where execution can be suspended while some background operation takes place. The instruction just in front of await becomes the place where execution resumes once the task has completed.

The above ugly sample, then becomes:

private async Task SnapAndPostAsync ()
    try {
        Busy = true;
        UpdateUIStatus ("Taking a picture");
        var picker = new Xamarin.Media.MediaPicker ();
        var mFile = await picker.TakePhotoAsync (new Xamarin.Media.StoreCameraMediaOptions ());
        var tagsCtrl = new GetTagsUIViewController (mFile.GetStream ());
        // Call new iOS await API
        await PresentViewControllerAsync (tagsCtrl, true);
        UpdateUIStatus ("Submitting picture to server");
        await PostPicToServiceAsync (mFile.GetStream (), tagsCtrl.Tags);
        UpdateUIStatus ("Success");
    } catch (OperationCanceledException) {
        UpdateUIStatus ("Canceled");
    } finally {
        Busy = false;

The compiler takes the above code and rewrites it for you. There is no longer a direct mapping between each line of code there to what the compiler produces. This is similar to what happens with C# iterators or even lambdas.

The above looks pretty linear. And now, I can see myself feeling pretty confident about changing the flow of execution. Perhaps using some conditional code that triggers different background processes, or using a loop to save the picture in various locations, or applying multiple filters at once. Jeremie has a nice post that happens to do this.

Notice that the handling of that annoying "Busy" flag is now centralized thanks to the finally clause. I can now guarantee that the variable is always properly updated, regardless of the code path in that program and the updates that take place to that code.

I have just delegated the bookkeeping to the compiler.

Async allows me to think about my software in the very basic terms that you would see in a flow-chart. Not as a collection of tightly coupled and messy processes with poorly defined interfaces.

Mind Liberation

The C# compiler infrastructure for Async is actually built on top of the Task primitive. This Task class is what people in other languages refer to as futures, promises or async. This is probably where the confusion comes from.

At this point, I consider all of these frameworks (including the one in .NET) just as lower-level plumbing.

Tasks encapsulate a unit of work and they have a few properties like their execution state, results (if completed), and exceptions or errors that might have been thrown. And there is a rich API used to combine tasks in interesting ways: wait for all, wait for some, combine multiple tasks in one and so on.

They are an important building block and they are a big improvement over rolling your own idioms and protocols, but they are not the means to liberate your mind. C# async is.

Frequently Asked Questions about Async

Today I had the chance to field a few questions, and I wanted to address those directly on my blog:

Q: Does async use a new thread for each operation?

A: When you use Async methods, the operation that you requested is encapsulated in a Task (or Task<T>) object. Some of these operations might require a separate thread to run, some might just queue an event for your runloop, some might use kernel asynchronous APIs with notifications. You do not really know what an Async method is using behind the scenes, that is something that the author of each user will pick.

Q: It seems like you no longer need to use InvokeOnMainThread when using Async, why?

A: When a task completes, the default is for execution to be resumed on the current synchronization context. This is a thread-local property that points to a specific implementation of a SynchronizationContext.

On iOS and Android, we setup a synchronization context on the UI thread that will ensure that code resumes execution on the main thread. Microsoft does the same for their platforms.

In addition, on iOS, we also have a DispatchQueue sync context, so by default if you start an await call on a Grand Central Dispatch queue, then execution is resumed on that queue.

You can of course customize this. Use SynchronizationContext and ConfigureAwait for this.

Finally, the PFX team has a good FAQ for Async and Await.

Async Resources

Here are some good places to learn more about Async:

Posted on 15 Aug 2013

Richard Dawkins should revisit the letter to his 10 year old daughter

by Miguel de Icaza

Like Richard Dawkins, I am also an atheist. I have also enjoyed his books and I am peripherally aware of his atheist advocacy.

Recently a letter Richard Dawkins wrote to his 10 year old daughter made the rounds.

He needs to ammend the letter and explain to her that it is not enough to find evidence, it is also important to be able to reason effectively about this evidence and avoid a series of logical pitfalls.

He failed to do this in a series of poorly thought out tweets, starting with this:

He followed up with a series of tweets to try to both explain the above as well as retweeting various people that came out in his defense with statements like:

I found the entire episode unbecoming of a scientist.

His original tweet, while true, does not have the effect of trying to advance our understanding of the world. It is at best a troll.

We expect from scientists to use the processes, techniques and tools of science math and logic to advance our understanding of the world, not resort to innuendo, fallacies and poor logical constructions to prove our points.

Correlation Does Not Imply Causation

Among others, I do not expect a scientist to imply that correlation implies causation. Which is what this tweet did.

Today he posted a large follow up where he explains what lead him to make this statement and also to selectively address some of the the criticism he received. He addressed the simpler criticism, but left out the meaty ones (you can find them on the replies to his tweet).

Dawkins failed to address the major problem with his tweet, which was exactly the use of correlation to imply causation.

Instead, he digs down deeper:

Twitter's 140 character limit always presents a tough challenge, but I tried to rise to it. Nobel Prizes are a pretty widely quoted, if not ideal, barometer of excellence in science. I thought about comparing the numbers of Nobel Prizes won by Jews (more than 120) and Muslims (ten if you count Peace Prizes, half that if you don't). This astonishing discrepancy is rendered the more dramatic when you consider the small size of the world's Jewish population. However, I decided against tweeting that comparison because it might seem unduly provocative (many Muslim "community leaders" are quite outspoken in their hatred of Jews) and I sought a more neutral comparison as more suitable to the potentially inflammable medium of Twitter. It is a remarkable fact that one Cambridge college, Trinity, has 32 Nobel Prizes to its credit. That's three times as many as the entire Muslim world even if you count Peace Prizes, six times as many if you don't. I dramatised the poverty of Muslim scientific achievement, and the contrast with their achievements in earlier centuries, in the following brief tweet: "All the world's Muslims have fewer Nobel Prizes than Trinity College, Cambridge. They did great things in the Middle Ages, though."

Now we know that Richard was not merely stating a couple of facts on his original tweet. He was trying to establish a relationship between a religion and scientific progress.

One possible explanation that does not involve Muslim-hood is that the majority of muslims live in impoverished nations (see map). Poverty and access to resources are likely bigger reasons for the lack of advancement in the sciences than belonging to a particular religion.

Is my theory better than Richard's? We could test the theory by looking at the list of Nobel laureates per country.

Let us consider my country, Mexico, a poor country compared to the wealth of the UK. We have twice as many people living in Mexico compared to the UK. Sadly, we only have three Nobel laureates vs Trinity College's thirty two.

If we expand the scope to Latin America which has half a billion people. Even with this, we can only muster sixteen laureates vs Trinity's 32.

Let us look into the African continent, with its billion people. They manage to only score 20 Nobel laureates.

And shockingly, the wealthier the nation, the more laureates. South Africa accounts for half of Africa's laureates (with ten), Egypt which has a better economy than most other African nations and gets tasty American aid gets five, which leaves another five for the rest of the continent.

If I had some axe to grind against Mexicans, Spanish speakers, Africans, Muslims, Bedouins, Brazilians, or Latin Americans I could probably make a statement as truthful as Richard's original tweet, which could be as offensive to those popuations and just like Richard prove absolutely nothing.

I think we have stronger evidence that access to wealth has an effect on how many people get this award than a religion.

The second flaw in his argument is to identify a University with access to funds, and a fertile ground for research and education to a group of people linked only by religion.

Perhaps people go to places like Trinity College becasue it is a fertile ground for research and education. If that is the case, then we have an explanation for why Trinity might have more Nobel laureates.

Luckily, Cesar Hidalgo's research on understanding prosperity shows what we intuitively know: that economic development clusters around existing centers. That is why actors, writers and directors move to LA, financiers move to New York and why companies ship their high-end phone manufacturing to China. You go where there is a fertile ground. Richard, instead of reading the long papers from Cesar, you might want to watch this 17 minute presentation he did at TEDx Boston.

So is Trinity one of these clusters? Can we find other clusters of research and expect them to have a high concentration of Nobel prize laureates? Let me pick two examples, MIT which is next door to my office has 78 laureates and I used to hang out at Berkeley because my mom graduated from there, and they have 22.

So we have three universities with 132 Nobel laureates.

The following statement is just as true as Richard's original tweet, and as pointless as his. Except I do not malign a religion:

All the world's companies have fewer Nobel Prizes than Universities do. Companies did great things in the Middle Ages though.

In fact there is a universe of different segments of the population that have fewer Nobel Prizes as Trinity. And every once in a while someone will try to make connections just like Richard did.

People will make their cases against groups of people based on language, race, sexual preferences, political orientation, food preferences, religion or even what video games they play.

We can not let poor logic cloud our judgement, no matter how importants our points are.

I agree with Richard that I want less religion in this world, and more science-based education. But if we are going to advocate for more science-based education, let us not resort to the very processes that are discredited by science to do so.

The Origins of the Tweet

We now know that Richard could just not stomach someone saying "Islamic science deserves enormous respect" and this is why he launched himself into this argument.

I can only guess that this happened because he was criticizing religion or Islam and someone told him "Actually, you are wrong about this, Islam contributed to X and Y" and he did not like his argument poked at.

The right answer is "You are correct, I did not consider that" and then try to incorporate this new knowledge into having a more nuanced position.

The answer is not to spread a meme based on a fallacy.

Posted on 09 Aug 2013

CFKArgentina Live-Tweets Evo Morales Airplane Crisis

by Miguel de Icaza

Last night Cristina Kirchner, Argentina's President, live tweeted the events around Evo Morales' European airplane hijacking:

  • I returned from la Rosada, Olivos 21:46 hs. They notify me, President Correa is on the phone. “Rafael? Put him on” [link]
  • “Hey Rafa, how are you?” He tells me he is angry and anguished, “You do not know what is happening?” [link]
  • “No, what is happening?”. I was in lala-land. Odd, because I am always paying attention... and viglant. I had just finished a meeting. [link]
  • “Cristina, they detained Evo with his airplane and they won’t let him leave Europe” [link]
  • “What? Evo? Evo Morales has been detained?” Immediately, I remember the last picture I saw with him, in Rusia [link]
  • Next to Putin, Nicolas Maduro and other Chiefs of State. “But what happened Rafael?” [link]
  • “Multiple countries revoked the flight permit and he is in Vienna”, he replies [link]
  • Definitely, everyone is crazy. A Chief of State and his airplane have total immunity. This level of impunity is unacceptable. [link]
  • Rafal tells me that he will call urgently a Ollanta Umala for an urgent meeting of UNASUR [link]
  • I call Evo. On the other line, his voice responds calmly “Hello friend, how are you doing?”. He asks me how I am doing? [link]
  • He has thousands of years of civilization more than me. He describes the situation. “I am here, in a small room in the airport...” [link]
  • “I am not going to let them inspect my airplane. I am not a thief”. Simply perfect. Strength Evo. [link]
  • CFK: “Let me call the Cancilleria. I want to see the jurisdiction, agreements and which court to go to. I’ll call you later”. “Thank you friend”. [link]
  • They confirm the absolute immunity by the right consuetudionario, embodied on the convention of 2004 and the Haye Court. [link]
  • If Austria does not let him leave, or wants to inspect his airplane, he can go to the international court of the Haya and ask.... [link]
  • Yes! AN INJUCTION. I dont’t know if I should laugh or cry. You realize what Injunctions are used for [link]
  • Well, if not, we can send a judge from here. MOther of God! What world! [link]
  • I call Evo again. His Minister of Defense takes note. In Austria it is 3am. They are going to try to reach the authorities [link]
  • I talk with Pepe (Mujica). He is outraged. He is right. The whole thing is very humiliating. Rafa calls me again [link]
  • Ollanta notifies me that he will call for a meeting of UNASUR. It is 00:25AM. Tomorrow will be a day long and hard. Calm. They wont succeed. [link]

Posted on 03 Jun 2013

Need for Exercises

by Miguel de Icaza

For many years, I have learned various subjects (mostly programming related, like languages and frameworks) purely by reading a book, blog posts or tutorials on the subjects, and maybe doing a few samples.

In recent years, I "learned" new programming languages by reading books on the subject. And I have noticed an interesting phenomenon: when having a choice between using these languages in a day-to-day basis or using another language I am already comfortable with, I go for the language I am comfortable with. This, despite my inner desire to use the hot new thing, or try out new ways of solving problems.

I believe the reason this is happening is that most of the texts I have read that introduce these languages are written by hackers and not by teachers.

What I mean by this is that these books are great at describing and exposing every feature of the language and have some clever examples shown to you, but none of these actually force you to write code in the language.

Compare this to Scheme and the book "Structure and Interpretation of Computer Programs". That book is designed with teaching in mind, so at the end of every section where a new concept has been introduced, the authors have a series of exercises specifically tailored to use the knowledge that you just gained and put it to use. Anyone that reads that book and does the exercises is going to be a guaranteed solid Scheme programmer, and will know more about computing than from reading any other book.

In contrast, the experience of reading a modern computing book from most of the high-tech publishers is very different. Most of the books being published do not have an educator reviewing the material, at best they have an editor that will fix your English and reorder some material and make sure the proper text is italicized and your samples are monospaced.

When you finish a chapter in a modern computing book, there are no exercises to try. When you finish it, your choices are to either take a break by checking some blogs or keep marching in a quest to collect more facts on the next chapter.

During this process, while you amass a bunch of information, at some neurological level, you have not really mastered the subject, nor gained the skills that you wanted. You have merely collected a bunch of trivia which most likely you will only put to use in an internet discussion forum.

What books involving an educator will do is include exercises that have been tailored to use the concepts that you just learned. When you come to this break, instead of drifting to the internet you can sit down and try to put your new knowledge to use.

Well developed exercises are an application of the psychology of Flow ensuring that the exercise matches the skills that you have developed and they guide you through a path that keeps you in an emotional state ranging that includes control, arousement and joy (flow).

Anecdote Time

Back in 1988 when I first got the first edition of the "C++ Language", there were a couple of very simple exercises in the first chapter that took me a long time to get right and they both proved very educational.

The first exercises was "Compile Hello World". You might think, that is an easy one, I am going to skip that. But I had decided that I was going to do each and every single of one of the exercises in the book, no matter how simple. So if the exercise said "Build Hello World", I would build Hello World, even if I was already seasoned assembly language programmer.

It turned out that getting "Hello World" to build and run was very educational. I was using the Zortech C++ compiler on DOS back, and getting a build turned out to be almost impossible. I could not get the application to build, I got some obscure error and no way to fix it.

It took me days to figure out that I had the Microsoft linker in my path before the Zortech Linker, which caused the build to fail with the obscure error. An important lesson right there.

On Error Messages

The second exercise that I struggled with was a simple class. The simple class was missing a semicolon at the end. But unlike modern compilers, the Zortech C++ compiler at the time error message was less than useful. It took a long time to spot the missing semicolon, because I was not paying close enough attention.

Doing these exercises trains your mind to recognize that "useless error message gobble gobble" actually means "you are missing a semicolon at the end of your class".

More recently, I learned in this same hard way that the F# error message "The value or constructor 'foo' is not defined" really means "You forgot to use 'rec' in your let", as in:

let foo x =
   if x == 1
     foo (x-1)

That is a subject for another post, but the F# error message should tell me what I did wrong at a language level, as opposed to explaining to me why the compiler is unable to figure things out in its internal processing of the matter.

Plea to book authors

Nowadays we are cranking books left and right to explain new technologies, but rarely do these books get the input from teachers and professional pedagogues. So we end up accumulating a lot of information, we sound lucid at cocktail parties and might even engage in a pointless engineering debate over features we barely master. But we have not learned.

Coming up with the ideas to try out what you have just learned is difficult. As you think of things that you could do, you quickly find that you are missing knowledge (discussed in further chapters) or your ideas are not that interesting. In my case, my mind drifts into solving other problems, and I go back to what I know best.

Please, build exercises into your books. Work with teachers to find the exercises that match the material just exposed and help us get in the zone of Flow.

Posted on 25 Apr 2013

Introducing MigCoin

by Miguel de Icaza

Non-government controlled currency systems are now in vogue. Currencies that are not controlled by some government that might devalue your preciously earned pesos at the blink of an eye.

BitCoin is powered by powerful cryptography and math to ensure a truly digital currency. But it poses significant downsides, for one, governments can track your every move, and every transaction is stored on each bitcoin, making it difficult to prevent a tax audit in the future by The Man.

Today, I am introducing an alternative currency system that both keeps the anonymity of your transactions, and is even more secure than the crypto mumbo jumbo of bitcoins.

Today, I am introducing the MigCoin.

Like bitcoins, various MigCoins will be minted over time, to cope with the creation of value in the world.

Like bitcoins, the supply of MigCoins will be limited and will eventually plateau. Like bitcoin, the MigCoin is immune to the will of some Big Government bureaucrat that wants to control the markets by printing or removing money from circulation. Just like this:

Projected number of Bitcoins and MigCoins over time.

Unlike bitcoins, I am standing by them and I am not hiding behind a false name.

Like BitCoins, MigCoins come with a powerful authentication system that can be used to verify their authenticity. Unlike BitCoins, they do not suffer from this attached "log" that Big Brother and the Tax Man can use to come knocking on your door one day.

How does this genius of a currency work? How can you guarantee that governments or rogue entities wont print their own MigCoins?

The answer is simple my friends.

MigCoins are made of my DNA material.

Specifically, spit.

Every morning, when I wake up, for as long as I remain alive, I will spit on a glass. A machine will take the minimum amount of spit necessary to lay down on a microscope slide, and this is how MigCoins are minted.

Then, you guys send me checks, and I send you the microscope slides with my spit.

To accept MigCoins payments all you have to do is carry a DNA sequencer with you, put the microscope slide on it, press a button, and BAM! 10 minutes later you have your currency validated.

To help accelerate the adoption of MigCoins, I will be offering bundles of MigCoins with the Ilumina MiSeq Personal DNA sequencer:

Some might argue that the machine alone is 125,000 dollars and validating one MigCoin is going to set me back 750 dollars.

Three words my friends: Economy of Scale.

We are going to need a few of you to put some extra pesos early on to get the prices to the DNA machines down.

Early Adopters of MigCoins

I will partner with visionaries like these to get the first few thousands sequencers built and start to get the prices down. Then we will hire that guy ex-Apple guy that was CEO of JC Penney to get his know-how on getting the prices of these puppies down.

Like Bitcoin, I expect to see a lot of nay-sayers and haters. People that will point out flaws on this system. But you know what?

The pace of innovation can not be held back by old-school economists that "don't get it" and pundits on CNN trying to make a quick buck. Hater are going to hate. 'nuff said.

Next week, I will be launching MigXchange, a place where you can trade your hard BitCoins for slabs of spit.

Join the revolution! Get your spit on!

Posted on 12 Apr 2013

Exclusive! What we know about the Facebook Phone

by Miguel de Icaza

We obtained some confidential information about the upcoming Facebook Phone. Here is what we know about it so far:

Posted on 29 Mar 2013

How I ended up with Mac

by Miguel de Icaza

While reading Dave Winer's Why Windows Lost to Mac post, I noticed many parallels with my own experience with Linux and the Mac. I will borrow the timeline from Dave's post.

I invested years of my life on the Linux desktop first as a personal passion (Gnome) and when while awoken for two Linux companies (my own, Ximian and then Novell). During this period, I believed strongly in dogfooding our own products. I believed that both me and my team had to use the software we wrote and catch bugs and errors before it reached our users. We were pretty strict about it: both from an ideological point of view, back in the days of all-software-will-be-free, and then practically - during my tamer business days. I routinely chastised fellow team members that had opted for the easy path and avoided our Linux products.

While I had Macs at Novell (to support Mono on MacOS), it would take a couple of years before I used a Mac regularly. In some vacation to Brazil around 2008 or so, I decided to only take the Mac for the trip and learn to live with the OS as a user, not just as a developer.

Computing-wise that three week vacation turned out to be very relaxing. Machine would suspend and resume without problem, WiFi just worked, audio did not stop working, I spent three weeks without having to recompile the kernel to adjust this or that, nor fighting the video drivers, or deal with the bizarre and random speed degradation that my ThinkPad suffered.

While I missed the comprehensive Linux toolchain and userland, I did not miss having to chase the proper package for my current version of Linux, or beg someone to package something. Binaries just worked.

From this point on, using the Mac was a part-time gig for me. During the Novell layoffs, I returned my laptop to Novell and I was left with only one Linux desktop computer at home. I purchased a Mac laptop and while I fully intended to keep using Linux, the dogfooding driver was no longer there.

Dave Winer writes, regarding Windows:

Back to 2005, the first thing I noticed about the white Mac laptop, that aside from being a really nice computer, there was no malware. In 2005, Windows was a horror. Once a virus got on your machine, that was pretty much it. And Microsoft wasn't doing much to stop the infestation. For a long time they didn't even see it as their problem. In retrospect, it was the computer equivalent of Three Mile Island or Chernobyl.

To me, the fragmentation of Linux as a platform, the multiple incompatible distros, and the incompatibilities across versions of the same distro were my Three Mile Island/Chernobyl.

Without noticing, I stopped turning on the screen for my Linux machine during 2012. By the time I moved to a new apartment in October of 2012, I did not even bother plugging the machine back and to this date, I have yet to turn it on.

Even during all of my dogfooding and Linux advocacy days, whenever I had to recommend a computer to a single new user, I recommended a Mac. And whenever I gave away computer gifts to friends and family, it was always a Mac. Linux just never managed to cross the desktop chasm.

Posted on 05 Mar 2013

The Making of Xamarin Studio

by Miguel de Icaza

We spent a year designing the new UI and features of Xamarin Studio (previously known as MonoDevelop).

I shared some stories of the process on the Xamarin blog.

After our launch, we open sourced all of the work that we did, as well as our new Gtk+ engine for OSX. Lanedo helps us tremendously making Gtk+ 2.x both solid and amazing on OSX (down to the new Lion scrollbars!). All of their work has either been upstreamed to Gtk+ or in the process of being upstreamed.

Posted on 22 Feb 2013

"Reality Distortion Field"

by Miguel de Icaza

"Reality Distortion Field" is a modern day cop out. A tool used by men that lack the intellectual curiosity to explain the world, and can deploy at will to explain excitement or success in the market place. Invoking this magical super power saves the writer from doing actual work and research. It is a con perpetuated against the readers.

The expression originated as an observation made by those that worked with Steve to describe his convincing passion. It was insider joke/expression which has now been hijacked by sloppy journalists when any subject is over their head.

The official Steve Jobs biography left much to be desired. Here a journalist was given unprecedented access to Steve Jobs and get answers to thousands of questions that we have to this day. How did he approach problems? Did he have a method? How did he really work with his team? How did he turn his passion for design into products? How did he make strategic decisions about the future of Apple? How did the man balance engineering and marketing problems?

The biography has some interesting anecdotes, but fails to answer any of these questions. The biographer was not really interested in understanding or explaining Steve Jobs. He collected a bunch of anecdotes, stringed them together in chronological order, had the text edited and cashed out.

Whenever the story gets close to an interesting historical event, or starts exploring a big unknown of Steve's work, we are condescendingly told that "Steve Activated the Reality Distortion Field".

Every. Single. Time.

Not once did the biographer try to uncover what made people listen to Steve. Not once did he try to understand the world in which Steve operated. The breakthroughs of his work are described with the same passion as a Reuters news feed: an enumeration of his achievements glued with anecdotes to glue the thing together.

Consider the iPhone: I would have loved to know how the iPhone project was conceived. What internal process took place that allowed Apple to gain the confidence to become a phone manufacturer. There is a fascinating story of the people that made this happen, millions of details of how this project was evaluated and what the vision for the project was down to every small detail that Steve cared about.

Instead of learning about the amazing hardware and software engineering challenges that Steve faced, we are told over and over that all Steve had to do was activate his special super power.

The biography in short, is a huge missed opportunity. Unprecedented access to a man that reshaped entire industries and all we got was some gossip.

The "Reality Distortion Field" is not really a Steve Jobs super-power, it is a special super power that the technical press uses every time they are too lazy to do research.

Why do expensive and slow user surveys, or purchase expensive research from analysts to explain why some product is doing well, or why people are buying it when you can just slap a "they activated the Reality Distortion Field and sales went through the roof" statement in your article.

As of today, a Google News search for "Reality Distortion Field Apple" reports 532 results for the last month.

Perhaps this is just how the tech press must operate nowadays. There is just no time to do research as new products are being unveiled around the clock, and you need to deliver opinions and analysis on a daily basis.

But as readers, we deserve better. We should reject these explanations for what they are: a cheap grifter trick.

Posted on 07 Nov 2012

Mono 3.0 is out

by Miguel de Icaza

After a year and a half, we have finally released Mono 3.0.

Like I discussed last year, we will be moving to a more nimble release process with Mono 3.0. We are trying to reduce our inventory of pending work and get new features to everyone faster. This means that our "master" branch will remain stable from now on, and that large projects will instead be developed in branches that are regularly landed into our master branch.

What is new

Check our release notes for the full details of this release. But here are some tasty bits:

  • C# Async compiler
  • Unified C# compiler for all profiles
  • 4.5 Async API Profile
  • Integrated new Microsoft's Open Sourced stacks:
    • ASP.NET MVC 4
    • ASP.NET WebPages
    • Entity Framework
    • Razor
    • System.Json (replaces our own)
  • New High performance Garbage Collector (SGen - with many performance and scalability improvements)
  • Metric ton of runtime and class library improvements.

Also, expect F# 3.0 to be bundled in our OSX distribution.

Posted on 22 Oct 2012

The Sophisticated Procrastinator - Volume 1

by Miguel de Icaza

Let me share with you some links that I found interesting in the past few weeks. These should keep the most diligent person busy for a few hours.

Software Reads

Talbot Crowell's Introduction to F# 3.0 slides from Boston CodeCamp.

Bertrand Meyer (The creator of Eiffel, father of good taste in engineering practices) writes Fundamental Duality of Software Engineering: on the specifications and tests. This is one of those essays where every idea is beautifully presented. A must read.

Good article on weakly ordered CPUs.

MonkeySpace slide deck on MonoGame.

David Siegel shares a cool C# trick, switch expressions.

Oak: Frictionless development for ASP.NET MVC.

Simon Peyton Jones on video talks about Haskell, past, present and future. A very tasty introductory talk to the language. David Siegel says about this:

Simon Peyton-Jones is the most eloquent speaker on programming languages. Brilliant, funny, humble, adorable.

Rob Pike's talk on Concurrency is not Parallelism. Rob is one of the crisper minds in software development, anything he writes, you must read, everything he says, you must listen to.

Answering the question of what is the fastest way to access properties dynamically: DynamicMethod LINQ expressions, MethodInfo. Discussion with Eric Maupin.

OpenGL ES Quick Reference Card, plus a good companion: Apple's Programming Guide.

Interesting Software

SparkleShare, the open source file syncing service running on top of Git released their feature-complete product. They are preparing for their 1.0 release. SparkleShare runs on Linux, Mac and Windows. Check out their Release Notes.

Experts warn that Canonical might likely distribute a patched version that modifies your documents and spreadhseets to include ads and Amazon referal links.

Pheed a twitter competitor with a twist.

Better debugging tools for Google Native Client.

Touch Draw comes to MacOS, great vector drawing application for OSX. Good companion to Pixelmator and great for maintaining iOS artwork. It has great support for structured graphics and for importing/exporting Visio files.

MonoGame 3D on the Raspberry Pi video.

Fruit Rocks a fun little game for iOS.

@Redth, the one man factory of cool hacks has released:

  • PassKitSharp, a library to generate, maintain, process Apple's Passbook files written in C#
  • Zxing.Mobile, an open source barcode library built on top of ZXing (Zebra Crossing) runs on iOS and Android.
  • PushSharp, A server-side library for sending Push Notifications to iOS (iPhone/iPad APNS), Android (C2DM and GCM - Google Cloud Message), Windows Phone, Windows 8, and Blackberry devices.

Coding on Passbook: Lessons Learned.

Building a Better World

Phil Haack blogs about MonkeySpace

Patrick McKenzie writes Designing First Run Experiences to Delight Users.

Kicking the Twitter habit.

Twitter Q&A with TJ Fixman, writer for Insomniac Games.

Debunking the myths of budget deficits: Children and Grandchildren do not pay for budget deficits, they get interest on the bonds.

Cool Stuff

Live updates on HoneyPots setup by the HoneyNet Project.

Updated Programming F# 3.0, 2nd Edition is out. By Chris Smith, a delightful book on F# has been updated to cover the new and amazing type providers in F#.

ServiceStack now has 113 contributors.


From Apple Insider: Google may settle mobile FRAND patent antitrust claim.

The Salt Lake City Tribune editorial board endorses Obama over Romney:

In considering which candidate to endorse, The Salt Lake Tribune editorial board had hoped that Romney would exhibit the same talents for organization, pragmatic problem solving and inspired leadership that he displayed here more than a decade ago. Instead, we have watched him morph into a friend of the far right, then tack toward the center with breathtaking aplomb. Through a pair of presidential debates, Romney’s domestic agenda remains bereft of detail and worthy of mistrust.

Therefore, our endorsement must go to the incumbent, a competent leader who, against tough odds, has guided the country through catastrophe and set a course that, while rocky, is pointing toward a brighter day. The president has earned a second term. Romney, in whatever guise, does not deserve a first.

From Blue States are from Scandinavia, Red States are from Guatemala the author looks at the differences in policies in red vs blue states, and concludes:

Advocates for the red-state approach to government invoke lofty principles: By resisting federal programs and defying federal laws, they say, they are standing up for liberty. These were the same arguments that the original red-staters made in the 1800s, before the Civil War, and in the 1900s, before the Civil Rights movement. Now, as then, the liberty the red states seek is the liberty to let a whole class of citizens suffer. That’s not something the rest of us should tolerate. This country has room for different approaches to policy. It doesn’t have room for different standards of human decency.

Esquire's take on the 2nd Presidential Debate.

Dave Winer wrote Readings from News Execs:

There was an interesting juxtaposition. Rupert Murdoch giving a mercifully short speech saying the biggest mistake someone in the news business could make is thinking the reader is stupid. He could easily have been introducing the next speaker, Bill Keller of the NY Times, who clearly thinks almost everyone who doesn't work at the NY Times is stupid.

What do you know, turns out that Bill Moyers is not funded by the government nor does he get tax money, like many Republicans like people to believe. The correction is here.

Twitter Quotes

Joseph Hill

"Non-Alcoholic Sparkling Beverage" - Whole Foods' $7.99 name for "bottle of soda".

Jonathan Chambers

Problem with most religious people is that their faith tells them to play excellently in game of life, but they want to be the referees.

Hylke Bons on software engineering:

"on average, there's one bug for every 100 lines of code" this is why i put everything on one line

Waldo Jaquith:

If government doesn't create jobs, isn't Romney admitting that his campaign is pointless?

Alex Brown

OH "It is a very solid grey area" #sc34 #ooxml

Jo Shields

"I don't care how many thousand words your blog post is, the words 'SYMBIAN WAS WINNING' mean you're too high on meth to listen too.

Jeremy Scahill on war monger Max Boots asks the questions

Do they make a Kevlar pencil protector? Asking for a think tanker.

Max Boot earned a Purple Heart (shaped ink stain on his shirt) during the Weekly Standard War in 1994.

Tim Bray

"W3C teams with Apple, Google, Mozilla on WebPlatform"... or we could all just sponsor a tag on StackOverflow.

David Siegel

Most programmers who claim that types "get in the way" had a sucky experience with Java 12 years ago, tried Python, then threw the baby out.

Outrage Dept

How Hollywood Studios employ creative accounting to avoid sharing the profits with the participants. If you were looking at ways to scam your employees and partners, look no further.

Startvation in Gaza: State forced to release 'red lines' document for food consumption.

Dirty tricks and disturbing trends: Billionaire warn employees that if Obama is reelected, they will be facing layoffs.

Israeli Children Deported to South Sudan Succumb to Malaria:

Here we are today, three months later, and within the last month alone, these two parents lost two children, and the two remaining ones are sick as well. Sunday is already in hospital with malaria, in serious condition, and Mahm is sick at home. “I’ve only two children left,” Michael told me today over the phone. The family doesn’t have money to properly treat their remaining children. The hospitals are at full capacity and more people leave them in shrouds than on their own two feet. I ask you, beg of you to help me scream the story of these children and their fate, dictated by the heartless, immoral Israeli government.

When Suicide is Cheaper the horrifying tales of Americans that can not afford health care.

Paul Ryan is not that different from Todd Akin, when it comes to women rights.

Interesting Discussions, Opinions and Articles

A Windows 8 critique: someone is not very happy with it.

On "meritocracy": what is wrong with it.

Fascinating read on the fast moving space of companies: Intimate Portrait of Innovation, Risk and Failure Through Hipstamatic's Lens.

Kathy Sierra discusses sexism in the tech world. How she changed her mind about it, and the story that prevented her from seeing it.

Response @antirez's sexist piece.

Chrystia Freeland's The Self Destruction of the 1% percent is a great article, which touches on the points of her book of Plutocrats

Sony's Steep Learning Process a look at the changing game with a focus on Sony's challenges.


One Minute Animated Primers on Major Theories on Religion.

Cat fact and Gif provides Cat facts with a gif that goes with it. The ultimate resource of cat facts and gifs.

Posted on 21 Oct 2012

Drowning Good Ideas with Bloat. The tale of pkg.m4.

by Miguel de Icaza

The gnome-config script was a precursor to pkg-config, they are tools used that you can run and use to extract information about the flags needed to compile some code, link some code, or check for a version. gnome-config itself was a pluggable version of Tcl's script.

The idea is simple: pkg-config is a tiny little tool that uses a system database of packages to provide version checking and build information to developers. Said database is merely a well-known directory in the system containing files with the extension ".pc", one per file.

These scripts are designed to be used in shell scripts to probe if a particular software package has been installed, for example, the following shell script probes whether Mono is installed in the system:

# shell script

if pkg-config --exists mono; then
    echo "Found Mono!"
    echo "You can download mono from"

It can also be used in simple makefiles to avoid hardcoding the paths to your software. The following makefile shows how:

CFLAGS = `pkg-config --cflags mono`
LIBS   = `pkg-config --libs mono`

myhost: myhost.c

And if you are using Automake and Autoconf to probe for the existence of a module with a specific version and extract the flags needed to build a module, you would do it like this:

if pkg-config --atleast-version=2.10 mono; then
    MONO_FLAGS=`pkg-config --cflags mono`
    MONO_LIBS=`pkg-config --libs mono`
   AC_MSG_ERROR("You need at least Mono 2.10")

There are two main use cases for pkg-config.

Probing: You use the tool to pobe for some condition about a package and taking an action based on this. For this, you use the pkg-config exit code in your scripts to determine whether the condition was met. This is what both the sample automake and the first script show.

Compile Information: You invoke the tool which outputs to standard output the results. To store the result or pass the values, you use the shell backtick (`). That is all there is to it (example: version=`pkg-config --version`).

The tool is so immensely simple that anyone can learn every command that matters in less than 5 minutes. The whole thing is beautiful because of its simplicity.

The Siege by the Forces of Bloat

Perhaps it was a cultural phenomenon, perhaps someone that had nothing better to do, perhaps someone that was just trying to be thorough introduced one of the most poisoning memes into the pool of ideas around pkg-config.

Whoever did this, thought that the "if" statement in shell was a complex command to master or that someone might not be able to find the backtick on their keyboards.

And they hit us, and they hit us hard.

They introduced pkg.m4, a macro intended to be used with autoconf, that would allow you to replace the handful of command line flags to pkg-config with one of their macros (PKG_CHECK_MODULES, PKG_CHECK_EXISTS). To do this, they wrote a 200 line script, which replaces one line of shell code with almost a hundred. Here is a handy comparison of what these offer:

# Shell style
if pkg-config --atleast-version=2.10 mono; then
   MONO_CFLAGS=`pkg-config --cflags mono`
   MONO_LIBS=`pkg-config --libs mono`
   AC_MSG_ERROR(Get your mono from

# With the idiotic macros
PKG_CHECK_MODULES([MONO], [mono >= 2.10],[], [
   AC_MSG_ERROR(Get your mono from

# If you do not need split flags, shell becomes shorter
if pkg-config --atleast-version=2.10 mono; then
   CFLAGS="$CFLAGS `pkg-config --cflags mono`"
   LIBS="$LIBS `pkg-config --libs mono`"
   AC_MSG_ERROR(Get your mono from

The above shows the full benefit of using a macro, MONO is a prefix that will have LIBS and CFLAGS extracted. So the shell script looses. The reality is that the macros only give you access to a subset of the functionality of pkg-config (no support for splitting -L and -l arguments, querying provider-specific variable names or performing macro expansion).

Most projects, adopted the macros because they copy/pasted the recipe from somewhere else, and thought this was the right way of doing things.

The hidden price is that saving that few lines of code actually inflicts a world of pain on your users. You will probably see this in your forums in the form of:

Subject: Compilation error

I am trying to build your software, but when I run, I get
the following error:

checking whether make sets $(MAKE)... yes
checking for pkg-config... /usr/bin/pkg-config
./configure: line 1758: syntax error near unexpected token FOO,'
./configure: line 1758:PKG_CHECK_MODULES(FOO, foo >= 2.9)'

And then you will engage in a discussion that in the best case scenario helps the user correctly configure his ACLOCAL_FLAGS, create his own "setup" script that will properly configure his system, and your new users will learn the difference between running a shell script and "sourcing" a shell script to properly setup his development system.

In the worst case scenario, the discussion will devolve into how stupid your user is for not knowing how to use a computer and how he should be shot in the head and taken out to the desert for his corpse to be eaten by vultures; because, god dammit, they should have googled that on their own, and they should have never in the first place have installed two separate automake installations in two prefixes, without properly updating their ACLOCAL_FLAGS or figured out on their own that their paths were wrong in the first place. Seriously, what moron in this day and age is not familiar with the limitations of aclocal and the best practices to use system-wide m4 macros?

Hours are spent on these discussions every year. Potential contributors to your project are driven away, countless hours that could have gone into fixing bugs and producing code are wasted, you users are frustrated. And you saved 4 lines of code.

The pkg.m4 is a poison that is holding us back.

We need to end this reign of terror.

Send pull requests to eliminate that turd, and ridicule anyone that suggests that there are good reasons to use it. In the war for good taste, it is ok to vilify and scourge anyone that defends pkg.m4.

Posted on 20 Oct 2012

Why Mitt does not need an Economic Plan

by Miguel de Icaza

Mitt Romney does not need to have an economic plan. He does not need to have a plan to cut the deficit or to cut services.

It is now well understood that to get the US out of the recession, the government has to inject money into the economy. To inject money into the economy, the US needs to borrow some money and spend it. Borrowing is also at an all-time low, so the price to pay is very low.

Economists know this, and Republicans know this.

But the Republicans top priority is to get Obama out of office at any cost. Even at the cost of prolonging the recession, damaging the US credit rating and keeping people unemployed.

The brilliance of the Republican strategy is that they have convinced the world that the real problem facing the US is the debt. Four years of non-stop propaganda on newspapers and TV shows have turned everyone into a "fiscal conservative". The propaganda efforts have succeeded into convincing the world that US economic policy should be subject to the same laws of balancing a household budget (I wont link to this idiocy).

The campaign has been a brilliant and has forced the Democrats to adopt policies of austerity, instead of policies of growth. Instead of spending left and right to create value, we are cutting. And yet, nobody has stopped the propaganda and pointed out that growth often comes after spending money. Startups start in the red and are funded for several years before they become profitable; Companies go public and use the IPO to raise capital to grow, and for many years they lose money until their investments pay off and allows them to turn the tide.

So this mood has forced Obama to talk about cuts. He needs to be detailed about his cuts, he needs to be a fiscal conservative.

But Economists and Republicans know what the real fix is. They know they have to spend money.

If Romney is elected to office, he will do just that. He will borrow and spend money, because that is the only way of getting out of the recession. That is why his plan does not need to have any substance, and why he can ignore the calls to get more details, because he has no intention to follow up with them.

Obama made a critical mistake in his presidency. He decided to compromise with Republicans, he was begging to be loved by Republicans and in the process betrayed his own base and played right into the Republican's plans.

Posted on 04 Oct 2012

Mono 2.11.4 is out

by Miguel de Icaza

A couple of weeks ago we released Mono 2.11.4; I had not had time to blog about it.

Since our previous release a month before, we had some 240 commits, spread like this:

488 files changed, 28716 insertions(+), 6921 deletions(-)

Among the major updates in this release:

  • Integrated the Google Summer of Code code for Code Contracts.
  • Integrated the Google Summer of Code code for TPL's DataFlow.
  • Plenty of networking stack fixes and updates (HTTP stack, web services stack, WCF)
  • Improvements to the SGen GC.
  • TPL fixes for AOT systems like the iPhone.
  • Debugger now supports batched method invocations.

And of course, a metric ton of bug fixes all around.

Head over to Mono's Download Page to get the goods. We would love to hear about any bugs to have a great stable release.

Posted on 02 Oct 2012

TypeScript: First Impressions

by Miguel de Icaza

Today Microsoft announced TypeScript a typed superset of Javascript. This means that existing Javascript code can be gradually modified to add typing information to improve the development experience: both by providing better errors at compile time and by providing code-completion during development.

As a language fan, I like the effort, just like I pretty much like most new language efforts aimed at improving developer productivity: from C#, to Rust, to Go, to Dart and to CoffeeScript.

A video introduction from Anders was posted on Microsoft's web site.

The Pros

  • Superset of Javascript allows easy transition from Javascript to typed versions of the code.
  • Open source from the start, using the Apache License.
  • Strong types assist developers catch errors before the deploy the code, this is a very welcome addition to the developer toolchest. Script#, Google GWT and C# on the web all try to solve the same problem in different ways.
  • Extensive type inference, so you get to keep a lot of the dynamism of Javascript, while benefiting from type checking.
  • Classes, interfaces, visibility are first class citizens. It formalizes them for those of us that like this model instead of the roll-your-own prototype system.
  • Nice syntactic sugar reduces boilerplate code to explicit constructs (class definitions for example).
  • TypeScript is distributed as a Node.JS package, and it can be trivially installed on Linux and MacOS.
  • The adoption can be done entirely server-side, or at compile time, and requires no changes to existing browsers or runtimes to run the resulting code.

Out of Scope

Type information is erased when it is compiled. Just like Java erases generic information when it compiles, which means that the underling Javascript engine is unable to optimize the resulting code based on the strong type information.

Dart on the other hand is more ambitious as it uses the type information to optimize the quality of the generated code. This means that a function that adds two numbers (function add (a,b) { return a+b;}) can generate native code to add two numbers, basically, it can generate the following C code:

double add (double a, double b)
    return a+b;

While weakly typed Javascript must generated something like:

JSObject add (JSObject a, JSObject b)
    if (type (a) == typeof (double) &&
	type (b) == typeof (double))
	return a.ToDouble () + b.ToDouble ();
	JIT_Compile_add_with_new_types ();

The Bad

The majority of the Web is powered by Unix.

Developers use MacOS and Linux workstations to write the bulk of the code, and deploy to Linux servers.

But TypeScript only delivers half of the value in using a strongly typed language to Unix developers: strong typing. Intellisense, code completion and refactoring are tools that are only available to Visual Studio Professional users on Windows.

There is no Eclipse, MonoDevelop or Emacs support for any of the language features.

So Microsoft will need to convince Unix developers to use this language merely based on the benefits of strong typing, a much harder task than luring them with both language features and tooling.

There is some basic support for editing TypeScript from Emacs, which is useful to try the language, but without Intellisense, it is obnoxious to use.

Posted on 01 Oct 2012

Free Market Fantasies

by Miguel de Icaza

This recording of a Q&A with Noam Chomsky in 1997 could be a Q&A session done last night about bailouts, corporate wellfare, and the various distractions that they use from keeping us in the dark, like caring about "fiscal responsibility".

Also on iTunes and Amazon.

Posted on 07 Sep 2012

2012 Update: Running C# on the Browser

by Miguel de Icaza

With our push to share the kernel of your software in reusable C# libraries and build a native experience per platform (iOS, Android, WP7 on phones and WPF/Windows, MonoMac/OSX, Gtk/Linux) one component that is always missing is what about doing a web UI that also shares some of the code.

Until very recently the answer was far from optimal, and included things like: put the kernel on the server and use some .NET stack to ship the HTML to the client.

Today there are two solid choices to run your C# code on the browser and share code between the web and your native UIs.


JSIL will translate the ECMA/.NET Intermediate Language into Javascript and will run your code in the browser. JSIL is pretty sophisticated and their approach at running IL code on the browser also includes a bridge that allows your .NET code to reference web page elements. This means that you can access the DOM directly from C#.

You can try their Try JSIL page to get a taste of what is possible.

Saltarelle Compiler

The Saltarelle Compiler takes a different approach. It is a C# 4.0 compiler that generates JavaScript instead of generating IL. It is interesting that this compiler is built on top of the new NRefactory which is in turn built on top of our C# Compiler as a Service.

It is a fresh, new compiler and unlik JSIL it is limited to compiling the C# language. Although it is missing some language features, it is actively being developed.

This compiler was inspired by Script# which is a C#-look-alike language that generated Javascript for consuming on the browser.

Native Client

I left NativeClient out, which is not fair, considering that both Bastion and Go Home Dinosaurs are both powered by Mono running on Native Client.

The only downside with Native Client today is that it does not run on iOS or Android.

Posted on 06 Sep 2012

What Killed the Linux Desktop

by Miguel de Icaza

True story.

The hard disk that hosted my /home directory on my Linux machine failed so I had to replace it with a new one. Since this machine lives under my desk, I had to unplug all the cables, get it out, swap the hard drives and plug everything back again.

Pretty standard stuff. Plug AC, plug keyboard, plug mouse but when I got to the speakers cable, I just skipped it.

Why bother setting up the audio?

It will likely break again and will force me to go on a hunting expedition to find out more than I ever wanted to know about the new audio system and the drivers technology we are using.

A few days ago I spoke to Klint Finley from Wired who wrote the article titled OSX Killed Linux. The original line of questioning was about my opinion between Gnome 3's shell, vs Ubuntu's Unity vs Xfte as competing shells.

Personally, I am quite happy with Gnome Shell, I think the team that put it together did a great job, and I love how it enabled the Gnome designers -which historically only design, barely hack- to actually extend the shell, tune the UI and prototype things without having to beg a hacker to implement things for them. It certainly could use some fixes and tuning, but I am sure they will address those eventually.

What went wrong with Linux on the Desktop

In my opinion, the problem with Linux on the Desktop is rooted in the developer culture that was created around it.

Linus, despite being a low-level kernel guy, set the tone for our community years ago when he dismissed binary compatibility for device drivers. The kernel people might have some valid reasons for it, and might have forced the industry to play by their rules, but the Desktop people did not have the power that the kernel people did. But we did keep the attitude.

The attitude of our community was one of engineering excellence: we do not want deprecated code in our source trees, we do not want to keep broken designs around, we want pure and beautiful designs and we want to eliminate all traces of bad or poorly implemented ideas from our source code trees.

And we did.

We deprecated APIs, because there was a better way. We removed functionality because "that approach is broken", for degrees of broken from "it is a security hole" all the way to "it does not conform to the new style we are using".

We replaced core subsystems in the operating system, with poor transitions paths. We introduced compatibility layers that were not really compatible, nor were they maintained. When faced with "this does not work", the community response was usually "you are doing it wrong".

As long as you had an operating system that was 100% free, and you could patch and upgrade every component of your operating system to keep up with the system updates, you were fine and it was merely an inconvenience that lasted a few months while the kinks were sorted out.

The second dimension to the problem is that no two Linux distributions agreed on which core components the system should use. Either they did not agree, the schedule of the transitions were out of sync or there were competing implementations for the same functionality.

The efforts to standardize on a kernel and a set of core libraries were undermined by the Distro of the Day that held the position of power. If you are the top dog, you did not want to make any concessions that would help other distributions catch up with you. Being incompatible became a way of gaining market share. A strategy that continues to be employed by the 800 pound gorillas in the Linux world.

To sum up: (a) First dimension: things change too quickly, breaking both open source and proprietary software alike; (b) incompatibility across Linux distributions.

This killed the ecosystem for third party developers trying to target Linux on the desktop. You would try once, do your best effort to support the "top" distro or if you were feeling generous "the top three" distros. Only to find out that your software no longer worked six months later.

Supporting Linux on the desktop became a burden for independent developers.

But at this point, those of us in the Linux world still believed that we could build everything as open source software. The software industry as a whole had a few home runs, and we were convinced we could implement those ourselves: spreadsheets, word processors, design programs. And we did a fine job at that.

Linux pioneered solid package management and the most advance software updating systems. We did a good job, considering our goals and our culture.

But we missed the big picture. We alienated every third party developer in the process. The ecosystem that has sprung to life with Apple's OSX AppStore is just impossible to achieve with Linux today.

The Rise of OSX

When OSX was launched it was by no means a very sophisticated Unix system. It had an old kernel, an old userland, poor compatibility with modern Unix, primitive development tools and a very pretty UI.

Over time Apple addressed the majority of the problems with its Unix stack: they improved compatibility, improved their kernel, more open source software started working and things worked out of the box.

The most pragmatic contributors to Linux and open source gradually changed their goals from "an world run by open source" to "the open web". Others found that messing around with their audio card every six months to play music and the hardships of watching video on Linux were not worth that much. People started moving to OSX.

Many hackers moved to OSX. It was a good looking Unix, with working audio, PDF viewers, working video drivers, codecs for watching movies and at the end of the day, a very pleasant system to use. Many exchanged absolute configurability of their system for a stable system.

As for myself, I had fallen in love with the iPhone, so using a Mac on a day-to-day basis was a must. Having been part of the Linux Desktop efforts, I felt a deep guilt for liking OSX and moving a lot of my work to it.

What we did wrong

Backwards compatibility, and compatibility across Linux distributions is not a sexy problem. It is not even remotely an interesting problem to solve. Nobody wants to do that work, everyone wants to innovate, and be responsible for the next big feature in Linux.

So Linux was left with idealists that wanted to design the best possible system without having to worry about boring details like support and backwards compatibility.

Meanwhile, you can still run the 2001 Photoshop that came when XP was launched on Windows 8. And you can still run your old OSX apps on Mountain Lion.

Back in February I attended FOSDEM and two of my very dear friends were giggling out of excitement at their plans to roll out a new system that will force many apps to be modified to continue running. They have a beautiful vision to solve a problem that I never knew we had, and that no end user probably cares about, but every Linux desktop user will pay the price.

That day I stopped feeling guilty about my new found love for OSX.

Update September 2nd, 2012

Clearly there is some confusion over the title of this blog post, so I wanted to post a quick follow-up.

What I mean with the title is that Linux on the Desktop lost the race for a consumer operating system. It will continue to be a great engineering workstation (that is why I am replacing the hard disk in my system at home) and yes, I am aware that many of my friends use Linux on the desktop and love it.

But we lost the chance of becoming a mainstream consumer OS. What this means is that nobody is recommending a non-technical person go get a computer with Linux on it for their desktop needs (unless you are doing it so for idelogical reasons).

We had our share of chances. The best one was when Vista bombed in the marketplace. But we had our own internal battles and struggles to deal with. Some of you have written your own takes of our struggled in that period.

Today, the various Linux on the desktops are the best they have ever been. Ubuntu and Unity, Fedora and GnomeShell, RHEL and Gnome 2, Debian and Xfce plus the KDE distros. And yet, we still have four major desktop APIs, and about half a dozen popular and slightly incompatible versions of Linux on the desktop: each with its own curated OS subsystems, with different packaging systems, with different dependencies and slightly different versions of the core libraries. Which works great for pure open source, but not so much for proprietary code.

Shipping and maintaining apps for these rapidly evolving platforms is a big challenge.

Linux succeeded in other areas: servers and mobile devices. But on the desktop, our major feature and our major differentiator is price, but comes at the expense of having a timid selection of native apps and frequent breakage. The Linux Hater blog parodied this on a series of posts called the Greatest Hates.

The only way to fix Linux is to take one distro, one set of components as a baseline, abadone everything else and everyone should just contribute to this single Linux. Whether this is Canonical's Ubutu, or Red Hat's Fedora or Debian's system or a new joint effort is something that intelligent people will disagree until the end of the days.

Posted on 29 Aug 2012

Mono 2.11.3 is out

by Miguel de Icaza

This is our fourth preview release of Mono 2.11. This version includes Microsoft's recently open sourced EntityFramework and has been updated to match the latest .NET 4.5 async support.

We are quite happy with over 349 commits spread like this:

 514 files changed, 15553 insertions(+), 3717 deletions(-)

Head over to Mono's Download Page to get the goods.

Posted on 13 Aug 2012

Hiring: Documentation Writer and Sysadmin

by Miguel de Icaza

We are growing our team at Xamarin, and we are looking to hire both a documentation writer and a system administrator.

For the documentation writer position, you should be both familiar with programming and API design and be able to type at least 70 wpms (you can check your own speed at Ideally, you would be based in Boston, but we can make this work remotely.

For the sysadmin position, you would need to be familiar with Unix system administration. Linux, Solaris or MacOS would work and you should feel comfortable with automating tasks. Knowledge of Python, C#, Ruby is a plus. This position is for working in our office in Cambridge, MA.

If you are interested, email me at: miguel at xamarin.

Posted on 11 Aug 2012

XNA on Windows 8 Metro

by Miguel de Icaza

The MonoGame Team has been working on adding Windows 8 Metro support to MonoGame.

This will be of interest to all XNA developers that wanted to target the Metro AppStore, since Microsoft does not plan on supporting XNA on Metro, only on the regular desktop.

The effort is taking place on IRC in the #monogame channel on The code is being worked in the develop3d branch of MonoGame.

Posted on 19 Apr 2012

Contributing to Mono 4.5 Support

by Miguel de Icaza

For a couple of weeks I have been holding off on posting about how to contribute to Mono, since I did not have a good place to point people to.

Gonzalo has just updated our Status pages to include the differences betwee .NET 4.0 to .NET 4.5, these provide a useful roadmap for features that should be added to Mono.

This in particular in the context of ASP.NET 4.5, please join us in [email protected].

Posted on 13 Apr 2012

Modest Proposal for C#

by Miguel de Icaza

This is a trivial change to implement, and would turn what today is an error into useful behavior.

Consider the following C# program:

struct Rect {
	public int X, Y, Width, Height;

class Window {
	Rect bounds;

	public Rect Bounds {
		get { return bounds; }
		set {
			// Some code that needs to run when the	property is set
			WindowManager.Invalidate (bounds);
			WindowManager.Invalidate (value);
			bounds = value;

Currently, code like this:

Window w = new Window ();
w.Bounds.X = 10;

Produces the error:

Cannot modify the return value of "Window.Bounds.X" because it is not a variable

The reason is that the compiler returns a copy of the "bounds" structure and making changes to the returned value has no effect on the original property.

If we had used a public field for Bounds, instead of a property, the above code would compile, as the compiler knows how to get to the "Bounds.X" field and set its value.

My suggestion is to alter the C# compiler to turn what today is considered an error when accessing properties and doing what the developer expects.

The compiler would rewrite the above code into:

Window w = new Window ();
var tmp = w.Bounds;
tmp.X = 10;
w.Bounds = tmp;

Additionally, it should cluster all of the changes done in a single call, so:

Window w = new Window ();
w.Bounds.X = 10;
w.Bounds.Y = 20;

Will be compiled as:

Window w = new Window ();
var tmp = w.Bounds;
tmp.X = 10;
tmp.Y = 20;
w.Bounds = tmp;

To avoid calling the setter for each property set in the underlying structure.

The change is trivial and wont break any existing code.

Posted on 11 Apr 2012

Can JITs be faster?

by Miguel de Icaza

Herb Sutter discusses in his Reader QA: When Will Better JITs save Managed Code?:

In the meantime, short answer: C++ and managed languages make different fundamental tradeoffs that opt for either performance or productivity when they are in tension.


This is a 199x/200x meme that’s hard to kill – “just wait for the next generation of (JIT or static) compilers and then managed languages will be as efficient.” Yes, I fully expect C# and Java compilers to keep improving – both JIT and NGEN-like static compilers. But no, they won’t erase the efficiency difference with native code, for two reasons.

First, JIT compilation isn’t the main issue. The root cause is much more fundamental: Managed languages made deliberate design tradeoffs to optimize for programmer productivity even when that was fundamentally in tension with, and at the expense of, performance efficiency. (This is the opposite of C++, which has added a lot of productivity-oriented features like auto and lambdas in the latest standard, but never at the expense of performance efficiency.) In particular, managed languages chose to incur costs even for programs that don’t need or use a given feature; the major examples are assumption/reliance on always-on or default-on garbage collection, a virtual machine runtime, and metadata.

This is a pretty accurate statement on the difference of the mainstream VMs for managed languages (.NET, Java and Javascript).

Designers of managed languages have chosen the path of safety over performance for their designs. For example, accessing elements outside the boundaries of an array is an invalid operation that terminates program execution, as opposed to crashing or creating an exploitable security hole.

But I have an issue with these statements:

Second, even if JIT were the only big issue, a JIT can never be as good as a regular optimizing compiler because a JIT compiler is in the business of being fast, not in the business of generating optimal code. Yes, JITters can target the user’s actual hardware and theoretically take advantage of a specific instruction set and such, but at best that’s a theoretical advantage of NGEN approaches (specifically, installation-time compilation), not JIT, because a JIT has no time to take much advantage of that knowledge, or do much of anything besides translation and code gen.

In general the statement is correct when it comes to early Just-in-Time compilers and perhaps reflects Microsoft's .NET JIT compiler, but this does not apply to state of the art JIT compilers.

Compilers are tools that convert human readable text into machine code. The simplest ones perform straight forward translations from the human readable text into machine code, and typically go through or more of these phases:

Optimizing compilers introduce a series of steps that alter their inputs to ensure that the semantics described by the user are preserved while generating better code:

An optimization that could be performed on the high-level representation would transform the textual "5 * 4" in the source code into the constant 20. This is an easy optimization that can be done up-front. Simple dead code elimination based on constant folding like "if (1 == 2) { ... }" can also be trivially done at this level.

An optimization on the medium representation would analyze the use of variables and could merge subexpressions that are computed more than once, for example:

	int j = (a*b) + (a*b)

Would be transformed by the compiler into:

	int _tmp = a * b;
	int j = _tmp + _tmp;

A low-level optimization would alter a "MULTIPLY REGISTER-1 BY 2" instruction into "SHIFT REGISTER-1 ONE BIT TO THE LEFT".

JIT compilers for Java and .NET essentially break the compilation process in two. They serialize the data in the compiler pipeline and split the process in two. The first part of the process dumps the result into a .dll or .class files:

The second step loads this file and generates the native code. This is similar to purchasing frozen foods from the super market, you unwrap the pie, shove it in the oven and wait 15 minutes:

Saving the intermediate representation and shipping it off to a new system is not a new idea. The TenDRA C and C++ compilers did this. These compilers saved their intermediate representation into an architecture neutral format called ANDF, similar in spirit to .NET's Common Intermediate Language and Java's bytecode. TenDRA used to have an installer program which was essentially a compiler for the target architecture that turned ANDF into native code.

Essentially JIT compilers have the same information than a batch compiler has today. For a JIT compiler, the problem comes down to striking a balance between the quality of the generated code and the time it takes to generate the code.

JIT compilers tend to go for fast compile times over quality of the generated code. Mono allows users to configure this threshold by allowing users to pick the optimization level defaults and even lets them pick LLVM to perform the heavy duty optimizations on the code. Slow, but the generated code quality is the same code quality you get from LLVM with C.

Java HotSpot takes a fascinating approach: they do a quick compilation on the first pass, but if the VM detects that a piece of code is being used a lot, the VM recompiles the code with all the optimization turned on and then they hot-swap the code.

.NET has a precompiler called NGen, and Mono allows the --aot flag to be passed to perform the equivalent process that TenDRA's installer did. They precompile the code tuned for the current hardware architecture to avoid having the JIT compiler spend time at runtime translating .NET CIL code to native code.

In Mono's case, you can use the LLVM optimizing compiler as the backend for precompiling code, which produces great code. This is the same compiler that Apple now uses on Lion and as LLVM improves, Mono's generated code improves.

NGen has a few limitations in the quality of the code that it can produce. Unlike Mono, NGen acts merely as a pre-compiler and tests suggest that there are very limited extra optimizations applied. I believe NGen's limitations are caused by .NET's Code Access Security feature which Mono never implemented [1].

[1] Mono only supports the CoreCLR security system, but that is an opt-in feature that is not enabled for desktop/server/mobile use. A special set of assemblies are shipped to support this.

Optimizing JIT compilation for Managed Languages

Java, JavaScript and .NET have chosen a path of productivity and safety over raw performance.

This means that they provide automatic memory management, arrays bounds checking and resource tracking. Those are really the elements that affect the raw performance of these languages.

There are several areas in which managed runtimes can evolve to improve their performance. They wont ever match the performance of hand-written assembly language code, but here are some areas that managed runtimes can work on to improve performance:

>Alias analysis is simpler as arrays are accessed with array operations instead of pointer arithmetic.

Intent: with the introduction of LINQ in C#, developers can shift their attention from how a particular task is done to expressing the desired outcome of an operation. For example:

var biggerThan10 = new List;
for (int i = 0; i < array.Length; i++){
    if (array [i] > 10)
       biggerThan10.Add (i);

Can be expressed now as:

var biggerThan10 = x.Where (x => x > 10).Select (x=>x);
// with LINQ syntax:
var biggerThan10 = from x in array where x > 10 select x;

Both managed compilers and JIT compilers can take advantage of the rich information that is preserved to turn the expressed intent into an optimized version of the code.

Extend VMs: Just like Javascript was recently extended to support strongly typed arrays to improve performance, both .NET and Java can be extended to allow fewer features to be supported at the expense of safety.

.NET could allow developers to run without the CAS sandbox and without AppDomains (like Mono does).

Both .NET and Java could offer "unsafe" sections that would allow performance critical code to not enforce arrays-bounds-optimization (at the expense of crashing or creating a security gap, this can be done today in Mono by using -O=unsafe).

.NET and Mono could provide allocation primitives that allocate objects on a particular heap or memory pool:

	var pool = MemoryPool.Allocate (1024*1024);

	// Allocate the TerrainMesh in the specified memory pool
	var p = new pool, TerrainMesh ();

	// Release all objects from the pool, all references are
	// nulled out
	Assert.NotEquals (p, null);
	pool.Destroy ();
	Assert.Equals (p, null);

Limiting Dynamic Features: Current JIT compilers for Java and .NET have to deal with the fact that code can be extended dynamically by either loading code at runtime or generating code dynamically.

HotSpot leverages its code recompiled to implement sophisticated techniques to perform devirtualization safely.

On iOS and other platforms it is not possible to generate code dynamically, so code generators could trivially devirtualize, inline certain operations and drop features from both their runtimes and the generated code.

More Intrinsics: An easy optimization that JIT engines can do is map common constructs into native features. For example, we recently inlined the use of ThreadLocal<T> variables. Many Math.* methods can be inlined, and we applied this technique to Mono.SIMD.

Posted on 04 Apr 2012

Microsoft's new Open Sourced Stacks

by Miguel de Icaza

Yesterday Microsoft announced that another component of .NET would be open sourced. The entire ASP.NET MVC stack is now open source, including the Razor Engine, System.Json, Web API and WebPages.

With this release, they will start accepting external contributions to these products and will be running the project like other open source projects are.

Mono and the new Stacks

We imported a copy of the git tree from Codeplex into GitHub's Mono organization in the aspnetwebstack module.

The mono module itself has now taken a dependency on this module, so the next time that you run in Mono, you will get a copy of the aspnetwebstack inside Mono.

As of today, we replaced our System.Json implementation (which was originally built for Moonlight) and replaced it with Microsoft's implementation.

Other libraries like Razor are next, as those are trivially imported into Mono. But ASP.NET MVC 4 itself will have to wait since it depends on extending our own core ASP.NET stack to add asynchronous support.

Our github copy will contain mostly changes to integrate the stack with Mono. If there are any changes worth integrating upstream, we will submit the code directly to Microsoft for inclusion. If you want to experiment with ASP.NET Web Stack, you should do this with your own work and work directly with the upstream maintainers.

Extending Mono's ASP.NET Engine

The new ASP.NET engine has been upgraded to support C# 5.0 asynchronous programming and this change will require a number of changes to the core ASP.NET.

We currently are not aware of anyone working on extending our ASP.NET core engine to add these features, but those of us in the Mono world would love to assist enthusiastic new developers of people that love async programming to bring these features to Mono.

Posted on 28 Mar 2012

Mono 2.11.0 is out

by Miguel de Icaza

After more than a year of development, we are happy to announce Mono 2.11, the first in a series of beta releases that will lead to the next 2.12 stable release.

Continuous Integration

To assist those helping us with testing the release, we have setup a new continuous build system that builds packages for Mac, OpenSUSE and Windows at


To test drive Mono 2.11 head to our our downloads page and select the "Alpha" section of the page to get the packages for Mac, Windows or Linux.

The Linux version is split up in multiple packages.

The Windows version ships with Gtk+ and Gtk#

The Mac version ships with Gtk+, Gtk#, F#, IronPython and IronRuby and comes in two versions: Mono Runtime Environment (MRE) and the more complete Mono Development Kit (MDK).

At this stage, we recommend that users get the complete kit.

Runtime Improvements in Mono 2.11

There are hundreds of new features available in this release as we have accumulated them over a very long time. Every fix that has gone into the Mono 2.10.xx series has been integrated into this release.

In addition, here are some of the highlights of this release.

Garbage Collector: Our SGen garbage collector is now considered production quality and is in use by Xamarin's own commercial products.

The collector on multi-CPU systems will also distribute various tasks across the CPUs, it is no longer limited to the marking phase.

The guide Working with SGen will help developers tune the collector for their needs and discusses tricks that developers can take advantage of.

ThreadLocal<T> is now inlined by the runtime engine, speeding up many threaded applications.

Full Unicode Surrogate Support this was a long standing feature and has now been implemented.

C# 5.0 -- Async Support

Mono 2.11 implements the C# 5.0 language with complete support for async programming.

The Mono's class libraries have been updated to better support async programming. See the section "4.5 API" for more details.

C# Backend Rewrite

The compiler code generation backend was rewritten entirely to support both IKVM.Reflection and System.Reflection which allowed us to unify all the old compilers (mcs, gmcs, dmcs and smcs) into a single compiler: mcs. For more information see Backend Rewrite.

The new IKVM.Reflection backend allows the compiler to consume any mscorlib.dll library, instead of being limited to the ones that were custom built/crafted for Mono.

In addition, the compiler is no longer a big set of static classes, instead the entire compiler is instance based, allowing multiple instances of the compiler to co-exist at the same time.

Compiler as a Service

Mono's Compiler as a Service has been extended significantly and reuses the compiler's fully instance based approach (see Instance API for more details).

Mono's compiler as a service is still a low-level API to the C# compiler. The NRefactory2 framework --shared by SharpDevelop and MonoDevelop-- provides a higher level abstraction that can be -- used by IDEs and other high-level tools.

C# Shell

Our C# interactive shell and our C# API to compile C# code can in addition to compiling expressions and statements can now compile class definitions.

4.5 API

4.5 Profile Mono now defaults to the 4.5 profile which is a strict superset of the 4.0 profile and reuses the same version number for the assemblies.

Although .NET 4.5 has not yet been officially released, the compiler now defaults to the 4.5 API, if you want to use different profile API you must use the -sdk:XXX switch to the command line compiler.

Because 4.5 API is a strict superset of 4.0 API they both share the same assembly version number, so we actually install the 4.5 library into the GAC.

Some of the changes in the 4.5 API family include:

  • New Async methods
  • WinRT compatibility API
  • Newly introduced assemblies: System.Net.Http, System.Threading.Tasks.Dataflow

The new System.Net.Http stack is ideal for developers using the C# 5.0 async framework.


The GDB support has been extended and can pretty print more internal variables of Mono as well as understanding SGen internals.

The soft debugger has seen a large set of improvements:

  • Single stepping is now implemented using breakpoints in most cases, speeding it up considerably.
  • Calls to System.Diagnostics.Debugger:Log()/Break () are now routed to the debugger using new UserLog/UserBreak event types.
  • S390x is now supported (Neale Ferguson).
  • MIPS is now supported.
  • Added new methods to Mono.Debugger.Soft and the runtime to decrease the amount of packets transmitted between the debugger and the debuggee. This significantly improves performance over high latency connections like USB.

Mac Support

Mac support has been vastly extended, from faster GC by using native Mach primitives to improves many features that previously only worked on Linux to extending the asynchronous socket support in Mono to use MacOS X specific primitives.

New Ports

We have completed the Mono MIPS port.


As a general theme, Mono 2.11 has hundreds of performance improvements in many small places which add up.

Posted on 22 Mar 2012

Mono and Google Summer of Code

by Miguel de Icaza

Students, get your pencils ready for an intense summer of hacking with the Google Summer of Code and Mono!

Check out the Mono organization Summer of Code Project site.

Posted on 16 Mar 2012

Cross Platform Game Development in C#

by Miguel de Icaza

If you missed the live session on Cross Platform Game Development in C# from AltDevConf you can now watch presentation.

You can also check the videos for all the AltDevConf presentations.

Posted on 16 Mar 2012

Phalanger's PHP on Mono/.NET Updates

by Miguel de Icaza

The Phalanger developers have published an updated set of benchmarks of their PHP compiler running on top of .NET vs PHP and Cached PHP, and the results are impressive:

There are two cases on the language shootout where they are slower than PHP (out of eighteen cases) and they are also slower on eight of thirtyone microbenchmarks.

But in general with real applications like WordPress and MediaWiki, the performance gains are impressive.

Posted on 05 Mar 2012

Working With SGen

by Miguel de Icaza

As SGen becomes the preferred garbage collector for Mono, I put together the Working With SGen document. This document is intended to explain the options that as a developer you can tune in SGen as well as some practices that you can adopt in your application to improve your application performance.

This document is a complement to the low-level implementation details that we had previously posted.

Posted on 05 Mar 2012

Gtk+ and MacOS X

by Miguel de Icaza

We have released a new build of Mono 2.10.9 (Beta) with the latest version of Gtk+2 containing dozens of bug fixes done by the Lanedo team to improve the quality of Mono/Gtk+ apps on OSX.

This is still a beta release, please take it out for a spin, we are almost ready to graduate this as our stable Mono package.

Posted on 05 Mar 2012

C# for Gaming: Slides

by Miguel de Icaza

You can now get the Slides for my Mono for Game Development talk.

Or you can go straight to the resources for the talk.

Posted on 11 Feb 2012

C# for Gaming: AltDevConf This Weekend

by Miguel de Icaza

It is a great honor to participate this weekend on the online AltDevConf conference. This is an online two-day event

Our goal is twofold: To provide free access to a comprehensive selection of game development topics taught by leading industry experts, and to create a space where bright and innovative voices can also be heard. We are able to do this, because as an online conference we are not subject to the same logistic and economic constrains imposed by the traditional conference model.

I will be participating in the talk on Cross Platform Game Development using C# with Matthieu Laban and Philippe Rollin.

You can register here for our session on Saturday at 3pm Eastern Standard Time, noon Pacific Time, and 9pm Paris Time.

If you are located in the Paris time zone, that means that you get to enjoy the talk sipping a tasty hot chocolate with some tasty baguettes.

Posted on 09 Feb 2012

Mono in 2011

by Miguel de Icaza

This was a very interesting year for Mono, and I wanted to capture some of the major milestones and news from the project as well as sharing a bit of what is coming up for Mono in 2012.

I used to be able to list all of the major applications and great projects built with Mono. The user base has grown so large that I am no longer able to do this. 2011 was a year that showed an explosion of applications built with Mono.

In this post I list a few of the high profile projects, but it is by no means an extensive list. There are too many great products and amazing technologies being built with Mono, but a comprehensive list would take too long to assemble.


The largest event for Mono this year was that the team working on Mono technologies at Novell was laid off after Novell was acquired.

We got back on our feet, and two weeks after the layoffs had taken place, the original Mono team incorporated as Xamarin.

Xamarin's goal is to deliver great productivity and great tools for mobile developers. Our main products are Mono on iOS and Mono on Android.

These products are built on top of the open source Mono project and the MonoDevelop project. We continue to contribute extensively to these two open source projects.

Launching Xamarin was a huge effort for all of us.

Xamarin would not have been possible without our great customers and friends in the industry. Many people cared deeply about the technology and helped us get up and running.

In July, we announced an agreement with Attachmate that ensured a bright future for our young company.

A couple of days later, we were ready to sell the mobile products that had been previously developed at Novell, and we started to provide all existing Novell customers with ongoing support for their Mono-based products.

Half a year later, we grew the company and continued to do what we like the most: writing amazing software.

Meanwhile, our users have created amazing mobile applications. You can see some of those in our App Catalog.

C# Everywhere

On the Mobile Space: This year Sony jumped to C# in a big way with the introduction of PS Suite (see the section below) and Nokia adopted Windows Phone 7 as their new operating system.

And we got you covered on Android and iOS for all of your C# needs.

On the Browser: we worked with Google to bring you Mono to Native Client. In fact, every demo shown at the Google Native Client event on December 8th was powered by Mono.

On the Desktop: this year we added MacOS X as a first-class citizen in the world of supported Mono platforms. We did this by introducing MonoMac 1.0 and supporting Apple's MacStore with it.

Games: continue to take advantage of C# blend of performance and high-level features. Read more on my GDC 2011 post.

It is a wild new world for C# and .NET developers that were used to build their UI using ASP.NET or Winforms only. It has been fascinating to see developers evolve their thinking from a Microsoft-only view of the world to a world where they design libraries and applications that split the presentation layer from the business logic.

Developers that make this transition will be able to get great native experiences on each device and form factor.

Sony PSSuite - Powered by Mono

At GDC, Sony announced that PS Suite was built on top of Mono. PS Suite is a new development stack for cross-platform games and cross-platform applications to run on Android devices and Sony Vita.

The PS Suite presentation is available in this video.

In particular, watch the game in Video 2 to get a feeling for the speed of a 3D game purely written in managed code (no native code):

Some of the juicy details from the GDC announcement:

  • PS Suite will have an open appstore model, different than the traditional game publishing business.
  • Open SDK, available for everyone at launch time.
  • PS Suite supports both game development with Sony's 3D libraries as well as regular app development.
  • Cross-platform, cross-device, using the ECMA Common Intermediate Language.
  • Code in C#, run using Mono.
  • GUI Designer called "UI Composer" for non-game applications.
  • The IDE is based on MonoDevelop.
  • Windows-simulator is included to try things out quickly.

MonoDevelop on PSSuite:

PS Suite comes with a GUI Toolkit and this is what the UI composer looks like:

Google Native Client

Google Engineers ported Mono to run on the sandboxed environment of Native Client. Last year they had added support for Mono code generator to output code for Native Client using Mono's static compiler.

This year Google extended Native Client to support Just in Time Compilation, in particular, Mono's brand of JIT compilation. This was used by all three demos shown at the Google Native Client event a couple of days ago:

Unity Powered Builder

This is another game built with Unity's Native Client code generator:

To get the latest version of Mono with support for Native Client, download and build Mono from Google's branch on github.

Mono 2.10

This was the year of Mono 2.10. We went from a beta release for Mono 2.10 in January to making it our new stable release for Mono.

While the world is on Mono 2.10, we have started our work to get Mono 2.12 out in beta form in January.

Mono on Android

This year we launched Mono for Android, a product that consists of port of Mono to the Android OS, C# bindings to the native Java APIs and IDE support for both MonoDevelop and Visual Studio.

The first release came out in April, it was rough around the edges, but thanks to the amazing community of users that worked with us during the year, we solved the performance problems, the slow debugging, vastly improved the edit/debug/deploy cycle and managed to catch up to Google's latest APIs with the introduction of Mono for Android 4.0.

Mono on iOS

Just like Android, we have been on a roll with MonoTouch.

In short, this year:

  • We kept up with Apple's newly introduced APIs (UIKit, iCloud, Airplay, Bluetooth, Newstand, CoreImage).
  • Integrated XCode 4's UI designer with MonoDevelop< and added support for storyboards.
  • Added the option of using LLVM for our builds, bringing thumb support and ARMv7 support along the way.

We started beta-testing a whole new set of features to be released early next year: a new unit testing framework, a heap profiler, integrating MonoTouch.Dialog in the product and improving the debug/deploy process.<

Mono for iOS has been on the market now for two years, and many products are coming to the market based on it.


Phalanger is a PHP compiler that runs on the .NET and Mono VMs and is powered by the Dynamic Language Runtime.

It is so complete that it can run both MediaWiki and WordPress out of the box. And does so by running faster than they would under PHP.

This year the Phalanger guys released Phalanger 3.0 which now runs on Mono (previously they required the C++/CLI compiler to run).

Phalanger's performance is impressive as it is just as fast as the newly announced Facebook HipHop VM for PHP. The major difference being that Phalanger is a complete PHP implementation and the HipHopVM is still not a complete implementation.

The other benefit of Phalanger is that it is able to participate and interop with code written in other .NET languages as well as benefitting from the existing .NET interop story (C, C++).


Our technology to bridge C# and C++ matured to the point that it can be used by regular users.

Compiler as a Service

This year our C# compiler was expanded in three directions:

  • We completed async/await support
  • We completed the two code output engines (System.Reflection.Emit and IKVM.Reflection).
  • We improved the compiler-as-a-service features of the compiler.

Our async/await support is scheduled to go out with the first preview of Mono 2.11 in early January. We can not wait to get this functionality to our users and start building a new generation of async-friendly/ready desktop, mobile and server apps.

One major difference between our compiler-as-a-service and Microsoft's version of the C# compiler as a service is that we support two code generation engines, one generates complete assemblies (like Microsoft does) and the other one is able to be integrated with running code (this is possible because we use System.Reflection.Emit and we can reference static or dynamic code from the running process).

We have also been improving the error recovery components of the compiler as this is going to power our new intellisense/code completion engine in MonoDevelop. Mono's C# compiler is the engine that is powering the upcoming NRefactory2 library.

You can read more about our compiler as a service updates.


Unity is one of Mono's major users. At this point Unity no longer requires an introduction, they went from independent game engine a few years ago to be one of the major game engine platforms in the game industry this year.

The Unity engine runs on every platform under the sun. From the Consoles (PS3, Wii and XBox360) to iPhones and Androids and runs on your desktop either with the Unity3D plugin or using Google's Native Client technology. The list of games being built with Unity keeps growing every day and they are consistently among the top sellers on every app store.

Mono is the engine that powers the scripts and custom code in games and applications built with Unity3D and it also powers the actual tool that users use to build games, the Unity3D editor:

The editor itself it implemented in terms of Unity primitives, and users can extend the Unity3D editor with C#, UnityScript or Boo scripts dynamically.

One of my favorite games built with Unity3D is Rochard was demoed earlier this year on a PS3 at the GDC and is now also avaialble on Steam:


Just before the end of the year, Microsoft shipped Kinectimals for iOS systems.

Kinectimals is built using Unity and this marks the first time that Microsoft ships a software product built with Mono.

Then again, this year has been an interesting year for Microsoft, as they have embraced open source technologies for Azure, released SDKs for iOS and Android at the same time they ship SDKs for their own platforms and shipped various applications on Apple's AppStore for iOS.


We started the year with MonoDevelop 2.4 and we finished after two major releases with MonoDevelop 2.8.5.

In the course of the year, we added:

  • Native Git support
  • Added .NET 4.0 project support, upgraded where possible to XBuild/MSBuild
  • MonoMac Projects
  • XCode 4 support for MonoMac, MonoTouch and Storyboards
  • Support for Android development
  • Support for iOS5 style properties
  • Major upgrade to the debugger engine
  • Adopted native dialogs on OSX and Windows

Our Git support was based on a machine assisted translation of the Java jGit library using Sharpen. Sharpen has proved to be an incredibly useful tool to bring Java code to the .NET world.


Our precise collector has gotten a full year of testing now. With Mono 2.10 we made it very easy for developers to try it out. All users had to do was run their programs with the --sgen flag, or set MONO_ENV_OPTIONS to gc=sgen.

Some of the new features in our new Garbage Collector include:

  • Windows, MacOS X and S390x ports of SGen (in addition to the existing x86, x86-64 and ARM ports).
  • Lock-free allocation to improve scalability (we only take locks when we run out of memory).
  • Work stealing parallel collector and a parallel nursery collector, to take advantage of extra CPUs on the system to help with the GC.
  • Work on performance and scalability work, as our users tried things out in the field, we identified hot-spots in SGen which we have been addressing.

As we are spending so much time on ARM-land these days, SGen has also gained various ARM-specific optimizations.

SGen was designed primarly to be used by Mono and we are extending it beyond being a pure garbage collector for Mono, to support scenarios where our garbage collector has to be integrated with other object systems and garbage collectors. This is the case of Mono for Android where we now have a cooperative garbage collector that works hand-in-hand with Dalvik's GC. And we also introduce support for toggle references to better support Objective-C environments like MonoTouch and MonoMac.

XNA and Mono: MonoGame

Ever since Microsoft published the XNA APIs for .NET, developers have been interested in bringing XNA to Mono-based platforms.

There was a MonoXNA project, which was later reused by projects like SilverXNA (an XNA implementation for Silverlight) and later XNAtouch an implementation of XNA for the iPhone powered by MonoTouch. Both very narrow projects focused on single platforms.

This year, the community got together and turned the single platform XNATouch into a full cross-platform framework, the result is the MonoGame project:

Platform Support Matrix

Currently MonoGame's strength is on building 2D games. They already have an extensive list of games that have been published on the iOS AppStore and the Mac AppStore and they were recently featured in Channel 9's Coding For Fun: MonoGame Write Once Play Everywhere.

An early version of MonoGame/XnaTouch powers SuperGiantGame's Bastion game on Google's Native Client. Which allows users of Windows, Mac and Linux desktop systems to run the same executable on all systems. If you are running Chrome, you can install it in seconds.

Incidentally, Bastion just won three awards at the Spike VGA awards including Best Downloadable Game, Best Indie Game, and Best Original Score.

The MonoGame team had been relatively quiet for the most part of 2011 as they were building their platform, but they got into a good release cadence with the MonoGame 2.0 release in October, when they launched as a cross-platform engine, followed up with a tasty 2.1 release only two weeks ago.

With the addition of OpenGL ES 2.0 support and 3D capabilities to MonoGame, 2012 looks like it will be a great year for the project.


Since MonoDevelop is built on top of the Gtk+ toolkit and since it was primarily a Unix toolkit there have been a few rough areas for our users in both Mac and Windows.

This year we started working with the amazing team at Lanedo to improve Gtk+ 2.x to work better on Mac and Windows.

The results are looking great and we want to encourage developers to try out our new Beta version of Mono, which features the updated Gtk+ stack.

This new Gtk+ stack solves many of the problems that our users have reported over the past few months.

Hosting Bills

I never tracked Mono downloads as I always felt that tracking download numbers for open source code that got repackaged and redistributed elsewhere pointless.

This summer we moved the code hosting from Novell to Xamarin and we were surprised by our hosting bills.

The major dominating force are binaries for Windows and MacOS which are communities that tend not to download source and package the software themselves. This is the breakdown for completed downloads (not partial downloads, or interrupted ones) for our first month of hosting of Mono:

  • 39,646 - Mono for Windows (Runtime + SDK)
  • 27,491 - Mono for Mac (Runtime)
  • 9,803 - Mono for Windows (Runtime)
  • 9,910 - Mono for Mac (Runtime + SDK)

  • Total: 86,850 downloads for Windows and Mac

These numbers are only for the Mono runtime, not MonoDevelop, the MonoDevelop add-ins or any other third party software.

It is also worth pointing out that none of our Windows products (MonoDevelop for Windows, or Mono for Android on Windows) use the Mono runtime. So these downloads are for people doing some sort of embedding of Mono on their applications on Windows.

At this point, we got curious. We ran a survey for two days and collected 3,949 answers. These is the summary of the answers:

What type of application will you run with Mono?

This one was fascinating, many new users to the .NET world:

The best results came form the free-form answers in the form. I am still trying to figure out how to summarize these answers, they are all very interesting, but they are also all over the map.

Some Key Quotes

When I asked last week for stories of how you used Mono in 2011, some of you posted on the thread, and some of you emailed me.

Here are a couple of quotes from Mono users:

I can't do without Mono and I don't just mean the iOS or Android dev with C# but MonoMac and Mono for *nix too. Thanks for everything; from the extraordinary tools to making hell turn into heaven, and thank you for making what used to be a predicament to effortless development pleasure.

I don't think we could have achieved our solutions without Mono in enterprise mobile development. It addresses so many key points, it is almost a trade secret. We extensively use AIR and JavaScript mobile frameworks too but ultimately we desperately need 1-to-1 mapping of the Cocoa Touch APIs or tap into low level features which determines our choice of development platform and frameworks.

That's where Mono comes in.

Gratefulness and paying polite respects aside, the key tenets of Mono we use are:

  • shared C# code base for all our enterprise solutions - achieving the write once, compile everywhere promise with modern language and VM features everyone demands and expects in this century
  • logical, consistent and self-explanatory wrapper APIs for native services - allows us to write meta APIs of our own across platforms
  • low latency, low overhead framework
  • professional grade IDE and tools
  • native integration with iOS tools and development workflow
  • existence of satisfactory documentation and support
  • legal clarity - favorable licensing options
  • dedicated product vision via Xamarin - commercial backing
  • community support

Koen Pijnenburg shared this story with me:

We've been in touch a few times before and would like to contribute my story. It's not really an interesting setup, but a real nice development for Mono(Touch). I've been developing app for iPhone since day 1, I was accepted in the early beta for the App Store. On launch day july 2008, 2 of the 500 apps in the App Store were mine, my share has decreased a lot in the past years ;)

I really, really, really like football(soccer), maybe you do also, I don't know. In september 2008 I created the first real soccer/football stats app for the iPhone called My Football. This was a huge succes, basically no competition at that time. In 2009 I released My Football Pro, an app with 800 leagues worldwide, including live data for more then 100 leagues. Since then I created lots of apps, all created with the iPhone SDK and with Objective-C.

Since the launch of MonoTouch, it merged the best of two worlds in my opinion. I've been a Mono/.NET developer for years before the iPhone apps, for me it was love at first line of code.

The last year I've increased my work with MonoTouch / Droid /MonoGame(Poppin' Frenzy etc ;)), and focused less on working with native SDK's only. Since our My Football apps are at the end of their lifecycle in this form, we are working on a new line of My Football apps. Our base framework supporting our data, is built with Mono, and the apps UI will be built with MonoTouch / MonoDroid / WP7 etc.

Included is the screenshot of our first app built with the framework, My Football Pro for iPad. It has a huge amount of data, stats / tables / matches / live data for more then 800 leagues worldwide. We think it's a great looking app!

Working with MonoTouch is fantastic and just wanted you to know this!

Mono on Mainframes

This year turned out to show a nice growh in the deployment of Mono for IBM zSeries computers.

Some are using ASP.NET, some are using Mono in headless mode. This was something that we were advocating a few years ago, and this year the deployments went live both in Brazil and Europe.

Neale Ferguson from Sinenomine has kept the zSeries port active and in shape.

Mono and ASP.NET

This year we delivered enough of ASP.NET 4.0 to run Microsoft's ASP.NET MVC 3.

Microsoft ASP.NET MVC 3 is a strange beast. It is licensed under a great open source license (MS-PL) but the distribution includes a number of binary blobs (the Razor engine).

I am inclined to think that the binaries are not under the MS-PL, but strictly speaking, since the binaries are part of the MS-PL distribution labeled as such, the entire download is MS-PL.

That being said, we played it safe in Mono-land and we did not bundle ASP.NET MVC3 with Mono. Instead, we provide instructions on how users can deploy ASP.NET MVC 3 applications using Razor as well as pure Razor apps (those with .cshtml extensions) with Mono.

2012, the year of Mono 2.12

2012 will be a year dominated by our upcoming Mono release: Mono 2.12. It packs a year worth of improvements to the runtime, to our build process and to the API profiles.

Mono 2.12 defaults to the .NET 4.x APIs and include support for .NET 4.5.

This is going to be the last time that we branch Mono for these extended periods of time. We are changing our development process and release policies to reduce the amount of code that is waiting on a warehouse to be rolled out to developers.


We wrapped up our work on updating the ECMA CLI standard this year. The resulting standard is now at ISO and going through the standard motions to become an official ISO standard.

The committee is getting ready for a juicy year ahead of us where we are shifting gears from polish/details to take on significant extensions to the spec.

Posted on 21 Dec 2011

CXXI: Bridging the C++ and C# worlds.

by Miguel de Icaza

The Mono runtime engine has many language interoperability features but has never had a strong story to interop with C++.

Thanks to the work of Alex Corrado, Andreia Gaita and Zoltan Varga, this is about to change.

The short story is that the new CXXI technology allows C#/.NET developers to:

  • Easily consume existing C++ classes from C# or any other .NET language
  • Instantiate C++ objects from C#
  • Invoke C++ methods in C++ classes from C# code
  • Invoke C++ inline methods from C# code (provided your library is compiled with -fkeep-inline-functions or that you provide a surrogate library)
  • Subclass C++ classes from C#
  • Override C++ methods with C# methods
  • Expose instances of C++ classes or mixed C++/C# classes to both C# code and C++ as if they were native code.

CXXI is the result of two summers of work from Google's Summer of Code towards improving the interoperability of Mono with the C++ language.

The Alternatives

This section is merely a refresher of of the underlying technologies for interoperability supported by Mono and how developers coped with C++ and C# interoperability in the past. You can skip it if you want to get to how to get started with CXXI.

As a reminder, Mono provides a number of interoperability bridges, mostly inherited from the ECMA standard. These bridges include:

  • The bi-directional "Platform Invoke" technology (P/Invoke) which allows managed code (C#) to call methods in native libraries as well as support for native libraries to call back into managed code.
  • COM Interop which allows Mono code to transparently call C or C++ code defined in native libraries as long as the code in the native libraries follows a few COM conventions [1].
  • A general interceptor technology that can be used to intercept method invocations on objects.

When it came to getting C# to consume C++ objects the choices were far from great. For example, consider a sample C++ class that you wanted to consume from C#:

class MessageLogger {
	MessageLogger (const char *domain);
	void LogMessage (const char *msg);

One option to expose the above to C# would be to wrap the Demo class in a COM object. This might work for some high-level objects, but it is a fairly repetitive exercise and also one that is devoid of any fun. You can see how this looks like in the COM Interop page.

The other option was to produce a C file that was C callable, and invoke those C methods. For the above constructor and method you would end up with something like this in C:

/* bridge.cpp, compile into */
MessageLogger *Construct_MessageLogger (const char *msg)
	return new MessageLogger (msg);

void LogMessage (MessageLogger *logger, const char *msg)
	logger->LogMessage (msg);

And your C# bridge, like this:

class MessageLogger {
	IntPtr handle;

	[DllImport ("bridge")]
	extern static IntPtr Construct_MessageLogger (string msg);

	public MessageLogger (string msg)
		handle = Construct_MessageLogger (msg);

	[DllImport ("bridge")]
	extern static void LogMessage (IntPtr handle, string msg);

	public void LogMessage (string msg)
		LogMessage (handle, msg);

This gets tedious very quickly.

Our PhyreEngine# binding was a C# binding to Sony's PhyreEngine C++ API. The code got very tedious, so we built a poor man's code generator for it.

To make things worse, the above does not even support overriding C++ classes with C# methods. Doing so would require a whole load of manual code, special cases and callbacks. The code quickly becomes very hard to maintain (as we found out ourselves with PhyreEngine).

This is what drove the motivation to build CXXI.

[1] The conventions that allow Mono to call unmanaged code via its COM interface are simple: a standard vtable layout, the implementation of the Add, Release and QueryInterface methods and using a well defined set of types that are marshaled between managed code and the COM world.

How CXXI Works

Accessing C++ methods poses several challenges. Here is a summary of the components that play a major role in CXXI:

  • Object Layout: this is the binary layout of the object in memory. This will vary from platform to platform.
  • VTable Layout: this is the binary layout that the C++ compiler will use for a given class based on the base classes and their virtual methods.
  • Mangled names: non-virtual methods do not enter an object vtable, instead these methods are merely turned into regular C functions. The name of the C functions is computed based on the return type and the parameter types of the method. These vary from compiler to compiler.

For example, given this C++ class definition, with its corresponding implementation:

class Widget {
	void SetVisible (bool visible);
	virtual void Layout ();
	virtual void Draw ();

class Label : public Widget {
	void SetText (const char *text);
	const char *GetText ();

The C++ compiler on my system will generate the following mangled names for the SetVisble, Layout, Draw, SetText and GetText methods:


The following C++ code:

	Label *l = new Label ();
	l->SetText ("foo");
	l->Draw ();	

Is roughly compiled into this (rendered as C code):

	Label *l = (Label *) malloc (sizeof (Label));
	ZN5LabelC1Ev (l);   // Mangled name for the Label's constructor
	_ZN5Label7SetTextEPKc (l, "foo");

	// This one calls draw
	(l->vtable [METHOD_PTR_SIZE*2])();

For CXXI to support these scenarios, it needs to know the exact layout for the vtable, to know where each method lives and it needs to know how to access a given method based on their mangled name.

The following chart explains shows how a native C++ library is exposed to C# or other .NET languages:

Your C++ source code is compiled twice. Once with the native C++ compiler to generate your native library, and once with the CXXI toolchain.

Technically, CXXI only needs the header files for your C++ project, and only the header files for the APIs that you are interested in wrapping. This means that you can create bindings for C++ libraries that you do not have the source code to, but have its header files.

The CXXI toolchain produces a .NET library that you can consume from C# or other .NET languages. This library exposes a C# class that has the following properties:

  • When you instantiate the C# class, it actually instantiates the underlying C++ class.
  • The resulting class can be used as the base class for other C# classes. Any methods flagged as virtual can be overwritten from C#.
  • Supports C++ multiple inheritance: The generated C# classes expose a number of cast operators that you can use to access the different C++ base classes.
  • Overwritten methods can call use the "base" C# keyword to invoke the base class implementation of the given method in C++.
  • You can override any of the virtual methods from classes that support multiple inheritance.
  • A convenience constructor is also provided if you want to instantiate a C# peer for an existing C++ instance that you surfaced through some other mean.

This is pure gold.

The CXXI pipeline in turn is made up of three components, as shown in the diagram on the right.

The GCC-XML compiler is used to parse your source code and extract the vtable layout information. The generated XML information is then processed by the CXXI tooling to generate a set of partial C# classes that contain the bridge code to integrate with C++.

This is then combined with any customization code that you might want to add (for example, you can add some overloads to improve the API, add a ToString() implementation, add some async front-ends or dynamic helper methods).

The result is the managed assembly that interfaces with the native static library.

It is important to note that the resulting assembly (Foo.dll) does not encode the actual in-memory layout of the fields in an object. Instead, the CXXI binder determines based on the ABI being used what the layout rules for the object are. This means that the Foo.dll is compiled only once and could be used across multiple platforms that have different rules for laying out the fields in memory.


The code on GitHub contains various test cases as well as a couple of examples. One of the samples is a minimal binding to the Qt stack.

Future Work

CXXI is not finished, but it is a strong foundation to drastically improve the interoperability between .NET managed languages and C++.

Currently CXXI achieves all of its work at runtime by using System.Reflection.Emit to generate the bridges on demand. This is useful as it can dynamically detect the ABI used by a C++ compiler.

One of the projects that we are interested in doing is to add support for static compilation, this would allow PS3 and iPhone users to use this technology. It would mean that the resulting library would be tied to the platform on which the CXXI tooling was used.

CXXI currently implements support for the GCC ABI, and has some early support for the MSVC ABI. Support for other compiler ABIs as well as for completing the MSVC ABI is something that we would like help with.

Currently CXXI only supports deleting objects that were instantiated from managed code. Other objects are assumed to be owned by the unmanaged world. Support for the delete operator is something that would be useful.

We also want to better document the pipeline, the runtime APIs and improve the binding.

Posted on 19 Dec 2011

2011: Tell me how you used Mono this year

by Miguel de Icaza

I have written a summary of Mono's progress in the year 2011, but I want to complement my post with stories from the community.

Did you use Mono in an interesting setup during 2011? Please post a comment on this post, or email me the story and tell me a little bit about it.

Posted on 15 Dec 2011

Porto Alegre

by Miguel de Icaza

We are traveling to Porto Alegre in Brazil today and will be staying in Brazil until January 4th.

Ping me by email (miguel at gnome dot org) if you would like to meet in Porto Alegre to talk hacking, Mono, Linux, open source, iPhone or if you want to enlighten me about the role of scrum masters as actors of social change.

Happy holidays!

Posted on 14 Dec 2011

Farewell to Google's CodeSearch

by Miguel de Icaza

It seems that part of Steve Jobs' legacy was to give Larry Page some advise: focus. This according to Steve Jobs' recently published biography.

So Larry Page took the advise seriously and decided to focus. His brand of focus is to kill projects that were distracting to their goals. One of them, -and the one I cared the most about- was CodeSearch..

What did CodeSearch do for programmers?

The CodeSearch service was a unique tool as it indexed open source code in the wild.

Codesearch is one of the most valuable tools in existence for all software developers, specifically:

  • When an API is poorly documented, you could find sample bits of code that used the API.
  • When an API error codes was poorly documented, you could find sample bits of code that handled it.
  • When an API was difficult to use (and the world is packed with those), you could find sample bits of code that used it.
  • When you quickly wanted to learn a language, you knew you could find quality code with simple searches.
  • When you wanted to find different solutions to everyday problems dealing with protocols, new specifications, evolving standards and trends. You could turn to CodeSearch.
  • When you were faced with an obscure error message, an obscure token, an obscure return value or other forms of poor coding, you would find sample bits of code that solved this problem.
  • When dealing with proprietary protocols or just poorly documented protocols, you could find how they worked in minutes.
  • When you were trying to debug yet another broken standard or yet another poorly specified standard, you knew you could turn quickly to CodeSearch to find the answers to your problems (memories of OAuth and IMAP flash in my head).
  • When learning a new programming language or trying to improve your skills on a new programming language, you could use CodeSearch to learn the idioms and the best (and worst practices).
  • When building a new version of a library, either in a new language, making a fluent version, making an open source version, building a more complete version you would just go to Codesearch to find answers to how other people did things.

It is a shame that Google is turning their back on their officially stated mission "To organize the world‘s information and make it universally accessible and useful". It is a shame that this noble goal is not as important as competing with Apple, Facebook, Microsoft, Twitter and Yelp.

Comparing Search Engines

While writing this blog entry, I fondly remembered how Codesearch helped me understand the horrible Security framework that ships with iOS. Nobody informed the Apple engineers that "Security through obscurity" was not intended for their developer documentation.

In this particular case, I was trying to understand the semantics of kSecReturnData. How to use this constant and how it interacts with the keyring system is both tricky, and poorly specified in Apple's docs. Sometimes things fail without any indication of what went wrong, other than "error". So I used CodeSearch to figure this out (along with some other 30 constants and APIs in that library that are just as poorly documented).

These are the results of looking for this value in three search engines as of this morning.

First Contender: GrepCode

GrepCode shows absolutely nothing relevant. But shows a bunch of Java packages with no context, no code snippets and if you make the mistake of drilling down, you wont find anything:

Not useful.

Second Contender: Codease

Codase is indexing 250 million lines of code, usually it takes minutes to get this page:

Maybe the server will come back up.

Third Contender: Koders

Koders is part of Black Duck, and searching for the term renders a bunch of matches. Not a single one of the results displayed actually contain a single use of the kSecReturnData constant. And not a single one of the snippets actually show the kSecReturnData constant. It is as useful as configuring your browser to use StumbleUpon as your search engine:

Not useful.

Google's CodeSearch

And this is what Codesearch shows:

The big innovation on Google's search engine is that it actually works and shows real matches for the text being searched, with a relevant snippet of the information you are looking for.

We are going to be entering the dark ages of software research in the next few months.

Is there a hacker White Knight out there?

Running a service like Codesearch is going to take a tremendous amount of resources. There are major engineering challenges involved and hosting a service like this can not be cheap. It is probably not even profitable.

Larry Page's Google has already dropped the project. We can only hope that in a few years Sergey Brin's Google or Eric Schmidt's Google will bring this service back.

Microsoft is too busy catching up to Google and wont have any spare resources to provide a Bing for code search. And if they did, they would limit the search to Win32 APIs.


I should thank Google for funding that project for as long as they did as well as the Google engineers that worked on it as long as they could. Over the years, it helped me fix problems in a fraction of the time and helped me understand complicated problems in minutes.

The Google engineers whose projects just got shutdown for in the name of strategy and focus are probably as sad as all of us are.

On the plus side, I get to share this rant on Google Plus with a dozen of my friends!

Posted on 29 Nov 2011

Updated Documentation Site

by Miguel de Icaza

Jeremie Laval has upgraded our Web-based documentation engine over at This upgrade brings a few features:

New Look: Base on Jonathan Pobst's redesign, this is what our documentation looks like now:

Better Links: Links to pages on the site will now properly open the left-side tree to the documentation you linked to. This has been an open request for about six years, and it got finally implemented.

Search: the search box on the web site uses Lucene to search the text on the server side, and shows you the matching results as you type:

Easier to Plug: MonoDoc/Web now easily supports loading documentation from alternate directories, it is no longer limited to loading the system-configured documentation.

No more frames: For years we used frames for the documentation pages. They had a poor experience and made the code uglier. They are now gone.

Powered by Mono's SGen: We have reduced the memory consumption of our web documentation by switching to Mono's Generational GC from Boehm's. The load on the server is lower, responses are faster and we scale better.

The source code changes are now on GitHub in the webdoc module.

We have also added Google Analytics support to our web site to help us determine which bits of documentation are more useful to you.

Posted on 22 Nov 2011

Hiring Mono Runtime Hackers

by Miguel de Icaza

As Mono grows on servers, mobile and desktop platforms, we are looking to hire programmers to join our Mono Runtime team.

The Mono Runtime team owns the code generator, the just-in-time and ahead-of-time compilers, the garbage collector, the threadpool and async layers in the runtime and mostly works in the C-side of the house.

If you are a developer with low-level experience with virtual machines, just in time compilers or love garbage collection, real time processing, or you read every new research paper on incremental garbage collection, hardware acceleration, register allocation and you are interested in joining our young, self-funded and profitable startup, we want to hear from you.

Send your resumes to [email protected]

Posted on 18 Oct 2011

Upcoming Mono Releases: Change in Policies

by Miguel de Icaza

We have historically made stable releases of Mono that get branched and maintained for long periods of time. During these long periods of time, we evolve our master release for some four to five months while we do major work on the branch.

Historically, we have had done some of these large changes since we have rewritten or re-architected large parts of our JIT, or our garbage collector, or our compilers.

There were points in the project history where it took us some 9 months to release: seven months of new development followed by two months of beta testing and fixing regressions. With Mono 2.6 we tried to change this, we tried to close the release time to at most six months, and we were relatively good at doing this with 2.8 and 2.10.

We were on track to do a quick Mono 2.12 release roughly around May, but with the April bump in the road, this derailed our plans.

Since 2.10.0 was released two things happened:

  • On Master: plenty of feature work and bug fixing.
  • On our 2.10 branch: bug fixes and backporting fixes from master to 2.10

Now that things have settled at Xamarin and that we are getting Mono back into continuous integration builds we are going to release our first public beta of the upcoming Mono, it will be called Mono 2.11.1. We will keep it under QA until we are happy with the results and we will then release Mono 2.12 based on this.

But after Mono 2.12, we want to move to a new development model where we keep our master branch always in a very stable state. This means that new experimental features will be developed in branches and only landed to the master branch once they have been completed.

Our goal is to more quickly bring the features that we are developing to our users instead of having everyone wait for very long periods of time to get their new features.

New Features in Mono 2.11

These are some of the new features availalable in Mono 2.11:

  • We refactored our C# compiler to have two backends one based on Cecil, one based on Reflection.Emit. Fixing some important usability properties of our compiler.
  • Implemented C# 5 Async.
  • Our C# compiler has TypedReference support (__refvalue, __reftype and __makeref).
  • Our compiler as a service can compile classes now and has an instance API (instantiate multiple C# compiler contexts independently).
  • Added the .NET 4.5 API profile and many of the new async APIs to use with C# 5.
  • Improved our new Garbage Collector: it is faster, it is more responsive and it is more stable. It has also gained MacOS/iOS native support.
  • We made System.Json available on every profile.
  • We added Portable Class Library support.
  • We added tooling for Code Contracts
  • We added a TPL Dataflow implementation
  • We added fast ThreadLocal support
  • We brought our ASP.NET implementation to the year 2011 and it now sports a new enormously cute error page as opposed to that error page that we have which transports you mind back to 1999.
  • Mono's debugger now supports attaching to a live process (deferred support)
  • Our socket stack is faster on BSD and OSX, by using kqueue (on Linux it uses epoll already).

Posted on 14 Oct 2011

WinRT and Mono

by Miguel de Icaza

Today Joseph mentioned to me that some of our users got the impression from my previous post on WinRT that we would be implementing WinRT for Linux. We are not working on a WinRT UI stack for Linux, and do not have plans to.

WinRT is a fabulous opportunity for Mono, because Microsoft is sending a strong message: if you want your code to run in multiple scenarios (server, desktops, sandboxed environments), you want to split your UI code from your backend code.

This is great because it encourages developers to think in terms of having multiple facades for the same code base and the direction that we have been taking Mono on in the last few years.

Use the native toolkit on each platform to produce an immersive user experience, and one that leverages the native platform in the best possible way.

These are the APIs that we envision .NET developers using on each platform:

  • Windows: WinRT, Winforms, WPF (fallbacks: Gtk#, Silverlight)
  • MacOS: MonoMac (fallback: Gtk#, Silverlight)
  • Linux: Gtk#
  • Android: MonoDroid APIs
  • iOS: MonoTouch
  • Windows Phone 7: Silverlight
  • XBox360: XNA-based UI

Even if a lot of code could be reused from Moonlight, WinRT is a moving target. It is not clear that the Linux desktop, as we know it today, is keeping up with the growth of other consumer environments. I talked to Tim about this at Build.

Head-less WinRT

There are some GUI-less components of WinRT that *do* make sense to bring to Mono platforms. There is already an implementation of some bits of the headless WinRT components being done by Eric.

The above effort will enable more code sharing to take place between regular .NET 4 apps, WP7 apps, Mono apps and WinRT apps.

Posted on 26 Sep 2011

WinRT demystified

by Miguel de Icaza

Windows 8 as introduced at Build is an exciting release as it has important updates to how Microsoft envisions users will interact with their computers, to a fresh new user interface to a new programming model and a lot more.

If you build software for end-users, you should watch Jensen Harris discuss the Metro principles in Windows 8. I find myself wanting to spend time using Windows 8.

But the purpose of this post is to share what I learned at the conference specifically about WinRT and .NET.

The Basics

Microsoft is using the launch of Windows 8 as an opportunity to fix long-standing problems with Windows, bring a new user interface, and enable a safe AppStore model for Windows.

To do this, they have created a third implementation of the XAML-based UI system. Unlike WPF which was exposed only to the .NET world and Silverlight which was only exposed to the browser, this new implementation is available to C++ developers, HTML/Javascript developers and also .NET developers.

.NET developers are very familiar with P/Invoke and COM Interop. Those are two technologies that allow a .NET developer to consume an external component, for example, this is how you would use the libc "system (const char *)" API from C#:

	[DllImport ("libc")]
	void system (string command);

	system ("ls -l /");

We have used P/Invoke extensively in the Mono world to create bindings to native libraries. Gtk# binds the Gtk+ API, MonoMac binds the Cocoa API, Qyoto binds the Qt API and hundred other bindings wrap other libraries that are exposed to C# as object-oriented libraries.

COM Interop allows using C or C++ APIs directly from C# by importing the COM type libraries and having the runtime provide the necessary glue. This is how Mono talked with OpenOffice (which is based on COM), or how Mono talks to VirtualBox (which has an XPCOM based API).

There are many ways of creating bindings for a native library, but doing it by hand is bound to be both tedious and error prone. So everyone has adopted some form of "contract" that states what the API is, and the binding author uses this contract to create their language binding.


WinRT is a new set of APIs that have the following properties:

  • It implements the new Metro look.
  • Has a simple UI programming model for Windows developers (You do not need to learn Win32, what an HDC, WndProc or LPARAM is).
  • It exposes the WPF/Silverlight XAML UI model to developers.
  • The APIs are all designed to be asynchronous.
  • It is a sandboxed API, designed for creating self-contained, AppStore-ready applications. You wont get everything you want to create for example Backup Software or Hard Disk Partitioning software.
  • The API definitions is exposed in the ECMA 335 metadata format (the same one that .NET uses, you can find those as ".winmd" files).

WinRT wraps both the new UI system as well as old Win32 APIs and it happens that this implementation is based on top of COM.

WinRT Projections

What we call "bindings" Microsoft now calls "projections". Projections are the process of exposing APIs to three environments: Native (C and C++), HTML/Javascript and .NET.

  • If you author a component in C++ or a .NET language, its API will be stored in a WinMD file and you will be able to consume it from all three environments (Native, JavaScript and .NET).

    Even in C++ you are not exposed to COM. The use of COM is hidden behind the C++ projection tools. You use what looks and feels like a C++ object oriented API.

    To support the various constructs of WinRT, the underlying platform defines a basic set of types and their mappings to various environment. In particular, collection objects in WinRT are mapped to constructs that are native to each environment.

    Asynchronous APIs

    Microsoft feels that when a developer is given the choice of a synchronous and an asynchronous API, developers will choose the simplicity of a synchronous API. The result usually works fine on the developer system, but is terrible when used in the wild.

    With WinRT, Microsoft has followed a simple rule: if an API is expected to take more than 50 milliseconds to run, the API is asynchronous.

    The idea of course is to ensure that every Metro application is designed to always respond to user input and to not hang, block or provide a poor user experience.

    Async programming has historically been a cumbersome process as callbacks and state must be cascaded over dozens of places and error handling (usually poor error handling) is sprinkled across multiple layers of code.

    To simplify this process, C# and VB have been extended to support the F#-inspired await/async pattern, turning async programming into a joy. C++ got a setup that is as good as you can get with C++ lambdas and Javascript uses promises and "then ()".

    Is it .NET or Not?

    Some developers are confused as to whether .NET is there or not in the first place, as not all of the .NET APIs are present (File I/O, Sockets), many were moved and others were introduced to integrate with WinRT.

    When you use C# and VB, you are using the full .NET framework. But they have chosen to expose a smaller subset of the API to developers to push the new vision for Windows 8.

    And this new vision includes safety/sandboxed systems and asynchronous programming. This is why you do not get direct file system access or socket access and why synchronous APIs that you were used to consuming are not exposed.

    Now, you notice that I said "exposed" and not "gone".

    What they did was that they only exposed to the compiler a set of APIs when you target the Metro profile. So your application will not accidentally call File.Create for example. At runtime though, the CLR will load the full class library, the very one that contains File.Create, so internally, the CLR could call something like File.Create, it is just you that will have no access to it.

    This split is similar to what has been done in the past with Silverlight, where not every API was exposed, and where mscorlib was given rights that your application did not have to ensure the system safety.

    You might be thinking that you can use some trick (referencing the GAC library instead of the compiler reference or using reflection to get to private APIs, or P/Invoking into Win32). But all of those uses will be caught by AppStore review application and you wont be able to publish your app through Microsoft's store.

    You can still do whatever ugly hack you please on your system. It just wont be possible to publish that through the AppStore.

    Finally, the .NET team has taken this opportunity to do some spring cleaning. mscorlib.dll and System.dll have been split in various libraries and they have moved some types around.

    Creating WinRT Components

    Microsoft demoed creating new WinRT components on both C++ and .NET.

    In the .NET case, creating a WinRT component has been drastically simplified. The following is the full source code for a component that adds 2:

    	public sealed class AddTwo {
    		public int Add (int a, int b)
    			return a + b;
    		public async IAsyncOperation SubAsync (int a, int b)
    			return a - await (CountEveryBitByHand (b));

    You will notice that there are no COM declarations of any kind. The only restriction is that your class must be sealed (unless you are creating a XAML UI component, in that case the restriction is lifted).

    There are also some limitations, you can not have private fields on structures, and there is not Task<T> for asynchronous APIs, instead you use the IAsyncOperation interface. Update to clarify: the no private fields rule is only limited to structs exposed to WinRT, and it does not apply to classes.

    UI Programming

    When it comes to your UI selection, you can either use HTML with CSS to style your app or you can use XAML UI.

    To make it easy for HTML apps to adhere to the Metro UI style and interaction model, Microsoft distributes Javascript and CSS files that you can consume from your project. Notice that this wont work on the public web. As soon as you use any WinRT APIs, your application is a Windows app, and wont run in a standalone web browser.

    .NET and C++ developers get to use XAML instead.

    There is clearly a gap to be filled in the story. It should be possible to use Microsoft's Razor formatting engine to style applications using HTML/CSS while using C#. Specially since they have shown the CLR running on their HTML/JS Metro engine.

    Right now HTML and CSS is limited to the Javascript use.

    In Short

    Microsoft has created a cool new UI library called WinRT and they have made it easy to consume from .NET, Javascript and C++ and if you adhere by their guidelines, they will publish the app on their appstore.

    Xamarin at BUILD

    If you are at build, come join us tonight at 6:30 at the Sheraton Park hotel, just after Meet the Experts. Come talk about Mono, Xamarin, MonoTouch, MonoDroid and MonoMac and discuss the finer points of this blog over an open bar.


    There is a long list of comments in the moderation queue that are not directly related to WinRT, or bigger questions that are not directly related to WinRT, .NET and this post's topic, so I wont be approving those comments to keep things on focus. There are better forums to have discussions on Metro.

  • Posted on 15 Sep 2011

    Xamarin and Mono at the BUILD Conference

    by Miguel de Icaza

    Continuing our tradition of getting together with Mono users at Microsoft conferences, we are going to be hosting an event at the Sheraton Hotel next to the conference on Thursday at 6:30pm (just after Ask the Experts).

    Come join us with your iOS, Android, Mac and Linux questions.

    Posted on 14 Sep 2011

    MonoDevelop 2.6 is out

    by Miguel de Icaza

    Lluis just released the final version of MonoDevelop 2.6.

    This release packs a lot of new features, some of my favorite features in this release are:

    • Git support.
      • It not only provides the regular source code control commands, it adds full support for the various Git idioms not available in our Subversion addin.
      • Based on Java's JGit engine
      • Ported to C# using db4Object's sharpen tool. Which Lluis updated significantly
      • Logging and Blaming are built into the editor.
    • Mac support:
      • Our fancy MonoMac support lets you build native Cocoa applications. If you have not jumped into this Steve Jobs Love Fest, you can get started with our built-in templates and our online API documentation.
      • Native File Dialogs! We now use the operating system file dialogs, and we even used our own MonoMac bindings to get this done.
      • You can also check my Mac/iOS-specific blog for more details.
    • Unified editor for Gtk#, ASP.NET, MonoTouch and MonoDroid: we no longer have to track various forks of MonoDevelop, they have all converged into one tree.

    The above is just a taste of the new features in MonoDevelop 2.6. There are many more nominate your own!

    Congratulations to the MonoDevelop team on the great job they did!

    And I want to thank everyone that contributed code to MonoDevelop, directly or indirectly to make this happen.

    Posted on 07 Sep 2011

    Learning Unix

    by Miguel de Icaza

    As I meet new Unix hackers using Linux or Mac, sometimes I am surprised at how few Unix tricks they know. It is sometimes painful to watch developers perform manual tasks on the shell.

    What follows are my recommendations on how to improve your Unix skills, with a little introduction as to why you should get each book. I have linked to each one of those books with my Amazon afiliates link, so feel free to click on those links liberally.

    Here is the list of books that programmers using Unix should read. It will only take you a couple of days to read them, but you will easily increase your productivity by a whole order of magnitude.

    The Basics

    The Unix Programming Environment by Kernighan and Pike is a must-read. Although this is a very old book and it does not cover the fancy new features in modern versions of Unix, no other book covers in such beauty the explanation of the shell quoting rules, expansion rules, shell functions and the redirection rules.

    Every single thing you do in Unix will use the above in some form or shape, and until you commit those to memory you will be a tourist, and not a resident.

    Then you will learn sed and basic awk, both tools that you will use on a daily basis once you become proficient. You do not have to ever be scared of sed or regular expressions anymore.

    Save yourself the embarrassment, and avoid posting on the comments section jwz's quote on regular expressions. You are not jwz.

    It will take you about a week of commuting by bus to read it. You do not have to finish the book, you can skip over the second part.

    Unix Boot Camp

    While Kernighan's book is basic literacy, you need to develop your muscles and you need to do this fast and not buy a book so thick and so packed with ridiculous screenshots that you will never get past page 20.

    Get UNIX for the Impatient. This book is fun, compact and is packed with goodies that will make you enjoy every minute in Unix.

    Learn Emacs

    Emacs has had a strong influence in Unix over the years. If you learn to use Emacs, you will automatically learn the hotkeys and keybindings in hundreds of applications in Unix.

    The best place to learn Emacs is to launch Emacs and then press Control-h and then t. This is the online tutorial and it will take you about two hours to complete.

    The knowledge that you will gain from Emacs will be useful for years to come. You will thank me. And you will offer to buy me a beer, which I will refuse because I rather have you buy me a freshly squeezed orange juice.

    Tooting my own horn

    Learn to use the Midnight Commander.

    The Midnight Commander blends the best of both worlds: GUI-esque file management with full access to the Unix console.

    The Midnight Commander is a console application that shows 2 panels listing two different directories side-by-side and provides a command line that is fed directly to the Unix shell.

    The basics are simple: use the arrow keys to move around, Control-S to do incremental searches over filenames, Control-t to tag or untag files and the F keys to perform copy, move or delete operations. Copy and Move default to copy to the other panel (which you can conveniently switch to by pressing the tab key).

    There is no better way of keeping your file system organized than using my file manager.

    Becoming a Power User

    If you can not quench your thirst for knowledge there is one last book that I will recommend. This is the atomic bomb of Unix knowledge.

    Unix Power Tools is a compilation of tricks by some of the best Unix users that got compiled into a huge volume. This is a book of individual tricks, each about a page long, ideal to keep either on your bedside or in the restoom to pick a new trick every day.

    Mavis Beacon

    At this point you might be thinking "I am awesome", "the world is my oyster" and "Avatar 3D was not such a bad movie".

    But unless you touch-type, you are neither awesome, nor you are in a position to judge the qualities of the world as an oyster or any James Cameron movies.

    You have to face the fact that not only you are a slow typist, you do look a little bit ridiculous. You are typing with two maybe three fingers on each hand and you move your head like a chicken as you alternate looking at your keyboard and looking at your screen.

    Do humanity a favor and learn to touch type.

    You can learn to touch type in about three weeks if you spend some two to three hours per day using Mavis Beacon Teaches Typing.

    Mavis Beacon costs seventeen dollars ($17). Those seventeen dollars and the sixty three hours you will spend using it will do more to advance your carreer than the same sixty three hours spend reading editorials on Hacker News.


    All of the books I list here have stood the test of time. They were written at a time when books were designed to last a lifetime.

    Unlike most modern computer books, all of these were a pleasure to read.

    Posted on 06 Sep 2011

    And we are back: Mono 2.10.3

    by Miguel de Icaza

    This is Xamarin's first official Mono release.

    This is a major bug fix release that addresses many of the problems that were reported since our last release back on April 25th.

    The detailed release notes have all the details, but the highlights of this release include:

    • MacOS X Lion is supported: both the Mono runtime and Gtk+ as shipped with Mono have been updated to run properly on Lion. This solves the known problems that users had running MonoDevelop on MacOS X.
    • Vastly improved WCF stack
    • Many bug fixes to our precise garbage collector.

    Major features continue to be developed in the main branch. Currently we are just waiting for the C# 5.0 Asynchronous Language support to be completed to release that version.

    Mono 2.10.3 also serves as the foundation for the upcoming Mono for Android 1.0.3 and MonoTouch 4.1.

    You can get it from Mono's Download Site.

    Currently we offer source code, Windows and MacOS packages. We will publish Linux packages as soon as we are done mirroring the contents of the old site that contains the Linux repositories.

    On C# 5.0

    Our new compiler, as you might know, has been rewritten to support two backends: a System.Reflection.Emit backend, and the brilliant IKVM.Reflection backend.

    The C# 5.0 support as found on master contains the C# 5.0 support as shipped by Microsoft on their latest public release.

    To try it out, use -langversion:future when invoking the compiler. You can try some of our samples in mono/mcs/tests/test-async*.cs

    Posted on 04 Aug 2011

    MonoDevelop on Lion

    by Miguel de Icaza

    We here at Xamarin are as excited as you are about the release of Lion. But unfortunately we're not quite ready to support you on Lion yet, and MonoDevelop doesn't work quite right. We're working around the clock to make MonoDevelop work perfectly on Lion, and we'll let you know as soon as it's ready.

    Update on July 29th: We have most of the fixes in place for Mono and will issue a build for testing on the Alpha channel soon.

    Posted on 20 Jul 2011

    Novell/Xamarin Partnership around Mono

    by Miguel de Icaza

    I have great news to share with the Mono community.

    Today together with SUSE, an Attachmate Business Unit, we announced:

    • Xamarin will be providing the support for all of the existing MonoTouch, Mono for Android and Mono for Visual Studio customers.
    • Existing and future SUSE customers that use the Mono Enterprise products on their SLES and SLED systems will continue to receive great support backed by the engineering team at Xamarin.
    • Xamarin obtained a perpetual license to all the intellectual property of Mono, MonoTouch, Mono for Android, Mono for Visual Studio and will continue updating and selling those products.
    • Starting today, developers will be able to purchase MonoTouch and Mono for Android from the Xamarin store. Existing customers will be able to purchase upgrades.
    • Xamarin will be taking over the stewardship of the Mono open source community project. This includes the larger Mono ecosystem of applications that you are familiar with including MonoDevelop and the other Mono-centric in the Mono Organization at GitHub.

    We are a young company, but we are completely dedicated to these mobile products and we can not wait to bring smiles to every one of our customers.


    Our immediate plans for both MonoTouch and Mono for Android is to make sure that your critical and major bugs are fixed. We have been listening to the needs of the community and we are working to improve these products to meet your needs. You can expect updates to the products in the next week.

    In the past couple of months, we have met with some of our users and we have learned a lot about what you wanted. We incorporated your feature requests into our products roadmaps for both the MonoTouch and the Mono for Android products.

    Another thing we learned is that many companies need to have a priority support offering for this class of products, so we have introduced this. It can be either be purchased when you first order MonoTouch or Mono for Android, or you get an upgrade to get the priority support.

    Next Steps

    Our goals are to delight software developers by giving them the most enjoyable environment, languages and tools to build mobile applications.

    We are thankful to everyone that provided feedback to us in our online form that we published a month ago. Please keep your feedback coming, you can reach us at [email protected]. We are reading every email that you send us and you can use my new miguel at new company dot com email address to reach me.

    We will be at the Monospace conference this weekend at the Microsoft NERD Center, hope to see you there!

    Remember to purchase early and often so we have the resources to bring you the best developer tools on the planet.

    Posted on 18 Jul 2011

    Update on Mono

    by Miguel de Icaza

    I have a posted an update on Mono and the upcoming release of Mono 2.12.

    Posted on 06 Jul 2011

    Mono Consultants

    by Miguel de Icaza

    We are getting flooded with paid support requests for Mono. Developers looking for us to fix bugs in Mono, to do some custom work, to port applications, libraries and adjust Mono for some specific needs.

    But we are trying to be a product company as opposed to a support company.

    We still want to help the Mono user community, and with all of the Mono talent out there, at least we can use this opportunity to get both groups in touch: the users that want custom engineering done, with the talented list of hackers.

    If you are a consultant available to do custom engineering and support for customers, we would love to put you in touch with people that need the custom engineering done. Email us at [email protected], in the subject line, specify that you are available for custom engineering, and in the body of the message list both your Mono skills (C# or C coding) and your availability to engage on those gigs.

    We will then get you in touch with users that needs the work done.

    Posted on 30 Jun 2011

    Xamarin Joy Factory

    by Miguel de Icaza

    Setting up a new company consumes a lot of time. Specially as we are developing as fast as we can not one, but two products: .NET for iPhone and .NET for Android.

    Structurally, we are better off than we were the first time that we built these products. We have more developers working on each product than we did the first time around, so progress is faster. But we also had to swap the developers around: those that wrote Foo, can not work on Foo again. This is just one of the things that we have to do to ensure a clean room implementation.

    Our vision is to create happy developers. We did that in the past by bringing the C# language, garbage collection, LINQ, strongly typed APIs, Parallel FX, intellisense and inline documentation to iPhone and Android developers. And by making it possible for the world's 6 million .NET developers to reuse their skills on the most popular mobile platforms.

    This time around, we are doing even more. We are addressing many of the frustrations that developers had with the old products and making sure that those frustrations go away.

    Nat and myself complement each other very well here. This means that there are a lot of new things that will be present in our offering that we never did in the past.

    There is a new level of polish that those familiar with Nat's previous products had (SUSE Studio, NLD/SLED, Ximian Desktop). Everyone at Xamarin can feel that Nat is hard at work when they noticed that one of the first things Nat did was to engage six design firms and an army of technical writers to ensure that our products go from "Nice" to "Amazing". And that was on his second week as CEO, a lot has happened since.

    I do not want to give away everything that we are doing, it would ruin the surprise, but we are here to deliver joy to programmers everywhere.

    If you are interested in working with us, and making mobile development and .NET development a joy that everyone can enjoy, check out our Jobs page

    Where we are now

    It gives me great pleasure to say that we have elevated the discourse on the iPhone simulator and my Chicken-powered TweetStation is up and running with the new iOS product. The picture on the left is TweetStation powered by MonoTouch, the picture on the right is TweetStation powered by Xamarin's iPhone product:

    TweetStation on MonoTouch

    TweetStation on Xamarin iOS

    Update: TweetStation now starts up on Device! We have the static compiler working!

    We also have the delicious iOS5 APIs exposed as strongly-typed and intellisense-friendly C#. We are now updating the APIs from Beta1 to Beta2, which should be completed today or tomorrow.

    Our Android efforts are moving fast. Only this morning we got Layouts to render on the device. This is a lot of work, as it gets Dalvik to start Mono, and initializes our entire bridge and exercises the C# and Java bridge. In addition, we have identified and fixed a serious problem in the distributed garbage collector.

    We also have a number of surprises for everyone in MonoDevelop, we believe that you guys are going to love the new features for iPhone and Android development.

    There is still a lot of polish left to do. We are working as hard as we can to have Preview releases in your hands, but we feel confident that we will have a great product for sale by the end of the summer. We hope you will all max out your credit cards buying it.

    Posted on 28 Jun 2011

    Xamarin recruits best CEO in the Industry

    by Miguel de Icaza

    I could not be more excited about this.

    Nat Friedman has joined Xamarin as a company founder and CEO this week.

    Nat and I have known each other and worked together on and off since the early days of Linux. In 1999, we started Ximian to advance the state of Linux, user experience and developer platforms - with many of our efforts brought to fruition after our acquisition by Novell in 2003.

    Anyone that has had the pleasure to work with Nat knows that ideas come in one side, and objects of desire come out on the other end.

    In mobile development, we've discovered a great opportunity: a need for products that developers love. And we are going to fill this need with great products that will make everyone's eyes shine every time they use our software.

    Update: Nat's most recent product was SUSE Studio.

    Posted on 25 May 2011

    Announcing Xamarin

    by Miguel de Icaza

    Today we start Xamarin, our new company focused on Mono-based products.

    These are some of the things that we will be doing at Xamarin:

    • Build a new commercial .NET offering for iOS
    • Build a new commercial .NET offering for Android
    • Continue to contribute, maintain and develop the open source Mono and Moonlight components.
    • Explore the Moonlight opportunities in the mobile space and the Mac appstore.

    We believe strongly in splitting the presentation layer from the business logic in your application and supporting both your backend needs with C# on the server, the client or mobile devices and giving you the tools to use .NET languages in every desktop and mobile client.

    Development started early this morning, we will first deliver the iPhone stack, followed by the Android stack, and then the Moonlight ports to both platforms.

    The new versions of .NET for the iPhone and Android will be source compatible with MonoTouch and Mono for Android. Like those versions, they will be commercial products, built on top of the open core Mono.

    In addition, we are going to provide support and custom development of Mono. A company that provides International Mono Support, if you will.

    As usual, your feedback will help us determine which platforms and features are important to you. Help us by filling out our survey. If you give us your email address, we will also add you to our preview/beta list for our upcoming products.

    Fighting for Your Right to Party

    We have been trying to spin Mono off from Novell for more than a year now. Everyone agreed that Mono would have a brighter future as an independent company, so a plan was prepared last year.

    To make a long story short, the plan to spin off was not executed. Instead on Monday May 2nd, the Canadian and American teams were laid off; Europe, Brazil and Japan followed a few days later. These layoffs included all the MonoTouch and MonoDroid engineers and other key Mono developers. Although Attachmate allowed us to go home that day, we opted to provide technical support to our users until our last day at Novell, which was Friday last week.

    We were clearly bummed out by this development, and had no desire to quit, especially with all the great progress in this last year. So, with a heavy dose of motivation from my music teacher, we hatched a plan.

    Now, two weeks later, we have a plan in place, which includes both angel funding for keeping the team together, as well as a couple of engineering contracts that will help us stay together as a team while we ship our revenue generating products.

    Update: although there was a plan to get Angel funding, it turns out that we self-funded the whole thing in the end.

    Next Steps

    Our plan is to maximize the pleasure that developers derive from using Mono and .NET languages on their favorite platforms.

    We do have some funding to get started and ship our initial products. But we are looking to raise more capital to address the shortcomings that we could not afford to do before, these include:

    • Tutorials for our various developer stacks
    • API documentation for the various Mono-specific APIs
    • Dedicated Customer Support Software (assistly or getsatisfaction)
    • Upgrade our Bug system
    • Training
    • Consulting and Support
    • and Marketing: we have a best of breed developer platform, and we need the world to know. Our previous marketing budget is what the ancient Olmec culture referred to as Zero.

    Stay tuned for more, meanwhile, hope to see you in July at the Monospace conference in Boston!

    Posted on 16 May 2011

    Dropbox Lack of Security

    by Miguel de Icaza

    I am a fan of Dropbox. It is a great tool, a great product, and clearly they have a passionate team over at Dropbox building the product.

    Dropbox recently announced an update to its security terms of service in which they announced that they would provide the government with your decrypted files if requested to do so.

    This is not my problem with Dropbox.

    My problem is that for as long as I have tried to figure out, Dropbox made some bold claims about how your files were encrypted and how nobody had access to them, with statements like:

    • All transmission of file data occurs over an encrypted channel (SSL).
    • All files stored on Dropbox servers are encrypted (AES-256)
    • Dropbox employees aren't able to access user files, and when troubleshooting an account they only have access to file metadata (filenames, file sizes, etc., not the file contents)

    But anyone that tried to look further came out empty handed. There really are no more details on what procedures Dropbox has in place or how they implement the crypto to prevent unauthorized access to your files. We all had to just take them at their word.

    This wishy-washy statement always made me felt uneasy.

    But this announcement that they are able to decrypt the files on behalf of the government contradicts their prior public statements. They claim that Dropbox employees aren't able to access user files.

    This announcement means that Dropbox never had any mechanism to prevent employees from accessing your files, and it means that Dropbox never had the crypto smarts to ensure the privacy of your files and never had the smarts to only decrypt the files for you. It turns out, they keep their keys on their servers, and anyone with clearance at Dropbox or anyone that manages to hack into their servers would be able to get access to your files.

    If companies with a very strict set of security policies and procedures like Google have had problems with employees that abused their privileges, one has to wonder what can happen at a startup like Dropbox where the security perimeter and the policies are likely going to be orders of magnitude laxer.

    Dropbox needs to come clear about what privacy do they actually offer in their product. Not only from the government, but from their own employees that could be bribed, blackmailed, making some money on the side or are just plain horny.

    Dropbox needs to recruit a neutral third-party to vouch for their security procedures and their security stack that surrounds users' files and privacy. If they are not up to their own marketed statements, they need to clearly specify where their service falls short and what are the potential security breaches that

    Unless Dropbox can prove that algorithmically they can protect your keys and only you can get access to your files, they need to revisit their public statements and explicitly state that Dropbox storage should be considered semi-public and not try to sell us snake oil.

    Posted on 19 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

    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

    MVP Summit and GDC 2011

    by Miguel de Icaza

    Next week I will be in Bellevue, WA from Sunday to Wednesday to participate in the 2011 Microsoft MVP Summit.

    From Wednesday to Friday I will be San Francisco attending the Game Developer's Conference.

    Ping me if you want to get together.

    Posted on 25 Feb 2011

    C# Compiler as a Service Update

    by Miguel de Icaza

    Our C# compiler-as-a-service library can now process any C# construct, it is no longer limited to expressions and statements.

    This means, that you can now enter entire class definitions in the command line:

    csharp> class Demo {
          >     public int Add (int a, int b)
          >     {
          >          return a + b;
          >     }
          > }
    csharp> new Demo ().Add (1, 3);

    This work was done by the amazing Marek and is now available on Mono's master branch in github.

    This functionality can also be used for scripts, in particular in Unix, you can now create C# "source executable" files, like this:

    bash$ cat demo.cs
    class Demo {
    	public dynamic Add (dynamic a, dynamic b)
    		return a + b;
    Console.WriteLine (new Demo ().Add ("this is", " cute"));
    bash$ chmod +x demo.cs
    bash$ ./demo.cs
    this is cute

    Multiple Compiler Instances

    In addition, we turned the static API Evalutor.Eval (string expression), into an instance API. The instance API allows developers that are embedding the C# compiler-as-a-service in their application to have different contexts.

    This required the entire compiler to be updated from being a giant set of static classes that could safely use global variables and state into a state that was properly encapsulated.

    The API is now richer, we provide a way to configure the compiler settings using a settings class. This can be populated either manually, or by using the build-in command-line parser for compiler options. The following sample shows how this could be used:

    using Mono.CSharp;
    using System;
    class Runner {
    	static int Main (string [] args)
    		var r = new Report (new ConsoleReportPrinter ());
    		var cmd = new CommandLineParser (r);
    		var settings = cmd.ParseArguments (args);
    		if (settings == null || r.Errors > 0)
    			Environment.Exit (1);
    		var evaluator = new Evaluator (settings, r);
    		evaluator.Run ("class Demo { public static int Add (int a, int b) { return a+b; }}");
    		evaluator.Run ("print (Demo.Add (1,2));");
    		return 0;

    Testers Wanted

    This revamped compiler will be part of Mono 2.12, but we would love to get users to test the new functionality and to help us identify any problems early on, before we even release this code.

    We do provide a convenient sln file that you can use the compiler as a service, and it works both in Visual Studio/.NET and Mono.


    We have not tested this with Silverlight, but in theory, it should now work fine with it. We would love to see someone build an interactive shell like the one we did with Gtk# but hosted on the browser:

    Posted on 24 Feb 2011

    Well, Actually

    by Miguel de Icaza

    Why you are not getting laid

    As software developers, we develop habits that allow us to build products that work and do not fail under stress. Every software developer knows what an "off-by-one" error is, and like the Karate Kid, we train extensively so we can avoid those traps. We learn how to avoid these and other similar software problems and we sharpen our skills to find logic errors.

    As we mature as developers, finding logic errors and incomplete solutions becomes our way of life. It defines us.

    But our engineering strength is also our social weakness. Countless times as engineers you will find yourself interrupting someone telling a story, an anecdote or a joke to correct a false assumption, provide an extra fact that the narrator overlooked, give a bigger perspective on the problem or point out that the joke premise is actually flawed.

    You can identify this behavior because the person interrupting usually starts with the phrase "Well, actually...".

    As a kid, I thought this was my strength. I knew a little bit more than my sister. So whenever she would say something, I would quickly interject something like "Well, actually, the origin of the word Shih Tzu means Lion Dog and has nothing to do with the dog's digestive patterns".

    Yes, I was really fun to hang out with.

    As a child, I wondered why my sister could make friends and keep them so easily, while I could not. It would take me years to discover this. And now, as a public service I am sharing with you, my fellow geek friends, what I learned.

    Whoever pulls a "well, actually" almost always shifts the conversation to himself. And now we are no longer following along with your friend's joke, we get to learn how much more you know about the limitations of the Sun Protection Factor scale in sunblock products.

    You are doing it wrong

    As a seasoned engineer, you need to learn control your impulses. Having dealt with my own well, actually problem, I can attest that adjusting this social behavior might even get you laid.

    Jokes are funny because they surprise us. But a joke is not funny if you have to present a 30-page document setting up every little detail. An ill-placed "Well, actually" will get your colleagues to abandon in an instant the water cooler conversation and escape to the peaceful solitude of their workstations.

    Range of Action

    You can find full-time well-actually folks both in person or monitoring your every quip on twitter.

    Even the most rudimentary of the well-actuallistas is able to spoil even the best Ricky Gervais material.

    Twitter being a medium limited to 140 character is like catnip for patronizing douchebags. They can not resist the urge to point out logic flaws in your minimalist observation.

    This is particularly a problem for those of us that love to tweet things that amuse us or that we find amusing. Fear of a barrage of factoids from an omitted detail can be paralyzing.

    Dealing with the Well Actually crowd

    The well-actually crowd wants as much as everyone else to participate in the conversation. They want to be loved.

    But instead of rolling with the punches and participating in a brainstorm of ideas and exploding humor, they contribute interruptions, facts and details that merely produce stop energy on an ongoing discussion. They turn the center of attention towards them.

    The well-actually crowd means well. They want to be loved, they just have not realized that they are undermining their own quest for friends.

    If you are a sagacious well-actuallista you need to understand that you are not outwitting anyone. It takes more intelligence to build a joke, tell a funny anecdote or narrate a gripping story than it takes to nitpick.

    You are not impressing anyone with your hard earned encyclopedic knowledge that you obtained by spending hours on the Internet. You are just making everyone around you realize that you are as much fun to have lunch with as a flaming turd in a bag.

    Those of us in the receiving end of a well-actually, need to start an awareness campaign. Perhaps using Twibbons to cure this disease. Unlike many diseases, this awareness program will lead to a cure.

    While being technically correct is the best kind of correct, what you don't realize is that while you enjoy the triumph of your well-actually, everyone around you is secretly hoping that you choke on a bucket of cocks.

    Practical Solutions

    In the office, we have lots of talented engineers and at one point or another one of us will interject a well placed "well, actually" at an innapropriate moment.

    These days we are fully aware of this social disease and we strive to avoid it. When someone interrupts a discussion with a well-actually you can hear someone say:

    "Did you just well-actually me?"

    Which is basically a way of saying "That has nothing to do with the topic, but thanks for derailing us" without having to go into the explanation and getting lost on the tangent.

    This is a good first step. In our case, we have printed copies of the Ok, It's Time To Explain Some Stuff Patronizing Douchebag Trollcat in two sizes: a full-size well-actually cat, and a small one that is given as an award to the douchiest interruption:

    Okay it’s time to explain some stuff patronizing douchebag trollcat

    On the Internet, you can try to point the patronizing douchebag to this blog post. Or if you have no patience, just click "block" on twitter.

    Posted on 17 Feb 2011

    Moonlight 4 Preview 1 is out

    by Miguel de Icaza

    Yesterday we released Moonlight 4, Preview 1.

    This release of Moonlight completes the Moonlight 3 feature set and includes many features from Silverlight 4. Check out our release notes for the list of things that are currently missing from our Silverlight 4 support.


    Moonlight rendering system uses a painter's algorithm coupled with culling to reduce the amount of rasterization that needs to take place.

    For example, if we had these objects all rendered at the same location, on top of each other:

    A simple implementation would render the triangle, then the rectangle and then the circle, and we would get this result:

    Moonlight optimizes this rendering by computing the bounding boxes of each element and determining which objects are completely obscured. In this case, the triangle never needs to be rendered as it is fully covered.

    Since we have the entire graph scene in memory, we can push all the rendering to the X server without ever having to pull data back from it.

    Each visible element on Silverlight derives from the class UIElement and Moonlight tracks the bounding box for all of each individual element. As you compose elements, the aggregate bounding box is computed. For example, a canvas that hosts these three UIElements would have a bounding box that contains all three of them:

    New Rendering Features

    With Silverlight 3, Microsoft introduced two large important changes to the framework: 3D transformations on objects and support for pixel shaders. Both of these are applied to every visual element in Silverlight (this is implemented in the class UIElement).

    In addition to the properties inherited from Silverlight 2, UIElements now have two new properties: Projection and Effect.

    The Projection property is a 3D matrix transformation (the 3D variation of the 2D affine transform that is available in most 2D graphics APIs). Silverlight exposes both the raw 3D matrix or a set of convenient properties that are easier to use and require no understanding of the interactions of the twelve elements of the 3D matrix (see this page for an explanation).

    Just like 2D affine APIs typically expose convenience methods to scale, rotate, skew and translate, the PlaneProjection properties allow developers to focus on those components.

    You can see a sample here.

    Effects follow a similar pattern. The blur and drop-shadow effects are given convenient names and accessors (BlurEffect and DropShadowEffect but Silverlight exposes an API to create programmable pixel shaders that go beyond these two simple cases.

    The ShaderEffect allows users to load pixel shaders written using the High Level Shader Language (HLSL). Here is a sample app showing pixel shaders in action.

    3D transformations and pixel shaders require that the contents of a UIElement are rendered to an intermediate output surface. The 3D transformation and shader effect is applied when this surface is composited onto the parent output surface. This compositing operation can be accelerated using graphics hardware.

    From our previous example, the three elements would be rendered into a 2D surface, and the actual transformation can be done in the hardware:

    Finally, the third new rendering upgrade was the introduction of a bitmap cache that can be applied to a UIElement. When a UIElement is flagged for being bitmap cached, the same kind of intermediate surface rendering and hardware accelerated compositing is performed as for elements with 3D transformations or pixel shaders. The contents of bitmap cache elements are also rendered once and kept on a bitmap that is later composited. This can improve performance vastly for complex controls with many interlocking pieces: instead of computing and re-rendering the entire contents every time, the bitmap cache is used.

    This of course has some visible effect. If you instruct Silverlight to use a bitmap cache, and then you zoom-in the contents, you will see the result get pixelated. You can learn more about this on the BitmapCache documentation.

    Moonlight's New Rendering Pipeline and GPU Acceleration

    Both effects and projections can be implemented purely in software. Effects can be implemented by providing a small interpreter for HLSL code and projections by performing the rendering in software and compositing the results.

    David Reveman, the hacker behind Compiz joined the Moonlight team last year to implement the new rendering primitives, but also to figure out how we could hardware accelerate Moonlight. The results of his work are available on yesterday's release of Moonlight 4.

    The rendering pipeline was modified. Now, whenever a UIElement has either a Projection, an Effect or has the the flag BitmapCache set the entire UIElement and its children are rendered into a surface that is then off-loaded for the GPU to render.

    When OpenGL is available on the system, the composition of UIElements is entirely done by the GPU.

    Moonlight will use the GPU to accelerate for compositing, perspective transformations and pixel shaders if the hardware is present without having to turn this on. Silverlight by default requires developers to opt into hardware acceleration and has its own set of features that it will hardware accelerate.

    In general, Moonlight uses the GPU more than Silverlight does, except in the case of DeepZoom, where we still do not accelerate this code path.


    Our new rendering pipeline is built using OpenGL and Gallium3D.

    Gallium is an engine that is typically used to implement OpenGL. In our case, we use the Gallium3D API when we need to fallback to software rendering 3D transforms on Linux. Otherwise we go through the OpenGL pipeline:

    If we were to only support Linux/X11, Gallium3D would have been a better choice for us. But we want to allow the Moonlight runtime to be ported to other windowing systems (Like Wayland on Linux) and other operating systems.

    Room for Growth

    Now that we have this 3D accelerated platform in place, it is easy to fine-tune specific UIElements to be hardware accelerated.

    This first release did only the basics, but we can now trivially use hardware decoders for video and have that directly composited in hardware with the rest of a scene, or we can offload image transformations entirely to the hardware on a type-by-type basis and of course, DeepZoom.

    Object Lifecycle

    Objects in moonlight live in two spaces, low-level components live in C++ and are surfaced to C#. Typically this means that we have code that looks like this in C++:

    	class MyElement : public UIElement {
    		MyElement ();
    	        // fields and methods for MyElement go here

    In C# we create a mirror, like this:

    	public class DependencyObject {
    		// Points to the C++ instance.
    		IntPtr _native;

    When a user wrote in C# "new MyElement", we would P/Invoke into C++ code that does "new MyElement", get a pointer back to this instance and store it in the "_native" field.

    In the other direction, if we created a C++ object and then we had to "surface" it to the managed world, we would initialize the object based on our C++ "this" pointer.

    We could create instances of MyElement in C++, and when this instance needs to be surfaces to the managed world, we would create an instance of the managed object, and store the pointer to the underlying C++ object in the _native pointer.

    In the Moonlight 2.0 days we used to have C++ objects that would only create managed objects on demand. At the time, we did this to avoid creating thousands of managed objects when loading a XAML file when only a handful of those would be controlled by user code.

    The Moonlight runtime, running in pure C++ code, surfaced objects to the C# world and we tracked the object life cycle with good old reference counts. But with Silverlight 2, we started to see problems with the design as it was possible to end up with cycles. These cycles did not happen only in the C++ side or the C# side, but they spanned the boundaries. This made it very hard to debug and it made it hard to keep Moonlight from not leaking memory.

    Templates for example could create these cycles.

    With Moonlight 4, we have landed a new life cycle management system that works like this:

    • Every C++ object that we create always points to a managed counterpart. Gone are the days where the managed peer was created only when needed.
    • Every C++ instance field that points to a DependencyObject subclass goes through this cool C++ templated class that notifies managed when the reference changes.
    • There are no ref/unref pairs surrounding stores to instance fields in c++ anymore.

    Now our base class in C++ has this:

    	// Our entire hierarchy exposed to managed code
    	// derives from EventObject
    	class EventObject {
            	GCHandle managed_handle;

    Now all the c++ objects exist and are kept alive solely by their managed peers (there are some rare exceptions for things like async calls) and the whole graph is traversable by Mono's GC because all stores to c++ instance fields result in a managed ref between the respective peers.

    With the new code, we no longer live in a world of refs/unrefs (again, except for some rare cases) and whenever we assign to a C++ field that points to a managed object we notify the managed peer of the change.

    We were not able to ship Moonlight 4 with our new garbage collection system (Sgen) as we ran into a couple of hard to track down bugs at the last minute, but we are going to switch it on again soon.

    Future Work

    There is still room for improvement, and now that we know how to cook this kind of code, the goal is to use Mono's new GC in Moonlight more extensively.

    We want to teach SGen to scan the C++ heap and track references to managed objects, dropping another potential source of problems and reducing the code needed. We would also love to go back to only creating managed objects on demand.

    Platform Abstraction Layer

    Moonlight was originally designed as a Linux-only, X11-only plugin for rendering Silverlight content. Developers constantly ask us whether they could run Moonlight on platform XX that is either not Linux or does not use X11.

    The amount of work to port Moonlight 2 to those kinds of scenarios was so overwhelming that most people abandoned the efforts relatively quickly.

    With Moonlight 4, we have introduced a new platform abstraction layer that will make it simpler for developers to port the Moonlight engine to other platforms.

    Whether you want hardware accelerated user experiences in your video game or you want to put Moonlight on a the FreezeMaster 10000 Domestic Fridge with an Internet Connection and SmoothStreaming running on a barebones ARM CPU, you can now enjoy this in the comfort of your home.

    We have done some minimal tests to exercise the API and can run the Moonlight engine on both MacOS and Android. You can look at exclusive footage of the animation test suite running on OSX and on Android.

    If you are like me, not much of a click-on-the-video kind of person, and would rather get a screenshot, you can bask on the smooth colors of this screenshot on Android or in this delightful test on MacOS.

    We are currently not planning on completing that work ourselves, so this is a fabulous opportunity for a caffeine-driven hacker to complete these ports.

    Some possibilities, from the top of my head include being able to use Silverlight to design parts of your user experience for apps on the Mac AppStore (think MoonlightView in your MonoMac apps), or for your Android app.

    Using Expression beats coding cute animations and futuristic UIs by hand. That is why every major video game embeds ScaleForm, the embeddable Flash runtime for handling the UI.

    New XAML Parser

    Our original XAML parser was written in C++, this worked fine for Moonlight 1, but with Moonlight 2 it started to become obvious that we were spending too much time calling back from C++ to C# to create managed objects.

    This was acceptable up to version 2, but it no longer scaled with Moonlight 3. Too much time was spent going back and forth between the C++ world and the C# world. Those following the development of Moonlight would have noticed that every couple of weeks a new extra parameter to the xaml_load function was added to deal with yet another callback.

    The new XAML parser is entirely written in C#, is faster and more reliable.

    And lots more

    Check out our release notes for Moonlight 4 Preview 1.

    Posted on 16 Feb 2011

    Three Months and Ten Days

    by Miguel de Icaza

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

    New in this release:

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

    Posted on 16 Feb 2011

    Nokia Simplifies the Mobile Landscape

    by Miguel de Icaza

    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.

    Posted on 14 Feb 2011

    On Reflector

    by Miguel de Icaza

    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.

    Posted on 04 Feb 2011

    Adult Principles, from JPBarlow

    by Miguel de Icaza

    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.

    Posted on 21 Jan 2011

    Help us test Mono 2.10

    by Miguel de Icaza

    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:

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

    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:

    Posted on 19 Jan 2011

    Your Own Sandbox

    by Miguel de Icaza

    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.

    Posted on 13 Jan 2011

    Mono at CES: More Games

    by Miguel de Icaza

    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.

    Posted on 06 Jan 2011

    Mono for Android

    by Miguel de Icaza

    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.

    Posted on 04 Jan 2011

    Open Source Contribution Etiquette

    by Miguel de Icaza

    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.

    Posted on 31 Dec 2010

    For your OOXML Conspiracy Theories

    by Miguel de Icaza

    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.

    Posted on 21 Dec 2010


    by Miguel de Icaza

    Tomorrow we are flying to Porto Alegre in Brazil to spend two weeks in a nice, warm climate tasting delicious foods and hanging out with good friends.

    If you are a Porto Alegre-based Linux-ista, Mono-ista, Android-ista, MacOS-hacker-ista, .NET-ista, C#-ista, or, iPhonista and would like to get together for coffee, lunch or dinner, drop me an email.

    Posted on 16 Dec 2010

    MonoReports: Report Designer and Reporting Engine

    by Miguel de Icaza

    This is quite cool, Tomasz Kubacki has released a report engine and designer that runs on Mono:

    MonoReports has a nice Gtk# based GUI designer that runs on Linux, Mac and Windows and can generate reports that you can later run GUI-less.

    From Tomasz announcement:

    • Simple layouting - if control in section is growable and will grow due to assigned data, engine will do layouting to make report look properly
    • Page breaking - Monoreports engine will break or keep together report sections whatever is needed
    • Generating and running reports from designer and code.
    • PDF export
    • Reporting engine is not tightly coupled with gtk/cairo stuff, therefore it's reasonably easy to write new export backends (e.g. html, or xls for example).

    He also made a six minute video walkthrough of MonoReports's features.

    Posted on 09 Dec 2010

    Mono: What we are Cooking

    by Miguel de Icaza

    Although everything we do is public in some form or another, folks that are not keeping track of things might be wondering what the Mono team at Novell has been up to.

    Here are some of the projects that we have been working on, and that we expect to release in the next three months, some sooner, some later. You are welcome to join us in testing, all you need is to get comfortable building Mono from git.

    Bundling F#, IronPython, IronRuby and UnityScript: Now that all of these languages are open source, we want more people to use them, and we want to remove any friction that there might be in getting started. So we are doing a push to provide packages on Linux and bundle with our OSX installer all of them.

    The first three languages are from Microsoft, the third one is from Unity, and it is a strongly-typed and class-based incarnation of JavaScript. The lightweight syntax of Javascript, with the components necessary to produce optimal native code.

    Getting F# to build and run on Mono was a challenge on its own. This is not a language that many of us were familiar with, but we are now at a point where things are baked. We should be uploading our modified version of F# to the fsharp organization on GitHub.

    MonoDevelop's Git support: MonoDevelop 2.6 will come with Git support. Originally Lluis prototyped this by calling out to the system Git, but this is not very elegant and also hard to make reliable and work smoothly across Windows, Linux and MacOS. So Lluis used db4object's tool to convert Java source code into C# source code to bring Eclipse's jGit into Mono as NGit. Now MonoDevelop has a full managed Git implementation that works the same on Windows, Linux and MacOS.

    MonoDevelop's Online Template System: To help developers get up and running with any kind of interesting .NET project, we are going to make MonoDevelop use an online gallery system and we are going to open it up for contributions.

    New Profiler: our new profiler is a complete new implementation that obsoletes the old logging profiler, the old heap-shot profiler and the old heap-buddy profiler and our old statistical profiler into a single profiler that does it all, does it better, and does it well.

    This new profiler was already used to pinpoint bugs and performance problems in our own web server, our Parallel Frameworks and inspired Alan to write a leak detector for Moonlight.

    MonoDevelop's Profiler GUI: The companion to our new profiler. Currently it only has a CPU profiling mode, but in the future we will add a GUI for memory profiling as well.

    Mono on Android: we are very close to shipping Mono on Android. The experience right now is very close to what we want.

    This has taken longer than we anticipated, but mostly because we are providing a full binding to the Android APIs. Not just a subset. This is made possible by Google publishing the Android API contract in XML form.

    WCF: Our WCF implementation so far has been the Silverlight client profiler and its mirror on the server. This is clearly not sufficient for many of our users, so we have redoubled our efforts to fill in all the gaps in WCF. Mono 2.10 will have better coverage for WCF, but it wont be complete. That is still some ways off.

    MonoDevelop support for MonoDroid: Currently our entire toolchain is Visual Studio based, just because we figured this is where the majority of developers would be. We are hard at work to bring the same experience to MonoDevelop users on MacOS and Linux.

    Upgrade MonoTouch to Mono 2.8: Currently our MonoTouch product is based on our older Mono 2.6 release, and there are too many features in Mono 2.8 that users want.

    One feature in particular that we are working on is the use of LLVM's optimizing compiler for Mono on the iPhone. As MonoTouch is entirely batch-compiled and has no JIT, we can use the LLVM backend of Mono instead of our codegen backend to generate smaller and faster code.

    And this is only weeks after we pushed our jumbo 3.2.2 release.

    Deploy Cecil/Light: Cecil is JB's library that we use every time we need to process ECMA CIL images. Debuggers, compilers, assembly browsers, linkers, mergers, spliters, injectors, decompilers and many other tools in Mono are built with Cecil.

    JB has revamped Cecil to be a lot lighter memory-wise, and has improved its API. This new version has been already deployed on most of our master trees in GitHub and will be available to everyone on the next iteration.

    C# Compiler to use IKVM Engine: Our C# compiler has historically used System.Reflection.Emit as its code generation engine. We are adding a second backend to the compiler, this time Jeroen Frijters's IKVM.Reflection engine.

    This will eliminate the need to have our compilers "bound" to an mscorlib profile. This means that we will no longer need various hacks that we have in place to build special compilers to target special profiles of Mono. Just one compiler for all API profiles.

    VB Compiler using Cecil Engine: Rolf updated the Visual Basic compiler to use Cecil as its backend engine.

    Upgrade our Online API documentation: a very much needed upgrade to our documentation system is ongoing, based on Jonathan's Kipunji ASP.NET MVC documentation engine and Jackson's hard work to productize it. We are going to move our documentation to this new system. You can preview our new documentation system here: MonoMac's Documentation Test Site.

    Hopefully, this time, we will make our documentation editable on the web.

    Moonlight GPU Acceleration and Perspective 3D transforms: this project has been underway for a little more than a year and I blogged about the GPU Acceleration recently.

    GPU acceleration is based on the fine work from Gallium, and also has made Moonlight's engine more reusable as a general purpose accelerated framework.

    Moonlight's RichText control: this is basically a word-processor on a widget. And who better to work on this than Chris Toshok who originally wrote XWord for Unix almost 13 years ago and which lead to the creation of LessTif.

    Moonlight Test Suite: We are up to 47.77% of the Silverlight 4 test suite passing. This is a really big number considering that we only started work on Silverlight 4 features very recently. We have been making progress at about 3% every week.

    Moonlight Beta: as the stars of codecs, tests and MS-PL code align, we are getting ready to do the first public beta of Moonlight 4 early next year.

    Moonlight Platform Abstraction Layer: We did a proof of concept port of Moonlight to Android and OSX to improve Moonlight's Platform Abstraction Layer. It should now be possible to reuse the Moonlight engine in other platforms and operating systems. Think of this as a "porting kit". You get the source, get it running elsewhere and if it breaks, you get to keep both pieces.

    MonoMac: we just released MonoMac 0.4 and we are now adding support for creating self-contained application bundles that developers can redistribute themselves or even submit to the Apple AppStore for MacOS.

    MonoMac has been a lot of work, mostly, due to popular contributions. There is a nice emerging community of new contributors to Mono that has sparked in the last few weeks.

    Garbage Collector Performance Tuning: with Mono 2.8 we shipped our new copying and precise collector and we made it easy for users to try it out (mono --with-gc=sgen). With the information we have collected, we are now improving the reliability and performance of the collector.

    Sgen already helped us get up to 30% performance boosts on ASP.NET workloads, and the new results are nothing short of amazing. We can not wait to share this with the world (or you can try it out today by building Mono from master).

    System.Xaml: The venerable desktop version of the XAML parser is coming to Mono in our next release.

    Precise Stack Scanning for SGen: we have also added support for precise stack scanning that will be useful in a few workloads.

    One surprising thing that we found out, and this will come as a shocker to many --it certainly was for me--, precise stack scanning over conservative scanning requires a lot of extra memory to keep stack maps. Unless you have some particular need to use precise stack scanning, you will be better off memory-wise and CPU-wise using conservative stack scanning.

    Concurrent GC with SGen: as you can guess, SGen has been great for Mono, and more concurrent configurations of GC scanning will be supported in our next release. Some were disabled in 2.8, some are new.

    Moonlight and DeepZoom: we had a decent DeepZoom implementation, but now we have a fabulous one. And by fabulous I mean, we pass Microsoft's tests :-)

    Intellisense for Android's markup: Atsushi created a DTD for us to bundle with MonoDroid to let users at least edit their Android UI XML with auto-complete in Visual Studio.

    ParallelFX: our parallel FX in Mono 2.8 was the first time that we distributed it. We have been working on improving its performance, distribution and balancing algorithms.

    Update: both the ParallelExtra samples gallery and Microsoft Biology Foundation are now runnable.

    Monodevelop Addins: Lluis launched the Beta for MonoDevelop's Addins system. You can use this to publish your MonoDevelop add-ins to your users, maintain multiple versions of them and get cute statistics on your add-in.

    This is the app-store of MonoDevelop addins, except they are all free. For example, this shows that in the last 7 days, 144 users installed the MonoMac addin:

    And that is what has kept us busy since the releases of Mono 2.8, Moonlight 2, MonoDevelop 2.4 and MonoTouch 3.2.

    January and February will be busy months for us as we release betas for Moonlight 3/4, MonoDevelop 2.6, Mono 2.10 and the official launch of MonoDroid 1.0.

    Posted on 09 Dec 2010

    Gtk# designer on OSX

    by Miguel de Icaza

    Happy to see that Gtk+ and Gtk# on MacOS are complete enough that the MonoDevelop GUI designer can be used there to build UIs.

    In the past, we had to use Linux to do all of our GUI design. Now our Gtk+ GUI design on OSX is self-hosting:

    You need the latest Mono and MonoDevelop to get this working.

    Posted on 08 Dec 2010

    Mono Introspect: Binding GObject-based APIs for use in Mono

    by Miguel de Icaza

    Alan McGovern, the hacker behind the amazing Moonlight GC tracking device has started work on a tool to bind the new Gtk+ 3.0-based APIs that use GObject instrospection for Mono consumption.

    Check out his project hosted in Github's mono-introspect module.

    Posted on 06 Dec 2010

    Beautiful Hack: Using Mono's Profiler to find Hard Memory Leaks

    by Miguel de Icaza

    Alan McGovern of MonoTorrent, Moonlight and Mono Introspect fame has written a blog post explaining how he used the new Mono Profiling interface to write a custom memory leak detector for Moonlight.

    His post is a step-by-step document on how he created a new loadable profiling module that the Mono runtime uses. He then registers for listening to profiling events for the GC roots (MONO_PROFILE_GC_ROOTS) and then tracks the GC handle use.

    This is how he found a difficult memory leak involving Mono's VM, the browser Javascript VM and the C++ code that backed every Moonlight object.

    Hard core hacking reading.

    Posted on 06 Dec 2010

    New iOS/OSX blog

    by Miguel de Icaza

    I have started a new blog on my iOS/OSX experiences with MonoTouch and MonoMac over at

    Posted on 30 Nov 2010

    David Reveman lands GPU acceleration for Moonlight…

    by Miguel de Icaza

    David Reveman had a great birhtday present for me today. He just completed the hardware accelerated support for Moonlight.

    You can watch two quick videos I made today with David: Hardware acceleration with Moonlight and Moonlight 3D Perspective Support.

    In Moonlight hardware acceleration is used for a number of features:

    • Applying 3D transforms to any Silverlight objects (drawings, images, videos).
    • Accelerating rendering of surfaces by pre-caching the contents on hardware textures.
    • Pixel shaders.

    Although Silverlight is able to accelerate some pixel shaders, Moonlight is able to accelerate all custom pixel shaders.

    The code currently lives on GitHub and we are doing daily builds of Moonlight for users interested in trying it out.

    Posted on 23 Nov 2010

    MonoDevelop 2.4.1 is out

    by Miguel de Icaza

    MonoDevelop 2.4.1 has been released. This release is focused mostly on bug fixes, but we still managed to add a few nice features:

    • we now support .NET 4.0 projects;
    • the Gtk# designer now works on OSX;
    • better native OS integration on Mac and Windows.
    • Improved support for XBuild projects

    Check out our release notes for the details about our changes.

    Posted on 22 Nov 2010

    Fund Raising 2.0

    by Miguel de Icaza

    It occurs to me that in this whole debate over angels and VCs, there is an important third option that is missing from the table and I have been referring to it colloquially as "Social Network Offering", or SNO.

    The idea is that instead of raising money directly from an angel investor or a professional venture capitalist, you raise money through a network of friends, acquaintances and contacts in the industry.

    The startup to-be creates a prospectus with some basic information like the business they are in, the execution plan, and the capital requirements to go from startup to profitability, acquisition or another exit strategy.

    So far, that is not any different than any other financing option available for a startup. The difference is how the share holders are invited into this process. Instead of being a closed door event where the angel or the vc sets the terms, the founders of the company set the terms for the investment as well as the initial round of capital that they are trying to raise and offer this to the social network.

    The Social Network Offering round would be setup through an escrow system that would give different investors a chance to participate in the first round of finacing, and if enough startup capital is raised in this phase, the money is given to the company and shares are distributed to the investors. If the startup fails to raise enough capital, the money is returned to the investors.

    Social Network Offerings are transparent in nature. They would not work well if you are trying to create something in secret, something that nobody has ever heard of, since you would need a level of secrecy for this to work. But it would work great for business built around open-core, or business where the strategy is to do it better than existing offerings.


    If you have a social network of friends that can help you raise this kind of cash, the advantages are:

    • Your social network knows you better than a new VC firm or an angel.
    • Individuals that have historically not had a channel to invest in startups, get a chance to participate. This is fairly unique.
    • Easier to keep the company vision intact.

    There are also some downsides to go with Social Funding: VCs can help you get a seasoned executive team in place, they assist you by filling the gaps during the early stages of the company, they let you tap into their network of companies and resources and they will not hesitate to course-correct any ideological problems that do not necessarily blend well with becoming profitable.

    What is your take?

    If you had a chance to invest on a high-tech startup, how much of your own money would you be willing to put up-front for something like this?

    Fill my survey here.

    Update: On twitter, @eoinh pointed out that one company already did something like this. They used Linked-In to raise 350,000 dollars through their contacts, and found matching funds from the government raising the total to 700,000.

    Posted on 17 Nov 2010

    GitHub Organizations for IronLanguages and F#

    by Miguel de Icaza

    The IronPython and IronRuby languages are now under the "IronLanguages" umbrella and are being maintained using GitHub's Organization support.

    Tomas has also created an organization for F#, it currently hosts the MonoDevelop F# Add-In, and we are going to maintain there F#'s changes that we make in the open source world to get it tuned for Linux and OSX.

    Posted on 17 Nov 2010

    F# MonoDevelop Add-In Available

    by Miguel de Icaza

    Tomas Petricek has announced the availability of the F# MonoDevelop Add-In.

    The add-in provides intellisense for MonoDevelop, inline documentation and access to the F# interactive shell. Most of the heavy lifting is done by the F# compiler itself which is used directly by the Add-In as a service:

    His blog also has screencasts on getting F# and the F# add-in installed on Linux and also shows how to create Gtk# applications with F#:

    Check his blog for more details.

    Posted on 16 Nov 2010

    Mono Developer Room at FOSDEM

    by Miguel de Icaza

    Ruben has announced that FOSDEM 2011 was kind enough to host a Mono Developer Room at next year's conference.

    Ruben is organizing the talks, if you want to present, please submit a proposal for a presentation.

    There are plenty of topics to discuss: Gtk# and the Gnome desktop; MonoDevelop and MonoDevelop add-ins; Mono Runtime; Languages: Iron*, UnityScript, C# 4, F#; Server programming with Manos or ASP.NET.

    Posted on 15 Nov 2010

    New Mono Log Profiler

    by Miguel de Icaza

    Paolo has checked into Mono's GIT repository our brand-new profiler for Mono applications.

    The new profiler is documented in detail here, and is available with Mono 2.9+ (this means: it is available if you build Mono from GIT, and will be part of the upcoming 2.10 release).

    We would love to hear your feedback on it, and we hope to have a UI integrated into MonoDevelop soon.

    Update: This is what one of the reports of the new profiler can produce, this is taken from running an ASP.NET application (a question that came up a few days ago on IRC):

           Heap shot 5 at 14.518 secs: size: 43684432, object count: 562907, class count: 543
                Bytes      Count  Average Class name
             10506984      87373      120 System.Collections.Hashtable.Slot[] (bytes: +1939272, count: +16161)
                   87346 references from: System.Collections.Hashtable
              8130304      87486       92 System.Int32[] (bytes: +1706912, count: +16164)
                   87346 references from: System.Collections.Hashtable
                   40 references from: System.Collections.Generic.Dictionary
                   30 references from: System.Globalization.NumberFormatInfo
              6846000      57050      120 System.Web.Caching.CacheItem (bytes: +1232880, count: +10274)
              4891432      87347       56 System.Collections.Hashtable (bytes: +904176, count: +16146)
                   28526 references from: System.Web.HttpStaticObjectsCollection
                   28525 references from: System.Threading.ReaderWriterLock
                   28524 references from: System.Web.SessionState.SessionStateItemCollection
              1597344      28524       56 System.Web.SessionState.InProcSessionItem (bytes: +287672, count: +5137)
                   28524 references from: System.Web.Caching.CacheItem
              1597344      28524       56 System.Web.SessionState.SessionStateItemCollection (bytes: +287616, count: +5136)
                   28524 references from: System.Web.SessionState.InProcSessionItem
    	This heapshot was taken 14.518 seconds after application startup, at the
    	time there were 562907 objects in the heap, of 543 different types,
    	using about 43 MB of memory.

    Posted on 11 Nov 2010

    F# Goes Open Source

    by Miguel de Icaza

    Last week, Don Syme announced that Microsoft has open sourced the F# compiler and the F# core libraries under the Apache 2 license.

    In addition, on Tuesday, Don also announced a new release that fixes a handful of bugs specifically for users targeting Mono.

    F# is a fascinating language, but I had not really spent much time with it as we could not really distribute it as an open source compiler limiting its usefulness in the Linux and Mac worlds. Now F# can become just another language that developers can use.

    F# supports asynchronous programming today, and it was the inspiration for C# 5.0's async support. There is no need to wait for C# 5 to come out, you can start using async workflows today with F# everywhere.

    MonoDevelop plugin

    At the F# in Education workshop Tomas Petricek announced his MonoDevelop add-in for F#. Although he has not released a binary add-in, the source code to his plugin is available here. It provides intellisense, parameter documentation, on-the-flight error underlying and support for the F# interactive shell from the IDE.

    Distributing F#

    Our plan is to distribute F# as part of Mono for both OSX and Linux. This will take some time, in the meantime, check for instructions on how to get started with F# on MacOS and Linux.

    It will likely run out of the box on Mono/Android and Mono/Wii. Since F# uses generics extensively, we do not know if it can be used to target the iPhone or the PS3 as both require Mono's full static compiler. We will be evaluating this in the coming weeks.

    Don, minutes after open sourcing F# enjoying a tasty meal.

    F# Resources

    These resources are straight from Don's blog:

    Posted on 11 Nov 2010

    Visiting Redmond and PDC

    by Miguel de Icaza

    If you are attending PDC or at Microsoft and love Mono, .NET, Open Source, Linux, MacOS, iPhone, Silverlight, Android or WP7 and want to hang out, discuss, or debate the finer points of trollcats in contemporary society, drop me an email at [email protected]

    Alternatively, we can also indulge in some Java-driven schadenfreude or debate whether chubby pixels are worth staring at.

    I will be in Redmond from Tuesday afternoon until Friday night.

    Posted on 26 Oct 2010

    IronRuby and IronPython Opportunities

    by Miguel de Icaza

    Yesterday, Jason Zander announced that the maintenance and future development of IronRuby and IronPython languages was being turned over to the Iron* communities.

    Microsoft reached out to some of the users of the Iron languages to take over the coordination for these projects. Together with JB Evain, Michael Foord, Jeff Hardy and Jimmy Schementi I agreed to help coordinate the future development of these languages. The Iron* community reaction to the opening of the process has been very supportive judging by the emails on the mailing list and the twitter responses.

    There are four pieces of code involved, all licensed under the Apache 2.0 license:

    Both IronPython and IronRuby will be developed like other open source projects without any of the limitations that previously existed. In particular, from my very Unix-centric view, we will be able to get the proper fixes into the Iron* languages to make them work out of the box on Linux and MacOS.

    Our Contributions

    Although we will help with the coordination efforts in the Iron languages as the community grows and evolves, we have some concrete tasks that we will be working towards right away:

    • Ensure that the Iron* languages build and work out of the box on Linux, MacOS and Unix.
    • Use Mono's Continuous build system to keep an eye on any regressions on IronRuby and IronPython.
    • Package the latest IronRuby and IronPython for Linux and MacOS.


    Ruby and Python make programmers happy. They bring joy and smiles to programmers everywhere in the Unix world. Both have strong user bases on Linux and MacOS and there is a strong ecosystem of independent implementations for both Ruby and Python, each with their unique features.

    In Iron's case the major feature is being able to use your scripting language of choice while having access to all Mono APIs for building standalone applications or for extending existing applications like MonoDevelop, F-Spot, Banshee, SparkleShare and Tomboy.

    From my Unix-biased standpoint, this means that all of the libraries that we have been working on over the years from Gtk# for building desktop Gnome apps, to MonoMac for creating native Mac applications with the entire universe of .NET libraries at your disposal.

    The Iron* languages, combined with our MonoMac will make an appealing platform for building apps for the Mac AppStore.

    Another fascinating project is the Pyjama Educational Project. Pyjama is written in IronPython, Gtk#, and GtkSourceView and currently supports 5 DLR languages.


    As the announcement came out last night, Geoff Norton cooked this simple teaser of IronRuby on the iPhone.

    Check it out here.

    Posted on 22 Oct 2010

    Missed Opportunities at Microsoft and Ray Ozzie Departure

    by Miguel de Icaza

    Microsoft has three big tasks ahead of itself: (a) make Azure successful; (b) make Windows Phone 7 successful; (c) keep the existing Windows and Office businesses printing money.

    There is probably not a lot of political support at this point to embark on more large-scale innovations at Microsoft while there are probably hundreds of smaller innovations that are waiting under all of their product groups.

    Ray Ozzie incubated a number of projects like Azure and Mesh at Microsoft that once they reached a level of usefulness were transferred to the product groups.

    He is probably leaving his position as Chief Architect at Microsoft as he transfers the Azure assets to the product group and he is once again left as a general without an Army. Starting new project and recruiting teams from scratch for new products has probably taken a toll on him and he is ready to move on.

    Missed Opportunities

    Back in June I blogged about what I would do if I was in charge of Windows 8: among other things, I would have created a Windows AppStore.

    This AppStore would have helped independent ISVs tremendously by opening the entire Windows user base as potential customer for Microsoft's products. It would have helped Microsoft make Windows even more relevant, and it would have done more to push native applications on Windows than anything else they have tried in the past.

    The Windows PC market is a market that is many times larger than today's iPhone market. It would have been a gold mine, and there would have been a renewed gold rush to ship "Windows AppStore-ready" applications for Windows.

    Hundreds of people at Microsoft must have had this idea, the question is why it never bubbled up to the top?

    Short of a Microsoft-powered AppStore, Intel has announced that their Windows Appstore will now include .NET software.

    On the one hand, Intel has now given up any attempts to make their AppStore be a cross-platform app-store, which I felt was a gracious thing for them to do, as it would have helped Linux.

    Financially, having a strong Windows-based appstore was probably the right thing to do for Intel. There was really no point in Intel undermining his own efforts by forcing people to use cross platform tools in the first place.

    If Microsoft was the one providing the AppStore, they would be reaching a much bigger market than what Intel hopes to reach.

    This could have been a great Ray-Ozzie level hack to pull at Microsoft. In the meantime, Apple today announced an AppStore, and they are going to get a bucket of apps and a bucket of developers to push software on their platform.

    Live Mesh

    Live Mesh had a lot of promise, but sadly, the groups working on it refused to open up the specs on time, and the product became fairly uninteresting over time.

    If you are going to open something for the world to see, you should be ready to let the world interoperate with it from the start. Otherwise you merely give your competitors the good ideas, and they throw away your bad ideas and avoid paying any of your strategy taxes.

    Posted on 20 Oct 2010

    Shipping Smiles on the AppStore

    by Miguel de Icaza

    Happy days at Mono Central. Just a few months ago we decided that we should apply the lessons learned from MonoTouch to Mono on the Mac and we built a new set of .NET APIs for developing native Mac applications. We called this MonoMac.

    We recently brought tears of joy to developers by shipping it.

    MonoMac will be a great tool to build native Mac application using your favorite .NET programming language.

    We clearly have to take this to the next step as MonoMac is merely a binding to .NET. We are going to have to extend MonoDevelop to create fully self-contained applications that embed both your application, any library dependencies that it needs as well as the Mono runtime.

    The above really had not been my priority, as far as I was concerned "Download Mono and Install it" was a perfectly suitable solution. So you have Apple to thank for my change of heart.

    Hopefully we will have an experience as smooth as the MonoTouch experience has been.

    Posted on 20 Oct 2010

    Bringing Smiles to the Faces of MacOS developers

    by Miguel de Icaza

    As part of our efforts to bring a superb developer experience to every platform in the world, we have made a new release of our bindings to the MacOS X APIs: MonoMac.

    We know that Mac users like to have a smooth installation experience, and we have worked hard to make this as simple as possible. Currently MonoMac is still not a 1.0 product, this is what developers need to do:

    The result is a .app that you can distribute to your users.

    The MonoMac API design is inspired by work that we did for MonoTouch.

    We have achieved a beautiful blend between C# and MacOS that will turn Mac developer's tears of pain into tears of joy.


    Update: to get started with MonoMac, you can join other MonoMac-ers on the IRC channel #monomac on server

    We use the mono-osx mailing list to discuss the binding.


    If you want to get your hands on the source code for MonoMac, head over to GitHub and download both monomac and maccore. The former contains the MacOS-specific bindings, while the latter contains the shared code between MonoMac and MonoTouch.

    The introductory post to MonoMac still contains many useful links and design details, you might want to read that if you want to hack on MonoMac.


    Our API coverage right now is very complete. We will certainly add more C# features to the binding as we learn how developers are using the API, but that is a bit of an organic process.

    One area that we need help to improve the developer experience is to fill-in all the "summary" sections in our documentation. This information is shown during auto-complete/intellisense for the developer for classes, methods, enumeration values and properties.

    Details on how you can contribute to this are on this post of mine.

    Posted on 12 Oct 2010

    A Mono Success Story of Biblical Proportions

    by Miguel de Icaza

    Read David Mitchell's experience in using Mono to reuse code between the Windows and Mac platforms.

    Posted on 07 Oct 2010

    Mono 2.8 is out

    by Miguel de Icaza

    We have just released Mono 2.8 a major upgrade to the Mono developer platform. This release contains ten months worth of new features, stability fixes, performance work and bug fixes.

    The highlights of this release include:

    • C# 4.0
    • Defaults to the 4.0 profile
    • New Generational Garbage Collector
      • Use mono --gc=sgen or mono-sgen to use Mono with the new GC
    • New Frameworks from Mono MIT X11 and Microsoft MS-PL/Apache2:
      • ASP.NET 4.0
      • Parallel Framework: including PLINQ.
      • System.XAML
      • System.Dynamic
      • Managed Extensibility Framework
      • ASP.NET MVC 2
      • System.Data.Services.Client (OData client framework)
      • WCF Routing
      • .NET 4.0's CodeContracts
    • Performance:
      • Large performance improvements
      • LLVM support has graduated to stable
        • Use mono-llvm command to run your server loads with the LLVM backend
    • Version 2.0 of the embedding API
    • Removed the 1.1 profile and various deprecated libraries.
    • OpenBSD support integrated
    • Mono no longer depends on GLIB
    • Threadpool exception behavior .NET 2.0

    For the full details, check our detailed Mono 2.8 Release Notes

    Posted on 06 Oct 2010

    The Mystery Behind the Hacking the Boston Museum of Fine Arts

    by Miguel de Icaza

    A decade ago some hackers went into the Boston Museum of Fine Arts and replaced the guided tour audio with their own content. The identity of the hackers remains a close guarded secret and one of Boston's biggest unsolved mystery's. Investigators could only agree on one thing: that the voice in the tape did not belong to Lev Davidovich Bronstein.

    I got my hands on the audio file back in 1999 and during one of my visits to MIT that year I saw the news paper coverage of the event. I vaguely remember the news article, but it described the reactions of the visitors and featured interviewed with shocked citizens.

    This is the recording.

    Update: Dylan tells me that the cat is out of the bag. Read the interview with BJ Novak here.

    Posted on 29 Sep 2010

    Chicken Tikka Masala Burrito

    by Miguel de Icaza

    	toshok: oh man… chicken tikka masala burrito
    	toshok: i got it to share with conchita, but she's asleep on the couch...

    20 seconds later:

    	toshok: it's so good, i might eat it all

    Posted on 16 Sep 2010

    Unix Stack Exchange: Call for Help

    by Miguel de Icaza

    Thanks to everyone that helped us get the Unix StackExchange group up and running.

    The site went into preview in record time, and then we went into Beta.

    My call for help: I am currently at 1,211 points, on 6th place answering questions on the site.

    So what I need you guys is to go and ask some interesting questions about Unix, Linux, Gnome in there, and I get to answer them with some awesome background.

    If you ever had a pressing Unix question, now is the time to ask it on the site, and help me get those points up.

    Posted on 14 Sep 2010

    This was news to me

    by Miguel de Icaza

    I have been living in the US for 10 years, and I never thought that people that many of the people that went through college end up with huge debts that they had to repay for 30 years.

    This is probably creating a generation of graduates that is unable to take risks, start their own business, take a year off, launch the next startup or just catch a break.

    During the discussion today on Twitter, this link came up, this one as well as this infographic from College Scolarships:

    Posted on 13 Sep 2010

    Great News for MonoTouch Users

    by Miguel de Icaza

    Apple has removed the restrictions that were introduced earlier this year (the famous section 3.3.1).

    Although Apple had not blocked any MonoTouch applications since the new rules were introduced, many developers either took a wait-and-see approach, or switched their development. We never stopped working on MonoTouch, just yesterday we released MonoTouch support for the new iOS 4.1 APIs. We did this within eight hours of the new operating system going public.

    With these new terms, the ambiguity is gone and C# lovers and enthusiasts can go back to using MonoTouch. Developers that like garbage collection and their strongly typed languages can resume their work.

    In addition, Apple has published their detailed review guidelines for application developers. This should help developers get their apps approved. And the MonoTouch Book is a great way to get started.

    Thank you!

    We would like to thank the MonoTouch community that stayed by our side all along and helped us improve MonoTouch and continued to build great applications during this time.

    Those of us that have a crush on iOS and .NET are grateful to Apple and the Apple employees that helped make these changes happen.

    Expanded MonoTouch iOS investment

    Although we continued to extend, improve and polish MonoTouch the older terms made it harder to justify taking on some larger tasks, the risk was high.

    We had some big projects in mind for MonoTouch. We are going to start prioritizing these new features, but we want to hear from our users, and we want to know what is more important to you. Please fill out this survey to tell us what do you think it would be more important to bring to MonoTouch.

    We will balance your input with our own "gut" (we would not be truth to the Stephen Colbert spirit if we didn't).

    ....and discounts!

    Joseph Hill has just told me that we are doing a 15% discount for the next two weeks for anyone buying MonoTouch. Use discount code "MONO-331" on

    We have also a surprise in store for existing MonoTouch customers that we will be announcing next week.

    Posted on 09 Sep 2010

    Initial Thoughts on Oracle vs Google Patent Lawsuit

    by Miguel de Icaza

    Today Oracle sued Google over Java patents and copyrights that they claim Google's Android OS infringes. The lawsuit claims that Google knowingly infringed on those patents, and that the continued distribution of Google's Android is harming Oracle's Java Business.

    You can read the actual complaint, the patents referenced are:

    There is also a copyright lawsuit, but there are not enough details on the complaint to figure out what the claim is. Until there is a trial, we will not really know what is being asked here.

    Pundit Prediction Time!

    I would like to think that this is going to be solved with a quick settlement where Oracle will shake Google for a few billion dollars and the entire matter will be put behind.

    Oracle will likely want to settle with Google under terms that will only cover Google's own use as they want to go shaking other OEM trees for more cash.

    An unlikely scenario is for Google to pay the bills for all Android OEMs as they are coming out fast and strong from every corner of the world.

    It occurred to me that Oracle could sell all the Java assets to Google. But Google probably passed on this opportunity back when Sun was put on the market.

    What Jonathan Schwartz Knew

    Sun's Ex-CEO Jonathan Schwartz has recently taken to the blogwaves to blog about the things he could not tell us while he was a CEO of Sun. While he might have found a new voice for gossip from the Sun days, he will not say a word on this matter, because he was likely engaged in shopping the patent lawsuit around.

    Sun had created Java, but it turned out to be very difficult for Sun to monetize Java directly after the initial source code license deals that they struck with IBM, Microsoft, Oracle, Netscape and others. They created the J2EE market, just to find that other companies and startups executed better than they did on the systems that they had initially engineered.

    Sun was left in the uncomfortable position of being the owner of the technology that everyone was cashing out on, but they themselves had very few revenue streams for Java. Like Clemens Vasters joked on Twitter today:

    They had the Microsoft lawsuit cash and they had the embedded licensing business with Java Micro Edition and Java Standard Edition licensing deals.

    The open sourcing of Java was also carefully planned. By picking the GPL as their license, they ensured that embedded system OEMs and developers would have to negotiate a different license with Sun if they wanted to use the OpenJDK on their systems.

    There is very little public information on the Google/Sun split over Java ME and the creation of Dalvik. The rumors on the grapevine were that Google and Sun could not reach an agreement over the Java Micro Edition licensing. Sun wanted to sit in the middle between Google and the handset OEMs, while Google wanted to create a free-for-all operating system.

    When it became clear that they would not be able to reach an agreement, Google started a project to replace Java Micro Edition and they used some clever engineering techniques that blended the best of both worlds.

    It is likely that during these negotiations, Google threatened to build their own Java runtime and Sun countered with a list of patents. This would explain why Google went through the trouble of making the Dalvik virtual machine explicitly incompatible with the existing Java virtual machine instructions.

    Although Dalvik uses a different set of instructions, Google created a translator that recompiled Java code into Dalvik code, and with this, they worked around whatever licensing technicalities they were aware at the time of the negotiations.

    Needless to say, Sun was not happy with Dalvik. Not only because Sun had lost a large licensing deal, but also because it had the potential of becoming the de-facto Java virtual machine that everyone on the embedded space would pick instead of Sun's own Java Micro Edition.

    In late 2007 Google announced both Android and the Open Handset Alliance to the public. On the Java front, Sun had delivered on the promise of open sourcing Java, but it had been a rough year for Sun and it would get worse, in the next twelve months after the announcement, Sun stock would lose 80% of its value.

    Sun had their plates full, so Sun did not feel the need to react immediately to the Android threat, so they kept their grievances to themselves.

    But Jonathan started to shop the company in late 2008. The monetary value of the Java assets had been devaluated due to the open sourcing of the technology under the GPL. I am going to bet that the same careful planning that went into picking the GPL went into pitching the potential for lawsuits.

    The world had already witnessed the awesome iPhone and the eyes were on Google to deliver a killer phone. Jonathan must have known this and he must have been pitching this to the potential suitors.

    By the time Oracle bought Sun, they knew that they would be going after Google and anyone else with a big, fat checkbook that did not have a licensing deal in place.

    And that explains the Exodus of famous Java people from Sun shortly after the acquisition. The wheels of the lawsuit started spinning the moment the sale was done. Those employees are probably under NDA.

    Update: I was wrong, apparently Gosling was not under NDA and has confirmed exactly what I said above:

    Oracle finally filed a patent lawsuit against Google. Not a big surprise. During the integration meetings between Sun and Oracle where we were being grilled about the patent situation between Sun and Google, we could see the Oracle lawyer's eyes sparkle. Filing patent suits was never in Sun's genetic code. Alas....

    I hope to avoid getting dragged into the fray: they only picked one of my patents (RE38,104) to sue over.

    So now we know that Jonathan shopped Sun with a big "Sue Google" sign. So much for his visionary patent defense against Apple and of course this jewel:

    The most egregious of such suits was filed against Sun by Kodak (yes, the film photography people).

    Egregious, because Kodak had acquired a patent from a defunct computer maker (Wang) for the exclusive purpose of suing Sun over an esoteric technology, Java Remote Method Invocation (“Java RMI” – not exactly the first thing that comes to mind when you hear “Kodak”).

    And he was just playing Wang's role a couple of months ago.

    Update: this post from the Dalvik announcement era discussed how Dalvik's work around the license-from-Sun challenge.

    Some Background on the Java Patents

    The Java specification patent grant seems to be only valid as long as you have a fully conformant implementation:

    (a) fully implements the Specification including all its required interfaces and functionality;

    (b) does not modify, subset, superset or otherwise extend the Licensor Name Space, or include any public or protected packages, classes, Java interfaces, fields or methods within the Licensor Name Space other than those required/authorized by the Specification or Specifications being implemented; and

    (c) passes the Technology Compatibility Kit (including satisfying the requirements of the applicable TCK Users Guide) for such Specification ("Compliant Implementation").

    This is more stringent than the Microsoft Community Promise that applies to .NET as the Community Promise only requires a minimum subset, it does not prevent supersets.

    This seems to be what the lawsuit is hinged upon.

    Is this it?

    I vaguely remember in one of the endless anti-Mono discussions that someone pointed (maybe it was Gosling himself?) that Java had a patent grant for anyone to implement under any conditions.

    They pointed to the spec. And I remember seeing this on the spec and thinking that it was a generous patent grant. Perhaps I was confused and the only patent grant is the one in the previous section, but if you know of the other document, please let me know.

    Sun's GPL

    By GPLing Java, Sun lost some of the exclusive rights that they used to have, in particular, anyone using the open sourced version of the OpenJDK is given the patent rights to run the software.

    The problem is that the rights are only available as long as you are using the GPL version of Java. Any patent grants are not available if you use a third-party licensed version of the Java virtual machine. In that case, it seems like the only option would be to to go back to the Sun licensing terms.

    Wishful thinking

    Too many engineering resources are devoted to Android at Google and at their partner companies, but I can not help to think that Google could migrate Android from Java to the ECMA/ISO CIL and C#.

    Unlike the Java patent grant, the Microsoft Community Promise for both C#, the core class libraries and the VM only require that you have a full implementation. Supersetting is allowed.

    Additionally, Microsoft has placed the .NET Micro Edition entirely under the Microsoft Public License which comes with an even more generous patent grant, and covers a superset of the code covered by ECMA/ISO 335.

    We have open source implementations of both, and even more luckily, the ECMA/ISO VM specification allows for different profiles, to allow for ultra-small or server-sized versions of the VM to be created. Ideal for mobile platforms.

    Google could settle current damages with Oracle, and switch to the better designed, more pleasant to use, and more open .NET platform.

    Some Humor

    There is a silver lining in this whole mess, and it is that the tweetosphere came up with a few funny tweets, here are my favorites:

    And while you are here

    I am very excited to see the first MonoTouch book published.

    Posted on 13 Aug 2010

    Unix and Linux StackExchange

    by Miguel de Icaza

    Help create a non-tribal version of StackOverflow for Unix and Linux questions.

    As we know, tribalism makes you stupid. So let us commit to the Linux and Unix Q&A site powered by StackOverflow that will help answer questions for Unix and Linux users of all distributions and blends.

    At the time of this writing, only 91 users have committed.

    Tell your Solaris, FreeBSD, NetBSD, OpenBSD, Unix, OSX, Linux, Red Hat, Fedora, Ubuntu, Debian, Mandrake, Mint, Arch, Slackware, CentOS, Gentoo, OpenSUSE, friends to commit to it and help create a global community of Unix love.

    Posted on 05 Aug 2010

    MonoTools 2 for VisualStudio has been released

    by Miguel de Icaza

    We just released Mono Tools for Visual Studio.

    There are four main features in MonoTools 2:

    • Soft debugger support.
    • Faster transfer of your program to the deployment system.
    • Support for Visual Studio 2010 in addition to 2008.
    • Polish, polish and more polish.

    Thanks to everyone that participated on our beta program for all of the bug reports and feedback!

    MonoTools is the foundation on which we are building the upcoming Mono for Android toolchain.

    New Long-Term Maintenance Mono Release

    With the introduction of MonoTools for Visual Studio, we are also moving our long-term maintenance Mono release from the Mono 2.4 release to Mono 2.6, the release that we announced last week.

    Getting Started

    Download our betas from this page. On Windows, you would install our plugin for either 2008 or 2010 and you need to install Mono 2.6.5 on the target platform (Windows, Linux or MacOS).

    On Linux, run `monotools-gui-server' or `monotools-server', this will let Visual Studio connect to your machine. Then proceed from Windows.

    On MacOS, double click on the "MonoTools Server" application.

    Once you run those, MonoTools will automatically show you the servers on your network that you can deploy to or debug:

    ASP.NET debugging with this is a joy!

    Soft Debugger

    This release is the first one that uses our new soft debugger. With is a more portable engine to debug that will allow our users to debug targets other than Linux/x86 for example OSX and Windows.

    This is the engine that we use on MonoTouch and that we are using for Mono on Android.

    Our previous debugger, a hard debugger, worked on Linux/x86 systems but was very hard to port to new platforms and to other operating systems. With our new soft debugger we can debug Mono applications running on Windows, helping developers test before moving to Linux.

    Faster Transfers

    When you are developing large applications or web applications, you want your turn around time from the time that you run hit Run to the site running on Linux to be as short as possible.

    Cheap Shot Alert: When dealing with large web sites, we used to behave like J2EE: click run and wait for a month for your app to be loaded into the application server.

    This is no longer the case. Deployments that used to take 30 seconds now take 2 seconds.

    Support for Visual Studio 2010

    Our plugin now supports the Visual Studio 2010 new features for plugin developers.

    This means you get a single .vsix package to install, no system installs, no registry messing around, no dedicated installers, none of that.

    The full plugin installs in 3 seconds. And you can remove it just as easily.

    Then you can just from VS's Mono menu pick "Run In Mono" and pick whether you want to run locally or remotely.

    We now also support multiple profiles, so you can debug from Visual Studio your code running on Linux boxes, Mac boxes or your local system.

    Polish and more Polish

    MonoTools was our first Windows software and we learned a lot about what Windows developers expected.

    We polished hundreds of small usability problems that the community reported in our last few iterations. You can also check our release notes for the meaty details.


    And we integrate directly with SuseStudio to create your ready-to-run appliances directly from Visual Studio.

    Posted on 03 Aug 2010

    Mono has migrated to GitHub

    by Miguel de Icaza

    We have now migrated all of Mono's source code from the Subversion at our Cambridge office over to GitHub.

    We are going to be maintaining a migration FAQ and providing help to developers on channel #mono for the new setup.

    The web site has not been updated yet and we still reference Subversion urls, but this will be fixed in the next few days.

    Posted on 22 Jul 2010

    Mono 2.8 Trick: tracing exceptions

    by Miguel de Icaza

    Mono has an strace-like feature built into the runtime. This is useful to see which methods are being called by your application, just invoke Mono with --trace.

    Our upcoming version has a neat new feature, when you use --trace=E:ExceptionName or --trace=E:all you get a stack trace of where the exception was thrown from:

    $ gmcs.exe
    mono$ gmcs missing.cs
    error CS2001: Source file `missing.cs' could not be found
    Compilation failed: 1 error(s), 0 warnings

    And now with tracing enabled, we do it setting the MONO_ENV_OPTIONS variable:

    mono$ MONO_ENV_OPTIONS=--trace=E:all gmcs missing.cs[0xb75136f0:] EXCEPTION handling: System.IO.FileNotFoundException: Could not find file "missing.cs".
    "{unnamed thread}" tid=0x0xb75136f0 this=0x0x53f18 thread handle 0x403 state : not waiting owns ()
      at System.IO.FileStream..ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare,int,bool,System.IO.FileOptions) {0x00619}
      at System.IO.FileStream..ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare) {0x00022}
      at (wrapper remoting-invoke-with-check) System.IO.FileStream..ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare) {0x0004f}
      at System.IO.File.OpenRead (string) {0x0002c}
      at Mono.CSharp.Driver.Parse (Mono.CSharp.CompilationUnit) {0x00016}
      at Mono.CSharp.Driver.Parse () {0x00068}
      at Mono.CSharp.Driver.Compile () {0x00098}
      at Mono.CSharp.Driver.Main (string[]) {0x000a2}
      at (wrapper runtime-invoke) {Module}.runtime_invoke_int_object (object,intptr,intptr,intptr) {0x00033}
    error CS2001: Source file `missing.cs' could not be found
    Compilation failed: 1 error(s), 0 warnings

    Posted on 21 Jul 2010

    Banshee Ships with Amazon Store Support

    by Miguel de Icaza

    Aaron just shipped Banshee 1.7.3 which lets you purchase MP3s from Amazon from the player directly.

    Banshee Amazon MP3 Store Screencast!

    Get it fresh!

    Posted on 21 Jul 2010

    Building apps for the Retina Display

    by Miguel de Icaza

    While adding Retina Display support to TweetStation I learned a couple of tricks that I figured would help other developers.

    iOS 4 Points

    Apple's Retina Display conveniently doubles the number of pixels on each dimension, the previous iPhone display had 320x480 pixels while the new new phone has 640x960 pixels.

    To make existing applications run out of the box on these new displays Apple changed the units on the display and instead of using pixels they now use points. They are not really typographical points, but iOS "points". Both the old iPhones and the new iPhone have a resolution of 320x480 points.

    This means that existing code that absolutely positioned views on the screen will get the views laid out in the same positions regardless of the device that the code is running on.

    In UIKit points are interpreted based on the value of the UIView.ContentScaleFactor. If the value is 1.0 each point is mapped to one pixel. If the value is set to 2.0 each point is mapped to four pixels (2x on each dimension).

    UIKit layout and CoreGraphics rendering primitives will automatically take this factor into account and position and render accordingly.


    The Image loading routines have been extended to load higher-resolution images by default when you use UIImage.FromBundle. On Retina Displays the code will probe for a [email protected] filename when you request file.ext to be loaded. For example this loads the background texture you use:

    	texture = UIImage.FromBundle ("Images/texture.png");

    TweetStation's images are here.

    Bitmaps and Inkscape

    All the icons and images on TweetStation were done using Inkscape. When I exported the icons they would invariably look blurry. For example, this is from my first attempt at getting the swipe menu on TweetStation working:

    I would just draw my icons on Inkscape and then export them as bitmaps. Inkscape would then anti-alias the result, you can see how the reply icon is not rendered properly:

    The Inkscape FAQ contains this bit of information that is very useful if you are drawing small icons:

    With the current renderer, it is not possible to completely get rid of antialiasing. However, it is possible to partially suppress it on export. Usually, antialiasing is unwelcome in horizontal and vertical lines which become "blurred". To work around this, make sure your horizontal/vertical edges are snapped on the pixel grid, and all strokes are a whole number of pixels wide. Then, export bitmap at the default 90dpi so that 1 px unit corresponds to 1 bitmap pixel. In the resulting bitmap, snapped color boundaries will be perfectly crisp.

    These are the settings that I use now to export the same graphic:

    I used guidelines on Inkscape to help me:

    This is the new version of the icon before it gets composited with the background

    To export the same image at high resolution, set the DPI in the dialog box to 180. Inkscape will automatically change the width and height for you.

    The other problem that I had was related to my centering code, this is what the rewteet icon looks like from the menu above:

    The blurry sides of the retweet icon were caused by the math code setting the X position of the image at a fraction of a point (0.5).

    After fixing both problems and adding a nice backdrop shadow, this is what the menu looks like:

    Graphics Context

    Loading images with more pixels for the background texture and the icons wont do you any good if you are drawing the images yourself.

    When you create a graphics context using the pre-iOS 4 APIs you will end up with a context that assumes that you are not aware of the Retina Display and hence will rescale your drawing up. When you create an image context of 100x100 points like this:

    	UIGraphics.BeginImageContext (new SizeF (100, 100));

    You will end up with a context that has 200x200 points, but will automatically double all of your pen widths and will scale any images up. If you had a high-resolution image, it will first be scaled down when rendering to the context, then scaled up when rendering the data.

    To take advantage of the retina display you need to call a new method:

    	UIGraphics.BeginImageContextWithOptions (SizeF size, bool opaque, float scale);

    If you set scale to zero, it will pick 1.0 for old display and 2.0 for retina displays. I use this helper method to support both iOS 3.x and iOS 4.0:

    	void BeginImageContext (SizeF size)
    		if (Graphics.HighRes)
    			UIGraphics.BeginImageContextWithOptions (size, false, 0);
    			UIGraphics.BeginImageContext (size);

    This is how the swipe menu is rendered at high resolution:


    Apple's Supporting Resolution Independence document has more information.

    Posted on 20 Jul 2010

    Mono's Git Migration

    by Miguel de Icaza

    Mono's source code is being migrated to GitHub on July 22nd, starting at 9am Boston time.

    We are psyched that Github was kind enough to host Mono's large repositories for free on their system. We are also taking advantage of their new Organizations functionality.

    Gonzalo posted the following details about the migration:

    We are moving our source code repository to GitHub.
    On July 22nd ~9am EDT (1300 GMT) the subversion repository at "svn
    +ssh://" will be set to read-only mode and
    kept that way forever.
    We estimate that the process of migrating all the projects and moving
    them to GitHub will take more than 3 and less than 8 hours. Once it is
    completed we will send an email to this list with URLs to the new
    repositories, FAQs,...

    If you have any questions about the migration, please ask them here and we will add them to our Git Migration FAQ.

    Posted on 20 Jul 2010

    Fresh Mono Baked

    by Miguel de Icaza

    Andrew just announced Mono 2.6.7, the version that is replacing our long-term maintenance release of Mono with plenty of bug fixes as well as the following new features:

    • Microsoft's ASP.NET MVC2 is now bundled with Mono.
    • Upgraded xbuild tool (Mono's msbuild)
    • Upgraded our LINQ to SQL (DbLinq)
    • Upgraded our Soft Debugger
    • We now publish CentOS/RHEL packages.

    Our CentOS/RHEL packages install on /opt/novell/mono, just like our packages for SUSE Linux Enterprise and should not conflict with your own packages of Mono that you might have from some other sources.

    Posted on 20 Jul 2010

    Microsoft Licensing Changes for IronRuby and IronPython

    by Miguel de Icaza

    If you check the latest versions of IronRubyIronPython or the Dynamic Language Runtime you will see that Microsoft has now relicensed the code from the Microsoft Permissive License to the Apache 2 License.

    Posted on 17 Jul 2010

    Spaniard Anger Towards Mexicans

    by Miguel de Icaza

    It has been brought to my attention that the upcoming 200 year celebration of Mexico's independence from Spain on September 15th has lead to office unrest all across the country between teams that have both Mexicans and Spaniards working side-by-side.

    Spain might have won the world cup, but Mexico upgraded from being a colony of Spain and being subject to the will of the Kings of Spain, to a democracy subject to the will of drug dealers.

    To resolve this animosity, I propose we settle the score this September 15th with a cook-off between Spaniard food and Mexican food.

    I propose the cook-off from the Novell/Cambridge team be held at my place the weekend before the festivities to settle the score before the celebrations take place. We will make delicious tacos. Gonzalo will be making a Paella.

    Posted on 17 Jul 2010

    New Mono Runtime Features

    by Miguel de Icaza

    With Mono 2.8 we want to make it very easy for developers to use the LLVM powered Mono engine and the new Mono Garbage Collector.

    Previously users had to build Mono from source code and choose as part of their build whether they wanted the Mono VM to be powered by LLVM or not and whether they wanted to use the Boehm GC or the new Generational GC. Typically users would have to keep multiple parallel Mono installations.

    This is no longer necessary.

    Mono 2.8 by default behaves just like any other Mono, by default you get the regular fast Mono JIT with the Boehm GC.

    You can then pass the --llvm flag to instruct the Mono runtime to use LLVM for code generation (much slower to JIT, but produces better code for long-running applications or compute intensive applications).

    To use the new garbage collector you pass the --gc=sgen command line argument.


    We wanted users to try LLVM, SGen or the LLVM/Sgen combination without having to modify all of their launch scripts or existing tools so we introduced a new environment variable that Mono parses on startup, the MONO_ENV_OPTIONS variable.

    Mono will parse the contents of the MONO_ENV_OPTIONS variable as if the arguments had been passed in the command line, so you could do a full bootstrap of Mono's class libraries with both by doing:

    	$ export MONO_ENV_OPTIONS="--llvm --gc=sgen"
    	$ make

    How to test LLVM and SGen

    Update: Both the --gc=sgen and --llvm options depend on your architecture and operating system being supported by SGen and LLVM and depend on you compiling your runtime with these features.

    SGen will be automatically enabled if your OS/architecture is supported when you run configure.

    LLVM requires the installation of the LLVM libraries. We strongly recommend that you use our modified version of LLVM that has been extended to support various constructs required by .NET.

    For more information on compiling LLVM and building your Mono with it, see our web page

    Posted on 14 Jul 2010

    GZip your downloads

    by Miguel de Icaza

    Gonzalo yesterday pointed me to a feature in the HTTP client stack for .NET that I did not know about.

    If you want the server to gzip the response before sending it to you, set the AutomaticDecompression flag in your HttpWebRequest:

    	var request = (HttpWebRequest) WebRequest.Create (uri);
    	request.AutomaticDecompression = DecompressionMethods.GZip;

    This will set the Accept-Encoding HTTP header to gzip when you make your connection and automatically decompress this for you when you get the response stream.

    Update: on the comments there is a suggestion that Deflate is another option you can use, and you can combine both GZip + Deflate on the flags above.

    Update2: Dennis Dietric emailed me to point out an important bit: if the server side does not support GZip or Deflate content, you will could get a 406 return code, so when dealing with third party web sites you need to be prepared to fall back and retry your request without compression in place. The relevant sections of rfc 2616 are 10.4.7, 14.1 and 14.3.

    Posted on 09 Jul 2010

    Microsoft MS-PL code in Mono

    by Miguel de Icaza

    Over the past couple of years Microsoft has been open sourcing some key .NET libraries under the MS-PL or Apache 2 license.

    We are tremendously grateful to Microsoft for making these components open source. This has allowed us to distribute this in the past, and we are going to be bundling a lot more of it with Mono 2.8:

    In Mono 2.8, the following assemblies and code come from Microsoft:

    With Mono 2.8 we are going to default to the .NET 4.0 profile. So from the list above MEF, the DLR, OData and MVC2 become first class citizens in Mono-land, no longer third-party packages that you needed to install.

    Update: as of July 17th 2010, the DLR, IronPython and IronRuby changed their licenses from MS-PL to Apache2.

    Posted on 07 Jul 2010

    First MonoTouch Book is out

    by Miguel de Icaza

    I am very excited to see the first MonoTouch book published.

    You could not ask for a better team of authors to explain the MonoTouch and the iPhone platform. Chris, Craig, Martin, Rory, and Wally.

    This book was a team effort by various active members of the MonoTouch community. They nurtured the community from the start by exploring MonoTouch, by reporting bugs and missing functionality in MonoTouch and by guiding .NET developers through the new world of building iPhone applications.

    Congratulations on the book release guys!

    You can find them here:

    Posted on 06 Jul 2010

    Pinta 0.4 Released

    by Miguel de Icaza

    Jonathan Pobst has released a new version of his paint program, Pinta, a lightweight app that runs on Linux, OSX and Windows and is built entirely using Gtk#.

    In this version, Jonathan added the MonoDevelop docking library to allow users to reorder the editing tools to match their workflow:

    There are ready-to-run packages available for Windows, OSX, Ubuntu and OpenSUSE.

    Posted on 06 Jul 2010

    TweetStation: Elevating the Discourse

    by Miguel de Icaza

    (See below for Updates).

    TweetStation is my first native iPhone app (as opposed to my award-winning HTML5-app iCoaster). More screenshots can be seen here

    Just like Rails, TweetStation is an opinionated Tweeting client, it contains my personal blend of features that I enjoy from other twitter clients, but also tries to do something about changing the world.

    TweetStation has been designed to elevate the level of discourse on Twitter.

    At a conceptual level, this is achieved by applying the cardinal rule of not taking anything too seriously, specially any interactions you might have online.

    At a practical level this is achieved with two features. The first feature plays back chicken noises whenever you request more Tweets (this is bound to the Tweetie-like "Pull to Refresh" feature). These chicken noises have been engineered to remind you that no matter how important an argument appears to be in Twitter, you should not take it too seriously.

    Additionally, the chicken-noise-on-refresh serves as a cue to other people talking to you that you rather see what @jacksonh, or @Mickey__Rourke have to say than hear them parrot back the physics of clouds wikipedia page that they just read twenty minutes ago.

    When you compose a message with TweetStation music starts playing back in the background. This music was specially selected to elicit in you the desire to write a witty and clever response as opposed to the usual "well, fuck you too" response seen too often on social media sites. The result will be the kind of tweet that your local newspaper would publish in the front page, or in their "Social Media Expert" column.

    But there is an elephant in the room, and I want to speak directly about it. Many Twitteristas are concerned about the Tweetpocalypse and Twitter's transition to use some bizarro world non-feature called OAuth.

    Tweetstation is feature packed and does not suffer from either problem. You can trust that Tweetstation was developed using the best engineering techniques available today, and that you will never be the victim of the Tweetpocalypse and be left incommunicado due to some silly programming mistake. Not in this 32-bit century, not in the next, and not under my watch. If my years of experience taught me one thing is and one thing only, it is when to use a 32-bit integer data type and when to use a 64-bit one. Do not fear dear user, I also master many other data types, but I digress.

    But you might be wondering, why another Twitter client, and why now? As a twitterista you know that there is a special bond, an intimate bond if you will, between the twitterista and his twitter client. This bond can exist as long as both the twitterista and the twitter client grow hand in hand, if they co-develop. And I found myself at odds with the design decisions and paths that other twitter clients were taking. In a metaphorical way, I felt uncomfortable, like a Woody Allen character under pressure. But a character that lacked Woody Allen's command of the language.

    And this is how TweetStation was born, it was a labor of love, but mostly of social awkwardness when my friends mocked my Twitter client for lacking a chicken noise, or when they suggested things at dinner like "would it not be cool if...". I decided to change all that, and make sure that other twitteristas in the future did not feel the social scorn that I had gone through, and this is why TweetStation's source code is on github.

    Getting TweetStation

    You can get TweetStation from iTunes.

    Activating the Chicken Noises

    By default, the chicken noises are off. To turn on this features, go to "Settings" and in the "Poultry" section set "Chicken Noises" to the "ON" position.

    TrollStation Pro vs TweetStation

    Since this is going to become a FAQ, I wanted to address this here.

    I have two sets of keys that I got from Twitter to access the service using OAuth. One set of keys is the regular set of keys that anyone can get, and I attached the name "TrollStation Pro" to that one. This set of keys is what I placed on the public code on GitHub, so anyone can try and anyone can use. I reserve the right to change that name on a day-by-day basis depending on what I consider to be funny that particular day.

    The second set of keys are labeled as "TweetStation" and that one is used for the actual application on the AppStore. These keys are special because Twitter was kind enough to give me access to their service using "xAuth" which improves the login experience (no web browser is involved).

    Retina Display

    TweetStation was submitted to Apple before I could get my hands on an iPhone4, so it is missing the high-resolution artwork. I just submitted a build that contains high-resolution icons for the iPhone4.


    Login bug: There is a login bug if your password contains any special characters. I have submitted a bug fix to Apple (including the Retina display update). For now you can work around this issue by changing your password to use letters and numbers.

    Posted on 01 Jul 2010

    Guadec this year.

    by Miguel de Icaza

    This year I will be skipping the Guadec conference. Like Ted Gould we are expecting our first baby this year around the same time that Guadec will take place.

    The good news is that next year any of you attending my talk at Guadec 2011 will get to enjoy a presentation packed with baby pictures.

    I wish a happy Guadec to all the Gnomers attending!

    Posted on 30 Jun 2010

    What I would do if I was in charge of Windows 8

    by Miguel de Icaza

    Apple and its AppStore did for software programmers what Google's AdWord did for bloggers and writers: it provided a mechanism for people to make money while doing what they love.

    The AppStore takes a big weight from the shoulders of software developers by taking care of the distribution and billing system.

    If I was in charge of the Windows 8 future (or MacOS for that matter), I would try to reproduce that formula on my mainstream operating system. And it seems from the leaked presentations that this is where Microsoft's head is.

    The leaked mockups for the AppStore are creative, but the entire slide deck misses the fundamental point that people are scared of installing software on Windows.

    Everyone is scared of installing applications on Windows either because they break the system or because you might be accidentally installing malware. In either case, the end result is countless wasted hours backing data up, reinstalling the operating sytem and all the applications.

    An AppStore wont fix this.

    For a Windows appstore to work, they need to guarantee that installing software wont ever break the system.

    They need to produce an appliance that allows users to install and remove software in seconds, and yet, guarantee that installing and removing apps will never break the system. This is not a problem that can be solved by hiring an army of curators and people that just sit all day rejecting apps.

    To solve the problem, Microsoft needs to both alter their kernel to ensure the safety of the host OS and come up with a new way of distributing applications. They need:

    • A sandboxed execution system.
    • Self contained applications, fully embedded in a single directory that require no installation.
    • A set of supported APIs that will run in the Sandbox execution system.
    • A public contract for extension points.

    The Sandboxed Execution System: would prevent applications from touching the registry, installing any drivers, any hooks, any visualizers or any other deep integration features that applications typically use to integrate with the OS.

    The sandboxed execution system would prevent applications from looking at the file system, except for locations that have been predetermined for sharing.

    The kernel would have to enforce what files they get access to, what devices and what components they get access to. And should be set to a bare minimum.

    Self Contained Applications would be required to install software from the network, or from their appstore. These applications would get absolutely no rights to modify anything outside their directory. Any extension points that they could register with the system ("open with") would have to be registered with the public extension point contract.

    Public Contract for Extension Points Any extension points like "open with", or handlers for mime-types would be self contained in a manifest in the application directory.

    Instead of having every app poking at the system registry and dumping their junk everywhere, applications would list all of their requirements from the operating system on the manifest and the OS would rebuild its internal data from all of the application manifests available from a user.

    Limited APIs: File access APIs, display access APIs would have to be altered to give applications limited access to the host operating system, and to give them as little access to anything that most applications do not need.

    The above obviously does not apply to frameworks like the .NET framework, Java or Adobe's AIR. But beyond frameworks, there are very few cases where an application really should have legitimate access to all of the features in the OS. Video games certainly do not need it, and even applications like Visual Studio would not need it.

    Posted on 28 Jun 2010

    Moonlight 3.0, Preview 7

    by Miguel de Icaza

    Chris Toshok has just announced our 7th preview of Moonlight 3.0. You can get it from our preview site.

    What is new in this release:

    • Roughly API complete to SL4.0 beta. Next preview will be API compatible with SL 4.0 RTW.
    • Video capture support, but support for pixel formats is sparse. right now the supported formats are YUYV and YV12/YUV420 (planar).
    • SSE2 fast paths for gradient fills in the embedded pixman/cairo, this improves performance significantly as some people seem to have discovered the use of gradients.
    • Fixes for chrome support and to our curl bridge.
    • Several html bridge fixes.
    • element to element binding.
    • Client HTTP stack
    • cascading (BasedOn) styles are now supported
    • new right-click dialog so we can (finally!) managed isostore usage.

    Posted on 18 Jun 2010

    Infragistics Announces Support for Mono

    by Miguel de Icaza

    Today Infragistics announced that their NetAdvantage for ASP.NET will support Mono out of the box.

    We loved working with Infragistics on this project, and I am very proud of the work that the Mono team did to get these fabulous controls working with Mono.

    You can read more about Infragistics and Mono on Infragistics site where you can also try out some of their sample applications running on Linux with Mono.

    From the press release:

    "In recent years, our customers have indicated that their organizations are moving to mixed IT environments and require UI tools that enable them to deploy applications in either Windows or open source environments," said Dean Guida, CEO of Infragistics. "With Mono compatibility in our ASP.NET toolkit, we enable developers who have a need for open source development to create UIs that are the basis for Killer Applications and deliver the best user experiences possible."

    Infragistics ASP.NET toolset excels in top performance, flexibility and usability and enables developers to build rich Web applications for line of business. By providing full compatibility with the Mono runtime, Infragistics extends this functionality to the Mono community.

    Coinciding with today's NetAdvantage for .NET 2010 Volume 2 availability, Infragistics highlights the ASP.NET toolkit's Mono compatibility through Sample Showcase hosted on a live Linux Server running Mono:

    For us this is a very important milestone as developers building .NET applications need to complement the core framework with packaged components like the ones that Infragistics provides.

    It also shows the maturity of the project, as commercial ISVs start supporting more Mono on Linux.

    Posted on 16 Jun 2010

    We have released MonoDevelop 2.4

    by Miguel de Icaza

    We have finally released MonoDevelop 2.4. You can read a high-level description of the changes or see screenshots with the details. I would go for the screenshots myself.

    We made packages for OpenSUSE, SLES, Windows and MacOS X. For other Linux distributions, you should consult with your favorite package provider or you can build it yourself from sources.

    Congratulations to the team. They not only improved the UI and the editing experience, but they support Gtk#, ASP.NET MVC, Silverlight, MonoMac and MonoTouch deployments from the same IDE. We have also added support for WCF references and T4 macro processing.

    Next Steps for MonoDevelop

    For the next release we have a couple of big goals in mind for MonoDevelop:

    • Git support, using GitSharp.
    • Mono on Android support (debugging, templates, deployment).
    • Templates and support for MVC2.

    Support for Foo is missing

    As you can see from our list of MonoDevelop Tasks there are plenty of tasks that currently have nobody assigned to. This includes even popular features like F#, IronPython, IronRuby or PHP support.

    We have limited resources and a huge wish-list. If you want to help us take on any of those tasks, please join us on IRC at on channel #monodevelop, or join our mailing lists.

    Posted on 16 Jun 2010

    Road to MonoDevelop 2.4: Navigation

    by Miguel de Icaza

    Perhaps my favorite feature in MonoDevelop 2.4 is the "Navigate To" functionality that we added. This new feature is hooked to Control-comma on Linux and Windows and to Command-. on Mac.

    This feature lets you quickly jump to a file, a class or a method:

    I used to navigate between my files by opening then from the solution explorer, and then using Control-tab or the tabs. Needless to say, the old way just felt too clumsy for a fast typist like me.

    With Navigate-To, I can just hit the hotkey and then like I would in Emacs, type the filename, type or method and jump directly to the method. This is fabulous.

    This will also search substrings, so you can either start typing the name of a method or you can fully qualify the method (for example: "Vector.ToString").

    But it gets better, you can use abbreviations, so instead of typing "DialogViewController" you can just type "dvc":

    BREAKING UPDATE Michael just told me of a cute extra feature: if your match is for a filename, if you type ":NUMBER" it will jump to the selected file to the specified line number.

    The result:

    Posted on 14 Jun 2010

    Conditional Attribute

    by Miguel de Icaza

    One cute feature of C# 1.0 was the introduction of the Conditional attribute. When you apply the conditional attribute to a method, calls to this method are only included in the resulting code if the appropriate define is set.

    For instance, consider:

    	[Conditional ("DEBUG")]
    	void Log (string format, params object [] args)
    		Console.WriteLine (String.Format (format, args));

    Calls to Foo.Log become no-ops unless you pass the -define:DEBUG command line option to the compiler.

    What is interesting about this compiler-supported feature is that that the code inside the method Log is checked for errors during compilation as any other regular method. They are first class citizens.

    Posted on 12 Jun 2010

    My first iPhone app

    by Miguel de Icaza

    I am proud to introduce my first iPhone App built entirely using standard HTML5 technologies.

    I felt that I had to go with HTML 5 as I did not want to write the app once for the iPhone and once for the Android. I am also open sourcing this application in its entirety, to help future generation of mobile HTML 5 developers learn from my experiences and hopefully help them write solid, cross platform mobile applications using HTML 5.

    I use this app every time we go to a pub, or when we are having lunch at the Cambridge Brewing Company.

    Before you check it out, my lawyer has advised me that I need to add the following disclaimer:


    I give you: iCoaster.

    Stay tuned for my Cheese Table app, coming soon to the iPad.

    What People Are Saying about iCoaster!

    From my survey on iCoaster for iPad:

    "I am currently resorting to use my four iPhones to create one giant iCoaster; this is ridiculous. Need iCoaster HD!!!!"

    "Buying an iPad every time I want to put a drink down is expensive, though it is better than getting those little rings all over my shiny new table."

    "Four coasters per iPad would be ideal"

    "Please keep up the great work. Not sure what I would do without this app, would at least have a lot of ruined coffee tables."

    Sadly, we do have some bugs being reported, and I can assure everyone that I am working around the clock to fix these issues. Ensuring that iCoaster is reliable is my top priority:

    "If I put my drink on iCoaster, and then rotate my phone to the landscape orientation, my drink gets spilled onto my lap. Please fix this in the iPad version."

    Survey Results as of 14:50 EST


    Update: We have confirmation that it works on WebOS and Blackberry as well. HTML5 FTW!

    Update 2: Due to popular demand, I am launching an effort to bring iCoaster to the iPad. If you want to participate in the beta for iCoasterHD, please fill in this survey, your feedback will help me prioritize features.

    Update 3: iCoaster works on walls too:

    Update 4: For those of you complaining about the missing DOCTYPE Geoff Norton has done what any honorable open source contributor would have done: he forked iCoaster and made it HTML "compliant": icoaster-fork.

    Update 5: After today's brouhaha over Apple's HTML 5, Mike Shaver from Mozilla talks about the elephant in the room.

    Update 6: iCoaster's HTML 5 fork has been forked to support full-screen on WebKit and Opera browsers.

    Update 7: We have a Silverlight port! This enables iCoaster to run on the upcoming Windows Compact Edition Media 7 Series Phone Embedded Release Plus Pro Advanced.

    Update 8: We got a Unity port of iCoaster, and showing true open source spirit, sethillgard open sourced the code.

    Posted on 04 Jun 2010

    First Beta of MonoTools 2 for VisualStudio

    by Miguel de Icaza

    Last week we released our first beta for the upcoming MonoTools2.

    There are four main features in MonoTools 2:

    • Soft debugger support.
    • Faster transfer of your program to the deployment system.
    • Support for Visual Studio 2010 in addition to 2008.
    • Polish, polish and more polish.

    Getting Started

    Download our betas from this page. On Windows, you would install our plugin for either 2008 or 2010 and you need to install Mono 2.6.5 on the target platform (Windows, Linux or MacOS).

    On Linux, run `monotools-gui-server' or `monotools-server', this will let Visual Studio connect to your machine. Then proceed from Windows.

    On MacOS, double click on the "MonoTools Server" application.

    Once you run those, MonoTools will automatically show you the servers on your network that you can deploy to or debug:

    ASP.NET debugging with this is a joy!

    Soft Debugger

    This release is the first one that uses our new soft debugger. With is a more portable engine to debug that will allow our users to debug targets other than Linux/x86 for example OSX and Windows.

    This is the engine that we use on MonoTouch and that we are using for Mono on Android.

    Our previous debugger, a hard debugger, worked on Linux/x86 systems but was very hard to port to new platforms and to other operating systems. With our new soft debugger we can debug Mono applications running on Windows, helping developers test before moving to Linux.

    Faster Transfers

    When you are developing large applications or web applications, you want your turn around time from the time that you run hit Run to the site running on Linux to be as short as possible.

    Cheap Shot Alert: When dealing with large web sites, we used to behave like J2EE: click run and wait for a month for your app to be loaded into the application server.

    This is no longer the case. Deployments that used to take 30 seconds now take 2 seconds.

    Support for Visual Studio 2010

    Our plugin now supports the Visual Studio 2010 new features for plugin developers.

    This means you get a single .vsix package to install, no system installs, no registry messing around, no dedicated installers, none of that.

    The full plugin installs in 3 seconds. And you can remove it just as easily.

    Then you can just from VS's Mono menu pick "Run In Mono" and pick whether you want to run locally or remotely.

    We now also support multiple profiles, so you can debug from Visual Studio your code running on Linux boxes, Mac boxes or your local system.

    Polish and more Polish

    MonoTools was our first Windows software and we learned a lot about what Windows developers expected.

    We polished hundreds of small usability problems that the community reported in our last few iterations. You can also check our release notes for the meaty details.


    And we integrate directly with SuseStudio to create your ready-to-run appliances directly from Visual Studio.

    Posted on 03 Jun 2010

    Linux for Consumers: MeeGo Updates

    by Miguel de Icaza

    Excited to see the work happening on the Linux consumer space in the MeeGo Universe. There is now a MeeGo 1.0 download available for everyone to try out.

    At Novell we have been contributing code, design and artwork for this new consumer-focused Linux system and today both Michael Meeks and Aaron Bockover blog about the work that they have been doing on MeeGo.

    These screenshots are taken directly from Aaron's and Michael's blog posts. Aaron discusses the new UI for the music player Banshee and Michael discusses the new UI for the Email/Calendar program.

    Media Panel in MeeGo

    You can still get access to the full Banshee UI themed appropriately:

    Themed MeeGo UI for Banshee

    Check Aaron's blog for the details on the design process and the new features coming out for it.

    Then, on the Evolution side of things Michael discusses Evolution Express a renewed effort to make Evolution suitable for netbooks. The work done there is amazing, here are some screenshots:

    Evolution Express on MeeGo

    Just like Banshee, Evolution now integrates with MeeGo panels, like this:

    Summary of your tasks on the MeeGo Panel

    This is what the new preferences panel looks like:

    Themed MeeGo UI for Banshee

    And finally the calendar:

    Evolution Express Calendar on MeeGo

    Third Party Applications

    You can also run existing Mono applications on MeeGo. I give you the photo management application F-Spot:

    F-Spot on MeeGo

    And this is Jonathan's Pinta painting program built on Mono with Gtk#:

    The Mono-based paint program Pinta

    Pinta is fascinating as it shows how much punch can be packed by CIL code. Pinta and all of its effects use 328k of disk space and for distribution it only takes 108k of disk space.

    Development Tools

    And we are of course very happy to be supporting developers that want to target MeeGo using Windows, Mac or Linux with our MonoDevelop plugin for MeeGo.

    If you are more of a Visual Studio developer, our upcoming MonoTools for Visual Studio 2.0 will also support developing applications for MeeGo from Windows.


    I am blown away by the way that everyone involved in MeeGo has been able to execute on the vision of bringing Linux to the consumer space by the way of the netbook.

    Kudos to everyone involved.

    Posted on 27 May 2010

    MonoDroid - Mono for Android Beta Program

    by Miguel de Icaza

    We are hard at work on MonoDroid -- Mono for Android -- and we have created a survey that will help us prioritize our tooling story and our binding story.

    If you are interested in Monodroid and in participating on the beta program, please fill out our Monodroid survey.

    Here is what you can expect from Mono on Android:

    • C#-ified bindings to the Android APIs.
    • Full JIT compiler: this means full LINQ, dynamic, and support for the Dynamic Language Runtime (IronPython, IronRuby and others).
    • Linker tools to ship only the bits that you need from Mono.
    • Ahead-of-Time compilation on install: when you install a Monodroid application, you can have Mono precompile the code to avoid any startup performance hit from your application.

    We are still debating a few things like:

    • Shared Full Mono runtime vs embedded/linked runtime on each application.
    • Which IDE and OS to make our primary developer platform. Our options are VS2010, VS2008 and MonoDevelop and the platforms are Windows, OSX and Linux.

      We are currently leaning towards using VS2008/2010 for Windows during the beta and later MonoDevelop on Linux/Mac.

    Like we did with MonoTouch, we will bring developers into the preview in batches of 150 developers, please enter enough information on the "comments" section if you want to be in the early batches.

    Posted on 21 May 2010

    Group Completion in MonoDevelop 2.4

    by Miguel de Icaza

    In our Beta for MonoDevelop 2.4 we introduced a new feature designed to help developers better explore a new API.

    Many developers use the IDE code-completion as a way of quickly navigate and explore an API. There is no need to flip through the documentation or Google for every possible issue, they start writing code and instantiating classes and the IDE offers completion for possible methods, properties and events to use as well as small text snippets describing what each completion does as well as parameter documentation:

    With MonoTouch, we were dealing with a new type hierarchy, with new methods. We found that our users wanted to explore the API through code completion, but they wanted more context than just the full list of possible options at some point.

    For example, the UIButton class has this hierarchy:

    Looking through the methods, properties and events of this class can be confusing, as for the UIButton class there were some 140 possible completions that came from the complete hierarchy. Sometimes the user knows that the method they want is a button-specific method, and as fascinating as UIResponder, UIView or UIControl might be, the method they are looking for is not going to be there.

    With MonoDevelop 2.4 we introduced a new shortcut during code completion that changes the completion order from alphabetic to grouped by type, with completions from the most derived type coming up first:

    To switch between the modes you use Control-space when the popup is visible. You can use shift-up and shift-down to quickly move between the groups as well.

    I have been using this feature extensively while exploring new APIs.

    Posted on 09 May 2010

    MonoDevelop's New Search Bar

    by Miguel de Icaza

    MonoDevelop 2.4 was a release in which we focused on improving the ergonomics of the IDE. We did this in dozens of places and we did this by dogfooding the IDE and comparing it to other tools and environments that we have been using.

    With MonoDevelop 2.0 and earlier we used a dialog box like most other GUI applications from 2005. The dialog would remain on top of the text and the user would press next, and move the dialog box around as the matches were found.

    In the current MonoDevelop (2.2) we adopted a more Firefox-like UI, this is what the search bar looks like:

    We have a relatively big bar at the bottom of the screen, big labels, a drop down for picking previously searched items and an options menu that would let users pick manually case sensitivity, whole world matching or toggling regular expressions.

    This took too much space, in a prime location of screen real estate. Additionally, the features although present were hard to pick. You would start an incremental search with Control-f but if you wanted to change the settings, you would have to use the mouse to access the options menu. If you later changed your mind, you would have to change the defaults again.

    With the new release of MonoDevelop (2.4) we have changed this again, this time adopting the Google Chrome search bar and done a few other usability changes:

    The first thing to notice is that instead of taking valuable horizontal space in the form of a full row, we now only take a corner of the screen, and we take it on the top right corner which is less likely to contain the information you are looking for as you search forward.

    Case sensitivity searches now use the same model used by Emacs. If you start searching for a term and you type only lowercase letters, the search will be case insensitive.

    Searching for "thread" will match "thread", "Thread" or "THREAD". But if at any point during the search you type an uppercase letter, then the search for this particular activation will switch into case-sensitive search. Searching for "Thread" will only match the word "Thread" and not "thread" or "THREAD".

    And we also highlight matches like some Mac applications do, all matching words in the screen are highlighted, and the current match gets both a brighter color as well as a bubble that inflates and deflates on every match.

    The replace functionality is built into this new UI, and is accessed either with a hotkey (Control-H) or by clicking on the left-side icon:

    Just like Google Chrome, we use a watermark to show the number of matches in the document.

    MonoDevelop 2.4 is packed with new features, and I hope to blog about some of the design decisions of the new feature as time permits. In the meantime, check out the list of new features in the Beta for MonoDevelop 2.4.

    Posted on 06 May 2010

    Pinta 0.3 is out

    by Miguel de Icaza

    Jonathan Pobst has announced the release of Pinta 0.3:

    Live Preview

    Pinta is a lightweight paint application for Linux, OSX and Windows written entirely in C# and using the Gtk# toolkit for its user interface. From the FAQ:

    Is Pinta a Port of Paint.NET?

    Not really, it's more of a clone. The interface is largely based off of Paint.NET, but most of the code is original. The only code directly used by Pinta is for the adjustments and effects, which is basically a straight copy from Paint.NET 3.0.

    Regardless, we are very grateful that Paint.NET 3.0 was open sourced under the MIT license so we could use some of their awesome code.

    Jonathan further adds that this release is very close to feature parity with the original Paint.NET.

    Posted on 03 May 2010

    CLI on the Web

    by Miguel de Icaza

    In the last few days Joe Hewitt has been lamenting the state of client side web development technologies on twitter. TechCrunch covered the progress in their The State Of Web Development Ripped Apart In 25 Tweets By One Man.

    Today Joe followed up with a brilliant point:

    joehewitt: If CLI was the ECMA standard baked into browsers instead of ECMAScript we'd have a much more flexible web:

    ECMA CLI would have given the web both strongly typed and loosely typed programming languages. It would have given developers a choice between performance and scriptability. A programming language choice (use the right tool for the right job) and would have in general made web pages faster just by moving performance sensitive code to strongly typed languages.

    A wide variety of languages would have become first-class citizens on the web client. Today those languages can run, but they can run in plugin islands. They can run inside Flash or they can run inside Silverlight, but they are second class citizens: they run on separate VMs, and they are constrained on how they talk to the browser with very limited APIs (only some 20 or so entry points exist to integrate the browser with a plugin, and most advance interoperability scenarios require extensive hacks and knowing about a browser internal).

    Perhaps the time has come to experiment embedding the ECMA CLI inside the browser. Not as a separate plugin, and not as a plugin island, but as a first-class VM inside the browser. Running side-by-side to the Javascript engine.

    Such an effort would have two goals:

    • Access to new languages inside the browser, optionally statically typed for major performance boosts.
    • A new platform for innovating on the browser by providing a safe mechanism to extend the browser APIs.

    We could do this by linking Mono directly into the browser. This would allow developers to write code like this:

    <script language="csharp">
    from email in documents.ElementsByTag ("email")
    	email.Style.Font = "bold";

    Or pulling the source from the server:

    <script language="csharp" source="ImageGallery.cs"></script>

    We could replace `csharp' with any of the existing open sourced compilers (C#, IronPython, IronRuby and others).

    Or alternatively, if users did not want to distribute their source and instead ship a compact binary to the end users, they could embed the binary CIL directly:

    <script language="cil" source="MailApp.dll"></script>

    Pre-emptive answer to the "view-source" crowd: you can use .NET Reflector to look at the source code of a compiled binary. If it is obfuscated, you will enjoy reading that as much as you would enjoy reading any Javascript in the real web.

    Embedding the CIL on the browser would create isolated execution environments for each page (AppDomain in ECMA parlance) and sandbox the execution system.

    The security model exposed by Silverlight exposes exactly what is needed to go beyond a language-neutral runtime. The security model distinguishes between untrusted code which is subject to verification, strict requirements on what it can do and limits what they can do from "platform" code that is trusted.

    Trusted platform code is granted special permissions that untrusted code is not given. The runtime enforces that no untrusted code can call into any security sensitive and protected areas.

    This would allow browser vendor to expose new APIs that get full access to the underlying operating system (for example getting direct access to special hardware on the system like microphones and camera) while enforcing that the user code accesses them only through safe gateways.

    This is very important to allow developers to try out new trusted APIs: new UI models, rendering systems and APIs built entirely on the same core.

    I am absolutely fascinated by the idea and I only regret not having come up with it. We have been too focused on the Moonlight-as-a-plugin to take a step back and think in more general terms: how can we use the ECMA CIL engine for *all* applications without a browser plugin.

    Joe like many of us is conflicted between the power of reach that the web has versus the polish and speed that native GUI toolkits deliver.

    Althought Silverlight provides a nice UI system inside the plugin, Joe's point is that we need a platform in which we can more quickly innovate new UI ideas, and probably completely different new ideas quickly. And with the ECMA sandbox model we can start testing new ideas without waiting for browser vendors to add the features themselves and we can make the integration between these plugins and the browser stronger than they have ever been.

    The plugin model does not provide the necessary tools to drive more innovation in the web. We need a new model, and I am ready to start prototyping Joe's idea.

    The only question is what browser to target first Firefox or Chrome.


    Gestalt allows developers to use the CLI inside the browser and it shows what can be done with other languages in the browsers. It requires Silverlight to run and the interaction between the code and the browser is limited in the level of integration that can be achieved via the browser-plugin interface.

    This solves only the half the problem: multi-languages and does it in a limited way.


    You can learn more about the security model in my previous blog post.

    Our open source Silverlight implementation.

    Posted on 03 May 2010

    MonoTouch and Apple's Section 3.3.1: Two Theories

    by Miguel de Icaza

    Before April 8th, developers targeting the iPhone had to deal with this section:

    3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.

    The above is a pretty reasonable requirement as it gives Apple the chance to not have to maintain and support internal APIs, temporary APIs or APIs that have not fully matured.

    When iPhoneOS 4.0 was announced, the wording was changed to:

    3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

    This spelled disaster for many developers that had chosen to use other programming languages like C#, Delphi, Lua, Python, Javascript, Java, Scheme, ActionScript and a handful of others. It also put a stop to porting efforts for languages like Eiffel and other industrial languages that can be used on the iPhoneOS and the iPad.

    Much of the discussion for the rationale of these changes on the blogosphere has centered around personal language preferences. They amount to little more than the usual discussions of Mac vs PC or Emacs vs VI.

    When Greg from Tao Effect discussed this with Steve Jobs his reply shed light into the reason. There is a business reason, and possibly a UI reason. Here are my theories.

    Theory #1: The Business Case

    With the iPhone Apple revolutionized the phone market in a way that nobody had planned for. Microsoft, Nokia, RIM, HTC and everyone else was left to catch up with the user experience and the operating system. One year after the iPhone took the world by surprise, Apple opened up the developer stack, launched the AppStore and leapfrogged every competitor in the field.

    Apple had the first mover advantage in a space that they created: the high-end smart phone market.

    The problem that Apple faces is that now every competitor has a blueprint of what they need to aim for. Competitors now know what the minimum required user experience and features required are. And they all likely have plans on how they can differentiate themselves and add features that Apple does not have.

    And this is where Adobe enters the picture.

    Flash and Flex have a huge user base of developers that have been building web and desktop applications for the past few years.

    Although Flash applications on the iPhone do not look and act like native iPhone applications they are useful for a certain class of development. It would very likely attract Flash developers to the iPhone, but also Objective-C developers to Flash. Developers that probably are not interested in creating UITableViews or using the low-level APIs, but wanted to focus more on the interactive content creation or exploring new UI ideas or games.

    Flash's killer feature would be that the same code that ran on the iPhone would run on many devices with minimal changes. The applications do look alien on every platform, but not every application needs to use native controls. Games, storyboards, marketing tie-ins and a whole new class of ideas do not need a native UI.

    Flash would erode some of Apple's first mover advantage in the market they created. So section 3.3.1 was added to protect Apple's shareholder's interests.

    Apple being the #1 platform for mobile applications and being the largest distribution channel for those applications probably felt that it would be ok to do.

    Eventually, Android, Windows Mobile 7 and Nokia will catch up in terms of UI with Apple. It might take a few years before there is a marketplace as large as Apple's AppStore and a few years before these phones catch up to Apple's dominance in the space.

    My prediction is: When those platforms do catch up to Apple in terms of market share and applications Apple will lift the restrictions on section 3.3.1. Apple at that point will have nothing left to lose and everything to gain. Adobe will also bring Flash back to the iPhone as it will be a nice bump in revenues.

    Theory #2: The UI

    As I mentioned before, using cross-platform solutions like Flash or Silverlight would make every application look alien. But also like Steve Jobs alluded to, developers would not have access to new features on the iPhoneOS if they had chosen a technology that did not expose it.

    For example, when Apple introduced in iPhoneOS 3.2 the new split views that the iPad uses extensively when rotating your screen, that functionality would have taken too long to bring in a satisfactory way to say Silverlight on iPhone or Flash on iPhone. Or when Apple introduced the UIView that can be used to render maps, it would also have been challenging to embed this control. Or when Apple introduced GameKit, an API to connect iPhones and exchange messages between them.

    As a developer, I feel that I should be responsible for my technological choices. If I pick a cross-platform toolkit that looks horrible on the iPhone, it will just leave the space open for a competitor to do a better job. Or if my application does not take advantage of a new API in iPhoneOS, I am also leaving a flank open for a competitor to take over. Apple does not need to intervene with guidelines as the application quality, the AppStore, magazines, reviews and word of mouth are creating the conditions for an all-out darwinian survival of the fittest.

    Why MonoTouch has been misrepresented

    MonoTouch has been misrepresented, initially by Gruber and by most people covering the debate over section 3.3.1. Probably because few of them have actually used MonoTouch or because they are not familiar with .NET. Probably folks think that MonoTouch is .NET, and .NET is Microsoft's Java and draw their own conclusions.

    MonoTouch brings the C# language and the core of .NET to the iPhone, but does nothing to provide a cross-platform UI experience or for that matter any sort of mobile device cross-platform APIs.

    We bring the C# language, garbage collection, a type safe system that help reduce errors, make programmers happier and more productive on the iPhone while getting access to every single iPhoneOS API that they want to.

    We have also been able to expose new APIs that Apple has exposed in record time thanks to the fact that we are not really an abstraction layer over the iPhoneOS, but merely a compiler that talks to the native APIs.

    We released the iPad support 24 hours after Apple released the SDK. We released the iPhoneOS 4.0 support within days of the release (mostly because every one of us was pretty bummed out). Our APIs are a 1:1 mapping to the iPhone APIs.

    Just like C and C++, if developers want to reuse code between MonoTouch, Windows 7 or MonoDroid, they will have to split their UI and device-specific code from their business logic. MonoTouch does not provide such an abstraction layer.

    The "core of .NET" that I refer to previously means: garbage collection, type safety, the platform-invoke bridge, file and networked streaming APIs (contrast with the iPhone ones), XML and Json libraries, Language Integrated Query, access to web services and the ability to reuse hundreds of GUI-less libraries that have been created for .NET.

    We believe that MonoTouch does not erode Apple's first mover advange and nourishes the iPhone ecosystem by giving developers and users the native iPhoneOS experience.

    Posted on 28 Apr 2010

    Mono's C# Compiler as a Service on Windows.

    by Miguel de Icaza

    The Mono team is proud to bring you a preview of C# 5.0 a few years before our friends in Building 41 do.

    A snapshot of the code is available in the file. This contains the csharp.exe C# REPL shell and the Mono.CSharp.dll compiler-as-a-service assembly.

    With Today's code drop all those scenarios now work:

    • Run Mono's C# compiler on .NET
    • Embed Mono's Evaluator in your C# app.
    • Use Mono's REPL with the .NET framework runtime.

    Update April 28th: I have now uploaded a new version that fixes the bug that people were getting when importing other libraries. Thanks to Marek for the rapid fix.


    Although we have had a compiler-as-a-service framework since September of 2008 it has been so far limited to Mono users, which effectively means only Linux and OSX users could use our C# REPL and the compiler as a service.

    The reason is that the Mono's C# compiler uses System.Reflection.Emit as its code generation backend. This API was fine for implementing C# 1.0 but required a few changes to support compiling its own core library (mscorlib, the equivalent of libc in C or rt in Java).

    When we started to work on our C# 2.0 support, we were working on our compiler as the language was being standardized at ECMA. Our compiler evolved faster than the underlying support for Reflection and Reflection.Emit did and this lead to more Mono-specific extensions being added to our Reflection and Reflection.Emit code. The more extensions that we depended on, the fewer chances we had of running with Microsoft's runtime.

    As time went by, Microsoft did improve their System.Reflection.Emit, but at that point, it was too late for us to go back to it.

    This had the unfortunate side effects that our compiler could not run on the Microsoft runtime. Now, this per se is not a major problem since Windows users likely use Microsoft's CSC compiler.

    But this also meant that our awesome compiler as a service could not be used by .NET developers and it also meant that our REPL shell could not be used with .NET and most importantly, neither one would run on Silverlight.

    Our compiler also relied heavily on our extended System.Reflection and System.Type as its own type system. And we could not just change our APIs for Microsoft's APIs to run on the Microsoft runtime.

    Today's commit at the coref replaces our dependency on System.Type and introduced our own Mono.CSharp.TypeSpec which lifts many of the restrictions that we had on System.Type. All of the hard computations that we had to do for inflating generics types are done here now and we can query the types without the backward Reflection limitations.

    With today's changes, not only we became more portable, but the move from System.Type to TypeSpec and MemberCache improved the compiler performance by 30% and fixes dozens of bugs that were very hard to fix with the previous compiler architecture.

    REPL Love

    We have a small guide on using the C# REPL on Linux.

    Caveat: both the Microsoft and the Mono C# compilers loads libraries from their "base directory", never from the Global Assembly Cache.

    In Mono, the csharp command happens to be in the same directory as the rest of Mono, so loading implicit libraries just works (Loading System.Core for example). But when running our csharp command on Windows, unless you put the binary in the same location as csc.exe the REPL wont be able to load libraries using their short names.

    This is particularly obnoxious because to use LINQ you need to use the full assembly name, or copy csharp.exe to the directory that contains System.Core so you can just do:

    	csharp> using System.Linq;
    	csharp> from x in "Foo" select x;

    Future work

    Public API: There is still some work left to do: we need to turn 99% of the public API in that assembly into a private API, the only class you should care about is the Mono.CSharp.Evaluator class, the rest you should consider internal.

    The Evaluator API needs to evolve, right now it is a big singleton that exposes all of the variables defined as global variables. They really should be tied to some kind of context so we can support multiple and independent execution contexts on the same address space.

    Chances are that we want to expose some of the internals of the compiler to the world, but we first need to figure out what makes sense.

    Now that the code runs on .NET, hopefully those of you that wanted to embed it can provide us some feedback on how you would like to see this API change or even better, provide patches for it.

    C# as a DLR language: Someone had suggested to also provide a hook into the DLR, so you can instantiate C# eval engines with the same API that you instantiate IronPython and IronRuby eval engines.

    Silverlight support: in theory this works out of the box, but we have not tested it yet.

    Contributions: Yes, we are accepting contributions to this awesome compiler.

    Keybindings: Currently the csharp command line repl uses Emacs keybindings as part of my fabulous getline.cs command line editor. We are aware that developers of different faiths might find other keybindings more appropriate. We are taking patches.

    Add support for IKVM Reflection: Jeroen has written a drop-in replacement for System.Reflection[.Emit] that will allow us to decouple the compile from the profile that it compiles code for (Monoistas are familiar with dmcs, smcs, gmcs and mcs; We will be able to have a single compiler).

    Source Code and Hacking

    The source code for Mono's C# compiler, the Compiler as a Service and the interactive REPL are all available from SVN, do a checkout from our subversion repository for the module "mcs".

    Download from GitHub the "mono" module

    Then open the VS2008 solution in mcs/tools/csharp. This will build the Mono.CSharp compiler as a service library and the csharp tool.

    We do not typically provide VS Solution files for most of Mono, but we are making an exception for the compiler as a service to encourage .NET developers to play with it.

    Update: Our compiler is MIT X11 licensed, so even developers at Microsoft can download this code and look at it. It is all kosher guys!

    Posted on 27 Apr 2010

    MonoMac Bindings: Blending Cocoa and .NET on OSX

    by Miguel de Icaza

    Today we released MonoMac, a new foundation for building Cocoa applications on OSX using Mono.

    MonoMac is the result of years of experimentation in blending .NET with Objective-C and is inspired by the same design principles that we used for MonoTouch.

    It is also the result of weekend hacking as our day to day work revolves around Mono's efforts on Linux servers, Linux desktops, Visual Studio integration and our mobile efforts. Luckily, it shares some components with MonoTouch.

    To get MonoMac, you need to get two modules from GitHub: monomac and maccore.


    Many years ago Geoff Norton produced CocoaSharp, the first set of .NET bindings to the Cocoa API. CocoaSharp was a fine first binding at the time and it was a good place to start learning about the challenges of binding Objective-C APIs to be consumed by .NET clients.

    Over the years three other frameworks were created to integrate the Objective-C world and the Objective-C APIs with C# and other .NET languages. Each one of these new frameworks had its pros and cons, and a year ago we made a call for all three competing frameworks to be merged, but sadly nothing came out of it.

    When we created MonoTouch, we wanted a binding for the Cocoa APIs that would fit the patterns and idioms used in the C# and .NET worlds, that would comply with the .NET Framework Design Guidelines and would allow give developers all the tools required to build full Cocoa applications.

    We had two main requirements: the binding should just work and the code should be MIT X11 licensed. For the binding to just work, we turned to the .NET Framework Design Guidelines book as it captures years of design decisions, programming idioms and advise that would help C# and .NET developers. By following the Design Guidelines we:

    • Avoid surprises
    • Blend with other C# and .NET libraries
    • Reduce the room for errors
    • Increase developer joy
    • Minimizes time for the developer to be productive
    • Every bit of existing .NET knowledge translates

    Luckily for us, .NET was designed from the start to be an interoperability framework. A framework that supports the most advanced requirements to make multiple runtimes and frameworks to communicate seamlessly with each other. We used these features to create our bindings.

    The above goals turned into the following technical requirements:

    • Developers should be able to consume Cocoa APIs as C# APIs
    • Allow developers to subclass Objective-C classes
      • Subclass should work with C# standard constructs
      • Derive from an existing class
      • Call base constructor
      • Overriding methods should be done with C#'s override system
      • Do not expose developers to Objective-C selectors
    • Provide a mechanism to call arbitrary Objective-C libraries
    • Make common Objective-C tasks easy, and hard Objective-C tasks possible
    • Expose Objective-C properties as C# properties
    • Expose a strongly typed API, for example instead of exposing the generic-container NSArray or individual NSObjects. This means that developers get a few benefits:
      • MonoDevelop can flag errors as you write the code
      • MonoDevelop can present documentation popups on types, methods, properties and parameters as you type them.
      • Minimize runtime errors by catching invalid casts at compile time.
      • Encourage in-IDE API exploration without rebuilding, and without having to look up the types in the documentation.
    • Turn int and uint parameters that should have been enums as C# enumerations and C# enumerations with [Flags] attributes
    • Expose the basic Foundation as C# native types:
      • NSString becomes string
      • NSArray becomes strongly-typed array
    • Events and notifications, give users a choice between:
      • Support the Objective-C delegate pattern:
        • Strongly typed version is the default
        • Weakly typed version for advance use cases
      • C# event system
    • Class libraries should be MIT X11 licensed, like the rest of Mono's class libraries.
    • Expose C# delegates (lambdas, anonymous methods and System.Delegate) to Objective-C APIs as "blocks".
    • Curated APIs: there is no point in binding every UNIX or CoreFoundation C API available, as those are not very useful in practice. Bind only those that are required to build applications or get access to mandatory functionality.

    More information about our API can be found here:

    Binding Cocoa

    Cocoa consists of two sets of APIs, one set is an object oriented C-callable API and another one is the Objective-C based API.

    C-based APIs were bound using a traditional P/Invoke approach where the C-based API is wrapped in a C# class. This includes APIs like AudioToolbx, CoreGraphics, CoreFoundation and CoreText. There is very little magic in these bindings, they are straight forward bindings, similar in spirit to what you would do if you wrapped those APIs for C++ use. I am in particular very proud of the much simpler AudioToolbox API.

    The Objective-C APIs is where the UI heavy lifting takes place and where most of the high-level functionality is found, and this includes APIs like Foundation and AppKit. The Objective-C APIs are bound using a new binding engine (MonoMac.ObjCRuntime) and the btouch binding generator.

    The btouch binding generator consumes an API contract in the form of a C# source file and generates a binding that matches the specified contract., for example, this is the API definition for the NSActionCell:

    	[BaseType (typeof (NSCell))]
    	interface NSActionCell {
    		[Export ("initTextCell:")]
    		IntPtr Constructor (string aString);
    		[Export ("initImageCell:")]
    		IntPtr Constructor (NSImage  image);
    		[Export ("target")]
    		NSObject Target  { get; set; }
    		[Export ("action")]
    		Selector Action  { get; set; }
    		[Export ("tag")]
    		int Tag  { get; set; }

    We produced a comprehensive guide to binding Objective-C APIs with MonoTouch that applies directly to MonoMac.

    Since a lot of the work of binding an Objective-C API is very repetitive, we have also included a header parser that does most of the heavy lifting in producing the above API from the Objective-C header file. The parser output then needs to be then massaged a bit to produce a binding that satisfies our design requirements. For example, NSArray arguments and return types must be looked up on the documentation and the proper strong typed inserted.


    Unlike MonoTouch, MonoMac is not a complete binding for all of the Cocoa APIs at this point. This has been a weekend effort for Geoff and myself but it has reached the point where it can be used for building applications and it has reached the point where we can start taking contributions to the effort.

    Currently MonoMac binds:

    • CoreFoundation (the parts that are needed, see the design principles)
    • CoreText (done)
    • CoreGraphics (done)
    • Foundation (the parts that are needed, and helper tools to support the rest)
    • AppKit (About 30% left to be done)

    If you are interested in advancing the state of MonoMac, we are currently looking for contributors to help us bind the other Objective-C frameworks and help us complete AppKit.

    Where we are going

    MonoMac is merely the library that gives C# developers access to the underlying APIs on OSX, it does not include the tooling necessary to create a full application bundle.

    Luckily, MonoDevelop has already most of the code needed in the form of the MonoTouch plugin. We will update this plugin to also support creating full application bundles for OSX.

    A new feature that developers will be interested in is the new "Mono bundler" tool that we are hoping we can include in Mono 2.8. This bundler examines your .NET application and generates an application bundle that contains both your application code and any dependencies that it needs from Mono in a self-contained package.

    This is the technology being used by Banshee on OSX today. The tool constructs a self-contained application based on your system installed Mono that you can distribute to your users, without requirement them to install Mono in the first place.

    But we need your help. There are many small and medium tasks that developers can help us with that will free our already busy weekends and will allow us to have a full MonoMac experience done in a shorter period of time.

    The more help we get, the sooner this will be done.

    We need contributors in the following areas:

    • API binding for the rest of the Frameworks
    • We need samples to be written
    • We need tutorials to be written (like the ones we did for MonoTouch)
    • We need to port existing Cocoa samples to C#:
      • To exercise the binding
      • To serve as reference for new developers
      • To identify missing frameworks
      • To prioritize bindings
    • We need to alter MonoDevelop's plugin to produce OSX Application bundles.

    Please join us on the mono-osx mailing list to discuss the future of MonoMac.

    Update Currently this requires a preview Mono to work from

    Posted on 19 Apr 2010

    MonoTouch 3.0

    by Miguel de Icaza

    We have just released MonoTouch 3.0.0 with support for iPhoneOS 4.0's new APIs. To try it out, you need to have Apple's iPhone 4.0 SDK installed otherwise MonoTouch 2.0 wont let you download the new toolkit (since it is Apple confidential at this point).

    This release is a preview, the final release will be some sort of 3.0.XX number.

    This release includes API support for the features that Apple announced last week, in broad terms:

    • Background application support
    • iAd support
    • Local notifications
    • Game Center support
    • Support for enterprise data protection

    We also sneaked in some new work that is not bound to the iPhoneOS 4.0 API and can be used when building for iPhoneOS 3.1.x and 3.2.x:

    • Size reductions:
      • Linker updates to reduce executable size
      • More fat trimmed from the final executable.
      • "Hello world" is 500k slimmer now
    • Native support for Objective-C blocks on the binding generator:
      • Exposed as C# delegates
      • Both lambdas and anonymous methods can be used as blocks
      • Standard C# semantics for variable capturing

    Posted on 16 Apr 2010

    Moonlight 3 Preview 6

    by Miguel de Icaza

    We have released a big update to Moonlight on Linux, our Moonlight 3, Preview 6.

    New in this release:

    • Chrome support and chrome packages
    • Many performance improvements
    • Most Silverlight 3 features are in now, including taking apps out-of-browser
    • Hundreds of bug fixes and improvements our Silverlight 3 compatibility story

    Remember to file bug reports. If you do not file a bug report, we have no way of knowing that something is not working.

    Posted on 16 Apr 2010

    ECMA 2010 Common Language Infrastructure Public Draft

    by Miguel de Icaza

    The ECMA working group that drives the Common Language Infrastructure standard (ECMA 335) has published the working draft for the 2010 edition of the standard.

    These are the work-in-progress documents that the team is working on.

    In addition to the Novell mirror copy above, you can get the standard from the following sites:

    Posted on 09 Apr 2010

    C#, Mono and the Google Summer of Code

    by Miguel de Icaza

    This year, Michael Hutchinson is the administrator for Mono's involvement in the Google Summer of Code.

    We are looking for motivated students that would like to either work on one of the ideas that we listed in our Student Projects page like work on MonoDevelop's IDE, Mono's runtime, Mono's class libraries and in Mono-based applications.

    Additionally, if you are a student and you have been thinking "The Mono guys really should do...", do not hesitate and propose your idea. Perhaps you get to implement your idea, get paid to do so, and be mentored by our group of awesome C and C# hackers.

    If you are a student, you can apply here and Google has a convenient list of frequently asked questions about the program.

    Remember: There are only 3 days left.

    Posted on 05 Apr 2010

    MonoTools for Visual Studio 1.1

    by Miguel de Icaza

    We just released our updated version of MonoTools for Visual Studio:

    A tool that helps Windows/.NET developers target Linux systems directly from Visual Studio, this release is still intended to be used with Visual Studio 2008 and includes some important improvements:

    • Smarter Remote File Copying
    • Automatically Detect Future Updates
    • Preview of Visual Studio 2010 Support
    • Easier Packaging of Precompiled Web Applications

    We are hard at work on our 2.0 release that will include soft-debugging support, MacOS support and will also run with Visual Studio 2010.

    Posted on 05 Apr 2010

    The Right Spirit

    by Miguel de Icaza

    From Steve Jobs 1997 presentation when he announced his partnership with Microsoft:

    Where we are right now is, we are shepherding some of the greatest assets in the computer industry.

    If we want to move forward, seeing Apple helping an prospering again.

    We have to let go of this notion that for Apple to win, Microsoft has to lose. We have to embrace the notion that for Apple to win, Apple has to do a really good job. And if others are going to help us, that's great. Because we need all the help we can get. And if we screw up and do not do a good job, it is not somebody else's fault, it is our fault.

    So I think that is a very important discussion.

    If we want Microsoft office on the Mac, we better treat the company that puts it out with a little bit of gratitude. We like their software.

    So the era of setting this up as a competition between Apple and Microsoft is over as far as I am concerned. This is about getting Apple healthy and this is about Apple being able to make incredibly great contributions to the industry and get healthy and prosper again.

    I feel exactly this way about open source. For open source to win, we do not need Microsoft, Apple or proprietary software to lose. The industry is not a zero-sum game, not only we enrich each other's platforms by exploring different ideas, but it is also incredibly healthy for the industry to have a blend of different approaches to computing.

    Open source software leads in some areas in the industry and we as a community are very proud of its success. But when it comes to the areas where open source has not delivered a full solution like our proprietary competitors have, we resort to finger pointing and blaming others.

    Some in the open source movement would like all the software in the industry to be open source/free software. Desktops, servers, games, embedded systems and everything that every human touches.

    Although it is a noble goal, it has set people up for suffering by making the goal unachievable. It has been 15 years since the rise of the first large open source companies and by now we should know that our dream of a pure open source stack ruling the world is not going to happen any decade now.

    Luckily, today, we have a much better understanding of where open source works and where it does not.

    It would do us good to ponder Steve's 1997 message:

    And if others are going to help us, that's great. Because we need all the help we can get. And if we screw up and do not do a good job, it is not somebody else's fault, it is our fault.

    Once again, I want to recommend Ben Zander's The Art of Possibility book, a book with various recipes on how to look at the world through new eyes.

    Posted on 03 Apr 2010

    Microsoft and .NET

    by Miguel de Icaza

    It seems that David's article on Windows strategy tax on .NET lacked enough context for my actual quotes in there.

    When David contacted me, he was writing a piece on the evolution of .NET and since he was speaking to Microsoft, he wanted to get feedback from other people on what we thought Microsoft got right and what they got wrong. This is how my email to David started:

    Well, I am a bit of a fan of large portions of .NET, so I might not be entirely objective. You might want to also get some feedback from a sworn enemy of Microsoft, but you should get at least the statements from a sworn enemy that has tried .NET, as opposed to most people that have strong opinions but have never used it.
    David said:
    Given your familiarity with the framework, are there any iterative changes that you find questionable or you feel require some explanation?
    There are certain areas that I do not quite like about .NET, they are not major issues as they can be either worked around or ignored (to some extent), but here are some.

    And this is where the quote on Microsoft shooting the .NET ecosystem comes from, I reproduce from my email for the sake of completeness, none of this is a secret:

    The most important part is that Microsoft has shot the .NET ecosystem in the foot because of the constant thread of patent infringement that they have cast on the ecosystem. Unlike the Java world that is blossoming with dozens of vibrant Java virtual machine implementations, the .NET world has suffered by this meme spread by Ballmer that they would come after people that do not license patents from them.

    Sun on the other hand said from day one: we will not sue you over patent infringement if you implement your own Java. Google does something similar with their APIs and Google's Wave: they are giving everyone access to their stuff.

    As the only implementor of the ECMA standards outside of Microsoft, I sure would have hoped that they had given rights to everyone to implement. They would still be the #1 stack, but it would have encouraged an ecosystem that would have innovated extensively around their platform.

    Instead, people went and innovated on Java or other platforms that might not have been as advanced as .NET, but at least they were not under Microsoft threat.

    Google could have used .NET, Rails could have been built on .NET, the Wikipedia and Facebook could have been built using ASP.NET.

    All of those are failed opportunities. Even if the cross-language story was great, the web integration fantastic, the architecture was the right one to fit whatever flavor of a platform you wanted, people flocked elsewhere.

    This is their largest mistake, and it is perhaps too late to do anything about it.

    It took Microsoft eight years, a new management and a fresh set of eyes to change some of these mistakes. The veil of threats that existed over the runtime in 2001 was lifted with the Community Promise announcement but it took eight years, and those were eight years of lost opportunity and FUD directed at all things Microsoft.

    I still believe that Microsoft lost a great opportunity of having .NET become the universal runtime of the net, and they could still have the best implementation. I still believe that they should put the rest of .NET under the Community Promise or OSP and even with Mono as an open source implementation, they would retain their edge.

    On Innovation on other Runtimes

    David quotes Ted Neward (a speaker on the .NET and Java circuits, but not an open source guy by any stretch of the imagination). Ted tried to refute my point about Java and innovation but seemed to have missed the point.

    The article attributed this to Ted: "Microsoft has made an open-source CLI implementation codenamed 'Rotor' freely available, but it has had little or no uptake".

    There is a very simple reason for that. Rotor was not open source and it was doomed to failure the moment it came out. When Microsoft released Rotor in 2002 or 2003 they had no idea what they were doing and basically botched the whole effort by using a proprietary license for Rotor.

    Rotor's license was "look but do not touch" and prohibited commercial use of it. This is a non-starter for anyone that wants to call their software open source. Had Rotor been open source, we would have just used that instead of building Mono and we would have invested in it.

    The article also gets the facts on the interest on Java virtual machines wrong. Certainly only a handful are used for large server deployments, but minor Java VMs were part of the Java culture for years. Fine-tuned versions of the JavaVM are used for all sorts of embedded scenarios and it has also been used extensively in research.

    The Jikes RVM Java implementation is still an important playground for researchers where new garbage collectors, code generator technology, large memory problems, and optimization have been prototyped and tested. The open source Kaffe was the first open source JIT engine and it lead to way for many developers to explore the problems of cross platform JIT compilation, Japhar lead the way for a full open source class library stack (this became GNU class path). The Cacao open source VM explored new code generation optimizations techniques that were eventually used by other JIT engines.

    In the industrial world, variations on Java were used for embedded systems, the most popular one today is Dalvik, Google's runtime for a Java-like runtime.

    The list above is by no means comprehensive and the above is merely the innovation that happened in the JavaVM world. What is clear is that .NET/ECMA CLI fixed a lot of the design mistakes in Java, improved in many areas and built on the knowledge that had been gained from Java.

    But my point about the ecosystem goes beyond the JVM, it is about the Java ecosystem in general vs the .NET ecosystem. Java was able to capitalize on having implementations on Linux and Unix, which accounts for more than half the web today. The Apache Foundation is a big hub for Java-based development and it grew organically.

    Had Microsoft been an open company in 2001 and had embraced diversity we would live in a different world. The awesome Mono team would probably be bigger, and the existing team members would have longer vacations.

    But for everyone that missed the point, luckily, Microsoft has new management, new employees that know open source, fresh new ideas, is becoming more open and is working actively on interoperability with third parties. They even launched the CodePlex Foundation.

    As I told David on that interview, I am still a fan of .NET, and we are going to continue working to bring Mono everywhere where we think we could improve developer's experience. We are actively working on improving Mono on Linux, Mono for MeeGo, Mono for OSX, Mono for the PlayStation, Mono for Xbox360, Mono for the Wii, Mono for the iPhone, Mono for Android and Mono everywhere.

    Just like everyone that complains about Sun's tight control over the Java development process, I have my own regarding Microsoft's development process for .NET. But that is just business as usual.

    The best C# and .NET days are ahead of us.

    Posted on 25 Mar 2010

    OData Client goes Open Source

    by Miguel de Icaza

    Microsoft is trying to succeed where web services failed before with their new Open Data Protocol (oData).

    A few years ago, I had an epiphany when listening to Don Box talk about data services and web services. Web services and web sites are merely public facades to your internal databases. Web sites expose your database rendered as HTML while web services expose them in some sort of data format, defined on a case-by-case basis.

    With Web Services, developers need to define what bits of information should be exposed and how it is exposed (this applies to both SOAP and REST-based services). The problem is that developers might not have the time to spend on exposing every possible bit of interesting information that you maintain in your databases. Most importantly, there are very few web services that provide server-side queries making the information harder to mine.

    oData is a little bit different, for a given oData endpoint (like you can request that the server do some work for you, for example, you can pass a query that will limit the results to only those that you are interested in, and you can also specify the information that you are interested in.

    For example:

    It seems like Microsoft is doing the right things to get oData to be adopted. It reused Atom as the exchange format, made the services REST-based, it made client libraries available for many developer platforms and placed the spec under the OSP.

    Consuming oData sources

    Microsoft is taking a very Google-y approach with oData. They have created client libraries for a wide range of platforms to encourage adoption of this new way of exposing data.

    In addition to the JavaScript, Java, PHP, .NET and Objective-C bindings, Microsoft has announced that they will be open sourcing the .NET client library under the Apache 2 license. I was pleasantly surprised to learn that they were open sourcing this code, as we can consume it right away on Mono.n

    So this is good news for everyone that wants to consume the information. The bindings for .NET are in particular great since you get strongly typed client-side code that you can use to invoke remote servers.

    Producing oData: the need to open source System.Data.Services

    This is trickier, and I believe that if Microsoft wants to bootstrap the oData universe they need to seed this space not only with some existing services but also with an open source OData server implementation for Unix.

    I should further add that they should not wait a single minute and open their server-side .NET implementation if they want to accelerate the oData adoption.

    Let me explain why.

    Although the client libraries are great step to drive the adoption of the protocol for clients, it will do very little to unlock the data that sits today out in the web behind Linux servers running PHP, Java, Ruby or Python-based applications.

    At the end of the day, the client side code is a relatively simple parser for an XML file format. The server side on the other hand is much more complicated to get right.

    The server side requires a complete implementation of the query syntax, selection as well as access control and transaction support required to expose the data safely.

    It is clearly possible to implement the oData server technology, IBM did it for WebSphere, but this is an unnecessary wait. Placing a standard under the OSP and documenting it is not enough to drive open source or even third party implementations.

    If Microsoft were to open source their server side implementation of oData, we could overnight allow Linux users to expose their data in a format that can be mined. Linux users would only need to run a Mono front-end to the System.Data.Services library to expose the data that currently lives in their servers and is being served by Joomla, Wordpress, Rails, Django front-ends to become available as data services.

    Witness what happened with the M modeling language: great idea, OSP-covered, and yet the steep work required to implement it means that not a single implementation has been created in the 18 months since the project went public.

    Update: I stand corrected, Douglas Purdy points out that there is an open source implementation of M built with Javascript here.

    Ok, so not the best example, risking another egg in my face, I want to say that chances are that jsmeta is not a complete implementation of M.

    More on oData

    A detailed overview is available on the oData site.

    The best intro to oData that I have seen is Douglas Pourdy tour-de-force during the second day keynote as he walks through all the pieces in a span of 20 minutes.

    The MIX sessions on oData are packed with great information. The transaction and access control requirements on the server-side support are discussed on the How to create a feed for that session.

    If you want to explore oData services, you can use this Silverlight application to build your queries.

    Posted on 22 Mar 2010

    Baby on the Way

    by Miguel de Icaza

    Laura and myself will become parents sometime this summer. This will be our first baby.

    A friend told me that "Most kids turn ok, despite of their parents" which I interpreted as a green light for raising our daughter with a touch of Dali-like surrealism.

    Also, as much as I love the Summer conference circuit, I will be skipping on most travel from May to October and spend some quality time nesting.

    Posted on 22 Mar 2010

    Big Day in MonoLand

    by Miguel de Icaza

    Mark Probst found and squashed one of the hardest bugs in our upcoming garbage collector. Pablo from Codice has been testing the new GC under stress and posted a nice message to the list.

    Plenty of great feedback on deprecating old libraries and tools from Mono. We will have a lighter distribution. As things are coming together so fast and we are now well into the features we had planned for 3.0, we might end up just calling the next version 3.0 instead o 2.8.

    Andreia got Moonlight running on Chrome.

    Posted on 03 Mar 2010

    Simplified User Interfaces on the iPhone with MonoTouch.Dialog

    by Miguel de Icaza

    At the core of the iPhone UI lies the UITableView, a powerful table rendering widget that is used by pretty much every application on the iPhone. The UITableView is a powerful widget that can render its data in many different ways based on how you configure the widget, these are all variations of the UITableView:

    This is one powerful widget.

    The contents of the UITableView are rendered by calling into a developer supplied set of routines that provide the data on demand. The protocol includes queries like "How many sections?", "How many rows in section N?", "What is the title for section N?" as well as callbacks to provide the actual contents of a cell. Although the widget is pretty powerful, creating UIs with it is a chore and a pain to maintain. The pain to maintain and the repetitive nature of the process leads to developers either spending too much time customizing each view, bare minimum configuration and lack of polish on certain configurations. As I ported many of the Objective-C samples to C# I found myself repeating the same process over and over.

    My fingers developed calluses, and at night I kept thinking that there should be a better way. But at the time, I was just doing a line-by-line port, I was not really ready to build a new API on top of it.

    Recently, when my favorite twitter client on the iPhone butchered its UI I figured I would write my own Twitter client. The first step was to create the account configuration for my twitter account. As you can imagine, the configuration is done with a variation of the UITableView. And once again I found myself setting up the model, responding to view events, sprinkling switch and if statements liberally all through my source code and just plainly not having any fun writing the code. This is how MonoTouch.Dialog was born.

    I wanted to reflection to allow a class to be mapped to a dialog box, something that would allow me to write a C# class and have it mapped to a UITableView, something like this:

    class TwitterConfig {
        [Section ("Account")]
          [Entry] string Username;
          [Password] string Password;
       [Section ("Settings")]
          bool AutoRefresh;
          bool AutoLoad;
          bool UseTwitterRetweet;

    Instead of starting with the Reflection code to deal with this, I first created an in memory representation of the entire dialog. The idea was that the Reflection code would then be a bridge that could use the engine code.

    The engine code is built on the idea that each row could be a specific kind of widget. It could contain text, a switch box, a text editing line, a slider control, a calendar picker or any other kind of user created control. I call these "Elements" and I created a bunch of these:

    • BooleanElement: rendered with a UISwitch
    • FloatElement: rendered with a slider.
    • HtmlElement: when tapped, starts the web browser on a url.
    • StringElement: used to render plain strings.
    • MultilineElement: A multi-line string element.
    • RadioElement: a radio-item, to select one of many choices.
    • CheckboxElement: like the BooleanElement, but uses a checkbox instead of a UISwitch.
    • ImageElement: Allows the user to pick an image or take a photo.
    • EntryElement: text entry element.
    • DateTimeElement, DateElement, TimeElement: pickers for dates and times, dates and times.

    The MonoTouch.Dialog follows the Apple HIG for the iPhone and implements as much of the UI policy allowing me to focus on the actual application instead of focusing on the administrivia.

    Although the UITableView is built on the powerful Model/View/Controller setup that would allow it to scale efficiently to large data sets, most configuration pages and data entry pages do not require this complexity.

    Another feature is that it takes care of all the bookkeeping required to do text entry without any work from the programmer: accepting keyboard input, automatically switching to the next entry line on return, aligning all entry lines in a section, dismissing the keyboard with the last input is reached.

    Here is a sample of the API in action:

    var root = new RootElement ("Settings") {
      new Section (){
        new BooleanElement ("Airplane Mode", false),
      new RootElement ("Notifications", 0, 0) { Notifications }
      new Section (){
        new RootElement ("Sound"), { Sound },
        new RootElement ("Brightness"){ Brightness },
        new RootElement ("Wallpaper"){ Wallpaper }
      new Section () {
        new EntryElement ("Login", "Your login name", "miguel"),
        new EntryElement ("Password", "Your password", "password", true),
        new DateElement ("Select Date", DateTime.Now),
        new TimeElement ("Select Time", DateTime.Now),

    Once the RootElement has been created, this can be passed to a DialogViewController to manage it:

    var dv = new DialogViewController (root);
    navigation.PushViewController (dv, true);

    Reflection API

    The reflection API inspects a class and looks for fields that have some special attributes on them.

    Here is a sample class and how it is rendered:

    class AccountInfo {
        public bool AirplaneMode;
        [Section ("Data Entry", "Your credentials")]
        [Entry ("Enter your login name")]
        public string Login;
        [Caption ("Password"), Password ("Enter your password")]
        public string passwd;
        [Section ("Travel options")]
        public SeatPreference preference;

    As you can see, enumerations (SeatPreference) are automatically turned into a radio selection that uses the UINavigationController to navigate and the captions are computed from the field names, a behavior that you can customize with the [Caption] attribute.

    The attributes that are attached to each instance variable control how things are rendered and can be used to specify a variety of attributes like captions, images and overriding the defaults from MonoTouch.Dialog.

    Some Samples


    new RootElement ("Settings") {
      new Section (){
        new BooleanElement ("Airplane Mode", false),
        new RootElement ("Notifications", 0, 0) { Notifications }
      new Section (){
        new RootElement ("Sound"), { Sound },
        new RootElement ("Brightness"){ Brightness },
        new RootElement ("Wallpaper"){ Wallpaper }
      new Section () {
        new EntryElement ("Login", "Your login name", "miguel"),
        new EntryElement ("Password", "Your password", "password", true),
        new DateElement ("Select Date", DateTime.Now),
        new TimeElement ("Select Time", DateTime.Now),

    LINQ and MonoTouch.Dialog

    Craig has written a great Conference application for the Mix 2010 conference. I helped him reduce the code size of the application by removing all of the repetitive code required to set up UITableViews for various pieces of the application with MonoTouch.Dialog. Since the conference application deals with a database schedule, I extended MonoTouch.Dialog to work better with LINQ.

    In the same spirit of the System.Xml.Linq API that allows you to create XML documents with nested LINQ statements, you can use MonoTouch.Dialog to create your entire UIs.

    For Craig's application, I wrote a SessionElement that allows sessions to be "starred" and shows both the title of the session as well as the location of the session.

    This code constructs the entire UI for the "My Schedule" tab. The data is populated on demand (Apple recommends that all views are loaded lazily)

    public class FavoritesViewController : DialogViewController {
      public FavoritesViewController () : base (null) { }
      public override void ViewWillAppear (bool animated)
        var favs = AppDelegate.UserData.GetFavoriteCodes();
        Root = new RootElement ("Favorites") {
          from s in AppDelegate.ConferenceData.Sessions
            where favs.Contains(s.Code)
            group s by s.Start into g
            orderby g.Key
            select new Section (MakeCaption ("", g.Key)) {
              from hs in g
                select (Element) new SessionElement (hs)

    That is it. The entire source code.

    So use any of the two models that you enjoy the most: Reflection for quick one-offs and quick data-entry or the Element API for more advanced user interfaces but without having to spend your life writing boilerplate code.

    I hope that this helps guys spend more time improving their applications, and less time writing boilerplate code.

    MonoTouch.Dialog is not perfect and does not have every possible bell and whistle that you might want to add. Although I do welcome patches for certain features, feel free to fork the code and patch at will to suit your needs.

    Posted on 23 Feb 2010

    MeeGo Support in MonoDevelop

    by Miguel de Icaza

    We just landed the support on MonoDevelop's trunk to support developing applications that target MeeGo powered devices.

    MeeGo is a Linux-based operating system designed to run on mobile computers, embedded systems, TVs and phones. Developers would not typically use a MeeGo device as a development platform, but as a deployment platform.

    So it made sense for us to leverage the work that we have done in MonoDevelop to support the iPhone to support MeeGo. Unlike MonoTouch, we are not limited to running on a Mac, you can use MonoDevelop on Windows, Linux and OSX to target Meego Devices.

    Developers would continue using their Linux Workstation, their Windows PC, or their Mac to develop and test and the resulting cross-platform binary can be deployed and debugged remotely over the wire using Mono's Soft Debugger.

    In this video, I interview Michael Hutchinson as he demostrates the developer experience:

    The MonoDevelop/Mono that we will be supporting is entirely Gtk# based, both during development as well as during deployment.

    Posted on 22 Feb 2010

    Using MonoDevelop to Debug Executables with no Solution Files

    by Miguel de Icaza

    Every once in a while I need to debug some Mono program that does not come with a solution. Either a program that was compiled using a Makefile or an executable that I installed with RPM on my system.

    Sometimes I would end up cretaing MonoDevelop solution that contained every source file, command line option and resource that I meticulously copied from the Makefile. In other words, I was in for a world of pain just to be able to use MonoDevelop's awesome debugger.

    Lluis offered this solution, and I am blogging it hoping that it will help someone else in the future. Follow these steps to debug a Mono executable and set breakpoints on the source code or class libraries source code:

    1. Create a Generic Solution

    Select File/New Solution and select Generic Solution:

    2. Open the Project Properties

    Double click on your project, in my case I called the project "compiler":

    3. Add an Execute Custom Command

    In your project select Custom Commands:

    Add a custom Execute command by selecting it from the "Select a Project Operation" option and point to your Mono executable:

    4. Load source files

    Use File/Open to load the source file where you want to set a breakpoint (the executable source or some class library source) and set your breakpoints:

    Then use Run/Debug to start your program in debugging mode (Linux and Windows users can use F5, MacOS X users can use Command-Return).

    Posted on 20 Feb 2010

    What have we been up to?

    by Miguel de Icaza

    Every once in a while I would run into someone that will ask me what exactly we are up to in Mono. As Mono becomes larger, and various big projects "land" into the trunk, we can no longer do releases on a monthly basis. Some of the work that we do is inherently very attractive, things like new features, new libraries, new UIs and new frameworks. But probably more important are the efforts to turn our code into programming system products: fixing bugs, testing it, packaging it, supporting it, writing documentation, test suites, improving error handling, scaling the software, making it faster, slimmer and backporting bug fixes.

    I wanted to give my readers a little bit of an insight of the various things that we are doing at Novell in my team. This is just focused on the work that we do at Novell, and not on the work of the larger Mono community which is helping us fill in the blanks in many areas of Mono.

    MonoDevelop work

    We just released MonoDevelop 2.2, a major upgraded to our IDE story, and the backbone that allows developers on Linux to debug various kinds of Mono-based applications. With support for the new Soft debugging engine, it has allowed us to support debugging ASP.NET web sites, ASP.NET web services, Silverlight applications, Gtk# and Console applications with minimal effort. Since the soft debugger leverages Mono's JIT engine, porting the soft debugger to a new architecture is very simple.

    MonoDevelop 2.2 major goal was to create a truly cross platform IDE for .NET applications. We are off to a solid start with Linux, Windows and OSX support as well as solid support for C#, VB, Vala and Python.

    We are now turning our attention to MonoDevelop 2.4. This new release will incorporate many new UI touch ups which I will blog about separately.

    MeeGo/Moblin Support

    We have been working closely with the MeeGo (previously Moblin) team at Novell to offer a streamlined developer experience for developers on Windows, Mac and Linux to target MeeGo devices.

    Developers will be able to develop, test and deploy from their favorite platform software for MeeGo devices.

    Mono Service Pack

    A service pack release of Mono's enterprise supported ASP.NET release is ahead of us and we will be upgrading Mono from release 2.4 to release 2.6.

    This will bring to our customers support for all of the new features in Mono 2.6 with the added benefit that it has gone through four months of extra testing and polish.

    As part of this effort we are also upgrading the MonoTools for Visual Studio to support the new Mono Soft Debugger.

    Runtime Infrastructure

    Mono's runtime is being upgraded in various ways: we continue to work on integrating LLVM [1], productize our new copying garbage collector that can compact the heap, and make Mono scale better on multi-core systems with the integration of ParallelFX into Mono as well as re-architecting thread management and thread pools in Mono.

    A big upgrade for Mono 2.8 will be the support for obfuscated assemblies that insert junk in dead blocks. This is a feature that we never had, but with many Silverlight applications being deployed with these options we started work on this.

    We are working to improve our support for F# and together with various groups at Microsoft we are working to improve Mono's compatibility with the CLR to run IronPython, IronRuby and F# flawlessly in Mono. Supporting F# will require some upgrades to the way that Mono works to effectively support tail call optimizations. [1] LLVM: better use LLVM to produce better code, use it in more places where the old JIT was still required and expand its use to be used for AOT code.

    Mono for Mobile Devices

    We recently shipped Mono for the iPhone and we continue to develop and improve that platform. Our goal is to provide developers with a great experience, so we are doing everything in our power to make sure that every wish and whim of the iPhone developer community is satisfied. We are working to expand our API coverage, write helper libraries to assist developers, tune existing .NET libraries to run on Mobile devices, reduce startup time, and reduce executable sizes.

    But we have also just started an effort to ship MonoDroid: Mono for the Android platform. This will include a comprehensive binding to the Java APIs, but accessible through the JIT-compiled, 335-powered runtime engine.

    Our vision is to allow developers to reuse their engine and business logic code across all mobile platforms and swapping out the user interface code for a platform-specific API. MonoTouch for iPhone devices and the Monodroid APIs for Android devices.

    Head-less Tasks

    A big part of Mono's effort is in the development kit: the compiler, the tools and the server side components.

    Mono has now a complete C# 4.0 implementation that will be ready to ship with the next version of Mono. Anyone can try it today by building Mono from SVN. We are also porting our C# compiler to work with Microsoft's Reflection.Emit to enable us to run our C# Interactive Shell in Silverlight applications and to allow .NET developers to embed our compiler in their applications to support C# Eval.

    Our MSBuild implementation is very robust these days, and it will be fully supported in Mono 2.8 (and we will be backporting it to Mono 2.6 as well).

    On the ASP.NET front, we are working with third party vendors to certify that their controls work with Mono's ASP.NET (we will have some tasty announcements soon) and we are also catching up to the new features that are coming with .NET 4.0.

    WCF has turned out to be one of the most requested features. We had historically only paid attention to WCF for its Silverlight/Moonlight use cases, but as time goes by, more and more users are moving to WCF. We are working on completing our WCF support.

    On the ADO.NET front our major focus has been to complete the support for LINQ to SQL as part of the DbLinq project that we are contributing to. At this point we have no plans to implement Entity Frameworks due to the large scope of that project.

    Moonlight 3

    I do not need to say much about Moonlight 3. Moonlight 3 is one of our most visible projects right now due to the adoption of Silverlight and Smooth Streaming.

    By the first week of Feburary there had been 610,000 downloads of Moonlight 2.0 for Linux. This is only counting the downloads since the official release on December.

    Policy Changes

    Mono 2.6 was the last release of Mono to support the .NET 1.0 API profile. With Mono 2.8 we are going to drop the class library support for 1.0 and ship both 3.5 and 4.0 assemblies.

    With Mono 2.8 we are also switching the default tools and compiler to be 4.0-based as opposed to be based on the 3.5 profile. We will be doing a release of Mono 2.8 a couple of months after .NET 4.0 ships.


    The above probably reflects the main focus of the team in the past three months. There are many community driven efforts that are very cool and that deserve their own space and a future blog post. Things like the amazing work that was done on Qyoto and the Synapse IM client come to mind.

    We look forward to a great year ahead of us.

    Posted on 17 Feb 2010

    Valentine's Day Call to Action

    by Miguel de Icaza

    Everyone knows that in this day an age a software product is not complete until it offers a Desktop UI, a Web UI, and a front-end on the Appstore.

    We access beautiful web sites, we purchase 0.99 apps on our phones and install gorgeous native software on our desktops.

    The sysadmin community, once the backbone of Linux adoption, keeps asking "but what about me?". Indeed. What about them?

    What are we doing about these heroes? The heroes that ssh in the middle of the night to a remote server to fix a database; The heroes that remove a chubby log file clogging the web server arteries; The very same heroes that restore a backup after we drag and dropped the /bin directory into the trashcan?

    They are a rare breed in danger of extinction, unable to transition into a GUI/web world. Trapped in a vt100 where they are forced to by conditions to a small 80x24 window (or 474 by 188 with 6 pixel fonts on a 21 inch flat screen display).

    These fragile creatures need our attention.

    Today I am doing my part, my 25 cents to help improve their lives.

    I am releasing Mono Curses 0.4 a toolkit to create text-based applications using C# or your favorite CLR language.

    The combination of C#'s high-level features, Mono's libraries, Mono/.NET third party library ecosystem and the beautifully designed gui.cs, we can bring both hope and change to this community. Hope and change in the form of innovative text-based applications that run comfortably in 80x24 columns.

    What is gui.cs

    We know that hardcore sysadmins will want full control over what gets placed on the screen, so at the core of mono-curses we expose a C# curses binding.

    On top of this, we provide a widget set called "gui.cs". gui.cs was introduced in 2007 enjoying unprecedented public acclaim among a circle of five friends of mine. Eight months after its introduction, it experienced an outstanding 100% growth when a second application was written using it.

    Today, gui.cs is the cornerstone of great work-in-progress applications that any decade now will see the light of day. Including a new and riveting version of the Midnight Commander:

    With only 3% of features implemented progress is clearly unstoppable!

    I believe in dogfooding my own software before I unleash it to the world:

    On a typical 21" sysadmin setup: 474x188 with the "Sysadmin Choice" award winning 6 pixel font.

    Valentine's Day

    So in this Valentine's Day, after you are tired of spending quality time with your grandmother, making out with your significant other or a stranger you just met at the checkout line in Costco, consider donating. Donate some of your time towards building some nice applications for your favorite sysadmin. God knows that he spent the whole day monitoring the dmesg output, looking for a SATA controller failure and keeping an eye on /var/log/secure, waiting for your ex to deface your wordpress installation.

    And you have a choice, you can use Boo, IronRuby, IronPython, F# for building your app. VB.NET is also available if you want to teach your sysadmin a lesson in humility.

    Get inspired today with some of the old screenshots.

    Posted on 14 Feb 2010

    Winter Olympics on Linux

    by Miguel de Icaza

    The amazing Moonlight Team lead by Chris Toshok just released Preview 2 of Moonlight 3 just in time for the Winter Olympics' broadcast:

    The player has some nice features like live streaming, Tivo-like "jump-back", accelerated playback and slow motion and it does this using Smooth Streaming which adjusts the quality of your video feed based on your bandwidth availability.

    Thanks to Tom Taylor, Brian Goldfarb and the rest of the team at Microsoft for assisting us with test suites and early access to some of the technologies in use at NBC Olympics. With their help we were able to make sure that Moonlight 3 would work on time for the event (with full 24 hours and 14 minutes still to burn!).

    As usual, the team did a great job, considering that we had to implement in record time plenty of Silverlight 3 features for Moonlight.

  • Release notes for Preview 2
  • List of Known Issues with the Olympics Player.

    Firefox 3.7 runs this code better than 3.5, and you can improve the performance by disabling the pixel shaders in Moonlight, like this:

    	MOONLIGHT_OVERRIDES=effects=no firefox
  • Posted on 11 Feb 2010

    Moonlight 3.0 Preview 1

    by Miguel de Icaza

    We have just released our first preview of Moonlight 3.0.

    This release contains many updates to our 3.0 support, mostly on the infrastructure level necessary to support the rest of the features.

    In the release:

    • MP4 demuxer support. The demuxer is in place but there are no codecs for it yet (unless you build from source code and configure Moonlight to pick up the codecs from ffmpeg).
    • Initial work on UI Virtualization.
    • Platform Abstraction Layer: the Moonlight core is now separated from the windowing system engine. This should make it possible for developers to port Moonligh to other windowing/graphics systems that are not X11/Gtk+ centric.
    • The new 3.0 Binding/BindingExpression support is in.
    • Many updates to the 3.0 APIs

    The above is in addition to some of the Silverlight 3.0 features that we shipped with Moonlight 2.0.

    For the adventurous among you, our SVN version of Moonlight contains David Reveman's pixel shader support:

    From Silverlight Parametric Pixel Shader.

    Posted on 03 Feb 2010

    Mono at FOSDEM

    by Miguel de Icaza

    I will be arriving in Brussels on Saturday Morning for the FOSDEM conference. We have an activity-packed day on Sunday of all-things-mono.

    This is the current schedule, pretty awesome!

    Feedback requested: My plan is to do a state-of-the-union kind of presentation on Mono, but if you have a specific topic that you would like me to present on, please leave a comment, I will try to prepare for that.

    See you in Brussels!

    Posted on 02 Feb 2010

    iPad - Inspirational Hardware

    by Miguel de Icaza

    iPad - Inspirational Hardware

    As a software developer, I find the iPad inspirational.

    Apple's iPad is not a new idea. They are not the first ones to think of a tablet and as many blogs have pointed out the Apple iPad is not everyone's dream machine, the hardware is lacking gadgets and the software is not that amazing.

    Five elements come together to revolutionize software:

    1. Price
    2. Multi-touch centric development
    3. Standard hardware available for consumers
    4. Apple's AppStore
    5. Large form factor.

    The iPhoneOS is a multi-touch centric operating system. For years application developers have been subjected to the tyranny of the mouse and keyboard. This has been the only input technology that developers could reliably depend on and expect to be available on the user's system. Any software that requires different input mechanism sees its potential market reduced.

    The mouse is a great device for certain class of desktop applications. But it has also led to applications that are incredibly frustrating to use. Software for editing music and audio is cumbersome. Find the target, drag it, move it, find the other button, click it, scroll, drag, click. Anyone that has used Garage Band to try to play along knows this. The same applies to software to paint or draw. The mouse and keyboard are poor substitutes for using your hands.

    On the iPhone, and now the iPad, the situation is reversed. Multi-touch is the only input mechanism that developers can depend on. Apple's iPhone helped create a community of developers that think in terms of taps, pinches and twirls instead of clicks, double-clicks and right-clicks. It is no longer an after thought. It is no longer a feature that is added if there is enough time in the schedule or enough budget. It is the only option available.

    Taps, pinches and twirls allow us to use the full expression of our hands to drive an application. And it is not just any multi-touch, it is multi-touch over the same surface where the application is providing feedback to the user. Software that respond to user input in the same way that a physical object responds to our physical contact is the key to create new user experiences.

    This is a whole new space in which we can research, a new space that we can explore and where we can create a whole new class of computer/user interactions. With the new form factor, we can now create applications that just made no sense on the iPhone.

    It is fascinating.

    The standardized hardware means that software developers do not have face testing their software with dozens of combinatorial options. There are only a handful types of systems. If the software works on the core systems, they will work on all consumer devices. Standardized hardware is at the core of the success of the console gaming market, developers test and develop against a uniform platform. Price is the cherry on top of the cake, this device will be mass produced and the affordable price means that it will have a deep reach.

    The possibilities for new computer/user interactions are no longer dampened by this market reality. As developers, a new door to invention and innovation has been opened for us. No longer will software developers have to cripple their user experiences based on the mouse and keyboard.

    For the past couple of years I have had some ideas for some software that I wanted to build on a touch-based computer, but the specter of having a small user base for my experiments always discouraged me. Ever since I heard the rumors about Apple producing a tablet computer I have not cared about what the device looked like, or what the software stack for it was going to be. I wanted to try new touch-based UI ideas, I have dozens of ideas that I want to try out. And with Mono, I get to do it in my favorite language.

    Posted on 29 Jan 2010


    by Miguel de Icaza

    Nice new releases of software that I use in the last few days.

    Banshee 1.5

    A new Banshee release, now supports new device syncing options, audiobooks, eMusic and GIO for non-local files. Gabriel has more details as well.

    Now with a fully self-contained Mono and Gtk+ stacks on OSX. On the OSX note, I recommend Michael Hutchinson's blog entries on how to package your Gtk# app for use in OSX as well as his article on how to make your Gtk# app integrate with OSX. Both based on the lessons of bringing MonoDevelop and MonoDoc to OSX.

    Jeroen Frijters released his IKVM.Reflection API. His API could be very useful for Reflection-Emit compiler writers, perhaps we could even use it in Mono's C# compiler to solve our long standing issues with Reflection. More research is needed on this area.

    Maurits Rijk has published a new version of GIMP# his Mono-based plugin engine that lets you write plugins in any Mono supported language. There are samples in C# 3, F#, Boo, Nemerle, Oxygene, IronPython, Java/IKVM and Visual Basic.

    Sandy released a new version of Tomboy, now supports exporting data in HTML format to the clipboard and jump Lists on Windows 7.

    Posted on 28 Jan 2010

    iPad Support for MonoTouch!

    by Miguel de Icaza

    We did it!   MonoTouch for iPad!

    24 hours after we got the iPad SDK we completed the support for the iPad for MonoTouch!

    To get started with iPad development, go to and follow the instructions.

    Let the iPad# hacking begin!

    Posted on 28 Jan 2010

    24 hour race

    by Miguel de Icaza

    Another Mono-race, in 24 hours we are aiming to:

    • Support the iPad SDK from Apple (freshly baked and published).
    • Add MonoDevelop support for it.

    Posted on 27 Jan 2010

    Preordering the Apple Tablet

    by Miguel de Icaza

    Posted on 25 Jan 2010

    MVP Award

    by Miguel de Icaza

    Thanks to everyone that participated in the campaign to nominate me for a C# MVP award, when I got back to Boston I found on my piles of email that I am now part of the program.

    This is Pretty Sweet(tm). This will be a great opportunity to build more bridges with Windows developers and show them that there is an ECMA CLI life in the other side of the OS spectrum.

    Looking forward to the group picture!

    Posted on 11 Jan 2010

    Mono at FOSDEM

    by Miguel de Icaza

    This year we will have a Mono Room at the FOSDEM Conference in Brussels. The FOSDEM conference is held on the weekend on February 6th and 7th.

    Ruben and Stephane organized the room and the speakers for the it. has posted the finalized schedule for the Mono activities at FOSDEM on Sunday.

    Here is the schedule, there are some pretty interesting talks:

    09:00 - 09:15Opening (Ruben Vermeersch, Stéphane Delcroix)
    09:15 - 10:00MonoDevelop (Lluis Sanchez Gual)
    10:00 - 11:00The Ruby and .NET love child (Ivan Porto Carrero)
    11:00 - 12:00Mono Edge (Miguel de Icaza)
    Lunch Break
    12:45 - 13:15The evolution of MonoTorrent (Alan McGovern)
    13:15 - 13:45Image processing with Mono.Simd (Stéphane Delcroix)
    13:45 - 14:15ParallelFx, bringing Mono applications in the multicore era (Jérémie Laval)
    Coffee Break
    14:30 - 15:30Building The Virtual Babel: Mono In Second Life (Jim Purbrick)
    15:30 - 16:00Moonlight and you (Andreia Gaita)
    16:00 - 16:30OSCTool - learning C# and Mono by doing (Jo Shields)
    16:30 - 16:45Smuxi - IRC in a modern environment (Mirco Bauer)
    16:45 - 17:00Closing (Ruben Vermeersch, Stéphane Delcroix)

    Posted on 11 Jan 2010

    Pixel Shaders for Moonlight

    by Miguel de Icaza

    David Reveman has just posted a fascinating patch that debuts the support of pixel shaders in Moonlight.

    David's patch uses Gallium, and he says:

    The current implementation uses gallium's softpipe driver but hooking up the llvm driver as well should be a minor task and give significantly better software performance.


    My current approach is to focus on getting all these things working in software first. By using a OpenVG backend for cairo we can incrementally move to using gallium and hardware for all rendering.

    Posted on 07 Jan 2010

    Moonlight: Platform Abstraction Layer Lands

    by Miguel de Icaza

    Chris Toshok has landed the changes necessary to abstract Moonlight's engine from the platform.

    The platform abstraction layer lives in moon/src/pal and the Gtk+ interface lives in moon/src/pal/gtk.

    This is a necessary step to bring Moonlight to non-X11 powered GUI systems.

    Posted on 06 Jan 2010

    C# Support for Tuples

    by Miguel de Icaza

    More Mono proof of concept extensions to C#.

    As part of the list of things I would like to see in C# is support for tuples in the language. They would show up in a few places, for example, to return multiple values from a function and assign the results to multiple values at once.

    In recent versions of the framework there is a new datatype called Tuple, it is used to hold N values, the Tuple for N=2 looks like this:

    	public class Tuple<T1, T2> {
    		public Tuple (T1 v1, T2 v2);
    		T1 Item1 { get; set; }
    		T2 Item2 {get; set; }

    The tuple patch extends the C# language to allow multiple variables to be assigned from any Tuple, like this:

    	(user, password, host, port, path) = ParseUri (url);

    The above would assign the four values to user, password, host, port and path from the call to ParseUri. ParseUri would be declared like this:

    	Tuple<string, string, string, int, string> ParseUri (string url);

    Future Work and Ideas

    In addition to handling Tuples, I would like to extend this to support collections and IEnumerables as well, for example:

    	(section, header) = my_array;

    The above would store my_array [0] in section, and my_array [1] in header.

    If the last element of a tuple is a collection, it could store the rest of the values from the collection or enumerable in the last element:

    	(query, page, other_options) = Request.QueryString;

    The above would store the first item in the QueryString into query, the second into page, and the rest into the other_options array.

    Tuple creation syntax:I would like to add nicer support for creating Tuples as return values, it could just mirror the assignment syntax.

    	ParseUri ()
    		return (user, password, host, port, path);

    Handling well-known types: In addition to Tuple, ICollections and IEnumerables, perhaps the compiler should know about older versions of Tuple like DictionaryEntry.

    Using statements: Today the using statement is limited to a single resource, with multi-valued return types, it could handle multiple resources at once, like this:

    	using (var (image, audio, badge) = iphoneApp.GetNotifications ()){
    	    // use IDisposable image
    	    // use IDisposable audio
    	    // use trivial int badge

    Posted on 23 Dec 2009

    New Moonlight Covenant has been posted

    by Miguel de Icaza

    As I mentioned a few days ago, there is a new covenant form Microsoft for Moonlight, it has been posted.

    Posted on 22 Dec 2009

    Cena Linuxera en el DF, hoy

    by Miguel de Icaza

    Cena Linuxera/Monera hoy (Diciembre 22) en el bar/restaurante del Covadonga a las 7pm. Para todo p�blico (incluso talibanes).

    Direcci�n: Puebla 121 cerca de el Metro Insurgentes.

    Posted on 22 Dec 2009

    C# String Interpolation

    by Miguel de Icaza

    We have discussed in the past adding support to C# to support string interpolation. I have cooked a patch that allows C# developers to embed expressions inside strings, like this:

    	var a = 'Hello {name} how are you?';

    Single quotes are used for strings that will have expressions interpolated between the braces. The above sample is equivalent to:

    	var a = String.Format ("Hello {0} how are you?", name);

    Currently the patch supports arbitrary expressions in the braces, it is not limited to referencing variables:

    	var a = 'There are {list.Count} elements';

    This notation can be abused, this shows a LINQ expression embedded in the string:

    	var a = 'The {(from x in args where x.StartsWith ("a") select x).FirstOrDefault ()} arguments';

    I am not familiar with what are the best practices for this sort of thing in Python, Ruby and other languages. Curious to find out.

    Update: after the discussion on the comments the syntax was changed to use $" instead of the single quote to denote a string that will be interpolated. Now you will write:

    	var a = $"There are {list.Count} elements";
    	var greeting = $"Hello {name} how are you?";

    The updated patch is here.

    Posted on 20 Dec 2009

    Debugging Silverlight/Moonlight Apps on Linux

    by Miguel de Icaza

    A little hidden feature from our release of MonoDevelop 2.2 and Mono 2.6 earlier this week was MonoDevelop's support for debugging Moonlight applications:

    Moonlight debugging is a feature that came together very recently, but we delayed Mono and MonoDevelop's release to make sure that we shipped with it.

    To debug, merely open your Moonlight/Silverlight project, set some breakpoints, and run your program (F5). Your app will be debugged.

    I did a quick screencast and annotated it:

    Posted on 17 Dec 2009

    Releasing Moonlight 2, Roadmap to Moonlight 3 and 4

    by Miguel de Icaza

    Today we are making a few of announcements:

    • Moonlight 2 is complete: Moonlight 2, our open source implementation of Silverlight 2 is done.
    • An updated collaboration agreement between Microsoft and Novell to bring Silverlight 3 and 4 to open source Unix.
    • Microsoft has an updated patent covenant that will covers third party distributions.

    Update: Sean Michael Kerner covers the announcement and talks to Brian Goldfarb from Microsoft.

    Update 2: New covenant from Microsoft has been posted.

    2.5 API

    Moonlight 2 is a superset of Silverlight 2. It contains everything that is part of Silverlight 2 but already ships with various features from Silverlight 3:

    • Silverlight 3 Pluggable Pipeline, this allows developers to hook into the media decoding pipeline at various points:
    • Easing animation functions
    • Partial out-of-browser support
    • Writable bitmaps
    • Some of the new databinding features of XAML in Silverlight 3

    We are moving quickly to complete our 3 support. Microsoft is not only providing us with test suites for Moonlight but also assisting us in making sure that flagship Silvelright applications work with Moonlight.

    When it comes to prioritization of Silverlight 3 features, we are going to focus on getting the major applications that users want to use first. Sunday Night Football, the Winter Olympics and Bing's Photosynth support.

    Smooth streaming works really well. Visit the site and test the immediate seek, and play with the bandwidth limiter to see how Silverlight/Moonlight can adapt the video quality based ont he bandwidth available:

    Moonlight 2

    Moonlight 2 is the result of love and passion to bring the Silverlight runtime to Linux.

    Moonlight 2 engine consists of 142,000 lines of C/C++ code and 320,000 lines of C# code (125,000 lines of code came from Microsoft's open source Silverlight Controls).

    Moonlight is built on top of Mono 2.6 runtime, Cairo and Gtk+ and today supports Firefox on Linux. We are hard at work to support Google Chrome on Linux as well.

    Updated Patent Covenant

    We worked with Microsoft to make sure that Moonlight was available to everyone on Linux and BSD.

    Culturally, we started on two opposite ends of the software licensing spectrum. The covenant that was issued for Moonlight 1 and 2 covered every user that used Moonlight, but only as long as the user obtained Moonlight from Novell. This is a model similar to how Flash is distributed: there is a well-known location where you get your plugin.

    The open source world does not work that way though. In the open source world, the idea is to release source code and have distributions play the role of editors and curators and distribute their own versions of the software.

    Microsoft's intention was to expand the reach of Silverlight, but the original covenant was not a good cultural fit. We worked with the team at Microsoft (Brian Goldfarb and Bob Muglia's teams) to make sure that the covenant would cover the other Linux distributions.

    The new patent covenant ensures that other third party distributions can distribute Moonlight without their users fearing of getting sued over patent infringement by Microsoft.

    There is one important difference between the version of Moonlight that will be available from Novell and the version that you will get from your distribution: the version obtained from Novell will have access to licensed media codecs.

    Third party distributions of Moonlight will be able to play unencumbered media using Vorbis, Theora and Ogg inside Moonlight (and Silverlight), but for playing back other formats, they will have a few options:

    • Negotiating directly with the media codec owners a license (MPEG-LA, Fraunhofer).
    • Negotiate access to Microsoft's Media Pack with Microsoft.
    • Plug-in GStreamer or another commercial codec license into their Moonlight implementations.
    • Update: Use a hardware provided decoder like VDPau.

    Moonlight 3 and Moonlight 4 Collaboration Agreement

    As readers of my blog know, the Silverlight 4 feature set is something that is very interesting to me.

    If our experience with the positive feedback that we have gotten from MonoDevelop is of any indication Silverlight 4 will enable a whole new class of cross-platform .NET application development to take place. Like nothing we have seen before.

    We are thrilled to be working with Microsoft to make sure that we can improve, fix and fine tune Moonlight to meet those requirements and to do so in a purely open source fashion.

    Update: Team Silverlight blogs.

    Posted on 17 Dec 2009

    Nine Months Later: Mono 2.6 and MonoDevelop 2.2

    by Miguel de Icaza

    About nine months ago we released MonoDevelop 2.0 and Mono 2.4. Today we are releasing the much anticipated upgrades to both. Mono 2.6 and MonoDevelop 2.2.

    For those in a hurry, binaries and source are available from:

    And if you want a quick mnemonic to remember this release, just think debugger! and cross platform.

    The Mono team and contributors worked on this release like we have never worked before. Thanks to everyone that reported bugs, filed feature requests, contributed code and helped newcomers with Mono.

    Mono 2.6 highlights:

    • WCF client and server, the subset exposed by Silverlight 2.0.
    • LLVM support, to improve performance on server/computational loads.
    • Continuations/Co-routine framework Mono.Tasklets (background info)
    • LINQ to SQL using DbLinq.
    • New Soft Debugger, integrated with MonoDevelop on Unix and OSX (background).
    • System.IO.Packaging.
    • csharp shell now supports auto-completion (press tab to complete)
    • xbuild can now build most msbuild projects.
    • Mono debuts a verifier and security sandbox (used by Moonlight).
    • More complete 3.5 API coverage.
    • This release includes Microsoft's open sourced ASP.NET MVC, ASP.NET AJAX and Microsoft's Dynamic Language Runtime.
    • Faster and slimmer.

    MonoDevelop 2.2 highlights (screenshots here and here):

    • MonoDevelop code is now LGPLv2 and MIT X11 licensed. We have removed all of the GPL code, allowing addins to use Apache, MS-PL code as well as allowing proprietary add-ins to be used with MonoDevelop (like RemObject's Oxygene).
    • User interface improvements: the first thing that MonoDevelop users will notice is that we have upgraded the UI to fit modern ideas. We borrowed ideas from Chrome, Firefox, Visual Studio, Eclipse and XCode.
    • ASP.NET MVC support, you can now develop, debug and build ASP.NET MVC applications from MonoDevelop.
    • New T4 Macro processor (Text Template Transformation Toolkit) integrated directly into the IDE (Mono's T4 is also available as a reusable library for use and abuse in your own programs).
    • Moonlight Project Support: you can now build, debug and run Moonlight applications using MonoDevelop.
    • New MacOS and Windows support. Check our feature matrix for details.
    • New Debugger support allows debugging Console, Gtk#, ASP.NET, iPhone and Moonlight applications.
    • Extensive text editor improvements:
      • Dynamic abbrev (Just like Emacs' Alt-/)
      • Code generator (Alt-Insert)
      • Acronym matching
      • Code templates
      • Block selection
      • C# Formatter
    • New refactoring commands:
      • Inline Rename (see screenshot).
      • Resolve Namespace
      • Rename Refactoring with Preview
      • Extract Method
      • Declare Local Variable
      • Integrate Temporary Variable
      • Introduce Constant
      • Move Type to Own File
      • Remove Unused Usings
      • Sort Usings
      • Create/Remove Backing Store
      • Keybindable Commands
    • Python add-in has graduated to be a supported plugin, includes code completion, syntax checking, method and class locator and code folding.
    • iPhone development plugin.

    The team is on #mono, #monodev and #monodevelop on fielding any questions you might have.

    Update: the diffstat results for Mono 2.4 to 2.6 on a 2 million line patch:

     7208 files changed, 1392400 insertions(+), 440016 deletions(-)

    About a million lines of new code in Mono.

    For MonoDevelop the patch is 750,000 lines and:

     2427 files changed, 464284 insertions(+), 120124 deletions(-)

    Roughly 300k lines of new code.

    Posted on 15 Dec 2009

    Apple's Reply to Nokia

    by Miguel de Icaza

    I felt like an archaeologist trying to formulate a theory of what had happened there. I loved the feeling of trying to put together the story from a partial puzzle.

    The patent infringement lawsuit against Apple was a list of accusations and patent lists that Nokia claims that Apple infringes with their iPhone. But behind the background information provided in the legal document and the list of ways in which Nokia felt Apple had wronged them, it was difficult to put together a narrative. Scanning the discussion forums for clues did not lead to anything significant beyond the superficial analysis.

    As a software developer, and in particular a Linux software developer, I have mixed feelings about this lawsuit. Apple has not been exactly a model citizen when it comes to interoperability between Apple and Linux products while Nokia has embraced Linux, embraced open source development and contributed to the universal pool of software. But I also found myself enjoying using my iPhone and building software for the iPhone.

    I wanted to give both companies the benefit of the doubt. What had happened between these two companies that had forced Nokia to sue Apple?

    There were various possibilities.

    The lack of immediate response from Apple suggested that they were caught unprepared, but that was just a small chance. Probably the companies had been on negotiations and these negotiations broke off when they could not reach an agreement. The iPhone had taken the world by surprise, nobody had seen it coming and nobody had envisioned that Apple would not merely do an incrementally better phone, but it would be many times better than anything available at the time.

    When Apple launched the iPhone, Steve Jobs wanted everyone to know that iPhone's innovations were patented and that Apple planned to prevent others from copying those ideas.

    Apple's response to Nokia is a very educational document. It reads as a crash course on patent litigation when it lays out Apple's strategy for their defense. It is also a crash course on the patent system and how corporation work with international bodies to develop technology. But most importantly for me, it fills some the gaps of what happened behind the scenes.

    We do not know yet which company approached the other first about patent infringement. It could have been someone on Nokia's board that decided to extract some revenue from their patents to compensate for their business losses or it could have been initiated by Apple's team notifying Nokia that their new phones used some idea from their phones.

    What does emerge from Apple's reply is that Nokia tried to use the patents that they had pledged to license under reasonable terms to get themselves rights to Apple's juicier iPhone innovations. Nokia's pledged patents might be formidable patents and key to the implementation of certain cellular and WiFi communications, but by being pledged under F/RAND terms to various industry consortia they lost a significant amount of value. But what they lost in value, they made up in volume. This is in stark contrast with Apple's un-pledged, pristine, fully proprietary patents that Nokia and everyone but China are trying to get rights to.

    Posted on 12 Dec 2009

    Marek Announces Mono's C# 4.0 has been completed

    by Miguel de Icaza

    Marek has just announced that Mono's C# compiler 4.0 is complete.

    To try it out, get the modules mono and mcs from our Anonymous Subversion Repository and build Mono like this:

    	$ mkdir $HOME/mono4
    	$ ./ --prefix=$HOME/mono4 --with-profile4=yes
    	$ make && make install

    Posted on 09 Dec 2009

    First MonoTouch Book is out!

    by Miguel de Icaza

    This was fast! Wallace B. McClure has written the first e-book on getting started with Mono on the iPhone with MonoTouch.

    This is a short e-book, 42-pages in size, but it is also very cheap, it is only 6.99 USD and will help you get started in no time with MonoTouch.

    Here is the table of contents:

    Table of Contents

    iPhone Requirements 2

    Development Strategies 3

    Web Development with ASP.NET 3

    MonoDevelop and MonoTouch 4

    Visual Studio .NET ➪MonoDevelop 4

    Classes in MonoTouch 4

    What Is MonoTouch? 4

    Namespaces and Classes 5

    Introduction to Development on the Mac with MonoDevelop 6

    Interface Builder 8

    Outlets 10

    Actions 14

    Deploying to an iPhone 15

    Mapping 17

    MKMapView 17

    The Application 18

    Annotating the Map 20

    Debugging 21

    Interacting with Other Applications 22

    UIPicker 22

    NSUrl 24

    UIAlertView 26

    UITableView 26

    DataSource 27

    Binding Data to a UITableView 29

    Customizing UITableView 30

    Accelerometer 33

    Settings 34

    Things to Watch Out For 37

    Resources Used 38

    Posted on 03 Dec 2009

    Mexico 2009

    by Miguel de Icaza

    Voy a Mexiquito lindo estas vacaciones de Diciembre.

    Si quieren que nos reunamos para hablar de software libre, Mono, Linux, Moonlight, Silverlight, C# o para discutir por que La Mancha ya no escribe o el ultimo blog del Jetas mándenme un correo para ponernos de acuerdo.

    Posted on 03 Dec 2009

    Mono Developer Room at FOSDEM

    by Miguel de Icaza

    Stephane and Ruben are chairing the first Mono-developer room at the upcoming FOSDEM 2010.

    Ruben writes:

    As of now, you can submit your talk proposals! We want to make this a fun room and we want to accomodate all kinds of talks. For that reason, one thing we're experimenting with is having dynamic timeslots. Only want 15 minutes? That's okay! Need an hour? We'll see if we can squeeze it in! The most important factor is that it's interesting and fun.

    So send in your proposals, be it large earth-shaking projects, or little hackery experiments that make you giggle with hacker joy, we want to hear it. We have the complete Sunday to schedule. Still have questions? Email me: ruben @ savanne be.

    The submission form is here, go fill it in now! (Send in your proposals before December 20)

    See you there!

    Posted on 02 Dec 2009

    Silverlight: Universal GUI toolkit

    by Miguel de Icaza

    The most important piece of news from last week's PDC was Microsoft's decision to turn Silverlight into the universal platform for building cross platform applications.

    The upcoming version of Silverlight will no longer be a Web-only technology. It will now be possible to build full desktop applications with Silverlight.

    Desktop Silverlight applications differ from the standard Silverlight in a few ways:

    • Full access to the host file system, like any other .NET application would have.
    • None of the socket connectivity limitations that are present on the sandboxed versioned of Silverlight. Full network access (we should build a MonoTorrent UI for it!)
    • Built-in Notifications API to show up bubbles to the user when they need to interact with the application.

    Although Moonlight has supported this mode of operation since day one, turning this into a standard way to develop applications was going to take a long time. We would have needed to port Moonlight to Windows and OSX and then we would have to bootstrap the ecosystem of "Silverlight+" applications.

    But having Microsoft stand behind this new model will open the gates to a whole new class of desktop applications for the desktop. The ones that I was dreaming about just two weeks ago.

    This was a big surprise for everyone. For years folks have been asking Microsoft to give Silverlight this capability to build desktop apps and to compete with Air and it is now finally here. This is a case of doing the right thing for users and developers.

    Desktop Tools in Silverlight?

    Now that this technology is available, perhaps it is a good time to start a movement to create a suite of Silverlight-based desktop applications.

    The benefits to me are many:

    • .NET applications that actually look good. In the past your choices were basically of Gtk# or Winforms, neither one really designed for this graphic-designer driven world.
    • We can join forces with Windows/MacOS developers to create the next generation of desktop applications.
    • Developers can tap into the large ecosystem of third-party controls that exists for Silverlight.

    For the Moonlight team, this means that there is a lot of work ahead of us to bring every Silverlight 3 and 4 feature. I think I speak for the whole Mono team when I say that this is exciting, fascinating, challenging and feels like we just drank a huge energy boost drink.

    If you want to help, come join us in the #moonlight or #mono channels on the IRC server at

    Silverlight 4

    There are many other great features in Silverlight 4, but none as important as Silverlight becoming a universal runtime for the CLR. This is a revolution.

    If you are curious about all the new tactical features of the revolution, check Tim's Complete Guide to the new Silverlight Features.

    If you have the time, watch Scott's keynote's presentation where he introduced the new features (he starts at 1:02). I loved the use of HTML as a Silverlight brush (paint with HTML and even Flash). If you have time, these are some great sessions on Silverlight:

    Droolingly yours,
    Miguel de Icaza.

    Posted on 23 Nov 2009

    The future of Moonlight

    by Miguel de Icaza

    With Moonlight quickly approaching its first official 2.0 release (which has feature parity with Silverlight 2.0 and has a handful of 3.0 features in place) we have been thinking about the work ahead of us, 3.0 and beyond.

    Although there is much work left to do to achieve full parity with Silverlight 3.0, a solid 2.0 core means that we can start thinking about new innovative ideas.

    Here are some ideas of things that Moonlight could prototype:

    • Video camera and audio support (Chris has a working prototype).
    • Native menu support for out-of-browser: we feel strongly that out-of-browser apps should get native menus and not be done with XAML. To allow proper MacOS, Windows and Linux integration.
    • Right-click support for taking screenshots of Moonlight apps, record a screencast of a video, support for saving individual images, XAML and video from the plugin.
    • Print the current canvas.
    • User opt-in for full network access and full file system access (This is possible with Moonlight if compiled for the desktop APIs, but perhaps we should extend this to the browser version).
    • Make the "Moonlight" widget ubiquitous. Allow any existing Gtk+, Win32, OSX, iPhone and Android to create content from a XAML file:
      		var splash = Moonlight.LoadFrom ("splash.xaml");
      		container.Add (sphash);
      		var mainMenu = Moonlight.LoadFrom ("mainMenu.xaml");
      		mainMenu.FindObject ("Start").Clicked += {
      			StartGame ();
      		window.Add (mainMenu);

    We could use Silverlight to build the next wave of cross-platform desktop applications.

    I think of the Moonlight relationship to Silverlight as the Firefox relationship to IE four years ago. It is a chance to try out new ideas in the Silverlight-o-sphere, we can try those ideas out, and if the ideas have merit, they could become part of the official Silverlight.

    This echoes to some extent what Bob Muglia said on an interview a few days ago: "[it] will allow for Silverlight to move into all sorts of places where we can't - we can't see."

    For example, we are hard at work to make Silverlight run on the native PlayStation 3 and the Wii.

    In any case, we have been working on Moonlight for a long time. With our security system in place, and both our smooth streaming media engine and GUI engine in place I feel that open source innovation can begin.

    Posted on 12 Nov 2009

    Concurrency with DREAM

    by Miguel de Icaza

    Arne's presentation on concurrent programming at Monospace ago has been published.

    Posted on 12 Nov 2009


    by Miguel de Icaza

    Although making changes to Moonlight might be a very fun thing to do, for the longest time I have had this entry in my TODO list: "Blog about writing a video editor in Moonlight".

    As much as I love Gtk+ and the Gnome desktop, our contributions for our desktop applications and for Gtk+ come mostly from from folks developing on Linux for Linux (with a handful of exceptions). And we are a small fraction of desktop developers.

    In my mind what is interesting to me about building applications with Silverlight is that we can create an ecosystem of free software applications that run on all three major platforms: Windows, Linux and MacOS.

    A few years ago, as part of the Google Summer of Code for Mono we created a project that could have had a great future, the Diva project (by MDK). Sadly, Michael moved on to other things, but in the back of my mind, I always wanted to have a nice video editing application for Linux.

    I like to think that with Silverlight we have a new opportunity: we can create a community of open source developers that goes beyond the Linux-desktop community, but will pull developers interested about such a project from the Windows and MacOS worlds. I know that various members of the Moonlight team are passionate about Moonlight because it is this next generation API for building GUI applications.

    Which applications do you think are needed nad could be built with Moonlight?

    I say video editing, and I have some ideas of how it should work.

    Posted on 12 Nov 2009

    BitTorrent in Silverlight

    by Miguel de Icaza

    A few years ago, thanks to the Google Summer of Code, I got to meet a brilliant programmer that wrote an entire BitTorrent implementation as a reusable library called bitsharp. Today, I am lucky enough to work with Alan in the team team at Novell.

    Alan wrote a Gtk+ UI on top of his library called Monsoon:

    With Mono running in the browser as part of Silverlight, I have always felt that we needed to build a UI for bitsharp.

    The most important advantage is that every web browser can be turned into a BitTorrent client without having to install extra software.

    Some other advantages: you could connect to a web page that contains the BitTorrent client, it would turn your machine into a seeding/downloading host, it could be shut down with minimal fuzz and it would be trivial to spice up the UI and add all kinds of visualizations for the download.

    Silverlight 2 now provides direct socket/network access and supports storing files in your local file system. Most of the pieces are already in place to make this happen.

    There are a few challenges though. Silverlight does not allow a client to listen on a port, and for security reasons it has a limited set of ports it can connect to.

    The first problem could be addressed by having the client initiate connections to third parties requesting and providing data. This might require a protocol extension.

    The second problem is easy to solve, but would require other Bittorrent clients to listen in a new port to explicitly grant access to Silverlight clients by exposing a clientaccesspolicy.xml file.

    Finally, at least for Moonlight's case, we could start doing some changes to the core and grant the out-of-browser plugin to have full network access.

    Posted on 12 Nov 2009

    Moonlight Branches

    by Miguel de Icaza

    Chris posted the new rules for the moonlight-2-0 branch and how to start working on 3.0 stuff.

    Another intesting post is David's initial take on bringing pixel shaders, perspective transforms and hardware acceleration to Moonlight.

    Posted on 11 Nov 2009

    Mono Tools for Visual Studio

    by Miguel de Icaza

    Today is a big day for the Mono team, we just released the Mono Tools for Visual Studio. The goal of this release is to make it simpler for Visual Studio developers to deploy their applications on Linux. ASP.NET, Windows.Forms, server and console applications are supported. These are the major features in the release:

    Deploy to Linux: You can deploy from Visual Studio to a Linux machine running Mono your software. We are using Universal Plug and Play to detect Linux machines on your local network, or you can enter the IP address of your favorite hosting provider.

    Debug Linux system remotely from Visual Studio: Developers complained that our debugging story left much to be desired, that deploying to Linux was possible, but debugging cumbersome. We now allow you to debug your application running on Linux without ever having to leave Visual Studio.

    You can continue to edit, build and debug the way you have always done it, but the software will be running on a Linux machine:

    We hooked the Mono debugging engine to Visual Studio, so all the regular debugging tasks are available (watches, locals, breakpoints, stepping) that you come to expect from Visual Studio debugging are available.

    Review your code for portability: We have integrated Mono's Migration Analysis (MOMA) tool into Visual Studio so you can check your software for Windows/Linux differences right from your IDE and work around APIs that do not exist in Linux or Mono and refactor your code accordingly.

    Package your software for Linux: Right from Visual Studio you can package your .NET application in Linux native installation format. Just create a packaging project in your solution, configure your package and produce an RPM that you can distribute:

    And finally, one of the most exciting features in this tool: go from shipping applications into shipping appliances in minutes:

    You use our wizard to prepare your appliance, select a base operating system template (Server, Client, and base operating system) and off you go.

    Once your appliance is built, you can test it and apply the finishing touches over the web (using a Flash applet that connects to our virtual machines in our data center) and when you are happy with the results, you can download and redistribute your appliance to your users.


    Earlier this year I wrote about Novell's SUSE Studio our hosted service that helps developers create ready-to-run appliances.

    Today, as a .NET developer, when you distribute your software to your users and customers, you probably have a list of requirements that goes like this:

    • Install Windows XXX, Reboot.
    • Install security updates A through Z, reboot as many times as needed.
    • Install .NET runtime, reboot as needed.
    • Install SQL server, reboot as needed.
    • Populate database, reboot as needed.
    • Install third party tool, reboot as needed.
    • Just to be sure, reboot.

    Then your users can start installing your software. At that point, you initiate a series of support calls that go like this:

    • Did you make sure that .NET xxx.yy was installed? Ah, so do that and resume the steps.
    • Wrong databases, uninstall, reboot, reinstall database, reboot.

    And repeat the above process for every single one of your users.

    Basically, every user has to repeat the same steps. Everyone has to assemble the solutions made up of the operating system, various pieces of dependencies that you have and your software, like this:

    The experience today is like trying to buy a car by buying the individual parts:

    We believe that for a class of developers there is a better way.

    We believe that we can help you put together the full car, and deliver the car in a single piece.

    With appliances you can ship a pre-configured operating system, pre-configured database and every service pre-configured and installed together with your software to deliver a full package, so you prepare your software for distribution once, you configure the database once, and then you give your users a ready-to-run virtual machine, CD-ROM or USB stick:

    SUSE Studio has been used to build Linux based appliances (over four thousand per week), and now we are making it easy for .NET developers to take advantage of one of Linux's strengths: it is free, it is open source, you can shrink it, you can grow it and you can ship your own version (and yes, we do provide the updates for all of the core components that you pick).

    Getting Started

    Check out our getting started document.

    Cool use of MonoVS

    This is a cool use of Mono for Visual Studio debugging the Axiom 3D engine from the amazing Michael Cummings:

    Visual Studio remotely debugging Axiom on an Ubuntu virtual machine hosted in Sun's VirtualBox.

    Update: How to get it to work with Ubuntu

    Posted on 10 Nov 2009

    Third Party MonoTouch controls

    by Miguel de Icaza

    This is pretty sweet in a couple of levels.

    A couple of hackers at RemObjects have released some reusable controls for use with MonoTouch that simplify some common tasks with UITableViews, they are part of their "Project Plateau":

    Not only this is sweet in that these are the first set of 3rd party controls for MonoTouch, they are also sweet because the authors built these controls using Oxygene, their Object Pascal compiler.

    Update: Some documentation can be found here: introducing Plateau for MonoTouch.

    Posted on 09 Nov 2009

    Mono's new Compacting GC

    by Miguel de Icaza

    I missed this post from Friday.

    Mark Probst has posted a call for testers for Mono's new garbage collector:

    Our new garbage collector, SGen, is now at the point where it's ready
    for early testing.  It's still a long way from being ready for
    production use - it's still slow and consumes too much memory,
    especially for long-running processes - but if you'd like to help us
    find bugs, please consider giving it a try.  I'm especially interested
    in cases where Mono crashes or hangs with SGen (other than for memory
    exhaustion).  The simpler the test cases the better.
    To use SGen instead of Boehm, configure mono with the switch
    "--with-gc=sgen".  At this point it's only known to run on x86 and
    AMD64 Linux.

    This collector is a precise-heap, conservative stack, moving, copying collector and will return unused memory back to the operating system. The details of this collector are available in our Compacting GC page.

    I am rebuilding my own Mono with Compacting GC now as we speak.

    Posted on 09 Nov 2009

    MonoTouch application for the PDC

    by Miguel de Icaza

    Craig Dunn has turned his Monospace application for the iPhone into a Microsoft PDC application that conference attendees can use at the upcoming conference.

    Mandatory screenshot:

    Since this app is not on the AppStore, you need to compile it and use Ad-Hoc deployment to run it into your phone.

    Update: If you do not have a Mac, come to our booth at the Microsoft PDC, and we will ad-hoc deploy the app for you.

    Posted on 09 Nov 2009

    Alleviating Memory Fragmentation in Mono

    by Miguel de Icaza

    Currently, Mono's Garbage Collector does not compact the heap and one of the problems that users have is that certain allocation patterns might result in a heap fragmentation that is hard to recover from. The observable side effect is that your process memory usage grows, but the memory is mostly unused:

    You can read more about this in the Compacting GC page at the Mono web site.

    Although a new GC is being developed to address this, the code is still not switched on by default in Mono as we do not consider it ready for production use (you must compiled Mono with --with-gc=sgen).

    Avoid allocating very large buffers, instead allocate smaller buffers, and if you need to provide the illusion of a large buffer, hide this behind an interface.

    If you must use large buffers, you might want to consider using MindTouch's ChunkedMemoryStream which exposes the same interface as MemoryStream, except that it uses 16k chunks instead of a very large buffer.

    This will avoid the fragmentation for a very common use case.

    Posted on 09 Nov 2009

    Introducing Debugging for MonoTouch

    by Miguel de Icaza

    Today we released MonoTouch 1.2.

    Perhaps the most important new feature in MonoTouch 1.2 is that it now has a debugger that supports debugging on both the iPhone simulator and on the iPhone/iPod Touch.

    The debugger is integrated directly into MonoDevelop/OSX. All you have to do is select one of the debugging configurations (either Debug|iPhone or Debug|iPhoneSimulator):

    and run your application:

    To set breakpoints, you use the usual MonoDevelop UI, just click on the left-hand side of the editor, or use Command-/:

    The debugger offers the usual watch windows, and also allows you to navigate object state by hovering over the value in the IDE:

    The Technology

    Although this was developed for the iPhone, I should probably have said that this is Mono's new soft debugger engine.

    The iPhone is once again a challenging platform to get debugging working on. Since Apple has not published the information necessary to implement something like GDB or Mono's own MDB and we are not going to reverse engineer the protocol, instead we created a new way of debugging Mono applications.

    The Mono Debugger for the iPhone platform uses a soft-debugger. Unlike traditional debuggers that act like a fully controlling entity over the Mono process, the soft-debugger is actually a debugger that is built into the Mono process itself. MonoDevelop communicates with this debugger over a compact protocol, similar to what has been done in the past with Java debuggers:

    We are providing a new library, the Mono.Debugger.Soft.dll that encapsulates the protocol and offers an API that developers can use to debug a remote Mono process.

    On systems where we have access to breakpoints the soft debugging engine will use the standard operating system facilities to single step and set breakpoints.

    But on systems like the iPhone and some video game consoles where there is no way to modify memory without special privileges we had to resort to a different technique. The Mono static compiler inserts special code at every sequence point that checks for single stepping or breakpoints. The code generated during these debug builds is larger, but it allows us to support the iPhone without having to resort to undocumented APIs in any form or shape.

    MonoDevelop and the iPhone

    When the user selects an application for debugging, MonoDevelop configures the application to contact MonoDevelop on startup and link the debugger to it, starts listening on a couple of ports (one for the debugging protocol, and one for redirecting standard output/standard error) and waits for the application on either the iPhone simulator or the iPhone to contact it.

    Upon contact, the debugger handshake takes place and operation continues. For the simulator, this takes place with a local socket; for the device, this happens over a TCP/IP socket over WiFi.

    One of the nice side effects of this approach to debugging is that it is possible to distribute binaries to testers (using the Ad-Hoc distribution model) and debug problems on a user's iPhone over the network.

    To support this scenario, when you build applications with the "Debug|iPhone" configuration, MonoDevelop will modify your application's Settings file on the iPhone.

    This allows your beta-testers to enable debugging and connect to your debugger for inspection. This is what the settings looks like:

    The first port is the port where MonoDevelop will be listening to. The second port is the port where the standard output and standard error will be redirected to.

    All of the Console.Output and Console.Error output will be sent to this port when debugging is enabled on the application.

    Pros and Cons

    There are pros and cons to the soft debugger approach.

    Soft debuggers are unable to do low-level debugging or debug Mono itself (mixed-mode debugging) and they are unable to stop applications at will, all it can do is request politely that the application stops, and when the Mono runtime decides that it is a good time to stop, it will stop.

    On the pro side, the soft debugger is easier to port and is more robust as it eliminates some dead-lock situations. These can happen when the runtime has been forcefully stopped by the debugger, and then the debugger invokes methods on the target. These methods in turn might require an internal lock that is currently held by a different thread.

    The Protocol

    The protocol used between the debugging agent running inside the Mono process and a debugger is implemented in the debugger-agent.c file.


    MonoTouch customers will be offered the update the next time they start MonoDevelop or if they manually "Check for Updates" on the MonoDevelop IDE.

    Users of MonoTouch for the iPhone simulator can get the it from the trial page.

    The source code for the soft-debugger is available on SVN. The API to communicate with the Mono runtime is available in the Mono.Debugger.Soft assembly and the debugger itself has already been integrated into the Mono 2.6 branch and Mono trunk on SVN.

    This should prove useful to other users of Mono that might benefit from a soft debugger like Unity3D or Second Life.


    Brent has a nice gallery of screenshots of the debugger in action on his MonoTouch 1.2 with debugging released! post.

    Posted on 04 Nov 2009

    Pig Farm Tour Oaxaca 09

    by Miguel de Icaza

    April IM logs:

    Posted on 04 Nov 2009

    10 years of Ximian

    by Miguel de Icaza

    Today is the ten year anniversary of the incorporation of Ximian, Inc. A company founded by Nat Friedman and myself whose goal was to advance the state of the Linux desktop. It was also an excuse for Nat and myself to hang out as we had become best friends forever in the previous two years.

    Our conversations over the years have always been a little surreal. I have megabytes worth of logs that look like this:

    Ximian was made up of friends that shared this vision, and its founders had no startup, business or management experience when we launched the company. We learned on the job and we were advised by friends that believed in our goals, and by people that cared about our mission.

    From the archive: Ettore Perazzoli, Raph Levien, Nat and myself in Summer of Linux.

    Ximian hired 90% of its employees from open source contributors in the community and folks that we had met over mailing lists or IRC channels.

    Nat was a Computer Science and Math graduate; I was a math drop out and we had no management experience. This means that we made every possible management mistake in the book, but all of our friends and employees stuck with us as we learned and as we worked to get the company off the ground.

    This is an interesting time to reflect on 10 years of hacking adventures. Writing, funding and advancing the state of the art of open source. In the next few weeks, Nat and myself will be publishing some short stories from Ximian.

    Today Ximian has been incorporated into Novell. Our goals have been expanded, but we still continue to work to advance the state of the art in Linux.

    Looking forward to another 10 years of joy and hacking.

    Posted on 19 Oct 2009

    iPhone application for MonoSpace Conference

    by Miguel de Icaza

    I woke up this morning and found that the amazing Craig Dunn put together an iPhone app for the Monospace Conference using MonoTouch!

    The app provides the schedule, access to the twitter feeds for the speakers and the conference, access to the MonoSpace blog, speaker profiles and access to their blogs and twitter feeds and a map to find the event.

    You can learn more, see larger screenshots and download the code to run on your iPhone from Craig's Post.

    Posted on 17 Oct 2009

    MonoSpace Conference in Austin - October 27 through 30

    by Miguel de Icaza

    Over the past few weeks, the final details of the program for the Monospace Conference have been announced, and now the event is just less than two weeks away. Some key details you may have missed:

    • The Monspace conference features 2 days of workshops and 2 days of Open Space sessions.
    • The full conference agenda has been posted, and now includes a full day of MonoTouch training (Mono for the iPhone).
    • The two-day open space sessions will be kicked off on Thursday with an Open Source Panel featuring Sam Ramji (CodePlex Foundation), Ayende Rahien (NHibernate and Castle Contributor), and Glenn Block (Managed Extensibility Framework) and moderated by Rod Paddock, Editor of CoDe Magazine.
    • The famous, prolific and thorough Ayende Rahien will be speaking on NHibernate.
    • Microsoft's own Glenn will be talking about the Managed Extesibility Framework.
    • M David Peterson will be discussing Mono on Amazon EC2.
    • The ThoughtWorks crew will be talking about F# on Mono.
    • Eric Hexter from Headsprings will be covering ASP.NET MVC.

    From the Mono team, various engineers will be presenting on special topics:

    • Larry Ewing will talk about the Moonlight, the open source implementation from
    • Aaron Bockover will talk about cross platform GUI development with Gtk#.
    • Geoff Norton will discuss development with MonoTouch on the iPhone.
    • Jackson Harper will talk about ASP.NET MVC development with Mono and Joseph Hill will discuss Mono Tools for Visual Studio.
    • Rodrigo Kumpera from our JIT team will do a low-level talk on Mono's Virtual Machine covering some of the innovations on the VM that are Mono-specific.
    • And I will focus on the schmoozing.

    The Monospace conference will be held in Austin, TX on Tuesday, October 27 through Friday, October 30. To register for the event, visit the Monospace Conference Registration Page.

    Check the program for more information.

    Registered Monospace attendees will receive a $150 discount on MonoTouch, if they purchase in the month of October.

    Posted on 16 Oct 2009

    Event mapping in MonoTouch

    by Miguel de Icaza

    When we were designing the MonoTouch APIs we had to map some of the constructs used by CocoaTouch and Objective-C to what C# developer expect.

    Like other modern toolkits, the behavior of a control can be customized by the programmer by hooking up to events and the responses to those events.

    This is a common pattern used in other toolkits. In Gtk+ objects emit signals, and the programmer can connect event handlers to individual signals, for example this is how you would connect

    void pause_player ()
    	// pause the player.
    void configure_pause ()
    	button = gtk_button_new_with_label ("pause");
    	gtk_signal_connect (button, "clicked", pause_player, NULL);

    In the ECMA CLI world developers hook up to events by connecting to events directly in the object, it is similar in spirit:

    void configure_pause ()
    	button = new Button ("Pause");
    	button.Clicked += delegate {
    		// Pause the player here.

    In both the Gtk+ and the ECMA CLI worlds there can be multiple subscribers to the event.

    In CocoaTouch, instead of having an event per action they use a pattern where the components emits all of its messages to an instance of an object. If a button were to emit messages like "clicked", "clicked_violently" and "caption_changed" all of those messages will be sent to an object that implemented the required interface.

    I am going to give myself a literary license and use some terms loosely and write a little bit of imaginary C#.

    A button implementation would look like this:

    interface ButtonDelegate {
    	optional void clicked ();
    	optional void clicked_violently ();
    	optional void caption_changed ();
    class Button {
    	public ButtonDelegate Delegate { get; set; }
    	public Button (string text) { ... }
    	public string Text {
    		get { return text; }
    		set {
    			text = value;
    			DoSomeRepainting ();
    			Delegate.caption_changed ();
    	public EventHandler ()
    		if (event_this_is_the_user_clicking){
    			// Send the message to the Delegate
    			Delegate.clicked ();

    The user of the Button class then needs to implement the interface ButtonDelegate to respond to messages. This in Objective-C is made simple by allowing this interface to have optional methods.

    This would not work with C# interfaces as those require that all the methods on the interface are implemented.

    So we came up with a design that would blend those worlds together.

    Supporting the Objective-C approach

    We can support the Objective-C model where a class can satisfy the contract by just registering methods to respond to the actions. A user could respond to some events like this:

    class Foo : NSObject { 
    	void ConfigureButton ()
    		button = new Button ("pause");
    		button.WeakDelegate = this;
    	[Export ("clicked")]
    	void pause_clicked ()
    		// Pause the button.

    In MonoTouch we expose the "WeakDelegate" property as the weakly-typed version of the delegate, that means that you can assign to it anything that derives from the NSObject class, and respond to messages by just annotating your method with the [Export ("name")] attribute.

    But weakly typing could introduce errors. What if the parameters of the method or the return value do not match the actual signature of the selector. If the developer introduce a typo, the compiler would not be able to point this out, and you would get a nice crash or some corrupt memory.

    So we introduced strongly typed delegates, these require the programmer to implement a class and override methods that have a very specific signature. The code would then look like this:

    class Foo : ButtonDelegate {
    	void ConfigureButton ()
    		button = new Button ("pause");
    		button.Delegate = this;
    	// strongly typed: override ensures that this method exists in
    	// the base class, or the contract is not satisfied. 
    	public override void pause_clicked ()
    		// Pause the button.

    The ButtonDelegate class is flagged with a special attribute, the [Model] attribute which informs the MonoTouch runtime that only methods that are overwritten from this class will be dispatched, any other methods will be considered optional and treated like optional methods.

    The problem of course is that if you wanted to respond to multiple buttons, you would have to actually distinguish them somewhere in your pause_clicked with some sort of closure value, or use helper classes, one for each button that you want to respond to. But that is a minor detail.

    So Objective-C developers that like the separation between model, view and controller can continue to use those patterns.

    That being said, although there is a lot of literature and discussion about the clean separation of Models, Views and Controllers, most samples I run across are a hodgepodge of Controller code for all sorts of things. At least the production code and the samples I have seen make it obvious that the separation of concerns is mostly academic, and in practice an instance object becomes a general purpose responder to all events, very much like you see in Gtk+, Qt, or Winforms.

    Our approach also has a limitation: the hodgepodge approach does not really work with the strongly-typed signatures as you can only derive from one class at a time. The solution is to use separate classes for each controller. Although that cleans things up and has some aesthetics associated with it in terms of clean separation of concerns, in my opinion, it is not very practical.

    Supporting the C# style

    With MonoTouch we wanted to preserve the C# style of programming where you could attach code to these notifications one-by-one.

    With C# you can use anonymous methods or lambda functions. These are incredibly powerful as they are able to capture the environment in which they were created. This means that you can trivially pass information and share information between multiple handlers.

    Additionally, you more than one method can "subscribe" to the same event, you are not limited to a single method being the receiving of the events.

    This means that in MonoTouch you configure buttons like this:

    void configure_button ()
    	button = new UIButton (dims) { Text = "Pause" };
    	button.Clicked += delegate {
    		// Pause the video

    What MonoTouch does internally is that the first time that you attach to a C#-like event, it create an instance of the ButtonDelegate that merely raises the event in the C# style.

    This means that you only pay for the memory usage if you use the feature. But when you do, you can subscribe to individual events and you can have more than one listener attached to the event.

    The Pattern

    Although we brought the pattern to most places in MonoTouch where a delegate was used, it is notably missing from the UITableView as we felt that the number of methods that had to be overwritten were too big for the model to make sense.

    In a few instances like UITableView, we suggest that developers just use the strongly typed version of the delegate classes and override the methods accordingly.

    One of the things that I would like to see is a UITableView derived class that can present the data and style the data entirely based on properties discovered at runtime with System.Reflection.

    Another thing that I want to see is support for System.Data data binding style versions of the UITableView and other UI controls in a single page.

    More details on the low-level implementation are available on the API design document on the web site.

    Posted on 15 Oct 2009

    Git# - First Public Release

    by Miguel de Icaza

    Meinrad Recheis has lead the effort to bring a full managed GIT implementation to the .NET and Mono worlds and he just announced the release of GitSharp 0.1.3, the first public release of Git#.

    The code is based on the original work from Kevin Thompson who ported the JGit Eclipse plugin to C#. Meinrad has put together a great community of contributors that integrated every JGit improvement, the credits for the first release are as follows:

    • Dave Cameron: for fixing bugs
    • Björn Carlson: for killing bugs that crept into the core
    • caytchen: for porting huge parts of the transport layer, and hunting down nasty bugs. btw, what's your real name?
    • Emeric Fermas: for eliminating some of the hardest to find bugs and for verifying the complete test suite against jgit
    • Martinho Fernandes: for fixing bugs
    • Andriano Machado: for porting massive amounts of code and tests, also fixing many bugs
    • Jim Radford: for the continuous integration server account and the support
    • Gil Ran: for porting and fixing lots of tests and initial efforts on Mono
    • Dan Rigby: for porting and fixing tests
    • rolenun: for the command line interface framework. hey, what is your real name?
    • Mauricio Scheffer: for the testing and build server expertise and CI server trouble shooting
    • Neil Stalker: for holding up the flag for git# on Mono compatibility and squashing bugs
    • Kevin Thompson: for initially porting large amounts of code and letting me rise the baby

    An easy to use API is being developed on top of the GIT core, check out some of the examples.

    Posted on 12 Oct 2009

    Your anthropological tidbit of the day

    by Miguel de Icaza

    In 1991 or 1992, I wrote a curses-based file manager for Unix, a clone of the DOS Norton Commander.

    Unlike the Norton Commander, curses, xterms and Linux did not support the mouse. So I called my file manager "The MouseLess Commander".

    Linux at that time was a cauldron of hot ideas. And Alessandro Rubini created a library for console applications to get mouse support on Linux. We worked to add mouse support to the MouseLess Commander and by the end of this exercise we renamed the file manager to "The MouseLess Commander With Mouse Support".

    Somehow I was talked into changing the name of the Mouseless Commander with Mouse Support. Since I was pretty bad at naming, we organized a vote on the mailing list and eventually the current name "Midnight Commander" was picked.

    I miss the previous name.

    Posted on 06 Oct 2009

    World Views

    by Miguel de Icaza

    Richard Stallman does not seem to have anything better to do than launch personal attacks against me. In his last piece he has decided to call me a Microsoft apologist because I do not participate in his witch hunt.

    I merely happen to have a different perspective on Microsoft than he has. I know that there are great people working for the company, and I know many people inside Microsoft that are steering the company towards being a community citizen. I have blogged about this for the last few years.

    At the end of the day, we both want to see free software succeed. But Richard, instead of opening new fronts to promote his causes, attacks his own allies for not being replicas of himself. To him, ridiculous statements like Linus "does not believe in Freedom" are somewhat normal [1].

    A Matter of Perspective

    A few years ago, I had the chance to listen to Benjamin Zander in person talk about his world of possibilities. His book "The Art of Possibility" had a profound effect on me.

    Benjamin tells this story in the book:

    Two shoe salesmen were sent to Africa in the early 1900's to scout the territory.

    One telegraphed back: "Situation hopeless. Stop. No one wears shoes."

    The other telegraphed: "Business opportunity. Stop. They have no shoes."

    Since we only have a limited time on earth, I have decided to spend my time on earth as much as I can trying to be like the second salesman. Looking at opportunities where others see hopelessness.

    This is why I love my work, because I work with friends that have consistently beat the odds and we have consistently proved our critics wrong. Because everyone that I work with wants to change the world and nobody I work with is dominated by fear.

    Far too many times, fear has prevented people from coming up with creative solutions. I rather work on constructive solutions to problems than moan and complain.

    Fear mongering is a vibrant industry, it is the easy way out for those that can not lead with the example. Create a bogeyman, make things up, lie, or tell half-truths, and demonize and you got a recipe to energize your base.

    Richard's Fear Mongering

    The documentary "The Power of Nightmares" is a fascinating view at the industry of selling "safety" to the scared population and how leaders like to scare people to push their own agendas. Richard's fear mongering is no different.

    Richard Stallman frequently conjures bogeymen to rally his base. Sometimes it is Microsoft, sometimes he makes up facts and sometimes he even attacks his own community [2]. His language is filled with simple, George W Bush-eque terms like Good vs Evil, Us vs Them.

    The creation of the CodePlex foundation was an internal effort of people that believe in open source at Microsoft. They have been working from within the company to change it. Working at CodePlex is a great way of helping steer Microsoft in the right direction.

    But to Richard, this simply does not compute.

    To Richard, the state of the world is hopeless. I on the other hand see possibility and opportunity.

    Not only you attract more bees with honey than with vinegar, there are lots of shoes to sell.

    [1] Plenty of attacks on other open source/free sofftware advocates/developers are readily googable.

    [2] the "open source" vs "free software" non-issue and the "Linux" vs "GNU/Linux" wars of the 90's that haunt us to this day.


    I am now closing the comments for this post. Feel free to move this to the Slashdot forum.

    Posted on 05 Oct 2009

    Feedback wanted: StackOverflow DevDays in Boston

    by Miguel de Icaza

    I will be presenting at StackOverflow DevDays in Boston, on October 7th at 4.20pm.

    As usual, I will be talking about Mono. But since Mono is an giant universe, I would like to know what the audience would like to hear about.

    Please fill in my small survey to provide feedback.

    See you there!

    Posted on 30 Sep 2009

    Pictures: ECMA 334/335 January 2003

    by Miguel de Icaza

    At the ECMA meeting in January of 2003 Anders was presenting C# 2.0:

    Todd Proebsting had just developed iterators for C# and was presenting, it was inspired by his previous work on Icon's iterators. Sam Ruby (from IBM), Thomas Plum (from Plum Hall) and Todd:

    Anonymous methods, the foundation for lambdas in C#, used a beautiful code generation technique. Anders who has a beautiful hand writing was explaining the design to the committee:

    Jim Hogg presented the design for generics in the ECMA CIL. Here he is discussing with Arch (at the time with Intel, and the guy behind ECMA's System.Parallelization), Jon Jagger and Emmanuel Stapf (ISE Eiffel):

    Joel Marcey, then at Intel and Jim Miller:

    Todd and Chris Fraser. I was fanboying them. Mono's original JIT design was based on a lot of his work. At dinner Chris recommened Csikszentmihalyi's book on Flow, which I loved:

    Posted on 26 Sep 2009

    Comment Policy on my Blog

    by Miguel de Icaza

    Here is a rough draft of the comment policy for my blog.

    When you come to my blog to comment, you are a guest in my blog and your opinions are hosted there in the same way that you would be hosted if you showed up at my place to chat.

    So standard rules of social engagement are required. If you are unable to operate under regular social situations and you feel the need to insult others or myself in my blog, not only you are not welcome, but your comment will not show up and will be promptly deleted.

    Constructive criticism is always welcome on my blog, now

    If you feel the need to be rude, offensive, lie or you are intentionaly trying to start a fight, I encourage to do that in your blog.

    If you can not articulate your thoughts without attacking and you can not keep your temper in check, I encourage to do that on your own blog.

    Trolling will be removed.

    Posted on 25 Sep 2009

    Branching for Mono 2.6

    by Miguel de Icaza

    Today Andrew branched Mono trunk for the Mono 2.6 release.

    Mono 2.6 is the last release that will support the mscorlib 1.1 profile and the C# 1.0 compiler. We are now moving to a pure generics world with Mono.

    Update: Specifically, we will be removing the 1.0 assemblies from the build, the mcs.exe command will now point to gmcs.exe, all of the xxx1 command versions will be eliminated and all of the conditional code in the Mono class libraires that depended on NET_1_0 and NET_1_1 will be removed.

    As for the Mono 2.6 release notes: we will put those together in the next few days. Please be patient.

    Posted on 25 Sep 2009

    On Richard Stallman

    by Miguel de Icaza

    I want to say that God loves all creatures. From the formidable elephant to the tiniest ant. And that includes Richard Stallman.

    As for me, I think that there is a world of possibility, and if Richard wants to discuss how we can improve the pool of open source/free software in the world he has my email address.

    Love, Miguel.

    Posted on 23 Sep 2009

    MonoTouch 1.0 goes live.

    by Miguel de Icaza

    MonoTouch is a commercial product based on Mono and is made up of the following components:

    • MonoTouch.dll The C# binding to the iPhone native APIs (the foundation classes, Quartz, CoreAnimation, CoreLocation, MapKit, Addressbook, AudioToolbox, AVFoundation, StoreKit and OpenGL/OpenAL).
    • Command Line SDK to compile C# code and other CIL language code to run on the iPhone simulator or an iPhone/iPod Touch device.
    • Commercial license of Mono's runtime (to allow static linking of Mono's runtime engine with your code).
    • MonoDevelop Add-in that streamlines the iPhone development and integrates with Interface Builder to create GUI applications.

    The MonoTouch API is documented on the Mono site. The MonoTouch API is a combination of the core of .NET 3.5 and the iPhone APIs.

    We have created some tutorials on how to use MonoTouch and you can read the design documentation on the MonoTouch framework.

    Some History

    Almost a year ago when we released Mono 2.0 for OSX, I asked the readers of this blog to fill a survey to help us understand where we should take Mono.

    Many developers asked us to provide Mono for the iPhone.

    A year ago, it was possible to use Mono's static compiler to compile ECMA 1.0 CIL bytecode for the iPhone. This is the technology that powered Unity3D's engine for the iPhone.

    Users of Unity3D have published more than 200 applications on the AppStore.

    We debated internally what exactly Mono for the iPhone would be. We considered doing a Windows.Forms port, to bring Compact Framework apps to the iPhone, but that would have required a complete new backend for Windows.Forms and would have required also a "theme" engine to make it look like the iPhone. We discarded this idea early on.

    We decided instead to go with a native binding the iPhone APIs. It would not be a cross platform API and it would tie developers to the iPhone platform, but it would also mean that applications would look and feel native, and developers would get closer to the iPhone.

    Creating a binding for the Objective-C APIs with .NET in the past has relied extensively on dynamic code generation, and this feature is not available on the iPhone (the kernel prevents JIT compilation from taking place). As we started doing the work to bind the low-level C APIs, Geoff started prototyping a new Objective-C/C# bridge that was specifically designed to work within the iPhone requirements.

    By the time we had sorted out the foundation and the Objective-C bridge we had gained some fresh experience from binding the C++ PhyreEngine to .NET and we decided to create a new binding generator to simplify our life (I will blog about this new approach to binding creation in another post).

    At this point, we started investing into supporting not only the device, but support the simulator. This would prove to be incredibly useful for quickly testing the code, without having to wait a long time to compile and deploy on the device.

    The Developer Experience

    At this point, we had enough to create mix-mode GUI applications (they were mostly Objective-C apps hosting Mono) and the pipeline was horrible: it involved using some 3 compilers, having 3 Mono checkouts and applying individual patches to all trees.

    We were aware of how easy Unity had made things for their users, they had set the bar pretty high in terms of usability for us. Unity had some advantages, they could "debug" without deploying the code to the device, something that we could not really do ourselves.

    We were still far from this.

    We introduced a command that would isolate all of the complexities of creating simulator and ARM executables, the mtouch command.

    With the mtouch command and the bindings complete, we started trying out the API by porting the Apple iPhone samples from Objective-C to C#. And in the process finding two things: C# 3.0 constructor initializers are a thing of beauty:

    UIControl SliderControl ()
    	var slider = new UISlider (new RectangleF (174f, 12f, 120f, 7f)){
    		BackgroundColor = UIColor.Clear,
    		MinValue = 0f,
    		MaxValue = 100f,
    		Continuous = true,
    		Value = 50f,
    		Tag = kViewTag
    	slider.ValueChanged += delegate {
    		Console.WriteLine ("New value {0}", slider.Value);
    	return slider;

    And also that the samples ported were half the size of the equivalent Objective-C programs.

    As we were doing this work to iron out the kinks in the API design, Michael got started on designing the MonoDevelop support for the iPhone. This included the regular bits that you would expect like templates, building, running and deploying, but most importantly the Interface Builder integration.

    Interface Builder produces an XML file that describes your UI, and it is able to generate some header files for you, but in general developers that want to refer to components in the UI and implement their backing store have to repeat the same stuff over and over. For example, controlling the contents of a label on the screen requires the developer to declare the same variable three times: 2 in the header file, and one in the Objective-C file (if you are lucky).

    We took a different approach. We made it so that MonoDevelop would automatically generate a code-behind partial C# class for each Interface Builder file. This meant that to users the entire process would be transparent.

    They would define outlets or messages, and those would just become part of their class. Intellisense and code completion would become available to them without any extra coding.

    Posted on 14 Sep 2009

    CodePlex Foundation

    by Miguel de Icaza

    Microsoft today launched the CodePlex Foundation a non-profit organization to promote the open source collaboration between companies and open source communties, projects and individuals.

    This is another step in the right direction for Microsoft. I have been working on open source software since 1992, and back then a world where open source played a major role was a dream to many of us. Microsoft adopting open source licenses, releasing some of their code under open source licenses and being a better community member was the stuff of fiction.

    There are still many things that I would like to see Microsoft do, and many things that I believe Microsoft has to change to become a full member of the open source community, but it is encouraging to me to see Microsoft evolve. I hope that the CodePlex foundation will help us continue to build bridges between our communities.

    I am glad that I was asked to be part of the board of directors of the foundation. And to work together with some great advisory board.

    I hope that I can last more on this foundation than I lasted at the FSF, where I was removed by RMS after refusing to be an active part of the campaign to rename Linux as GNU/Linux.

    Posted on 10 Sep 2009

    MonoDevelop 2.2 Beta 1: We go cross platform.

    by Miguel de Icaza

    MonoDevelop goes cross platform.

    Since the beginning of time, man has yearned to get a cross platform .NET IDE. Homer's Odyssey described one man's effort to achieve such a thing. And it was not until today, September 9th of 2009 that the world can test out such a tool.

    With this release MonoDevelop leaves its cozy Linux nest and embarks on a wild adventure into the hearth of MacOS and Windows. The MonoDevelop team made this one of their major goals for this release: to turn our loved IDE into a cross platform IDE.

    If you are curious about the details, check out the What is new in MonoDevelop 2.2 page.

    MonoDevelop on Windows

    We are not only bringing MonoDevelop to OSX and Windows as a plain GUI port, but we are also providing installers, deep operating system integration and support for native debugging on each platform.

    MonoDevelop on MacOS X

    In addition to becoming a cross platform IDE, there are many new features in MonoDevelop.

    For instance, MonoDevelop can be used to develop ASP.NET MVC applications on OSX and Linux and Silverlight applications on OSX and Linux.


    MonoDevelop now has integrated debugger support. Not only it is able to debug Mono applications, it also can work as a frontend to GDB to debug native applications.

    In addition, on Linux it is possible to debug ASP.NET pages.

    New Add-ins

    New exciting add-ins: ASP.NET MVC, Silverlight and iPhone (for use with MonoTouch).


    A common problem that we face as open source developers is that not every project uses the same coding style. Different teams use different coding conventions. MonoDevelop now supports policies to describe how files should be edited and what defaults should be used in each:

    Editor Improvements

    My favorite new feature is Dynamic Abbrev (Alt-/) a feature that we brought from Emacs and that fills me with joy. That being said, for the non-Emacs lovers there are plenty of features that you asked for, and that we implemented:

    • Extensive refactoring support. And I mean, it is extensive.
    • Code templates.
    • On the fly formatting.
    • Acronym Matching in Code Completion
    • XML Documentation Shown in Code Completion
    • VI mode for those users hooked up on VI commands, they can now use those within MonoDevelop.

    Another pretty cool feature is the code generation support that is triggered with Alt-Insert. When you press Alt-insert it will popup a context sensitive dialog box that offers a few options of code that could be generated at this point: ToString methods, Equals/GetHashCode methods all based on existing fields and properties.

    Why go Cross Platform?

    Going cross platform means that developers will have the same tool across all of the operating systems they use: Windows, Mac and Linux.

    .NET developers that have been enchanted by OSX will be able to continue developing software with their favorite programming languages while enjoying OSX and will be able to go back and forth between Windows, OSX and Linux as needed. This also means that they can work with developers in other platforms, regardless of the personal choices of other team members.

    As many of you know, the number of contributors to a project is linked to the number of users of that project. By expanding our market presence from Linux, we expect to get contributions, fixes, improvements, bug reports, code and add-ins from developers in other platforms.

    We intend to make MonoDevelop the Eclipse of the .NET community. Just like Eclipse became the foundation for Java development, we hope that MonoDevelop will become the foundation for .NET development, and hopefully for much more than that.

    A multi-system IDE

    We are not religious when it comes to supporting other programming languages [1]. We want to embrace not only .NET-based projects like Gtk#, Silverlight, ASP.NET, Boo, C#, F#, Visual Basic and Windows.Forms. We are also embracing other developer platforms like Python, C/C++, Vala, and we want to expand our presence to work with the Flash, PHP, Ruby, Rails, Flex and any other communities that need a cross platform IDE.

    [1] we are just religious about the fact that C# is a better programming language to build an IDE than Java is.


    This release could not have been possible without the endless nights and the collaborations of our contributors and all of the end users that reported bugs and gave us feedback.

    Posted on 09 Sep 2009

    Mono Survey Time!

    by Miguel de Icaza

    Is it that time of the year when I unleash Google Docs' Survey platform on the users of my blog.

    Every once in a while people ask us "When will you support Mono on..." and our answer is usually "thanks for your feedback, we will carefully consider it".

    The reality is that all we have at this point is a lot of anecdotal data. Since my previous surveys on Mono, Mono for OSX, Mono for the iPhone and Mono for Visual Studio turned out to be great tools to understand what people actually want, I have created a new survey.

    In this survey, I want to know how much people are willing to pay for (or not pay) for Mono commercial support on a variety of platforms: Red Hat Enterprise Linux, HP-UX, AIX, Solaris on a variety of architectures.

    Go to my survey

    Posted on 08 Sep 2009

    Mono/.NET CodeCamp in Catalonia, Spain

    by Miguel de Icaza

    The .NET and Mono user communities are working together in Spain to organize a joint .NET/Mono Code Camp. This Code Camp is going to be interesting because it is putting together two communities with very different points of view, but between which there is a lot of synergy. It will be a good chance to talk about Mono, Moonlight, MonoDevelop, MonoTouch and all the stuff we are working on.

    Lluis just announced that the call for papers is ending this Friday, so not much time is left if you want to participate with a talk. There are more details in his blog post

    Posted on 08 Sep 2009

    MonoTouch Resources

    by Miguel de Icaza

    While I was gone, a pretty nice site called MonoTouch.infowas created that is aggregating all kinds of MonoTouch samples, posts, and discussions.

    From the MonoTouch Bill Splitter page.

    It is aggregating many of the samples being discussed in the tweetosphere and from the MonoTouch mailing list.

    The samples are particularly useful as MonoTouch merges two worlds: .NET development and Objective-C programming on the iPhone/iTouch.

    MonoTouch supports the Objective-C like setup where classes can respond to messages and you have to structure your code with MVC patterns. But it also supports the C# event-style programming mode, where developers can use lambda functions to hook up to interesting events.

    You can also follow @monotouchinfo on twitter.

    Posted on 01 Sep 2009

    GitSharp making progress

    by Miguel de Icaza

    Meinrad Recheis emailed me to inform me that he has forked the Gitty project (a project that was doing a line-by-line port of a Java version of GIT) and that the project is making progress on having a full C# based GIT implementation.

    GitSharp source code can be downloaded from github and they are making sure that GitSharp works on both .NET and Mono.

    I can not wait for a MonoDevelop UI for it!

    Posted on 01 Sep 2009

    Silverlight/C#, Flash/ActionScript 3 and Canvas/Javascript

    by Miguel de Icaza

    Been following some of the discussion around Action Script 3 on the tweetosphere. Here are three implementations of the same model from Joa Ebert (he works on a fabulous Flash product for doing music that I absolutely love).

    From his Flirting with Silverlight post:

    Lately a lot of discussion had the ActionScript language as its focus. People start complaining about complex language features but I think they are great because the end user will benefit from that. Yesterday evening I had my very first test with Silverlight — and I am really impressed.

    It took me a short amount of time to port the strange attractor to Silverlight. I agree that this is may be not a fair comparison because I know C# already but have a look at the source code. I make heavy use of type inference and the Matrix4x4 class has the plus, multiply and array-index operator overloaded. The code is more readable. And besides: it executes really fast. Faster than my heavily optimized ActionScript version. Imagine I would write var bleh = 1.0 in ActionScript. Framerate would drop to something like zero. But this is sad since there is no reason for me to write var bleh: Number = 1.0. A modern compiler should be able to figure this out. haXe can do it, C# can do it, OCaml can do it and lots of others as well.

    Remember: This was my first time using Silverlight. To achieve the same result with Flash you have to be kind of an expert in strange player and language “features”. Now tell me again that the end user will not benefit.

    Here are the three implementations:

    Posted on 12 Aug 2009

    C# 4's Dynamic in Mono

    by Miguel de Icaza

    C# 4.0 introduces the dynamic type into the language. The language will ship in Visual Studio 2010.

    Once a variable is declared as having type dynamic, operations on these value are not done or verified at compile time, but instead happen entirely at runtime.

    Marek has been working on Mono's C# 4 implementation and it is coming along nicely. Zoltan wrote a small "PInvoke" dynamic class using Mono's C# compiler that allows you to call C library methods like this:

    	dynamic d = new PInvoke ("libc");
    	d.printf ("I have been clicked %d times", times);

    In this case "printf" is resolved at runtime to be a method in the "libc" library. This is similar to Python's ctype library in about 70 lines of C# leveraging LINQ Expression, the Dynamic Language Runtime and C#'s dynamic:

    The code is:

    using System;
    using System.Dynamic;
    using System.Reflection;
    using System.Reflection.Emit;
    using System.Runtime.InteropServices;
    using System.Threading;
    using System.Linq.Expressions;
    class PInvokeMetaObject : DynamicMetaObject {
        public PInvokeMetaObject (Expression parameter, object o) :
            base (parameter, BindingRestrictions.Empty, o) { }
        public override DynamicMetaObject BindInvokeMember (InvokeMemberBinder binder, DynamicMetaObject[] args) {
            var self = this.Expression;
            var pinvoke = (PInvoke)base.Value;
            var arg_types = new Type [args.Length];
            var arg_exps = new Expression [args.Length];
            for (int i = 0; i < args.Length; ++i) {
                arg_types [i] = args [i].LimitType;
                arg_exps [i] = args [i].Expression;
            var m = pinvoke.GetInvoke (binder.Name, arg_types);
            var target = Expression.Block (
    			    Expression.Call (m, arg_exps),
    			    Expression.Default (typeof (object)));
            var restrictions = BindingRestrictions.GetTypeRestriction (self, typeof (PInvoke));
            return new DynamicMetaObject (target, restrictions);
    public class PInvoke : DynamicObject {
        string dll;
        AssemblyBuilder ab;
        ModuleBuilder moduleb;
        int id_gen;
        public PInvoke (string dll) {
            this.dll = dll;
        public override DynamicMetaObject GetMetaObject (Expression parameter) {
            return new PInvokeMetaObject (parameter, this);
        public MethodInfo GetInvoke (string entry_point, Type[] arg_types) {
            if (ab == null) {
                AssemblyName aname = new AssemblyName ("ctype");
                ab = AppDomain.CurrentDomain.DefineDynamicAssembly (aname, AssemblyBuilderAccess.Run);
                moduleb = ab.DefineDynamicModule ("ctype");
            // Can't use DynamicMethod as they don't support custom attributes
            var tb = moduleb.DefineType ("ctype_" + Interlocked.Increment (ref id_gen) + "_" + entry_point);
            tb.DefinePInvokeMethod ("Invoke", dll, entry_point,
    			    CallingConventions.Standard, typeof
    			    (void), arg_types,
    			    CallingConvention.StdCall, CharSet.Auto);
            var t = tb.CreateType ();
            var m = t.GetMethod ("Invoke", BindingFlags.Static|BindingFlags.NonPublic);
            return m;
    public class Tests
        public static void Main (String[] args) {
            dynamic d = new PInvoke ("libc");
            for (int i = 0; i < 100; ++i)
                d.printf ("Hello, World %d\n", i);

    You can download the C# 4.0 Future document for details.

    Mono's C# 4 compiler so far implements optional parameters, named parameters, has support for the new covariant and contravariant specifiers and the dynamic keyword is evolving very quickly (as shown by the example above).

    If you want to test drive Mono's C# 4.0 compiler, you need Mono from Git and you must pass the "--enable-profile4=yes" argument. Once you do this, the new compiler will be installed as dmcs on your system.

    Nikhil has a nice sample that shows JSon integrated directly into C#.

    Posted on 11 Aug 2009

    C# Sqlite

    by Miguel de Icaza

    Noah Hart did a line-by-line port of Sqlite to C# and has uploaded the code to

    The frequently asked questions on the web site talks about performance (it is about 5 times slower than native code, but still, it can do 1.5 million selects per second, 300k inserts per second).

    Still, not bad for a line-by-line port; Folks on the #mono channel on a couple of days ago were commenting on the possible ways of tuning it up by not forcing the C way where the C# way would work just fine.

    The potential for this library is huge. It could be used for ASP.NET servers running in medium trust mode, or it could be used by Silverlight applications.

    It seems like Tim Anderson is attempting to remove all the P/Invokes from it to make it run on Silverlight (the P/Invokes are mostly used for doing file-level locking; Again part of the line-by-line history of it).

    Posted on 06 Aug 2009

    IronRuby Progres

    by Miguel de Icaza

    Antonio Cangiano from IBM compares the performance of the recently released IronRuby with Ruby 1.8 and 1.9 on Windows.

    On his blog post he looks at both the micro benchmarks and overall benchmarks. The summarized results:

    Antonio comment:

    IronRuby went from being much slower than Ruby MRI to considerably faster across nearly all the tests. That’s major progress for sure, and the team behind the project deserves mad props for it.

    One final warning before we get too excited here. IronRuby is not faster than Ruby 1.9.1 at this stage. Don’t let that first chart mislead you. While it’s faster in certain tests, it’s also slower is many others. Currently, it’s situated between Ruby 1.8.6 and Ruby 1.9.1, but much closer to the latter. The reason why this chart is misleading is that it doesn’t take into account any tests that timed out, and several of such timeouts were caused by IronRuby (more than those caused by Ruby 1.9.1). If you were to add, say, 300 seconds to the total, for each timeout for the two implementations, you’d quickly see that Ruby 1.9.1 still has the edge. The second chart that compares macro-benchmarks does a better job at realistically showing how IronRuby sits between Ruby 1.8.6 and Ruby 1.9.1 from a performance standpoint. If you were to plot every single benchmark on a chart, you’d find a similar outcomes for a large percentage of the tests.

    Whether it’s faster than Ruby 1.9 or not, now that good performances are staring to show up, it’s easier to see IronRuby delivering on it’s goal of becoming the main implementation choice for those who both develop and deploy on Windows. This, paired with the .NET and possible Visual Studio integration, the great tools available to .NET developers, and the ability to execute Ruby code in the browser client-side thanks to projects like Silverlight/Moonlight and Gestalt, make the project all the more interesting.

    Posted on 03 Aug 2009

    MonoTouch: Mono on iPhone closed preview

    by Miguel de Icaza

    We have reached feature completion status for our MonoTouch project and we are looking for some adventurous iPhone developers that might be interested in trying out Mono for the iPhone and the MonoTouch APIs (A C# API for building Cocoa applications).

    We are doing a closed preview to gather feedback on MonoTouch, if you would like to be part of this preview/beta, please fill out the signup form.

    You can browse the source code for the sample widget catalog built using the MonoTouch.UIKit .NET binding to Cocoa's UIKit.

    Posted on 03 Aug 2009

    MonoTouch: Mono on iPhone closed preview

    by Miguel de Icaza

    We have reached feature completion status for our MonoTouch project and we are looking for some adventurous iPhone developers that might be interested in trying out Mono for the iPhone and the MonoTouch APIs (A C# API for building Cocoa applications).

    We are doing a closed preview to gather feedback on MonoTouch, if you would like to be part of this preview/beta, please fill out the signup form.

    You can browse the source code for the sample widget catalog built using the MonoTouch.UIKit .NET binding to Cocoa's UIKit.

    Posted on 03 Aug 2009

    Bridging C# and C++ on Unix

    by Miguel de Icaza

    Unlike Microsoft's .NET, Mono lacks a C++ compiler that can generate CIL code or mixed CIL/native code. This makes it harder for C++ codebases to integrate with C# code.

    One solution to the problem is to write C wrappers for every C++ method and then use P/Invoke to call into each wrapper. Dealing with virtual methods then becomes challenging.

    Andreia Gaita explains on Binding C++ APIs a technique that can be used to bridge the C++ and C# worlds using Mono's built-in support for COM objects.

    Posted on 03 Aug 2009

    SUSE Studio is out - The Linux Appliance Builder

    by Miguel de Icaza

    Update: Nat Friedman has written two great blog posts on SUSE Studio, check them out here:

    Today Novell announced the release of Nat's latest project: SUSE Studio. Nat has been working on this for a very long time.

    Studio is a tool that allows anyone with a web browser to create Linux-based systems and appliances. We believe that this is one of Linux' major strengths and we wanted to turn this potential into a reality.

    In addition to custom Linux builds, Nat's team has put a strong focus on Linux-based appliances.

    The goal of an appliance is:

    • Perform a single task well.
    • Requires minimal assembly and setup.
    • It comes as a standalone unit.

    The idea is that software developers can combine into a single deployable unit (a) the operating system; (b) your software plus any dependencies requires; (c) the proper configuration and data files required to operate.

    When you build your appliance with Studio, you can select the kind of system you want, the packages you want to install, you can preconfigure the system and you can even test-drive the result over the web (it uses a Flash applet) and even fine tune or do some last minute touches over the web (inside the Flash applet) before producing your final version:

    Test your Linux over the web.

    The resulting Linux distribution can be downloaded as an ISO image, you can update it, you can create a bootable USB Linux system with your software, generate a VMWare image or VPC image and next week you should be able to deploy them in Amazon EC2.

    We have been using Studio for building the Mono downloaded VMware/VPC images for a while. We bundle the latest Mono, MonoDevelop and various ASP.NET and Windows.Forms samples for developers to try out.

    As a software developer, you can move from a world where you let the end users assemble the solution themselves:

    Into a setup where you deliver the entire package to your end user:

    The above scenario is common in the Linux world, non-existent in the OSX world, and only large OEMs are able to do the same on the Windows world.

    What we wanted to do was enable anyone, with little Linux expertise to setup their own operating systems. You do not have to be an expert on kernels, boot loading, dependencies or anything else to produce your own operating system.

    In addition to Unix software, we are going to make it very easy for Windows developers to bring their applications to Linux. Our Mono for Visual Studio project will now allow developers to go straight from Visual Studio into a Linux powered appliance:

    Mono Visual Studio Plugin allows .NET to Appliance compilation.

    Posted on 28 Jul 2009

    Proposed C# extensions

    by Miguel de Icaza

    Scott Peterson has written a proposal to extend C# to support parameterless anonymous methods.

    Scott's proposal includes a patch for Mono's C# compiler that implements the suggestion.

    The short story is that with this patch allows constructor initializers to also initialize events in an object. So you can now write code like this:

    var button = new Button () {
        Label = "Push Me",
        Relief = ReliefStyle.None,
        Clicked +=> Console.WriteLine ("ouch!")

    Both Bockover and myself love the 3.0 initializer syntax for objects and the only place where the awesomeness broke was the event initialization.

    Posted on 27 Jul 2009

    Improving Mono's compatibility with .NET CLR

    by Miguel de Icaza

    For as long as we remember, most new versions of IronPython, IronRuby or the Dynamic Language Runtime exposed new missing functionality in Mono.

    After a major release of any of these tools that deeply exercise the internal Reflection.Emit support and the runtime we would implement the missing features and ship a new Mono version.

    As part of the Microsoft/Novell collaboration on Silverlight for Linux, a couple of months ago, we received from Microsoft the test suite for the Silverlight class libraries.

    We have been working on fixing all of the issues exposed by the test suite. The test suite exposed bugs in Mono and missing features that are necessary for Silverlight in general, as well as the DLR and the DLR-based languages like IronRuby and IronPython.

    We are pretty excited about the progress and the increased compatibility of Mono with Microsoft's .NET.

    Posted on 27 Jul 2009

    MonoDevelop Refactoring

    by Miguel de Icaza

    The other day I did a quick tweet-vey asking folks what they wanted to see in MonoDevelop the most. It turned out that what they wanted the most matched pretty much what we had been working on.

    About 50% of the features requested will be in our upcoming MonoDevelop 2.2. One cool refactoring tool is bound to the F2 key. You press F2 in a parameter or local variable, and as you edit the local/variable, all the references in your method are updated accordingly live.


    There are many more features on the pipeline, but they deserve more than a quick post-and-run.

    Posted on 24 Jul 2009

    Using Ruby and Python on Web Clients

    by Miguel de Icaza

    Project Gestalt allows developers to use Ruby and Python to script their web UIs.

    The project is powered by Silverlight's Dynamic Language Runtime and the IronPython and IronRuby. This means that they run under a sandboxed JIT engine.

    Using it in your web pages is very simple. All you need to do is include in your web page the "gestalt.js" javascript. Once you do that, you can then embed Python or Ruby source code using <script> language="python"<script> or <script> language="ruby"<script>

    <button id="say_hello">Say, Hello!</button>
    <script language="python">
    def OnClick(s,e):
      document.say_hello.innerHTML = "Hello, World!"

    This addresses a part of Silverlight's story that I always felt was less than ideal. Without the Gestalt script, developers using Ruby or Python had to package their software on a ZIP file before sending down to the client.

    Jimmy covers in more detail this important development. We both disliked the ZIP-file deployment model that Silverlight comes out of the box with.

    With Gestalt developers can treat Python and Ruby on the client in the same way they have been treating HTML and Javascript. Write code, hit save, refresh page.

    Check the samples.

    All four pieces (Gestalt, the Dynamic Language Runtime, IronRuby and IronPython) are open source technologies that run on either Microsoft's Silverlight or our own open source Moonlight.

    Posted on 22 Jul 2009

    Popular Topics on ServerOverflow

    by Miguel de Icaza

    In the comments from my previous post someone pointed out ServerFault's question clouds:

    The StackOverflow tags are:

    I love to be working, contributing and participating with fabulous people that are advancing the hottest topics of discussion at Stack/Server/Overflow.

    Posted on 22 Jul 2009

    Popular Topics on StackOverflow

    by Miguel de Icaza

    I am probably the last person to find about this, but I find the number of questions/tagged on StackOverflow fascinating:

    Posted on 21 Jul 2009

    TreemapViewer: Building Silverlight Applications on Unix

    by Miguel de Icaza

    A few months ago, to get an idea of what contributed to the size of Mono libraries I wrote a small Treemap visualizer using Moonlight:

    Moonlight's assemblies; area represents the codesize.

    You can browser the code or get a copy from our AnonSVN repository.

    There are a couple of tools here:

    My Treemap is not very ambitious, and it is nowhere as complete as the new Treemap control that is part of the open source Silverlight Toolkit. But it was a fun learning experience for me.

    Reusable Engine

    I did not really know where we would use this control, on the web or on the desktop when I started. So I split the actual engine that does the heavy lifting from the actual chrome for the application.

    This is why I ended up with a Silverlight user interface and a Gtk# user interface. This idea in general might be useful for other developers as well.

    The Custom Control

    The custom control is very simple, it is called TreemapRenderer and derives from UserControl. The code overwrites two methods: MeasureOverride and ArrangeOverride. These methods are used to allow the control to participate in the Silverlight layout system (for example, the control can be embedded in a table that can auto-stretch). Silverlight invokes your MeasureOverride to find out the desired size that you control would like to consume:

    public class TreemapRenderer : UserControl {
    	protected override Size MeasureOverride(Size availableSize)
    	protected override Size ArrangeOverride(Size finalSize)

    Silverlight will invoke your control's ArrangeOverride to layout its contents once it has determined the size that the control will use.

    This is where my TreemapRenderer lays out its contents.

    This code renders an actual region on the treemap, I like the C# 3.0 initializer syntax for the text created:

    public void SetRegion (Rect newRegion)
            region = newRegion;
            content.Children.Clear ();
            content.Width = region.Width;
            content.Height = region.Height;
            if (caption != ""){
                    int max;
                    string formatted = MakeCaption (caption, out max);
                    double w = region.Width * 1.60;
                    double s = w / max;
                    var text = new TextBlock () {
                            FontSize = s,
                            Text = formatted,
                            Foreground = new SolidColorBrush (Color.FromArgb (255, 0x5c, 0x5c, 0x5c))
                    Canvas.SetTop (text, (region.Height-text.ActualHeight)/2);
                    Canvas.SetLeft (text, (region.Width-text.ActualWidth)/2);
                    content.Children.Add (text);
            Rect emptyArea = region;
            Squarify (emptyArea, root.Children);
            Plot (root.Children);

    To provide feedback to the user, I change the background color of the treemap on enter/leave. I use anonymous two anonymous methods, one for MouseEnter, one for MouseLeave.

    Notice that state is shared by these two blocks of code using C# variable capturing. A key feature of the language:

    	bool inside = false;
    	host.MouseEnter += delegate {
    	        host.Background = new SolidColorBrush (Colors.Yellow);
    	        if (text != null)
    	                text.Foreground = new SolidColorBrush (Colors.Black);
    	        inside = true;
    	host.MouseLeave += delegate {
    	        host.Background = transparentBrush;
    	        if (text != null)
    	                text.Foreground = borderBrush;
    	        inside = false;

    One thing that proved very useful was the ability to zoom-into an area. If you click on an assembly, you will get a rendering of the code size used by a type; If you click on that, you get a method breakdown on a class:

    drill-down into mscorlib's sizes.

    To transition, I added a cute animation where I render the new image and animate it from the area occupied in the larger view into the final size. This is the code that queues the animation:

            // Render a child
            void Clicked (Node n)
    		// This is the child rendered, configure it to its final size
                    TreemapRenderer c = new TreemapRenderer (n, n.Name);
                    Size ns = new Size(region.Width, region.Height);
                    c.Measure (ns);
    		// Scale it and position on the spot that it currently
    		// occupies on the screen
                    var xlate = new TranslateTransform () {
                            X = n.Rect.X,
                            Y = n.Rect.Y };
                    var scale = new ScaleTransform () {
                            ScaleX = n.Rect.Width / region.Width,
                            ScaleY = n.Rect.Height / region.Height };
                    c.RenderTransform = new TransformGroup { Children = { scale, xlate } };
                    c.Opacity = 0.5;
                    content.Children.Add (c);
                    activeChild = c;
    		// Animate this to its final location
                    TimeSpan time = TimeSpan.FromSeconds (0.3);
                    var s = new Storyboard () {
                            Children = {
                                    Animate (time, xlate, "X", 0),
                                    Animate (time, xlate, "Y", 0),
                                    Animate (time, scale, "ScaleX", 1.0),
                                    Animate (time, scale, "ScaleY", 1.0),
                                    Animate (time, c, "Opacity", 1.0),
                    s.Begin ();
    	// Helper method;   
            static Timeline Animate (TimeSpan time, DependencyObject target, string path, double to)
                    var animation = new DoubleAnimation () {
                            Duration = time,
                            To = to
                    Storyboard.SetTarget (animation, target);
                    Storyboard.SetTargetProperty (animation, new PropertyPath (path));
                    return animation;

    The Silverlight Application

    Using the control is fairly simple, but since it loads a large XML files (feel free to change this to use a web service) I use the downloader and a callback to render the control.

            private void Application_Startup(object sender, StartupEventArgs e)
                var webclient = new WebClient();
                webclient.DownloadStringCompleted += delegate (object sender2, DownloadStringCompletedEventArgs ee){
                    try {
                        RootVisual.Dispatcher.BeginInvoke(() => LoadNodesFromString(ee.Result));
                    catch (Exception ex) {
                        main.BackButton.Content = ex.ToString();
                webclient.DownloadStringAsync(new Uri("../mscorlib.xml", UriKind.Relative));

    The actual creation of the control happens in LoadNodesFromString:

            void LoadNodesFromString(String s)
    	    // Use Size for the area.
                Node n = LoadNodes(s, "Size", "Extra");
                while (n.Children.Count == 1)
                    n = n.Children[0];
                treemap = new TreemapRenderer(n, "");
                Grid.SetColumn(treemap, 0);
                Grid.SetRow(treemap, 1);

    Building a Gtk# Out-of-Browser Client

    The above works great for Silverlight, but I like my application on the desktop, so I created a Gtk# version of it.

    Moonlight provides a Gtk# widget that can be embedded into C# desktop applications. This is what it looks like when running on the desktop. I know this screenshot is not too exciting as I did not do much with the Gtk+ side of things:

    Gtk# is rendering, seriously.

    The core of embedding Moonlight as a Gtk# widget is very simple, here it is:

    using Moonlight.Gtk;
    using Moonlight;
            public static void Main(string[] args)
                    n = LoadNodes (args [0], "Size", "Foo");
                    Gtk.Application.Init ();
                    MoonlightRuntime.Init ();
    		// My container window.
                    Gtk.Window w = new Gtk.Window ("Foo");
                    w.DeleteEvent += delegate {
                            Gtk.Application.Quit ();
                    w.SetSizeRequest (width, height);
    		// The Moonlight widget that will host my UI.
                    MoonlightHost h = new MoonlightHost ();
    		// Add Moonlight widget, show window.
                    w.Add (h);
                    w.ShowAll ();
                    // Make it pretty, skip all levels that are just 1 element
                    while (n.Children.Count == 1)
                            n = n.Children [0];
                    // Render
                    TreemapRenderer r = new TreemapRenderer (n, "");
                    Size available = new Size (width, height);
                    r.Measure (available);
                    r.Arrange (new Rect (0, 0, width, height));
    		// This informs the widget which widget is the root
                    h.Application.RootVisual = r;
                    Gtk.Application.Run ();

    There are Visual Studio and MonoDevelop solutions on the SVN for folks to try out.

    You can also try a sample live on the web.

    Posted on 20 Jul 2009

    MiggyTour 2009

    by Miguel de Icaza

    In the third and fourth weeks of August, Laura and I will be spending a couple of days in Madrid visiting friends.

    Then a couple of days hanging out with Nat, Stephanie and a bunch of awesome friends and family friends in Florence.

    And then we are spending a week in Morocco, most likely in Marrakesh.

    If you live in Madrid or Marrakesh and would like to get together to meet and talk, send me an email.

    Posted on 17 Jul 2009

    StackOverflow DevDays in Boston

    by Miguel de Icaza

    Joel Spolsky and Jeff Atwood have invited me to participate on StackOverflow's DevDays in Boston on October 7th.

    I will be talking about Mono, Mono and Visual Studio and Mono on iPhone. Come equipped with questions.

    Shocking, I know.

    Posted on 17 Jul 2009

    LLVM powered Mono

    by Miguel de Icaza

    Mono from SVN is now able to use LLVM as a backend for code generation in addition to Mono's built-in JIT compiler.

    This allows Mono to benefit from all of the compiler optimizations done in LLVM. For example the SciMark score goes from 482 to 610.

    This extra performance comes at a cost: it consumes more time and more memory to JIT compile using LLVM than using Mono's built-in JIT, so it is not a solution for everyone.

    Long running desktop applications like Banshee and Gnome-Do want to keep memory usage low and also would most likely not benefit from better code generation. Our own tests show that ASP.NET applications do not seem to benefit very much (but web apps are inherently IO-bound).

    But computationally intensive applications will definitely benefit from this. Financial and scientific users will surely appreciate this performance boost

    Taking it out for a spin

    Note: the notes here are no longer relevant, these applied to Mono back in 2009. LLVM has now been integrated into Mono, follow the steps in instead

    You need to install both LLVM and Mono from SVN.

    Get and install LLVM like this:

    $ svn co llvm
    $ cd llvm
    $ ./configure --prefix=/mono --enable-optimized
    $ make && make install

    Then get Mono, and you need to apply a tiny patch to

    $ wget
    $ svn co svn:// 
    $ svn co svn:// 
    $ cd mono
    $ patch -p1 < m7a9da378.txt
    $ ./ --prefix=/mono --enable-llvm=yes
    $ make && make install

    Now you have an LLVM-powered Mono.

    LLVM is not able to support some of the features that Mono needs, so in those cases the JIT compiler will still fall back to Mono's JIT engine (methods that contain try/catch clauses or methods that do interface calls).

    This backend was written by Zoltan.

    Posted on 16 Jul 2009

    Banshee as a Platform?

    by Miguel de Icaza

    Aaron Bockover recently discussed Banshee's modular architecture. Aaron discusses using Banshee as a foundation for managing not only music, and videos but merging with F-Spot to manage photos as well:

    The slides from his talk go into a bit more detail.

    Jonathan Pobst takes the platform idea one step further and suggests that Banshee's core could also be used to replace YAST's Software Installer UI:

    Jonathan says:

    Every time I use YaST's Software Manager, I wonder if it would be better implemented using Banshee. Banshee's interface has been tuned for usability, both on its own, and what it borrows from iTunes. Software management is a naturally scary operation, and using an interface that the user is already familiar with could help reduce user fear.

    Of course, it would just be the interface pieces of Banshee in a new app, you wouldn't actually start Banshee for software installation.

    Another feature I would like to see taken from iTunes/Banshee is downloading/installing in the background. Once I hit Install, go ahead and download the application in the background, and install it in the background. I can click on the "Downloading/Installing.." menu item if I want to see what's going on. Most of the time, I'd rather be looking at other things to download.

    I think this is a brilliant idea.

    Posted on 15 Jul 2009

    From Microsoft: C# and CLI under the Community Promise

    by Miguel de Icaza

    First the big news: Microsoft will be applying the Community Promise patent licensing to both C# and the CLI.

    The announcement was done by Peter Galli at Microsoft over at Port25 and it states (emphasis is mine):

    I have some good news to announce: Microsoft will be applying the Community Promise to the ECMA 334 and ECMA 335 specs.

    ECMA 334 specifies the form and establishes the interpretation of programs written in the C# programming language, while the ECMA 335 standard defines the Common Language Infrastructure (CLI) in which applications written in multiple high-level languages can be executed in different system environments without the need to rewrite those applications to take into consideration the unique characteristics of those environments.

    "The Community Promise is an excellent vehicle and, in this situation, ensures the best balance of interoperability and flexibility for developers," Scott Guthrie, the Corporate Vice President for the .Net Developer Platform, told me July 6.

    It is important to note that, under the Community Promise, anyone can freely implement these specifications with their technology, code, and solutions.

    You do not need to sign a license agreement, or otherwise communicate to Microsoft how you will implement the specifications.

    The Promise applies to developers, distributors, and users of Covered Implementations without regard to the development model that created the implementations, the type of copyright licenses under which it is distributed, or the associated business model.

    Under the Community Promise, Microsoft provides assurance that it will not assert its Necessary Claims against anyone who makes, uses, sells, offers for sale, imports, or distributes any Covered Implementation under any type of development or distribution model, including open-source licensing models such as the LGPL or GPL.

    You can find the terms of the Microsoft Community Promise here.

    I told you this was good news!

    A few months ago we approached Bob Muglia and Brian Goldfarb (@bgoldy) at Microsoft with a request to clarify the licensing situation for the ECMA standards covering C# and the CLI (also ISO standards, for the ISO loving among you).

    Previously Microsoft had detailed the patent license plans and today they have delivered on those plans.

    Astute readers will point out that Mono contains much more than the ECMA standards, and they will be correct.

    In the next few months we will be working towards splitting the jumbo Mono source code that includes ECMA + A lot more into two separate source code distributions. One will be ECMA, the other will contain our implementation of ASP.NET, ADO.NET, Winforms and others.

    Depending on how you get Mono today, you might already have the this split in house or not.

    Thanks to everyone at Microsoft that worked to get this approved and released. We appreciate that they made this a priority when we approached them, and we know that everyone in the .NET team was also incredibly busy with various betas: .NET 4, Visual Studio 2010, Silverlight, MVC, MEF and much more.

    I am overflowing with joy right now. Cheers!

    Update: Send your thanks to @bgoldy on tweeter, who crossed all the t's and dotted all the i's to make this happen.

    Update: Moderation of comments is taking place. Off topic messages will be removed immediatly. Trolling, as mild as it might be will be deleted. If you want to argue what language is the best one take the debate to a newsgroup.

    Posted on 06 Jul 2009

    PhyreSharp runs on the PS3

    by Miguel de Icaza

    Mono on the PS3 has been making some nice progress. Supporting the PS3 requires some special features in Mono, for instance, a static compiler for .NET code for the PowerPC/Cell processor.

    PhyreSharp, our .NET binding to Sony's PhyreEngine game engine ran on Thursday for the first time.

    Posted on 03 Jul 2009

    MonoSpace Conference Announced

    by Miguel de Icaza

    Scott Bellware has announced the MonoSpace Conference in Austin Texas on October 27-30th.

    Scott has made a Call for Speakers:

    The Monospace Conference is looking for teachers to give tutorials on the Mono framework, tools, languages, and platforms supported by Mono.

    Some tutorials are aimed at .NET developers with little experience with operating systems other than Windows, and others are geared to experienced Mono developers with exposure to the various Mono platforms.

    The tutorials are two hour to three hour interactive sessions that can be any combination of follow-along examples, labs, and lecture.

    We're looking for tutorials on subjects such as Linux, Mac, Windows, web, desktop, servers, message queues, databases, iPhone, Android, Amazon's EC2, among others.

    You can track the progress of the conference at the MonoSpace Conf Blog.

    You can also follow the progress on twitter.

    Scott was one of the founders of the Alt.Net series of conferences.

    Posted on 30 Jun 2009

    Some Cool Mono Announcements

    by Miguel de Icaza

    Yesterday we shipped Mono 2.4.2, our long-term supported version of Mono. It ships Microsoft's opensourced ASP.NET MVC stack for the first time (you could get it before on your own, but now it is integrated) and fixes over 150 reported bugs.

    Chris Toshok announced M/Invoke a tool to port applications that use P/Invokes on Win32 to Linux and MacOS.

    What Chris does not talk about on his post is that he was trying to use some .NET software that interfaces via USB to his glucose meter and was trying to get this to run on Linux. The tool is mostly .NET with the usual handful of P/Invokes to Win32. And this is how M/Invoke was born: a tool to retarget P/Invoke happy applications into becoming pure managed applications.

    This opens new doors to forcefully port more apps to Linux.

    Alan McGovern released a new version of Mono.Nat one of the libraries used by MonoTorrent.

    Jordi Mas released a new version of Mistelix a DVD authoring tool for Linux:

    Jordi's GBrainy brain teaser game was picked up by MoLinux, a regional Linux distribution, and shipped it translated to Spanish:

    Joe Audette's mojoPortal was being installed four times as much when it got included in in Microsoft's Web Platform Installer site (more stats here).

    For years I have loved the Joel on Software rules for software engineering. And one of those rules is "Build in one step". We have not always succeeded, but we have always tried. Lluis delivers the one step to build and run for MonoDevelop on Windows: Load solution, Hit F5, up and running.

    Google Chrome really lead the way here, and I want very badly to have all of Mono building in Visual Studio with one keystroke, but we are not there yet.

    Stephane reports on some nice startup performance improvements for F-Spot. Loading time for 10 images from Stephane's own image collection went from 1.2 seconds to .5 seconds.

    MonoDevelop got some enhanced support for autoconf integration.

    Jeremy Laval released another version of ZenComic a desktop Comic reader:

    David Siegel announced a new release of Gnome Do on behalf of the Gnome Do team. In particular, it is now easier to write "Docklets" for the Gnome Do panel and for those of us that like the Emacs keybindings, it is now possible to use C-N and C-P for navigation

    And of course the Google Summer of Code is in full swing:

    And we have various very exciting projects brewing.

    Jonathan Pobst has been exploring integration points for Mono and Visual Studio 2010:

    Guadec: I will sadly not be attending the Guadec/Akademy conference in Canaria next week. This is going to be a busy summer for us as we are shipping a lot of code in the next few months: Moonlight 2.0, Mono for Visual Studio, MonoTouch 1.0 and Mono 2.6.

    Posted on 30 Jun 2009


    by Miguel de Icaza

    Posted on 29 Jun 2009

    PhyreEngine, Mono, cool Mono uses in Gaming, and more.

    by Miguel de Icaza

    Last week there was a little Mono surprise. It can be found on this Novell-hosted web page web page (scroll a little bit).

    It has been a few very busy weeks at Novell's Eastern Research and Development Facility (Novell NERD Facility) here in Cambridge and we have been incredibly busy polishing some nice toys.

    A few weeks ago we learned about Sony's developer event in the West Coast. Michael, Zoltan and myself worked very hard to put together a demo to show the virtues of C# and the CIL to developers. So we cranked on some record time some code:

    • PhyreEngine#
    • Static compiler for PowerPC for Mono on PS3
    • A yield-based co-routine framework.

    We picked Sony's PhyreEngine to demostrate how to use Mono to write the high-level code for a game using Sony's finely tuned engine. We figured this was better than showing a for loop printing the numbers 1 to 10 on the screen.

    PhyreEngine# wraps PhyreEngine using the same techniques that we used in Gtk# and Moonlight. The resulting API is glorious and by letting PhyreEngine do all the heavy lifting while driving all the high-level from C# there is no way of telling that the driving force is not C++. All you get is pure unadultered productivity.

    To make our demos a little more interesting, Michael wrote a minimalistic yield-based co-routine framework inspired by some of the ideas that our friend Lucas gave us. It is a tiny toy, but we used it to illustrate the concept of using C# iterators as the foundation for game logic development and how a cooperative scheduler would work (Unity game logic works just like this).

    We were also working on completing Mono's port to the PlayStation 3's native operating system (this is different than running Mono on Linux on the PS3: that already works, and it was used for developing CellDotNet, a JIT for the PS3's SPUs). Zoltan developed the static compiler for PowerPC and I did the platform support.

    Mono can now run "Hello World" on the PS3 native OS. There are still lots of ins, lots of outs and lots of whathaveyous that need to be tied up before this fully works and before we are able to run PhyreEngine# on the PS3.

    Posted on 08 Jun 2009

    Developing Cross Platform application with MonoDevelop

    by Miguel de Icaza

    Yesterday Lluis announced the last missing piece from our strategy to make MonoDevelop a full cross-platform IDE: MonoDevelop now runs on Windows as well:

    When we started the planning for MonoDevelop 2.2, the major goal of that release was to get feature parity on Linux, MacOS and Windows.

    We want to grow the community of developers that contribute to MonoDevelop and we wanted to attract add-in developers that wanted to bring their IDE extensions to all three platforms.

    MonoDevelop has recently been getting some nice community contributed plugins like Flash/Flex development support, Vala language support, Mono debugger for OSX (thanks to the nice folks at Unity for this!), VI editing mode and of course our own Silverlight and ASP.NET MVC add-ins.

    My theory is that supporting MonoDevelop on all the three major operating systems will have a multiplication effect in terms of contributions to MonoDevelop: it will help both users and will enable developers that extend MonoDevelop with add-ins to reach more users.

    I secretly want Unity to adopt MonoDevelop as the code editor for Unity; for the FlashDevelop guys on Windows to adopt MonoDevelop as their cross-platform foundation (their users want a cross platform Flashdevelop); for Flashbang to bring their UnityScript framework to MonoDevelop

    Developing an add-in for MonoDevelop now brings your enhancements to a much larger community.

    Look and Feel

    Although the IDE is built using Gtk#, but we are aware that developers want to get things integrated with their operating system as much as possible. This is why we have invested in properly integrating MonoDevelop with the Mac and Windows.

    The Look of MonoDevelop still has a heavy feel of the Linux Gtk+, but we are bluring the lines by making the theme and style match the operating system. Development in Gtk native themes will also continue to improve things.

    Feel wise, we make MonoDevelop follow the conventions of the host platform. For example, on the Mac, MonoDevelop uses the Mac system menu, it uses an entirely different keybinding style that follows what every Mac developer expects (Command-KEY operations that match X-Code for example) and even text selection in the editor behaves differently:

    More work will come, because we want MonoDevelop to feel native on each platform.

    On Windows for example, MonoDevelop runs on top of the .NET Framework and uses the .NET managed debugger instead of using Mono's runtime and Mono's debugger, so there is no dependency on Mono to be installed on the system.

    Posted on 04 Jun 2009

    Moonlight 2 Preview 3

    by Miguel de Icaza

    Another week of excellent work on the Moonlight universe and we bring you our Preview 3 release of Moonlight. Alan McGovern said it best though.

    This week stats:

    This is what the Silverlight Toolkit Sample page looked with Preview 2:

    Moonlight 2 Preview 2

    This is what the Silverlight Toolkit page looks with Preview 3:

    Moonlight 2 Preview 3

    You should be able to update directly from Firefox, or if you are trying it for the first time, go to our page.

    Now, although Preview 2 was able to run the IronPython mini-Web IDE I am still going to try to pass that as a new feature.

    And now you can try the IronPython mini-Web IDE!

    Posted on 18 May 2009

    Three Melon's Quest for R2-D2

    by Miguel de Icaza

    I had the honor to meet the Three Melon developers at Unity's party this year at the Game Developer Conference. Three Melons is an Argentinian-based company that builds online games, and most recently they have been using Unity to build their new online games.

    Today they just announced that their latest online game powered by Unity and Mono. "Quest for R2-D2" is now live at

    Pato Jutard, co-founder of Three Meleons announced the launch and posted the Making of Lego Star Wars game by Three Melons:

    Congratulations to the Three Melon developers for their launch!

    You can follow them on twitter.

    Posted on 16 May 2009

    Moonlight 2 Preview 2

    by Miguel de Icaza

    As we promised last week (threatened?) now that the foundation for Moonlight 2 is in place, we will be doing weekly releases for folks to try out, and to increase the feedback that we have received.

    Thanks to everyone that provided bug reports and contacted us about the problems with last week's preview. In particular the issue affecting Ubuntu and SLED 10 users has been fixed and the plugin should work.

    If you installed Moonlight already, you can update either by restarting Firefox or by following these steps:

  • Click Tools/Addons
  • Click on the "Extensions" toolbar icon.
  • Click "Find Updates":
  • This will check for updates, and take you to the updates tab. Then clikc "Install Updates".

    If you have not installed Moonlight yet and want to try it out, go to

    This release fixes various rendering problems, more sites should be working and the performance was increased in multiple hot spots.

  • Posted on 12 May 2009

    Micro Focus Video

    by Miguel de Icaza

    My friend Stephen sent me an interesting video they just cooked up at Micro Focus giving some hints as to what is coming up on the keynote of Micro Focus Live.

    They recently bought Borland.

    Video: Micro Focus Live Developers Keynote.

    Posted on 11 May 2009

    Developing Silverlight Apps on Linux and MacOS with Moonlight

    by Miguel de Icaza

    Earlier this week I promised I would blog about how to build Silverlight apps in Linux. Michael beat me to this and did a couple of screencasts.

    In Moonlight Development in Linux with MonoDevelop he walks us through the steps necessary to install the Moonlight SDK on top of Mono 2.4 and using MonoDevelop to create your app. Once you get these installed, here is how you get started with development:

    To render this content, you need Silverlight or Moonlight Preview or Silverlight

    MonoDevelop will provide auto-complete for the Silverlight APIs and also provide auto-complete in XAML files.

    In addition to Linux, you can also use MonoDevelop on OSX to do the same thing. We shipped Moonlight's SDK as part of the MonoDevelop/OSX release, the result runs with Microsoft's Silverlight.

    Michael again talks about it and produced a nice screencast:


    Posted on 08 May 2009

    I, for one, welcome our new SH4 embedded overlords.

    by Miguel de Icaza

    ST Microelectronics, the maintainers of GCC-CIL (the GCC code generator backend that produces ECMA CIL bytecodes for Mono/.NET) have announced their port of Mono to the SH4 platform.

    The code is currently available from

    In addition to the MIPS64 port that I mentioned last week from SiCortex/nIX is now being merged into Mono's repository.

    MIPS apparently is not only used in super computers, but apparently is also powering $169 dollar netbooks.

    Posted on 07 May 2009


    by Miguel de Icaza

    Dana Blankenhorn comments on the the Moonlight 2.0 release and says:

    It's the kind of open source success story Microsoft wants publicized. Microsoft innovates, open source copies.

    It's not the kind of open source story open source needs, however.

    What open source needs is real innovation, created by teams who may or may not represent Microsoft's fierce competitors. This can be hard to deliver, and Microsoft would like us all to know resistance in this case is futile.

    A few points.

    First: Moonlight's core is designed to ensure that Linux users get access to content that is produced for Silverlight on the web.

    This is about making sure that Linux (and for that matter any other system where Moonlight can be compiled) does not become a second class citizen on the web.

    Folks will argue all day whether the Silverlight model is the right one; whether it is gaining adoption; whether it is necessary; whether it is part of the open web.

    But none of that matters when trying to access content on Linux: it is either possible to use it, or not. And having a working relationship with Microsoft allows us to bring it to Linux.

    Second: Dana is looking in all the wrong places for innovation. If he wants to see my team's work that deviates from the set of APIs that Microsoft has created, he could look at our work on SIMD; our interactive C#; Static compilation technology to support things like the iPhone; our cross platform MonoDevelop (Linux, OSX, Windows); Our Gtk# API for building the above; He could look at all of our Mono.* classes, or all of the libraries and APIs produced by our community (Mono.Addins, Mono.Nat, Mono.ZeroConf, BitSharp, Cecil, CocoaSharp, MonoObjc, Crimson, and some forty others; I just got tired of going through the list here and here).

    All of these created to solve a particular problem with the tools that we had on the platform we used.

    Or for that matter, even reading the announcements on my blog.

    Or he could look elsewhere in the vast universe of open source projects for ideas that match his definition of innovation. Not everything that is built in the open source world has to be about innovating in a completely new direction.

    Third, and most important one: The definition of Innovation.


    Most people that discuss innovation have not even bothered to actually think about what this means in the first place. And I am particularly bothered when people claim that open source does not innovate, but can only copy.

    Google's define:innovation is a good starting point.

    Are Ideas Innovations? Everyone has ideas, even great ideas. Every day you go to lunch, every day you are taking a shower, every day you are walking alone and thinking you are having new ideas.

    You can have a million ideas, and these might be innovative, but if they do not reach the world, did they matter?

    For an idea or an innovation to have a practical effect, they need to go beyond the discussion at the lunch table with your friends and become a reality.

    Bringing an Idea to Life Once I sit down and turn my idea into an actual tangible result there are a number of hurdles in my path.

    The idea must be good enough for people to try out, I must get it distributed, and I must get people to use it.

    Being first versus being to market first: It does not matter that many great ideas originate in the open source world or at the lunch table with your friends. You must bring the ideas to the public and the public must be in a position to adopt it.

    For instance, Compaq/Digital were showing portable MP3 players based on Linux years before the iPod took the world by storm. Yet, nobody remembers these devices anymore and Apple gets the credit for bringing digital audio to the masses.

    Or tagging and searching your email. GMail uses it today, but few people remember that the idea had been implemented before in Digital's Pachyderm.

    Many ideas might originate as personal prototypes or even open source prototypes, but without a distribution channel and an ecosystem that would sustain the innovation many of those ideas exist merely to be replaced by folks in a better position to market/distribute it.

    Claiming "I had the idea first" or "we were the first ones" is of little consolation if someone out-executes and out-markets you.

    Definitions of Innovation: Wikipedia (as of 10 seconds ago) defines Innovation as:

    The term innovation means a new way of doing something. It may refer to incremental, radical, and revolutionary changes in thinking, products, processes, or organizations. A distinction is typically made between invention, an idea made manifest, and innovation, ideas applied successfully.

    I also like this one (from Google's define: too):

    Innovation is the process that translates knowledge into economic growth and social well-being. It encompasses a series of scientific, technological, organizational, financial and commercial activities.

    I think that Moonlight fits this definition perfectly well in that case.

    Moonlight and Innovation

    Sure, we do follow the APIs that Microsoft set for Silverlight.

    But we have innovated in a number of ways:

    • We innovate in the development process: we are an open source project, taking contributions and consuming other open source components.

      We dogfood other FOSS components, and we iterate to improve them.

      In 1999, the MIT Technology Review magazine named me the innovator of the year. In the award ceremony, Bob Metcalfe said that I was receiving the award for the work on Gnome, not because Gnome was a ground-breaking system, but because the goals and processes of Gnome were.

    • We innovate in our cross-platform stance: Moonlight runs on more platforms (although admittedly, with a smaller market share than Windows and MacOS).
    • We had out-of-browser support before Silverlight did: Sure it was trivial, but we had it before (see above note on futility of claiming "we were here first").
    • Working with Microsoft: Ok, this is a bit of a stretch to claim as innovation, but here it goes: I am very proud that we are finding ways of working with a company that for many years resisted Linux and open source as well as helping Microsoft with all of its inertia become more open source friendly.
    • Update: Mats on the comments points out something that I wish I had thought of when I wrote this: "Innovation is also, and I'd say mostly if history teaches us anything, about building and improving upon ideas - not just making new ones from scratch."

    We (the Mono/Moonlight team) are not Dana's beacon of revolutionary change. But it is no secret that we are fans of the CLI virtual machine, and we believe that giving developers this platform will help them turn their ideas into innovations by giving them the best technologies available.

    Users of Mono and Moonlight have already demonstrated that they have way better ideas than I have ever had. And they already have used Mono in brilliant ways. Dana might want to check my blog more periodically to take note of those innovations.

    Posted on 06 May 2009

    Mono talk at the Beantown.NET Users Group

    by Miguel de Icaza

    Tomorrow, Joseph, Michael, Gonzalo and myself will be talking at the Beantown.NET Users Group about Mono, Moonlight and MonoDevelop at 6pm.

    If you are in the Boston area, come join us for these open source festivities at Microsoft NERD center in Cambridge.

    Posted on 06 May 2009

    MonoDevelop on MacOS X

    by Miguel de Icaza

    Good news for all OSX users, a build of MonoDevelop that integrates with OSX is now available:

    MonoDevelop OSX-ified.

    For the impatient among you, click and run

    It requires Mono 2.4 for OSX, on the upside, you can use this to develop ASP.NET MVC apps on the Mac.

    Some Background

    Back in February I showed a screenshot of MonoDevelop 2.0 for the Mac, it looked like this:

    Super-Alpha-Preview of MonoDevelop on OSX.

    It was basically the Gtk# based MonoDevelop IDE binary executing on the Mac. There was no porting involved, just the same executable running under Mono/OSX. The code works, but it did not feel like a Mac app:

    • The Menu bar was embedded in the window.
    • The keyboard accelerators were the Linux ones. They felt unnatural for OSX users, and also did not take advantage of the spare key (Command) to liberate the control key for other uses.
    • The editor behaved like a Linux editor.

    There is a vibrant Mono on OSX community out there, and it will only grow larger. We wanted to make sure that all of the work that is going into creating a great IDE is available for folks on the Mac in a way that is actually comfortable to use.

    So working with folks in the Mac Community and with folks at Unity Michael has been working on tuning up MonoDevelop on the Mac to become an editor that does not get in the way of Mac users and developers and integrates better from the "feel" perspective with other tools in the OS.

    For instance, not only does the new MonoDevelop for MacOS use the Mac menu bar, and the Mac accelerators (a combination of XCode and Textmate accelerators), but even the text editor has been altered to support the way selection and navigation works on the Mac.

    I figured that for every 100 users of MonoDevelop one of them will contribute patches back to the effort. If you happen to be that 1% hacker that will contribute back, you might want to look at a list of ideas to improve MonoDevelop on the Mac.

    MonoDevelop on Windows.

    MonoDevelop on Windows is on a similar boat: the 2.0 release works "out of the box" on Windows, but again, it is a GNOME IDE in a Windows land.

    Stay tuned for news from the MonoDevelop community as to what will happen there.

    Update: Lluis posted an update on the progress of MonoDevelop on Windows.

    Posted on 05 May 2009

    Smooth Streaming with Moonlight

    by Miguel de Icaza

    I never tested Smooth Streaming before, just the more basic media tests, but the Smooth Streaming stack is running with our Moonlight preview:

    You can see a few rendering glitches for the controls on the screen. But this is really good news for our new media pipeline.

    Posted on 05 May 2009

    First Moonlight 2.0 Preview is Out

    by Miguel de Icaza

    After a loving incubation period, the Moonlight 2.0 preview, an open source implementation of Microsoft's Silverlight for Linux has been released:

    This is really the release I have been looking for since Microsoft first introduced Silverlight 1.1 and ever since our 21-day hack-a-thon to bring Silverlight to Linux.

    This is the ECMA VM running inside the browser and powering C# and any other CIL-compatible languages like Ruby, Python and Boo. You can use Moonlight/Silverlight as a GUI (this is what most folks do) or you can use it as the engine to power your Python/Ruby scripting in the browser.

    Installing Moonlight 1.9

    Go to our preview page, select the platform and hit the download icon.

    That will download and install the plugin in your Firefox installation. You can then restart the browser, and you should see this:

    Then you can try out some of the test web sites we have been working on. This is CNN's The Moment that uses Silverlight/Photosynth:

    If instead of binaries you want to build Moonlight in the comfort of your own living room while sipping margaritas, fetch the source code for mono, mcs, mono-basic and moon from the branch and build them in this order: mono, mono-basic and moon.

    While one hand holds your margarita, use the other one to follow the instructions on how to compile Mono from SVN.

    Some Notes on this Release

    Now some qualifications to this release:

    This is a preview release. By this we mean that we are not yet feature complete with Silverlight 2.0 feature-to-feature but we are relatively close. For example, we do not yet pass the entire Silverlight GUI 2.0 test suite that was provided to us by Microsoft and you can spot glitches in various web sites.

    Security Sandbox: One of the reasons we delayed the first preview of Moonlight for public consumption was that we did not want to release Moonlight without the security sandbox. In the pre-Moonlight days there was no reason for Mono to implement a security sandbox, so we never had it. With Moonlight a security sandbox is mandatory so we implemented it.

    Moonlight 2.0 ships with the new CoreCLR Sandbox that was introduced in Silverlight 2.0. This security system is very easy to understand, it is pretty straightforward and is a lot easier to secure and audit than something like CAS. I will blog about the security stack in another post.

    But even if we now have a security sandbox , we have not completed the security audit.

    Weekly Releases: Our current plan is to update the plugin once a week during this preview/alpha period hoping that we can get good bug reports and to ensure that we work in as many Linux distributions as possible.

    Debug Builds: During the preview/alpha cycle we are shipping our code with debugging symbols hoping that this will improve the quality of the bug reports that we receive. This means that the plugin size instead of being 3.9 megs is 8.8 megs on average. This will change when we do the final release.

    The Cool Toys

    There are a number of cool toys on this release, the foundation for many things to come. Here are some:

    Silverlight Unix SDK: If you install Mono 2.4 and Moonlight SDK (not the browser plugin, but the -devel package) you can now develop Silverlight applications entirely in Unix.