Media Notes / Software Porting

The term porting is one that is feared by software developers, loved by management, and possibly thrown left and right indiscriminately by consumers. Software porting is when software written for one environment, which can be a particular hardware configuration, OS, API, etc., is written for another environment. The reality sets in when every environment is typically different from one another. It's like trying to make San Francisco Sourdough Bread when you're in another part of the world. There's a reason why it's specific to the city ^note It's due to the Lactobacillus Sanfranciscensis bacteria that was found there, but it can be found elsewhere.

Porting Disaster is a good read. Considering how long the list is, it can be obviously shown that porting is not an easy thing to do!

Scenarios that make porting much harder include:

• Hardware incompatibilities
  • Processor architectures vary wildly from one another, and it's probably a miracle when two are actually "binary compatible" (this is the most compatibility you can get, where the 0s and 1s process exactly the same). For example, porting from the 65816 (Super Nintendo) architecture to the M68000 (Sega Genesis) is no easy task, since the two processors use entirely different, entirely incompatible machine languages.
  • Even if the port is going from one environment to a very similar one, other hardware considerations must be taken to account.
    • For example, Deus Ex: Invisible War was developed more with the Xbox in mind than the PC. The biggest evidence to support this is that the level maps in Invisible War were much smaller than in the prequel game. Much of this design decision could be attributed to the Xbox having 64 MB of RAM while gaming PCs at the time commonly had at least 512 MB. This likely aided the development of the PC version by not needing to do any extra work. i.e., not having to chop level sizes down to fit the Xbox, much like how levels in Deus Ex were chopped up for the PS2 version
  • Custom hardware. Many 8- and 16-bit computers (and nearly all game consoles) were packed with custom chips to handle graphics, sound and other tasks. Applications and games that make use of that hardware can be especially tricky to port.
    • For example, a common complaint when SNES games that were ported over to the Game Boy Advance was usually the music. The audio chip used was only a DAC, software had to do all the mixing whereas the SNES SPC700 had hardware mixing.
• Software incompatibilities
  • Programs between operating systems won't work, even if the hardware is exactly the same. The OS has specific function calls to do things, and between Linux, UNIX, Mac OS X, and Windows, they're all different. While UNIX, Mac OS X and Linux (more or less) follow the POSIX standard, they may have implementation details that don't align with each other. A subset from that there is also the issue of the binary file structure: For example, Mac OS uses the MACH binary file structure while Linux uses the ELF binary file structure.
    • On a similar front, there's the issue of the ABI (application binary interface). An ABI defines how the processor's resources are to be used, since most processors leave it up to the software developer to figure out how to use the resources it has access to, such as the registers. For example, a typical RISC processor may have 32 general purpose registers. If compiler A uses registers 0-4 for one purpose, but compiler B uses registers 8-12 for the same purpose, this can create issues.
  • Using a programming language or framework that has limited or no support for the target platform. For example, the .NET Framework for C# apps doesn't have much support from Microsoft (the creators of said framework) when used outside of Windows. There is an open-source alternative called Mono however. Similarly, while Apple has released a development tool chain to develop Swift written apps to Windows, Apple likely isn't giving it the same amount of attention as it does on their macOS-based platforms. Of course, one easy way to make a program much harder to port is to write it in assembly code.
  • Relying on libraries or APIs that don't have support on the platform. An example is if a developer primarily uses DirectX as the API of choice, it'll be difficult to port their applications over to non-Microsoft systems as DirectX is only supported on Microsoft systems. Conversely, writing a program using Apple's Metal and Core Audio API would make it require a ton of rewrites to port the program to Windows. Luckily, as mentioned below, this issue can also be sidestepped by using a Middleware solution.

To avoid porting disasters as much as possible, software developers use the following techniques to ease the burden of porting their application from one system to another:

• Isolate the parts that need to be specific to the system and expose a generic function that the application can use, something called abstraction. For example, instead of having the application knowing how to manipulate a hard drive when it wants to read or write something, it calls a function that could be as simple as "get X bytes from Y location" and the function itself handles those details. And as long as every software that manipulates hard drives exposes the same function name and inputs and outputs the data in the same format, the application can work with any hard drive. And this makes an Application Programming Interface. The advantage to this is porting should be made easier by only needing to replace just these parts, the rest of the application should work as expected.
• Using frameworks, Game Engine, Middleware, and other software foundations that have support for a wide variety of platforms and systems. This mostly takes care of the first part, allowing developers to focus on the actual application itself, rather than have to constantly worry about the system they're working on.
• Use some sort of "universal" platform. The only one that comes close to this is the World Wide Web, which applications from the user's side can be built with HTML, CSS, and JavaScript. Even games with 3D acceleration can be developed through use of the WebGL API, an implementation of OpenGL ES that's wrapped around JavaScript. And even then, you could effectively cheat by having another system do the processing and presenting the output, such as how Cloud Gaming works.

---