Back

@abstractxan In my experience, a port is a series of text operations than turn code of one syntax to that of another— followed by operations to swap out dependencies. Some text transformations can be automatic, but often it’s a manual (but systematic) process. It helps when the original project is somewhat modular, because you can then transform one module at a time.

@abstractxan Verification of the correctness of a port is important for knowing when the job is done, but also (when possible) to identify problems partway through. When I ported Drivey in 2018, I started by hand-converting it to Haxe, an inherently typed language with a strict compiler. The compiler errors acted as an evolving checklist of remaining work to do. Only afterwards did I transpile it from Haxe to the more accessible but less strict Javascript.

@abstractxan Often, you also need to make a “shim”— a layer of code that gives the ported code familiar functionality similar to an original dependency. For instance, Verreciel was originally built in Apple’s SceneKit, and used the SCNTransaction to smoothly animate rotations and colors. The browser and three.js have animation features, but they’re nothing like SCNTransaction, so I had to shim it.

That was pretty fun actually!

@rezmason Doesn't that mean one needs to understand the ins and outs of all the dependencies?

Though this could be checked with the progress of the porting via the output. Isn't this way too manual?

FOLLOW UP So 'porting' include a lot of studying about the insides of libraries ?

@abstractxan It all comes down to luck, really. Some dependencies have common APIs that map easily to other libraries. Some libraries are available for multiple platforms, and expose identical APIs. A shim should be as small as possible. SCNTransaction is just an oddball API.

In fact, I've entertained the idea of refactoring Verreciel's UI to be declarative, like an SVG type thing, to get away from its dependency on the animation system. But a post-port refactor is complicated.

@abstractxan Once a ported codebase is refactored, the relationship between the port and the original project becomes more distant. If the port is the official remake, then that's fine, but if the original project continues, it can feel like, I dunno, code estrangement. Speciation. Whereas the original aim of a port is to be faithful to the original. I overthink this part often

@abstractxan I was searching for a different old conversation and found this one instead. I offer you an updated answer to your question:

My answer in 2020 holds true *if you have the original source code*. And much of it holds true in general— designing a shim, planning the port as a step by step process broken up by concrete milestones where you can compare what you have with the original program.

But if you don't have the source code, the cost and extent of researching the original program skyrockets. A decompiler like Ghidra or Binary Ninja can sometimes demystify the program with static analysis or even breakpoint debugging, but 20/20 vision doesn't make finding a needle in a haystack elementary. I've benefited tremendously from having a mentor of sorts, and from putting in the time to slowly develop techniques and intuition.

Then there are tools like RenderDoc and apitrace that provide new views into the running process. There are documents in the Internet Archive or scattered across the web that teach the things the program is made of, that have since become obsolete and obscure. There's information that's hard to find, that will still be too much information to consume all at once.

And, of course, there's the untaught skill that is limiting the scope of whatever port you're making.