Mono in 2011

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.

Xamarin

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 the following videos (first, second and third).

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

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++).

CXXI

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.

Unity3D

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:

Microsoft

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.

MonoDevelop

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.

SGen

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.

Gtk+

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.

ECMA

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 by Miguel de Icaza

CXXI: Bridging the C++ and C# worlds.

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 {
public:
	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 bridge.so */
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 {
public:
	void SetVisible (bool visible);
	virtual void Layout ();
	virtual void Draw ();
};

class Label : public Widget {
public:
	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:

__ZN6Widget10SetVisibleEb
__ZN6Widget6LayoutEv
__ZN6Widget4DrawEv
__ZN5Label7SetTextEPKc
__ZN5Label7GetTextEv

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.

Demos

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 by Miguel de Icaza

2011: Tell me how you used Mono this year

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 by Miguel de Icaza

Porto Alegre

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 by Miguel de Icaza

Farewell to Google's CodeSearch

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.

Thanks!

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 by Miguel de Icaza

Updated Documentation Site

Jeremie Laval has upgraded our Web-based documentation engine over at docs.go-mono.com. 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 by Miguel de Icaza

Hiring Mono Runtime Hackers

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 jobs@xamarin.com

Posted on 18 Oct 2011 by Miguel de Icaza

Upcoming Mono Releases: Change in Policies

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 by Miguel de Icaza

WinRT and Mono

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 by Miguel de Icaza

WinRT demystified

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

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.

    Comments

    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 by Miguel de Icaza

    Xamarin and Mono at the BUILD Conference

    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 by Miguel de Icaza

    MonoDevelop 2.6 is out

    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 by Miguel de Icaza

    Learning Unix

    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.

    Classics

    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 by Miguel de Icaza

    And we are back: Mono 2.10.3

    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 by Miguel de Icaza

    MonoDevelop on Lion

    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 by Miguel de Icaza

    Novell/Xamarin Partnership around Mono

    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.

    Roadmaps

    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 contact@xamarin.com. 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 by Miguel de Icaza

    Update on Mono

    I have a posted an update on Mono and the upcoming release of Mono 2.12.

    Posted on 06 Jul 2011 by Miguel de Icaza

    Mono Consultants

    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 contact@xamarin.com, 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 by Miguel de Icaza

    Xamarin Joy Factory

    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 by Miguel de Icaza

    Xamarin recruits best CEO in the Industry

    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 by Miguel de Icaza

    Announcing Xamarin

    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.

    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 by Miguel de Icaza

    Dropbox Lack of Security

    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 by Miguel de Icaza

    Save the Date: Monospace Conferece in Boston

    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 by Miguel de Icaza

    Save the Date: Monospace Conferece in Boston

    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 by Miguel de Icaza

    Mono Android and iPhone Updates

    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.

    APIs

    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.

    Linking

    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: docs.mono-android.net.

    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 by Miguel de Icaza

    Mono and Google Summer of Code

    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 irc.gnome.org

    Posted on 30 Mar 2011 by Miguel de Icaza

    Monospace Conference: Boston, July 2011

    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 by Miguel de Icaza

    Save your Cleverness

    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 by Miguel de Icaza

    Hardware Accelerated Video Playback in Moonlight

    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 by Miguel de Icaza

    Kid's Games on the iPad

    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 by Miguel de Icaza

    GDC 2011

    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 by Miguel de Icaza

    Saturday Mono Update

    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 by Miguel de Icaza

    MVP Summit and GDC 2011

    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 by Miguel de Icaza

    C# Compiler as a Service Update

    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);
    4
    csharp>
    

    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
    #!/usr/bin/csharp
    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
    bash$
    

    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.

    Silverlight

    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 by Miguel de Icaza

    Well, Actually

    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 by Miguel de Icaza

    Moonlight 4 Preview 1 is out

    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.

    Rendering

    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.

    Gallium3D

    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 {
    	  protected:
    		MyElement ();
    	  private:
    	        // 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 by Miguel de Icaza

    Three Months and Ten Days

    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 by Miguel de Icaza

    Nokia Simplifies the Mobile Landscape

    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 by Miguel de Icaza

    On Reflector

    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 by Miguel de Icaza

    Adult Principles, from JPBarlow

    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 by Miguel de Icaza

    Help us test Mono 2.10

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

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

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

    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 by Miguel de Icaza

    Your Own Sandbox

    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 by Miguel de Icaza

    Mono at CES: More Games

    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 by Miguel de Icaza

    Mono for Android

    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 by Miguel de Icaza

    Open Source Contribution Etiquette

    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 by Miguel de Icaza

    For your OOXML Conspiracy Theories

    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

    Brazil

    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 by Miguel de Icaza

    MonoReports: Report Designer and Reporting Engine

    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 by Miguel de Icaza

    Mono: What we are Cooking

    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 by Miguel de Icaza

    Gtk# designer on OSX

    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 by Miguel de Icaza

    Mono Introspect: Binding GObject-based APIs for use in Mono

    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 by Miguel de Icaza

    Beautiful Hack: Using Mono's Profiler to find Hard Memory Leaks

    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 by Miguel de Icaza

    New iOS/OSX blog

    I have started a new blog on my iOS/OSX experiences with MonoTouch and MonoMac over at http://tirania.org/monomac.

    Posted on 30 Nov 2010 by Miguel de Icaza

    David Reveman lands GPU acceleration for Moonlight…

    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 by Miguel de Icaza

    MonoDevelop 2.4.1 is out

    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 by Miguel de Icaza

    Fund Raising 2.0

    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.

    Balance

    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 by Miguel de Icaza

    GitHub Organizations for IronLanguages and F#

    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 by Miguel de Icaza

    F# MonoDevelop Add-In Available

    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 by Miguel de Icaza

    Mono Developer Room at FOSDEM

    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 by Miguel de Icaza

    New Mono Log Profiler

    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 by Miguel de Icaza

    F# Goes Open Source

    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 fsxplat.codeplex.com 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 by Miguel de Icaza

    Visiting Redmond and PDC

    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 miguel@novell.com.

    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 by Miguel de Icaza

    IronRuby and IronPython Opportunities

    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.

    Opportunities

    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.

    Teaser

    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 by Miguel de Icaza

    Missed Opportunities at Microsoft and Ray Ozzie Departure

    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 by Miguel de Icaza

    Shipping Smiles on the AppStore

    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 by Miguel de Icaza

    Bringing Smiles to the Faces of MacOS developers

    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.

    Community

    Update: to get started with MonoMac, you can join other MonoMac-ers on the IRC channel #monomac on server irc.gnome.org.

    We use the mono-osx mailing list to discuss the binding.

    Hackers

    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.

    Contributors

    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 by Miguel de Icaza

    A Mono Success Story of Biblical Proportions

    Read David Mitchell's experience in using Mono to reuse code between the Windows and Mac platforms.

    Posted on 07 Oct 2010 by Miguel de Icaza

    Mono 2.8 is out

    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 by Miguel de Icaza

    The Mystery Behind the Hacking the Boston Museum of Fine Arts

    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 by Miguel de Icaza

    Chicken Tikka Masala Burrito

    	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 by Miguel de Icaza

    Unix Stack Exchange: Call for Help

    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 by Miguel de Icaza

    This was news to me

    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 by Miguel de Icaza

    Great News for MonoTouch Users

    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 http://monotouch.net/Store.

    We have also a surprise in store for existing MonoTouch customers that we will be announcing next week.

    Posted on 09 Sep 2010 by Miguel de Icaza

    Initial Thoughts on Oracle vs Google Patent Lawsuit

    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 by Miguel de Icaza

    Unix and Linux StackExchange

    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 by Miguel de Icaza

    MonoTools 2 for VisualStudio has been released

    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.

    Appliances

    And we integrate directly with SuseStudio to create your ready-to-run appliances directly from Visual Studio.

    Posted on 03 Aug 2010 by Miguel de Icaza

    Mono has migrated to GitHub

    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 irc.gnome.org 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 by Miguel de Icaza

    Mono 2.8 Trick: tracing exceptions

    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 by Miguel de Icaza

    Banshee Ships with Amazon Store Support

    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 by Miguel de Icaza

    Building apps for the Retina Display

    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.

    Images

    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 file@2x.ext 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);
    		else
    			UIGraphics.BeginImageContext (size);
    	}
    	

    This is how the swipe menu is rendered at high resolution:

    More

    Apple's Supporting Resolution Independence document has more information.

    Posted on 20 Jul 2010 by Miguel de Icaza

    Mono's Git Migration

    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://mono-cvs.ximian.com/source" 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 by Miguel de Icaza

    Fresh Mono Baked

    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 by Miguel de Icaza

    Microsoft Licensing Changes for IronRuby and IronPython

    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 by Miguel de Icaza

    Spaniard Anger Towards Mexicans

    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 by Miguel de Icaza

    New Mono Runtime Features

    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.

    New MONO_ENV_OPTIONS

    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 by Miguel de Icaza

    GZip your downloads

    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 by Miguel de Icaza

    Microsoft MS-PL code in Mono

    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 by Miguel de Icaza

    First MonoTouch Book is out

    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 by Miguel de Icaza

    Pinta 0.4 Released

    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 by Miguel de Icaza

    TweetStation: Elevating the Discourse

    (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.

    Updates

    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 by Miguel de Icaza

    Guadec this year.

    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 by Miguel de Icaza

    What I would do if I was in charge of Windows 8

    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 by Miguel de Icaza

    Moonlight 3.0, Preview 7

    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 by Miguel de Icaza

    Infragistics Announces Support for Mono

    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: http://mono.infragistics.com/

    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 by Miguel de Icaza

    We have released MonoDevelop 2.4

    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 irc.gnome.org on channel #monodevelop, or join our mailing lists.

    Posted on 16 Jun 2010 by Miguel de Icaza

    Road to MonoDevelop 2.4: Navigation

    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 by Miguel de Icaza

    Conditional Attribute

    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 by Miguel de Icaza

    My first iPhone app

    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:

    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

    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

    Updates

    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: http://yfrog.com/c9wlkogj.

    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 by Miguel de Icaza

    First Beta of MonoTools 2 for VisualStudio

    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.

    Appliances

    And we integrate directly with SuseStudio to create your ready-to-run appliances directly from Visual Studio.

    Posted on 03 Jun 2010 by Miguel de Icaza

    Linux for Consumers: MeeGo Updates

    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.

    MeeGo

    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 by Miguel de Icaza

    MonoDroid - Mono for Android Beta Program

    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 by Miguel de Icaza

    Group Completion in MonoDevelop 2.4

    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 by Miguel de Icaza

    MonoDevelop's New Search Bar

    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 by Miguel de Icaza

    Pinta 0.3 is out

    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 by Miguel de Icaza

    CLI on the Web

    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: http://bit.ly/sLILI

    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";
    </script>
    	

    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

    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.

    Resources

    You can learn more about the security model in my previous blog post.

    Our open source Silverlight implementation.

    Posted on 03 May 2010 by Miguel de Icaza

    MonoTouch and Apple's Section 3.3.1: Two Theories

    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 by Miguel de Icaza

    Mono's C# Compiler as a Service on Windows.

    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 demo-repl.zip 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.

    Background

    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 by Miguel de Icaza

    MonoMac Bindings: Blending Cocoa and .NET on OSX

    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.

    Background

    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: http://monotouch.net/Documentation/API_Design

    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.

    Status

    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 http://mono.ximian.com/monobuild/preview/download-preview/

    Posted on 19 Apr 2010 by Miguel de Icaza

    MonoTouch 3.0

    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 by Miguel de Icaza

    Moonlight 3 Preview 6

    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 by Miguel de Icaza

    ECMA 2010 Common Language Infrastructure Public Draft

    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 by Miguel de Icaza

    MonoTools for Visual Studio 1.1

    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 by Miguel de Icaza

    C#, Mono and the Google Summer of Code

    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 by Miguel de Icaza

    The Right Spirit

    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 by Miguel de Icaza

    Microsoft and .NET

    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 by Miguel de Icaza

    OData Client goes Open Source

    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 http://odata.netflix.com/Catalog/CatalogTitles) 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 by Miguel de Icaza

    Baby on the Way

    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 by Miguel de Icaza

    Big Day in MonoLand

    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 by Miguel de Icaza

    Simplified User Interfaces on the iPhone with MonoTouch.Dialog

    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 {
        [Section]
        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

    Code:

    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 by Miguel de Icaza

    MeeGo Support in MonoDevelop

    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 by Miguel de Icaza

    Using MonoDevelop to Debug Executables with no Solution Files

    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 by Miguel de Icaza

    What have we been up to?

    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.

    Ciao!

    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 by Miguel de Icaza

    Valentine's Day Call to Action

    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 by Miguel de Icaza

    Winter Olympics on Linux

    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 by Miguel de Icaza

    Moonlight 3.0 Preview 1

    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 by Miguel de Icaza

    Mono at FOSDEM

    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 by Miguel de Icaza

    iPad - Inspirational Hardware

    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

    iPad Support for MonoTouch!

    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 http://monotouch.net/iPad and follow the instructions.

    Let the iPad# hacking begin!

    Posted on 28 Jan 2010 by Miguel de Icaza

    Release-o-Rama

    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 by Miguel de Icaza

    24 hour race

    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 by Miguel de Icaza

    Preordering the Apple Tablet

    Posted on 25 Jan 2010 by Miguel de Icaza

    MVP Award

    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 by Miguel de Icaza

    Mono at FOSDEM

    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 by Miguel de Icaza

    Pixel Shaders for Moonlight

    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 by Miguel de Icaza

    Moonlight: Platform Abstraction Layer Lands

    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 by Miguel de Icaza

    C# Support for Tuples

    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 by Miguel de Icaza

    New Moonlight Covenant has been posted

    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 by Miguel de Icaza

    Cena Linuxera en el DF, hoy

    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 by Miguel de Icaza

    C# String Interpolation

    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 by Miguel de Icaza

    Debugging Silverlight/Moonlight Apps on Linux

    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 by Miguel de Icaza

    Releasing Moonlight 2, Roadmap to Moonlight 3 and 4

    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 li