Porting is a weird business.
You have to have a very good knowledge of coding, and you have to have a very good feel for debugging other people's code, and sort of sniffing out bugs, since a lot of the time you are trying to track down unknown problems in unknown code!
However, you also have to have patience and the discipline to do a lot of boring grunt work, since that's what porting mostly consists of.
Being a true programmer - and therefore far more interested in building tools than in actually doing the job I'm supposed to be doing - I decided to try to automate as much of the grunt work as I could.
External Libraries
One of the hardest things to work out when you are given a big lump of source code to port is: "what calls does it make to external libraries?".
In other words, what other stuff do I have to fake, recreate or replace, which I don't even have the source code for.
To answer this question for Black & White, I started building some analysis tools in Perl which allowed me to scan a large body of source code and pull information out of it, like how many calls it made to an external API and what those calls were. I was conscious that B&W was a bigger job than TPW, and I wanted some metrics that would allow me to make a better estimate of how long the port would take.
Compile Errors
The next task when porting a project from one architecture to another is simply to try to get the new compiler to compile the code that you've been given (this is before you worry what to do about all the external calls that this code makes to libraries that don't exist on the platform you're porting to!).
If the developer has been disciplined, and/or has needed to compile their code under more than one compiler, then this can be a simple task. Few games developers are disciplined however - and most only use one compiler, usually VisualStudio, which in the past at least has been very permissive about non-standard C++.
What this means is that a lot of the time, when you take a project compiled under VisualStudio and try to compile it under CodeWarrior (for example), you get thousands of syntax errors.
Each one of these errors is usually very easy to fix, and the same sort of errors tend to come up again and again, so I saw an opportunity to automate this process.
The result was a perl script that I wrote called cleaner, which did lots of skanky regular expression matching on source code to try to spot portability problems and fix them. It wasn't foolproof, but it worked quite well and in the end I think it handled about twelve different syntax tweaks that were easy to spot and correct.