Guadec this year.

by Miguel de Icaza

This year I will be skipping the Guadec conference. Like Ted Gould we are expecting our first baby this year around the same time that Guadec will take place.

The good news is that next year any of you attending my talk at Guadec 2011 will get to enjoy a presentation packed with baby pictures.

I wish a happy Guadec to all the Gnomers attending!

Posted on 30 Jun 2010

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

by Miguel de Icaza

Apple and its AppStore did for software programmers what Google's AdWord did for bloggers and writers: it provided a mechanism for people to make money while doing what they love.

The AppStore takes a big weight from the shoulders of software developers by taking care of the distribution and billing system.

If I was in charge of the Windows 8 future (or MacOS for that matter), I would try to reproduce that formula on my mainstream operating system. And it seems from the leaked presentations that this is where Microsoft's head is.

The leaked mockups for the AppStore are creative, but the entire slide deck misses the fundamental point that people are scared of installing software on Windows.

Everyone is scared of installing applications on Windows either because they break the system or because you might be accidentally installing malware. In either case, the end result is countless wasted hours backing data up, reinstalling the operating sytem and all the applications.

An AppStore wont fix this.

For a Windows appstore to work, they need to guarantee that installing software wont ever break the system.

They need to produce an appliance that allows users to install and remove software in seconds, and yet, guarantee that installing and removing apps will never break the system. This is not a problem that can be solved by hiring an army of curators and people that just sit all day rejecting apps.

To solve the problem, Microsoft needs to both alter their kernel to ensure the safety of the host OS and come up with a new way of distributing applications. They need:

  • A sandboxed execution system.
  • Self contained applications, fully embedded in a single directory that require no installation.
  • A set of supported APIs that will run in the Sandbox execution system.
  • A public contract for extension points.

The Sandboxed Execution System: would prevent applications from touching the registry, installing any drivers, any hooks, any visualizers or any other deep integration features that applications typically use to integrate with the OS.

The sandboxed execution system would prevent applications from looking at the file system, except for locations that have been predetermined for sharing.

The kernel would have to enforce what files they get access to, what devices and what components they get access to. And should be set to a bare minimum.

Self Contained Applications would be required to install software from the network, or from their appstore. These applications would get absolutely no rights to modify anything outside their directory. Any extension points that they could register with the system ("open with") would have to be registered with the public extension point contract.

Public Contract for Extension Points Any extension points like "open with", or handlers for mime-types would be self contained in a manifest in the application directory.

Instead of having every app poking at the system registry and dumping their junk everywhere, applications would list all of their requirements from the operating system on the manifest and the OS would rebuild its internal data from all of the application manifests available from a user.

Limited APIs: File access APIs, display access APIs would have to be altered to give applications limited access to the host operating system, and to give them as little access to anything that most applications do not need.

The above obviously does not apply to frameworks like the .NET framework, Java or Adobe's AIR. But beyond frameworks, there are very few cases where an application really should have legitimate access to all of the features in the OS. Video games certainly do not need it, and even applications like Visual Studio would not need it.

Posted on 28 Jun 2010

Moonlight 3.0, Preview 7

by Miguel de Icaza

Chris Toshok has just announced our 7th preview of Moonlight 3.0. You can get it from our preview site.

What is new in this release:

  • Roughly API complete to SL4.0 beta. Next preview will be API compatible with SL 4.0 RTW.
  • Video capture support, but support for pixel formats is sparse. right now the supported formats are YUYV and YV12/YUV420 (planar).
  • SSE2 fast paths for gradient fills in the embedded pixman/cairo, this improves performance significantly as some people seem to have discovered the use of gradients.
  • Fixes for chrome support and to our curl bridge.
  • Several html bridge fixes.
  • element to element binding.
  • Client HTTP stack
  • cascading (BasedOn) styles are now supported
  • new right-click dialog so we can (finally!) managed isostore usage.

Posted on 18 Jun 2010

Infragistics Announces Support for Mono

by Miguel de Icaza

Today Infragistics announced that their NetAdvantage for ASP.NET will support Mono out of the box.

We loved working with Infragistics on this project, and I am very proud of the work that the Mono team did to get these fabulous controls working with Mono.

You can read more about Infragistics and Mono on Infragistics site where you can also try out some of their sample applications running on Linux with Mono.

From the press release:

"In recent years, our customers have indicated that their organizations are moving to mixed IT environments and require UI tools that enable them to deploy applications in either Windows or open source environments," said Dean Guida, CEO of Infragistics. "With Mono compatibility in our ASP.NET toolkit, we enable developers who have a need for open source development to create UIs that are the basis for Killer Applications and deliver the best user experiences possible."

Infragistics ASP.NET toolset excels in top performance, flexibility and usability and enables developers to build rich Web applications for line of business. By providing full compatibility with the Mono runtime, Infragistics extends this functionality to the Mono community.

Coinciding with today's NetAdvantage for .NET 2010 Volume 2 availability, Infragistics highlights the ASP.NET toolkit's Mono compatibility through Sample Showcase hosted on a live Linux Server running Mono:

For us this is a very important milestone as developers building .NET applications need to complement the core framework with packaged components like the ones that Infragistics provides.

It also shows the maturity of the project, as commercial ISVs start supporting more Mono on Linux.

Posted on 16 Jun 2010

We have released MonoDevelop 2.4

by Miguel de Icaza

We have finally released MonoDevelop 2.4. You can read a high-level description of the changes or see screenshots with the details. I would go for the screenshots myself.

We made packages for OpenSUSE, SLES, Windows and MacOS X. For other Linux distributions, you should consult with your favorite package provider or you can build it yourself from sources.

Congratulations to the team. They not only improved the UI and the editing experience, but they support Gtk#, ASP.NET MVC, Silverlight, MonoMac and MonoTouch deployments from the same IDE. We have also added support for WCF references and T4 macro processing.

Next Steps for MonoDevelop

For the next release we have a couple of big goals in mind for MonoDevelop:

  • Git support, using GitSharp.
  • Mono on Android support (debugging, templates, deployment).
  • Templates and support for MVC2.

Support for Foo is missing

As you can see from our list of MonoDevelop Tasks there are plenty of tasks that currently have nobody assigned to. This includes even popular features like F#, IronPython, IronRuby or PHP support.

We have limited resources and a huge wish-list. If you want to help us take on any of those tasks, please join us on IRC at on channel #monodevelop, or join our mailing lists.

Posted on 16 Jun 2010

Road to MonoDevelop 2.4: Navigation

by Miguel de Icaza

Perhaps my favorite feature in MonoDevelop 2.4 is the "Navigate To" functionality that we added. This new feature is hooked to Control-comma on Linux and Windows and to Command-. on Mac.

This feature lets you quickly jump to a file, a class or a method:

I used to navigate between my files by opening then from the solution explorer, and then using Control-tab or the tabs. Needless to say, the old way just felt too clumsy for a fast typist like me.

With Navigate-To, I can just hit the hotkey and then like I would in Emacs, type the filename, type or method and jump directly to the method. This is fabulous.

This will also search substrings, so you can either start typing the name of a method or you can fully qualify the method (for example: "Vector.ToString").

But it gets better, you can use abbreviations, so instead of typing "DialogViewController" you can just type "dvc":

BREAKING UPDATE Michael just told me of a cute extra feature: if your match is for a filename, if you type ":NUMBER" it will jump to the selected file to the specified line number.

The result:

Posted on 14 Jun 2010

Conditional Attribute

by Miguel de Icaza

One cute feature of C# 1.0 was the introduction of the Conditional attribute. When you apply the conditional attribute to a method, calls to this method are only included in the resulting code if the appropriate define is set.

For instance, consider:

	[Conditional ("DEBUG")]
	void Log (string format, params object [] args)
		Console.WriteLine (String.Format (format, args));

Calls to Foo.Log become no-ops unless you pass the -define:DEBUG command line option to the compiler.

What is interesting about this compiler-supported feature is that that the code inside the method Log is checked for errors during compilation as any other regular method. They are first class citizens.

Posted on 12 Jun 2010

My first iPhone app

by Miguel de Icaza

I am proud to introduce my first iPhone App built entirely using standard HTML5 technologies.

I felt that I had to go with HTML 5 as I did not want to write the app once for the iPhone and once for the Android. I am also open sourcing this application in its entirety, to help future generation of mobile HTML 5 developers learn from my experiences and hopefully help them write solid, cross platform mobile applications using HTML 5.

I use this app every time we go to a pub, or when we are having lunch at the Cambridge Brewing Company.

Before you check it out, my lawyer has advised me that I need to add the following disclaimer:


I give you: iCoaster.

Stay tuned for my Cheese Table app, coming soon to the iPad.

What People Are Saying about iCoaster!

From my survey on iCoaster for iPad:

"I am currently resorting to use my four iPhones to create one giant iCoaster; this is ridiculous. Need iCoaster HD!!!!"

"Buying an iPad every time I want to put a drink down is expensive, though it is better than getting those little rings all over my shiny new table."

"Four coasters per iPad would be ideal"

"Please keep up the great work. Not sure what I would do without this app, would at least have a lot of ruined coffee tables."

Sadly, we do have some bugs being reported, and I can assure everyone that I am working around the clock to fix these issues. Ensuring that iCoaster is reliable is my top priority:

"If I put my drink on iCoaster, and then rotate my phone to the landscape orientation, my drink gets spilled onto my lap. Please fix this in the iPad version."

Survey Results as of 14:50 EST


Update: We have confirmation that it works on WebOS and Blackberry as well. HTML5 FTW!

Update 2: Due to popular demand, I am launching an effort to bring iCoaster to the iPad. If you want to participate in the beta for iCoasterHD, please fill in this survey, your feedback will help me prioritize features.

Update 3: iCoaster works on walls too:

Update 4: For those of you complaining about the missing DOCTYPE Geoff Norton has done what any honorable open source contributor would have done: he forked iCoaster and made it HTML "compliant": icoaster-fork.

Update 5: After today's brouhaha over Apple's HTML 5, Mike Shaver from Mozilla talks about the elephant in the room.

Update 6: iCoaster's HTML 5 fork has been forked to support full-screen on WebKit and Opera browsers.

Update 7: We have a Silverlight port! This enables iCoaster to run on the upcoming Windows Compact Edition Media 7 Series Phone Embedded Release Plus Pro Advanced.

Update 8: We got a Unity port of iCoaster, and showing true open source spirit, sethillgard open sourced the code.

Posted on 04 Jun 2010

First Beta of MonoTools 2 for VisualStudio

by Miguel de Icaza

Last week we released our first beta for the upcoming MonoTools2.

There are four main features in MonoTools 2:

  • Soft debugger support.
  • Faster transfer of your program to the deployment system.
  • Support for Visual Studio 2010 in addition to 2008.
  • Polish, polish and more polish.

Getting Started

Download our betas from this page. On Windows, you would install our plugin for either 2008 or 2010 and you need to install Mono 2.6.5 on the target platform (Windows, Linux or MacOS).

On Linux, run `monotools-gui-server' or `monotools-server', this will let Visual Studio connect to your machine. Then proceed from Windows.

On MacOS, double click on the "MonoTools Server" application.

Once you run those, MonoTools will automatically show you the servers on your network that you can deploy to or debug:

ASP.NET debugging with this is a joy!

Soft Debugger

This release is the first one that uses our new soft debugger. With is a more portable engine to debug that will allow our users to debug targets other than Linux/x86 for example OSX and Windows.

This is the engine that we use on MonoTouch and that we are using for Mono on Android.

Our previous debugger, a hard debugger, worked on Linux/x86 systems but was very hard to port to new platforms and to other operating systems. With our new soft debugger we can debug Mono applications running on Windows, helping developers test before moving to Linux.

Faster Transfers

When you are developing large applications or web applications, you want your turn around time from the time that you run hit Run to the site running on Linux to be as short as possible.

Cheap Shot Alert: When dealing with large web sites, we used to behave like J2EE: click run and wait for a month for your app to be loaded into the application server.

This is no longer the case. Deployments that used to take 30 seconds now take 2 seconds.

Support for Visual Studio 2010

Our plugin now supports the Visual Studio 2010 new features for plugin developers.

This means you get a single .vsix package to install, no system installs, no registry messing around, no dedicated installers, none of that.

The full plugin installs in 3 seconds. And you can remove it just as easily.

Then you can just from VS's Mono menu pick "Run In Mono" and pick whether you want to run locally or remotely.

We now also support multiple profiles, so you can debug from Visual Studio your code running on Linux boxes, Mac boxes or your local system.

Polish and more Polish

MonoTools was our first Windows software and we learned a lot about what Windows developers expected.

We polished hundreds of small usability problems that the community reported in our last few iterations. You can also check our release notes for the meaty details.


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

Posted on 03 Jun 2010