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

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

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

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

« Newer entries | Older entries »