Mono Migration Analyser tool (MoMA): Port Windows Software To Linux

All of this meant that I couldn’t run the program as is under the Mono run-time, the code would need to be changed. But what’s nice about MoMA is that when it finds errors, it will give you a detailed report of what’s wrong in an HTML file, offering up a View Detail Report link that opens a report in your default browser when you click on it.

The report is broken down by assembly in the left column, with columns to the right showing the problems from each of the four categories. Assemblies that have problems can be clicked on for full details, showing exactly the function calls that are an issue. In the case of Paint.NET, I saw a sprinkling of NotImplementedException and MonoTodo problems throughout the assemblies, but nothing major. I could also see that almost all the P/Invokes were within a single assembly. That’s the assembly that would likely have to be overhauled to get the software to run under Mono.

Now, I don’t know the developers of Paint.NET, and so I can’t speak for them. But they do make it very clear in their FAQ that they have no intention of porting the software to Mono. Yet, interestingly, the MoMA tool shows they did an excellent job of isolating the system calls into a single assembly. I suspect that was intentional – not for the purpose of future porting, but rather the result of simply being good developers. (That’s no surprise if you read their blog at http://blog.getpaint.net/. For example, they have an entry on using parameter validation in C# to ensure robust software.)

Of course, the DLL that contains these system calls is itself very large and clearly has a huge amount of code. So porting it would be no small job. But the MoMA does make it clear to me where the porting would need to be done if anybody cares to take on the job.

But Do We Need MoMA?

In a perfect world, you shouldn’t need a tool like MoMA. I know that I have a tendency to raise the ire of some programmers by being a perfectionist, I’ve been accused of being overly idealistic in my goal of teaching programmers how to build perfect software. And, indeed, our industry has come a long way – users are no longer required to type cryptic commands into the command prompt, and software houses have realised that blaming the user every time something goes wrong really isn’t good for business.

But part of creating perfect software means creating robust software. Creating robust software involves many factors, such as isolating your system calls into a single library (at least with the kind of GUI-oriented, user-friendly software we want on Windows and Linux). Creating code like this should come naturally to a good developer. If you unintentionally break the basic rules of sound software design, then you should fix them early on, and not after your software is finished and suddenly a client asks you to port it from Windows to Linux.

In other words, by the time you run MoMA, you should already have done whatever the tool ends up saying you need to do, without any intentions to port your software – just as the Paint.NET developers did.

But I need to qualify that statement. In fact, Mono isn’t a 100 percent port of .NET. There are parts that are missing, and the MoMA results include a column for “Not Implemented” and another for “Missing”. I, for one, am not about to refrain from using aspects of the .NET framework simply because I “might” want to port my software someday. (Case in point: The Mono project has no plans to implement the WPF, or Windows Presentation Foundation, API.)

So much for the perfect world I dream of.

Perhaps, then, the best thing to do is to isolate the calls – again, as in the Paint.NET software – so that if you do eventually need to port, you can. Or, if that’s not possible, then you’ll want to make sure the requirements don’t require porting, and that the client understands that your software will not port.

The bottom line: I would use the MoMA tool only for projects where I’m quite sure I’m going to be porting the software. You know the routine: Use early, use often. After all, who would want to have a completed, solid software package with millions of lines of code, and only then discover that you have a thousand calls into unsupported functions? If you use MoMA, you probably won’t find yourself in that situation.

In a perfect world, anyway.