Software Porting
The term porting is one that is feared by software developers, loved by management, and possibly thrown left and right 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.[1]
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 more harder include:
- Hardware incompatibilities
- Processor architectures vary wildly from one another, and it's probably a miracle that two are even "binary compatible" (this is the most compatibility you can get, where the 0s and 1s process exactly the same). For example, porting from the x86 (PC) architecture to the POWER5 (Xbox 360 or Play Station 3) is no easy task. The x86 is a CISC processor, POWER5 is a RISC processor. x86 addresses memory Little Endian style, while POWER5 does it Big Endian style. And ultimately, the processors machine language is different.
- Even if the port is going from one environment to a very similar one, hardware considerations must be taken to account. For example, Deus Ex Invisible War, which was made for the Xbox in mind, was considered paltry on the PC, despite the Xbox running fully compatible x86 PC hardware. While not exactly a port, the developers didn't want to "port" it and thus the levels were assuming a machine with 64MB of memory, when PCs could easily have 512MB of memory.
- Custom hardware. Many 8- and 16-bit computers 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.
- 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, MacOS X, and Windows, they're all different.
- Using a programming language that has limited or no support for the platform. One of the easiest ways to make software not-portable is to write it in assembly language (which is specific to a family of hardware). Even among high-level languages, some are used more on some environments than others: it would be harder to port a C# application to Mac OS, or an Objective-C application to Windows, than it would be to port a C++ application either way.
- This also includes relying on libraries or APIs that don't have support on the platform.
Simplifying ports
Many programmers today try to avoid porting disasters and minimize the time to port by carefully designing their software such that the core parts are the only thing that needs changing. Everything else can just "plug in" and work as expected.
The industry as a whole is invested in making porting as easy as possible for developers. Time spent porting is time not spent on making features, new games, or other things that make money. A major selling point for some game engines are their ability to easily port projects to different operating systems with minimal fuss, and to port to console with the appropriate dev kit. Even game consoles have mostly shied away from strange hardware. The PlayStation 4 and 5, as well as the Xbox One and Series consoles were all based on PC architecture, which made porting comparatively straightforward. Even the Nintendo Switch features guts not too dissimilar from a high end Android device from the mid 2010s.
- ↑ There's a reason why it's specific to the city. Namely the yeast that gives it its distinctive flavor thrives in that specific climate. Therefore trying to get similar results elsewhere is much harder.