Paint.NET and SafeHandles

Earlier this year, I ported Paint.NET to Mono. At the time, we used the port to help us identify performance bottlenecks, missing functionality and bugs in our code. It turned out to be a fantastic test case for Windows.Forms.

The port was never released because the port is botched. In general the port went fine, but I made a few mistakes early on which lead to the half-done Paint.NET port.

Broken Port of Paint.NET 1.x on Linux.

Here are some of the lessons I learned:

Removal of Code: Paint.NET 1.x used a proprietary third-party library that we did not have access to, and this third-party library used plenty of P/Invoke calls to achieve some special effects. This library for doing toolbars and special buttons was called DotNetWidgets and it seems to have morphed from a freeware library to some sort of commercial library.

During the initial phase of the port I started removing references to this library one by one and during this removal I either removed the code completely (those pieces that seemed unnecessary) or I replaced it with Windows.Forms 1.x controls that had similar functionality.

Halfway through the port, I realized it would have been better to just implement the API exposed by this third party control than to amputate left and right Paint.NET.

So I implemented a barely functioning wrapper class that exposed the same API but barely worked. This was good, as I did not have to amputate any more code. The downside is that by the time I did this, half the classes that used this library had been amputated, and I did not feel like redoing the work.

So I ended up with half the code base amputated, and half the code base semi-working (semi-working because my wrapper was not completed).

Emulation vs Refactoring: In a handful of places I decided to implement small native wrappers that are distributed with Mono and that provide some of the P/Invoke methods that Paint.NET uses. In particular the Heap* family of calls from Win32.

At the time, it made sense to emulate a handful of calls, and we also came up with a design for routing P/Invoke calls done to USER32 to be forwarded to our managed System.Windows.Forms library. The infrastructure is still in place and we could use it to simplify the porting of applications, but am still debating if this is a good idea or not.

In retrospect, I should just have taken advantage of Paint.NET's architecture. Paint.NET actually had isolated the system-dependant code in their SystemLayer library, I could have provided Unix alternatives in that library instead of trying to emulate its underlying functionality (this was another part where half the code was emulated, and half was worked around).

Based on the various Moma Reports it seems that we might be better served by having a portability library that developers could use with their application.

From the Moma reports that people have submitted, we have noticed that some people are using incorrect P/Invoke signatures. This means that their software is actually broken and is probably fragile. It only happens to work because this month stars are properly aligned, but it could break easily, or could have undesirable effects easily (and this is on Windows!).

Second, there are some APIs that can be used for many different things, like "SendMessage".

So it seems like it would be best to provide a portability library "Winforms.Portability" and make sure that the software is migrated to use it. The nice side effect of this would be that features that are not supported would be explicitly visible on the source code.

In any case, we are still considering the options and what our recommendation will be.

The Release: So I never felt like releasing the Paint.NET changes because they are broken, and people would judge Mono's Windows.Forms implementation not on its strengths and limitations but on the broken nature of this port (for example, a bunch of button actions are not even wired up).

Paint.NET 2.x

I never went back to fix Paint.NET 1.x because the developers of Paint.NET were working towards their 2.x series, and this release would replace DotNetWidgets with the various "Strip" controls in Winforms 2. So it was not a very good time investment to work on the 1.x codebase anymore.

We still use the 1.x codebase as a gigantic test case, but we are not going to be upgrading it.

Instead, we will complete the support for the Winforms 2.x APIs that are in use and do the Paint.NET refactoring again.

The 2.x port of Paint.NET is underway, but we are still missing some classes in Windows.Forms that prevent it from building.

The SystemLayer, SetupFrontEnd, Resources, Help, PdnLib and Data components compile fine. The Effects component and the shell still needs some API calls to be implemented (TableLayout related code).

Once those APIs are completed, the real porting work will begin. That is when I will have to do the refactoring or provide a Unix-specific implementation of the SystemLayer API that Paint.NET uses.

SafeHandles

As part of my mission to modify as little code as possible from the Paint.NET 2.x codebase, I implemented SafeHandles for Mono. The current status of our implementation is tracked here.

Implementing SafeHandle support in Mono was a lot of fun. It was the first time I touched the code in the Mono marshaler and it was interesting to figure out all the relations between SafeHandles, CriticalFinalizerObjects how P/Invoke provided the magic that allowed a type-safe object to be marshaled as an IntPtr and where to hook all the behind-the scene calls that happen inside SafeHandles.

The most important source of information was Chris Brumme's "Finalization" blog entry and Ravi Krishnaswamy's "SafeHandles: the best V2.0 feature of the .NET Framework" blog entry.

The patch to support the user visible features of SafeHandles is now on SVN and I plan on continuing some of the work outlined here. Likely, I will need some help from the runtime guys, as I do not quite understand all the issues involved.

As I was exploring the magic behind SafeHandles, I discovered that some of the features that I considered to be ratholes turned out to not be supported, and instead of trying to come up with a confusing solution, certain uses of SafeHandles are just not supported (changes on a SafeHandles passed in ref structures is not mapped back to the managed world, and instead an exception is thrown).

See the mono/mono/tests/safehandle.2.cs file for some other interesting tidbits.