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).
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.
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.
Posted on 16 Dec 2006
Excellent article on the Guardian:
So here's the scoresheet for Afghanistan, Iraq, Iran, Israel, Palestine, Lebanon and Egypt: worse, worse, worse, worse, worse, worse and worse.
Many a time, in these pages and elsewhere, I have warned against reflex Bush-bashing and kneejerk anti-Americanism. The United States is by no means the only culprit. Changing the Middle East for the better is one of the most difficult challenges in world politics. The people of the region bear much responsibility for their own plight. So do we Europeans, for past sins of commission and current sins of omission. But Bush must take the lion's share of the blame. There are few examples in recent history of such a comprehensive failure. Congratulations, Mr President; you have made one hell of a disaster.
Posted on 14 Dec 2006
The same folks that were calling for "Iraqi Liberation" from Saddam are now pitching the need for a strong man. They never made any sense, but they are now venturing into new delusional grounds when they suggest that Augusto Pinochet is a good model to follow.
Of course, this particular columnist has always shown the intellectual prodigy of a clam, the wit and finese of a dumb rock.
His claim: Pinochet's abuses "helped create a civil society". Well, you can not get any dumber than that. All he knows about Chile he probably learned this week.
Posted on 14 Dec 2006
My books on the Israeli/Palestine conflict now amount for a considerable part of my bookshelf real estate.
A few weeks ago, I was having a discussion with a friend of mine around the pros and cons of the "one state" vs "two state" solutions to the conflict.
For those not familiar with the options, they are:
One State Solution: Israel and the West Bank become one country, with the same rights and laws applying to all the inhabitants. No distinction made based on ethnicity or religion.
Two States Solution: Israel continues as it exists today; the West Bank and Gaza become a sovereign state and the inhabitants of the West Bank are governed by its inhabitants. The Israeli military evacuates the occupied territories, and Israeli citizens living in the West Bank become Palestinian citizens or have an option to emigrate back.
My friend had good points against both solutions, the one state solution and the two state solutions. And I agree that both have problems, but the status quo of "one state and a colony" is way worse.
The One State and a Colony is the current configuration: Israel is an independent country and the West Bank is a colony under a military occupation.
This is a good Q&A with Chomsky on the prospects of a solution. This article lead to Noah Cohen's reply: Apologetics for Injustice in Palestine?. He advocates the one-state solution. Chomsky replied in Advocacy and Realism A reply to Noah Cohen.
The problems of the two state solution today are explored by Haim Bresheeth.
Posted on 13 Dec 2006
Just ordered three new books:
Patrick Cockburn's Occupation is a very interesting read on the occuptation of Iraq and what went on. The story is told from the perspective of the Indepedent's journalist point of view. Patrick's book is packed with interesting stories, but Robert Fisk is still a better story teller.
Meanwhile, Mexico is going back to the 70's style repression. With hundreds of "disappeared", tortured and a handful of killed protesters at the hands of the state and federal police and an incompetent new president whose only significant act so far has been to propose education budget cuts (he back-pedaled yesterday on his plan) and raise the salaries of the military.
Democracy Now has a complete report on the situation in Oaxaca.
Brad Will's (a journalist with Indymedia) was covering one of the confrontations between the police and Oaxaca protestors, when government gun men shot him. His reporting and in particular his own video where he is killed is available with subtitles in English on YouTube.
Posted on 13 Dec 2006
One of the advantages of going to the movies in Boston is that the experience is enhanced by comments from expert graduates and undergraduates from the many famous universities in town.
We recently went to see the new James Bond movie, "Casino Royale" at one of Boston's largest movie theaters. We arrived with plenty of time to spare, and we managed to get some great seats: middle, center-front.
There were four or five Harvard students sitting behind us. Properly dressed, well groomed, and with impeccable haircuts. On our left, an MIT student with his date. He reminded me of the comic guy from the Simpsons.
MIT guy provided some valuable data throughout the movie.
When the first bullet was fired and the character dies, he solemnly informed his date "That is unrealistic" and he gave some details to back up his assertion "a bullet fired in that direction and speed would not push the body in that angle, let alone throw a guy from a chair".
This was a premonition of the things to come. He had found a mission, a goal worth standing up for. During the rest of the movie he kept us informed about which parts were realistic and which ones were not. For the next two hours and a half, we were treated to a string of assessments "realistic" and "not realistic".
Every once in a while he would also comment on the technological developments in this new Bond movie, "that technology actually exists.". He complements it with, "they are actually different". I was hoping he would say to his date at some point "That myth has been busted", but I waited in vain.
I probably could have learned more from this MIT fellow about poker and the probabilities in the game, but the movie was distracting me from his fascinating lecture on the math and strategy behind poker.
The Harvard guys were definitely more social, more outgoing. And they also shared with the rest of us their movie evaluations.
Although they mostly focused on the various Bond girls. Unlike the MIT guy that went into longer discussions and technical explorations, they limited their comments to short sentences, they had developed an advanced taste for succinct statements: "Yeah Baby" was a favorite, a few "I want some of that" and sometimes they just used a few guttural sounds.
They also shared with us their jet-setting background as they addressed the local culture "That is totally Venice".
If I had to guess, I would guess they were not English Majors.
What I found interesting is that the well-groomed Harvard folks giggled every time a girl was on screen. If the scene contained some erotic material, love declarations or kissing, the giggling usually turned into chatter. I learned a lot from them. Four out of five would "totally do her" and one of them would "Also quit the job for her", perhaps he was a secret agent wearing a Harvard sweat shirt yearning for a better undercover assignment.
Posted on 06 Dec 2006
This new release from Jonathan Pobst has some important updates:
In the last week since the release of Moma, we have received 524 application submissions, from 299 different IP addresses (196 of them were single submissions, 48 were two submissions, 28 were three and a few folks sent more than that).
Posted on 05 Dec 2006
Groklaw is running a sensationalistic headline today:
Novell "Forking" OpenOffice.org
Well, if there are any Novell supporters left, here's something else to put in your pipe and smoke it. Novell is forking OpenOffice.org.
There will be a Novell edition of OpenOffice.org and it will support Microsoft OpenXML. (The default will be ODF, they claim, but note that the subheading mentions OpenXML instead.) I am guessing this will be the only OpenOffice.org covered by the "patent agreement" with Microsoft. You think?
Facts barely matter when they get in the way of a good smear. The comments over at Groklaw are interesting, in that they explore new levels of ignorance.
Let me explain.
We have been working on OpenOffice.Org for longer than anyone else has. We were some of the earliest contributors to OpenOffice, and we are the largest external contributor to actual code to OpenOffice than anyone else.
We have for years maintained go-ooo.org (as well as its previous incarnations) a site where we encouraged new developers to join the OpenOffice effort, and worked to lower the barrier for contributors by creating tutorials, pre-compiled images and provide tools for contributors to work on it (some of this content is now being migrated to OpenOffice's new Wiki system).
For years we have been shipping a patched version of OpenOffice because the release schedule of OpenOffice did not match our release schedule. In the very same way that Linux distributions have to ship patches against vanilla packages because the release schedule of those packages does not necessarily match the release schedule of a distribution.
The work at go-ooo.org started in the Ximian days, when we were an independent startup, and we did quite a lot of work to make OpenOffice better integrate with the Linux desktop, upgrading its aging pieces and did quite some work on improving its performance.
But technically, Ximian never shipped a vanilla OpenOffice, we always shipped an improved version of it (with bug fixes, with backports or new features). This is nothing new.
Today we ship modified versions of OpenOffice to integrate GStreamer, 64-bit fixes, integrate with the GNOME and KDE file choosers, add SVG importing support, add OpenDMA support, add VBA support, integrate Mono, integrate fontconfig, fix bugs, improve performance and a myriad of others. The above url contains some of the patches that are pending, but like every other open source project, we have published all of those patches as part of the src.rpm files that we shipped, and those patches have eventually ended up in every distribution under the sun.
But the problem of course is not improving OpenOffice, the problem is improving OpenOffice in ways that PJ disapproves of. Improving OpenOffice to support an XML format created by Microsoft is tantamount to treason.
And of course, the code that we write to interop with Office XML is covered by the Microsoft Open Specification Promise (Update: this is a public patent agreement, this has nothing to do with the Microsoft/Novell agreement, and is available to anyone; If you still want to email me, read the previous link, and read it twice before hitting the send button).
I would reply to each individual point from PJ, but she either has not grasped how open source is actually delivered to people or she is using this as a rallying cry to advance her own ideological position on ODF vs OfficeXML.
Debating the technical merits of one of those might be interesting, but they are both standards that are here to stay, so from an adoption and support standpoint they are a no-brainer to me. The ideological argument on the other hand is a discussion as interesting as watching water boil. Am myself surprised at the spasms and epileptic seizures that folks are having over this.
Btw, I believe the translator that people are discussing is built with C# and XSLT and is available here. I wonder some of the posters on the Groklaw thread are going to have a stroke over the fact that the software is hosted at source forge.
Posted on 04 Dec 2006
Mexico is in a turmoil over the questionable elections this year.
Fighting erupted among the representatives over the new appointed president. The new president was sworn-in in a rush, the international guests barely could sit before they had to whisk him out. Link
The upside is that what is typically an incredibly boring TV broadcast that goes for a few hours was reduced to less than five minutes.
I will be talking at the GULEV conference in Cancun next weekend. The GULEV conference has been running for a few years and it has always been incredibly fun. It is usually hosted in the port city of Veracruz.
The last time I attended, my friend Arturo had just broken the screen of his powerbook. He traveled to Veracruz with an external monitor, underwear and a toothbrush.
Posted on 02 Dec 2006
Posted on 01 Dec 2006