by Miguel de Icaza

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

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

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

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

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

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

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

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

Going Native

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

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

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

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

Stay tuned!

Posted on 20 Feb 2018

Why I am excited about Unity in 2018

by Miguel de Icaza

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

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

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

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

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

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

C# 7

The Unity team has also provided very valuable guidance to the C# team which have directly influenced features in C# 7 like ref locals and returns - In our own tests using C# for an AR application, we doubled the speed of managed-code AR processing by using these new features.

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

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

Visual Studio

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

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

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

Posted on 20 Feb 2018

Interactive Line Editing in .NET

by Miguel de Icaza

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

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

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

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

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

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

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

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

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

Check the GitHub project page for more information.

Posted on 12 Jan 2018

Default ColorSpaces

by Miguel de Icaza

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

You can see the difference here:

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

You can see the differences in this workbook

Posted on 07 Dec 2017

Mono's TLS 1.2 Update

by Miguel de Icaza

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

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

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

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

Posted on 20 Nov 2017

Creating .NET Bindings for C Libraries with ObjectiveSharpie

by Miguel de Icaza

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

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

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

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

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

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

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

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

Posted on 18 Jan 2017

TLS 1.2 Comes to Mono: Update

by Miguel de Icaza

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

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

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

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

In Detail

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

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

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

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

Linux Distributions

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

Let us discuss the details in the

Posted on 30 Sep 2016

Asset Previewer

by Miguel de Icaza

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

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

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

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

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

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

Posted on 28 Jul 2016

The Evolution of Interactive C#

by Miguel de Icaza

The Early Days

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

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

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

Like Owen, I added a plot command:

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

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

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

The Xamarin Years

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

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

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

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

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

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

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

We recently switched the inspector to use Roslyn:

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


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

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

The Glorious Future

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

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

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

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

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

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

Posted on 17 Feb 2016

Shared Projects or PCL?

by Miguel de Icaza

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

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

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

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

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

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

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

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

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

Posted on 22 Jan 2016

Older entries »