We have upgraded our VMWare Mono Image from SLED to OpenSUSE 10.2. In the process we fixed most of the problems that were reported by our Windows users doing their .NET migration from Windows to Linux. Please keep sending us your feedback!

I have also migrated my desktop computer at home to OpenSUSE 10.2 (my laptop remains in SLED-land for now), and here are some personal experiences.

Duncan improved my computing experience ten times by suggesting that I install the Smart package management system for OpenSUSE (Smart home page is here).

Smart is fantastic, and I like it a bit better than apt-get so far (still got apt-get installed, but I have switched to smart for my package management now).

The second piece of advise from Duncan was to configure the Additional Package Repositories. Which is a fantastic universe of packages for OpenSUSE, pretty much anything under the sun is packaged there. I accidentally ran into the "GuitarScaleAssistant" while trying out the smart search features. GuitarScaleAssistant: lovely piece of software.

Jonathan Pryor has also a blog entry on caring and feeding your new OpenSUSE 10.2 installation, which should be very useful to Windows guys migrating to Linux.

The new Content, Restriction, Annulment and Protection (CRAP) subsystem built into Vista is another reason to stay away from it.

Leaving aside the political issues of CRAP, this is what users of Vista will be treated to:

Executive Executive Summary

The Vista Content Protection specification could very well constitute the longest suicide note in history.

...

This document looks purely at the cost of the technical portions of Vista's content protection. [...] However, one important point that must be kept in mind when reading this document is that in order to work, Vista's content protection must be able to violate the laws of physics, something that's unlikely to happen no matter how much the content industry wishes it were possible.

Read the whole piece, its hilarious.

The "remote shutdown" capability for device drivers, if true is a reason enough to not buy Vista in any form or shape.

Microsoft: Shooting itself in the foot. One toe at a time.

Cocotron is a cross-platform, MIT X11-licensed implementation of the Cocoa APIs.

The Foundation works on Windows, Linux and Solaris. The GUI side (AppKit) currently only has a Win32 backend.

The TODO list is here.

It might be useful to hack on Cocoa# and Dumbarton on non-Apple platforms.

The quality of the writing over at Billmon never ceased to amaze me. I wish I had the anything remotely as good in the way of writing, constructing and researching that Billmon had.

The blog started in April 10th of 2003. A time when the anti-war movement had been served a slap in the face, jingoism in the US reached new levels and war peddlers were at the top of their game.

Today Billmon has a retrospective on the blog posts from those days:

By my rough guess, at least two thirds, if not more, of the almost three thousand posts I've written since that day have concerned the Iraq War, directly or indirectly. Over the past three-and-a-half years the war has come to define my thinking just as thoroughly as it has come to define Shrub's presidency -- not to mention the world we now live in.

What I also realized, ploughing through hundreds of forgotten or half-remembered posts, is that much of what I wrote back then proved not only true but also extremely prescient -- especially in the first few months after "mission accomplished," when the corporate media by and large was still drinking the White House Kool-Aid and the conservative movement was proclaiming the deification of Emperor George.

It's not that the story wasn't being told. Then as now, most of what I understood to be true about Iraq came from reading between the lines of the semi-official media (New York Times, Washington Post) from the samzidat journalists at Knight-Ridder, from the foreign press (the Guardian and the Independent in particular) and from the Juan Cole's crucial work translating and analyzing Iraqi and other Arabic-language sources. The downward trends could even be seen in the bare factual bones of wire service reports with obscure datelines like Fallujah and Haditha and Tikrit.

But to piece together the truth in those days you had to scrounge for it, ignore the ignorance and lies pouring out of Donald Rumfeld's mouth and defy the prevailing political tide of arrogant triumphalism. Very few journalists, and even fewer politicians, were willing to do that. Some in Left Blogistan were (Kos, Needlenose and Steve Gilliard, among others, also come readily to mind). As a result we presented a far more accurate picture of the war to our readers than the corporate media -- with a few honorable exceptions -- did to its own. I'm proud enough of that to want to remind the world, and the moronic media blog bashers in particular, of it.

The retrospective is here.

Compiz has a new web site and they now also have forums.

Logo contest is here and you can vote here.

SunUO is a free Ultima Online server based on "RunUO".

SunUO has released a new version of their server that runs on Mono.

Mono adoption in SecondLife was discussed in the Technical Town Hall with Cory Linden:

There are some technical changes we still need to make in particular, we’ll need to compile Mono on the server side which requires a distributed compilation service to be running on the grid (yay, backbone!) but I expect that we will begin testing Mono on the main grid in Q1/Q2 2007.

The process there will be to have places on the grid where you can bring scripts and recompile them into Mono for testing. That will let you report broken scripts to us.

Since Mono tends to execute LSL about 600 times faster, I expect that there will be some interesting borkage around carefully timed scripts. Babbage has talked about the implications of Mono extensively, but it’s important to remember that the sequence will be:

• Start allowing compilation of LSL to Mono/CLI. Test existing scripts like crazy. (Q1/Q2)
• Think about ways to include other languages (Q more than 2)

A small article explaining the dangers that the dollar faces ahead here.

My Friend Taylor Hayward has launched a site that tracks hundreds of widgets that people can use to develop web applications, the ThePeoplesToolbox.

Check it out, and if you like it, digg it.

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.