More Serious Work

 

Testing the MoMA tool itself didn't yield much information, so I wanted to also test a bigger application. I wrote a quick little form-based application, but that didn't yield much either; it passed with no problems. I needed a bigger application to test.

While writing my own million-line, production-quality software to use as a test in this article certainly sounds exciting, I suspect my boss wouldn't be thrilled about the decade or so it would take to me to do so when I should be writing articles. So I decided to use the tool to analyze some existing programs written in .NET.

One such tool is Paint.NET, which is an excellent Paint tool that has evolved from a .NET version of the old die-hard Paint tool that comes with Windows to a full-featured tool that some say rivals Adobe Photoshop.

I used MoMA to process all the binaries that come with Paint.NET. In this case, the tool didn't pass with flying colors. (That's not a knock against Paint.NET, however; please keep reading.) For starters, the tool included several non-.NET assemblies, which were skipped. But the several other binaries were .NET assemblies; these were scanned.

This time the results were:

--All methods called exist in Mono. So far, so good.

--P/Invokes called: 157

--Methods called that throw NotImplementedException: 7

--Methods called marked with [MonoTodo]: 58

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.