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
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.
- 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.
- 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.
- 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.
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.
Also, as of 2017, the popular computer systems available have changed since the early days of personal computers and game consoles. The PlayStation 4 and Xbox One use the same basic system architecture as most PCs. This makes porting between them much easier than before. Likewise since the Xbox One also runs much of the same software libraries as a Windows PC, porting between those two should also be a much easier task.