View source for Porting

In software development, '''porting''' is the process of adapting [[Software|software]] to run in a different context. Often it involves modifying [[Source code|source code]] so that a [[Computer program|program]] can run on a different [[Computing platform|platform]] (i.e. on a different [[Central processing unit|CPU]] or [[Operating system|operating system]]) or in a different environment (i.e. with a different [[Library (computing)|library]] or [[Software framework|framework]]). It also describes adapting a change or feature from one [[Codebase|codebase]] to another {{endash}} even between different versions of the same software.<ref>{{cite journal |date=March 1975
|title=A machine and configuration independent Fortran: Portable Fortran
|first1=D.E. |last1=Whitten |first2=P.A.D. |last2=Demaine |journal=[[Engineering:IEEE Transactions on Software Engineering|IEEE Transactions on Software Engineering]] |volume=SE-1 |issue=1 |pages=111–124 |doi=10.1109/TSE.1975.6312825|s2cid=16485156}}</ref>

Software is classified as portable if it can be hosted in a different context with no change to the source code. It might be considered portable if the cost of adapting it to a context is significantly less than the cost of writing it from scratch. The lower the cost of porting relative to the cost to re-write, the more portable it is said to be. The effort depends on several factors including the extent to which the original context differs from the new context, the skill of the programmers, and the portability of the codebase.

== Etymology ==
The term "port" is derived from the Latin ''portāre'', meaning "to carry".<ref>{{Cite web|url=http://www.oed.com/view/Entry/148098|title=port, v.2|website=Oxford English Dictionary (OED Online)|publisher=[[Organization:Oxford University Press|Oxford University Press]]|access-date=December 21, 2017|url-access=subscription|quote=Origin: Of multiple origins. Partly a borrowing from French. Partly a borrowing from Latin. Etymons: French ''porter''; Latin ''portāre''. ...  1. ''trans.'' To carry, bear, or convey; to bring.}}</ref> When code is not compatible with a particular [[Operating system|operating system]] or [[Computer architecture|architecture]], the code must be "carried" to the new system.

== History ==
The number of significantly different CPUs and operating systems used on the desktop today is much smaller than in the past. The dominance of the [[X86|x86]] [[Instruction set architecture|architecture]] means that most desktop software is never ported to a different CPU. In that same market, the choice of operating systems has effectively been reduced to three: [[Software:Microsoft Windows|Microsoft Windows]], [[Software:MacOS|macOS]], and [[Software:Linux|Linux]]. In the [[Embedded system|embedded system]]s and [[Mobile computing|mobile]] markets, however, [[Software portability|portability]] remains a significant issue, with the [[ARM architecture family|ARM]] being a widely used alternative.

International standards, such as those promulgated by the [[Organization:International Organization for Standardization|ISO]], greatly facilitate porting by specifying details of the computing environment in a way that helps reduce differences between different standards-conforming [[Computing platform|platforms]]. Writing software that stays within the bounds specified by these standards represents a practical although nontrivial effort. Porting such a program between two standards-compliant platforms (such as [[POSIX|POSIX.1]]) can be just a matter of loading the source code and [[Compiler|recompiling]] it on the new platform, but practitioners often find that various minor corrections are required, due to subtle platform differences. Most standards suffer from "gray areas" where differences in interpretation of standards lead to small variations from platform to platform.

There also exists an ever-increasing number of tools to facilitate porting, such as the [[Software:GNU Compiler Collection|GNU Compiler Collection]], which provides consistent programming languages on different platforms, and [[Software:GNU Autotools|Autotools]], which automates the detection of minor variations in the environment and adapts the software accordingly before compilation.

The compilers for some [[High-level programming language|high-level programming language]]s (e.g. [[Eiffel (programming language)|Eiffel]], [[Esterel]]) gain portability by outputting source code in another high level [[Intermediate representation|intermediate language]] (such as [[C (programming language)|C]]) for which compilers for many platforms are generally available.

==Porting compilers==
Instead of translating directly into [[Machine code|machine code]], modern [[Compiler|compiler]]s translate to a machine independent [[Software:Bytecode|intermediate code]] in order to enhance portability of the compiler and minimize design efforts. The intermediate language defines a ''[[Virtual machine|virtual machine]]'' that can execute all programs written in the [[Intermediate representation|intermediate language]] (a machine is defined by its language and vice versa).<ref name="Machinelanguage">{{harvnb|Tanenbaum|1984|p=3|loc=§&nbsp;1.1 Languages, Levels, and Virtual Machines}} describes the terms and their relations.</ref> The intermediate code instructions are translated into equivalent machine code sequences by a ''code generator'' to create [[Executable|executable code]]. It is also possible to skip the generation of machine code by actually implementing an [[Interpreter (computing)|interpreter]] or [[Just-in-time compilation|JIT]] for the virtual machine.<ref>{{harvnb|Tanenbaum|1984|p=2. Ch. 1 Introduction}} explains translation and interpretation.</ref>

The use of intermediate code enhances portability of the compiler, because only the machine dependent code (the interpreter or the code generator) of the compiler itself needs to be ported to the target machine. The remainder of the compiler can be imported as intermediate code and then further processed by the ported code generator or interpreter, thus producing the compiler software or directly executing the intermediate code on the interpreter. The machine independent part can be developed and [[Software testing|tested]] on another machine (the ''host machine''). This greatly reduces design efforts, because the machine independent part needs to be developed only once to create portable intermediate code.<ref>{{harvnb|Richards|Whitby-Strevens|1984|p=124|loc=§&nbsp;7.1 Introduction}} explains compiler portability using intermediate code.</ref>

An interpreter is less complex and therefore easier to port than a code generator, because it is not able to do code optimizations due to its limited view of the program code (it only sees one instruction at a time, and users need a sequence to do optimization). Some interpreters are extremely easy to port, because they only make minimal assumptions about the instruction set of the underlying hardware. As a result, the virtual machine is even simpler than the target CPU.<ref>{{harvnb|Richards|Whitby-Strevens|1984|p=133|loc=§&nbsp;7.4 The bootstrapping process and INTCODE}} explains the role of the INTCODE interpreter.</ref>

Writing the compiler sources entirely in the programming language the compiler is supposed to translate, makes the following approach, better known as ''[[Bootstrapping (compilers)|compiler bootstrapping]]'', feasible on the target machine: 
# Port the interpreter. This needs to be coded in assembly code, using an already present [[Assembly language|assembler]] on the target.
# Adapt the source of the code generator to the new machine.
# Execute the adapted source using the interpreter with the code generator source as input. This will generate the machine code for the code generator.

The difficult part of coding the optimization routines is done using the high-level language instead of the assembly language of the target.

According to the designers of the [[BCPL]] language, interpreted code (in the BCPL case) is more compact than machine code, typically by a factor of two to one. Interpreted code however runs about ten times slower than compiled code on the same machine.<ref>{{harvnb|Richards|Whitby-Strevens|1984|p=136|loc=§&nbsp;7.4.3 Example}} gives an example translation of a BCPL program into INTCODE for the interpreter.</ref>

The designers of the [[Java (programming language)|Java programming language]] try to take advantage of the compactness of interpreted code, because a Java program may need to be transmitted over the Internet before execution can start on the target's [[Java virtual machine]] (JVM).

== {{Anchor|Porting in gaming|conversion}} Porting of video games ==
{{Redirect|Video game port|the hardware connector|Game port}}
Porting is also the term used when a [[Engineering:Video game|video game]] designed to run on one platform, be it an [[Software:Arcade game|arcade]], [[Engineering:Video game console|video game console]], or [[Engineering:Personal computer|personal computer]], is converted to run on a different platform, perhaps with some minor differences.<ref name="Wolf2008">{{cite book|last=Wolf|first=Mark J. P.|title=The Video Game Explosion: A History from PONG to Playstation and Beyond|chapter-url=https://books.google.com/books?id=XiM0ntMybNwC&pg=PA315|year=2008|isbn=978-0-313-33868-7|page=315|chapter=Glossary|publisher=[[Company:Bloomsbury Publishing|Bloomsbury Publishing]]}}</ref> From the beginning of video games through to the 1990s, "ports", at the time often known as "[[Software:Video game conversion|conversions]]", were often not true ports, but rather reworked versions of the games due to the limitations of different systems. For example, the 1982 game ''[[Software:The Hobbit (1982 video game)|The Hobbit]]'', a text adventure augmented with graphic images, has significantly different graphic styles across the range of personal computers that its ports were developed for.<ref name="port vs conversion">{{citation | last1 = Grabarczyk | first1 = Pawel | first2 = Espen | last2 = Aarseth | title = Port or conversion? An ontological framework for classifying game versions {{!}} DiGRA Conference 2019 | date = 2019}}</ref> Many 21st century video games, however, are developed using software (often in [[C++]]) that can output code for one or more consoles as well as for a PC without the need for actual porting (instead relying on the common porting of individual component [[Library (computing)|libraries]]).<ref name="port vs conversion"/>

Porting arcade games to home systems with inferior hardware was difficult. The ported version of ''[[Software:Pac-Man|Pac-Man]]'' for the [[Engineering:Atari 2600|Atari 2600]] omitted many of the visual features of the original game to compensate for the lack of [[Read-only memory|ROM]] space, and the hardware struggled when multiple ghosts appeared on the screen, creating a flickering effect. The poor performance of the [[Software:Pac-Man (Atari 2600 video game)|Atari 2600 ''Pac-Man'']] is cited by some scholars as a cause of the video game crash of 1983.<ref>{{cite journal |last1=Nicoll |first1=Benjamin |title=Bridging the Gap: The Neo Geo, the Media Imaginary, and the Domestication of Arcade Games |journal=Games and Culture |date=2015 |doi=10.1177/1555412015590048|s2cid=147981978}}</ref>

Many early ports suffered significant gameplay quality issues because computers greatly differed.{{r|bunten198412}} Richard Garriott stated in 1984 at Origins Game Fair that [[Company:Origin Systems|Origin Systems]] developed video games for the Apple II first then ported them to [[Engineering:Commodore 64|Commodore 64]] and [[Engineering:Atari 8-bit computers|Atari 8-bit computers]], because the latter machines' [[Sprite (computer graphics)|sprite]]s and other sophisticated features made porting from them to Apple "far more difficult, perhaps even impossible".<ref name="cgw198410">{{cite magazine | title=The CGW Computer Game Conference | magazine=Computer Gaming World | date=October 1984 | access-date=31 October 2013 | url=http://www.cgwmuseum.org/galleries/index.php?year=1984&pub=2&id=18 | pages=30 | type=panel discussion}}</ref> Reviews complained of ports that suffered from "Apple conversionitis",<ref name="info198701c64">{{Cite magazine |last1=Dunnington |first1=Benn |last2=Brown |first2=Mark R. |last3=Malcolm |first3=Tom |date=January–February 1987 |title=64/128 Gallery |url=https://archive.org/stream/info-magazine-13/Info_Issue_13_1987_Jan-Feb#page/n13/mode/2up |magazine=Info |pages=14–21}}</ref> retaining the Apple's "lousy sound and black-white-green-purple graphics";<ref name="aw1984">{{cite book | url=https://archive.org/stream/Atari_Software_1984#page/n21/mode/2up | title=The Addison-Wesley Book of Atari Software | publisher=Addison-Wesley | year=1984 | pages=12,21,44,126 | isbn=0-201-16454-X | editor1=Stanton, Jeffrey | editor2=Wells, Robert P. | editor3=Rochowansky, Sandra | editor4=Mellid, Michael}}</ref><ref name="bernstein198505">{{cite news | url=https://archive.org/stream/1985-05-anticmagazine/Antic_Vol_4-01_1985-05_New_Super_Ataris#page/n81/mode/2up | title=Beyond Castle Wolfenstein | work=Antic | date=May 1985 | access-date=8 January 2015 | author=Bernstein, Harvey | pages=83}}</ref> after Garriott's statement, when Dan Bunten asked "Atari and Commodore people in the audience, are you happy with the Apple rewrites?" the audience shouted "No!" Garriott responded, "[otherwise] the Apple version will never get done. From a publisher's point of view that's not money wise".{{r|cgw198410}}

Others worked differently. Ozark Softscape, for example, wrote ''[[Software:M.U.L.E.|M.U.L.E.]]'' for the Atari first because it preferred to develop for the most advanced computers, removing or altering features as necessary during porting. Such a policy was not always feasible; Bunten stated that "M.U.L.E. can't be done for an Apple",<ref name="bunten198412">{{cite magazine | title=Dispatches / Insights From the Strategy Game Design Front | magazine=Computer Gaming World | url=http://www.cgwmuseum.org/galleries/index.php?year=1984&pub=2&id=19 | date=December 1984 | access-date=31 October 2013 | author=Bunten, Dan | pages=40}}</ref> and that the non-Atari versions of ''[[Software:The Seven Cities of Gold (video game)|The Seven Cities of Gold]]'' were inferior.<ref name="buntengamedesignmemoir">{{Cite web |url=http://www.ozarksoftscape.com/the-game-collection.html |title=The Game Collection |last=Bunten |first=Dan |website=Ozark Softscape |access-date=2017-10-04}}</ref> ''Compute!'s Gazette'' wrote in 1986 that when porting from Atari to Commodore the original was usually superior. The latter's games' quality improved when developers began creating new software for it in late 1983.<ref name="Yakal198606">{{Cite magazine |last=Yakal |first=Kathy |date=June 1986 |title=The Evolution of Commodore Graphics |url=https://archive.org/details/1986-06-computegazette/page/n35 |magazine=Compute!'s Gazette |pages=34–42 |access-date=2019-06-18}}</ref>

In porting [[Software:Arcade game|arcade game]]s, the terms "arcade perfect" or "arcade accurate" were often used to describe how closely the gameplay, graphics, and other assets on the ported version matched the arcade version. Many arcade ports in the early 1980s were far from arcade perfect as home consoles and computers lacked the sophisticated hardware in arcade games, but games could still approximate the gameplay. Notably, ''[[Software:Space Invaders|Space Invaders]]'' on the Atari VCS became the console's [[Killer application|killer app]] despite its differences,<ref>{{cite book |title=The Ultimate History of Video Games |first=Steven |last=Kent |page=190 |publisher=Three Rivers Press |isbn=0-7615-3643-4 |year=2001}}</ref> while the later ''Pac-Man'' port was notorious for its deviations from the arcade version.<ref>{{cite book | title = The Ultimate History of Video Games | last = Kent | first = Steven | year = 2001 | chapter = The Fall | publisher = Three Rivers Press | pages = 237–239 | isbn = 978-0-7615-3643-7}}</ref> Arcade-accurate games became more prevalent starting in the 1990s as home consoles caught up to the power of arcade systems. Notably, the [[Engineering:Neo Geo|Neo Geo]] system from [[Company:SNK|SNK]], which was introduced as a multi-game arcade system, would also be offered as a home console with the same specifications. This allowed arcade perfect games to be played at home.<ref name="port vs conversion"/>

A "console port" is a game that was originally or primarily made for a console before a version is created which can be played on a personal computer. The process of porting games from console to PC is often regarded more cynically than other types of port. This perception stems from the fact that some PC ports do not fully utilize the more powerful hardware available on many PCs, even at the time of a console's launch. Because console hardware remains fixed throughout a generation while PC hardware continues to advance, games designed around console limitations may appear under-optimized when released on PC. While broadly similar today, some architectural differences persist, such as the use of [[Glossary of computer graphics#U|unified memory]] and smaller [[Operating system|OSs]] on consoles. Other objections arise from [[User interface|user interface]] differences conventional to consoles, such as [[Engineering:Gamepad|gamepad]]s, [[Engineering:10-foot user interface|TFUIs]] accompanied by narrow [[Software:Field of view in video games|FoV]], fixed [[Software:Saved game#Checkpoints|checkpoints]], [[Software:Online game|online]] restricted to official [[Game server|servers]] or [[Peer-to-peer|P2P]], poor or no [[Software:Video game modding|modding]] support, as well as the generally greater reliance among console developers on internal [[Hard coding|hard coding]] and [[Default (computer science)|defaults]] instead of external [[API]]s and [[Computer configuration|configurability]], all of which may require expensive deep reaching redesign to avoid a "lazy" feeling port to PC.<ref>{{cite web |url=https://www.pcgamer.com/stop-making-horrible-console-ports-a-guide/ |title=Stop making horrible console ports - a guide |publisher=PC Gamer |year=2013}}</ref>

Impossible ports are ports of video games onto hardware significantly weaker than the target release.<ref>{{Cite web |last=Yarwood |first=Jack |date=2024-12-17 |title=The Making Of: Dragon's Lair's "Impossible" Game Boy Color Port |url=https://www.timeextension.com/features/the-making-of-dragonrs-lairrs-impossible-game-boy-color-port |access-date=2026-01-17 |website=Time Extension |language=en-GB}}</ref> Examples include ports of [[Engineering:PlayStation 4|PlayStation 4]] and [[Engineering:Xbox One|Xbox One]] games, such as ''[[Software:Nier: Automata]]'' and ''[[Software:The Witcher 3: Wild Hunt]]'', to the [[Engineering:Nintendo Switch|Nintendo Switch]].<ref>{{Cite web |last=Minor |first=Jordan |date=2020-06-29 |title=The Beauty of the Impossible Nintendo Switch Port |url=https://www.pcmag.com/opinions/the-beauty-of-the-impossible-nintendo-switch-port?test_uuid=04IpBmWGZleS0I0J3epvMrC&test_variant=A |access-date=2026-01-17 |website=PCMag |language=en}}</ref><ref>{{Cite web |last=Cryer |first=Hirun |date=2022-10-06 |title=Nier Automata's Switch port might actually be the best place to play the 2017 game |url=https://www.gamesradar.com/nier-automatas-switch-port-might-actually-be-the-best-place-to-play-the-2017-game/ |access-date=2026-01-17 |website=GamesRadar+ |language=en}}</ref>

==See also==
* {{Annotated link|Backporting}}
* {{Annotated link|Video game console emulator}}
* {{Annotated link|Cross compiler}}
* {{Annotated link|Cross-platform software}}
* {{Annotated link|Emulator}}
* {{Annotated link|Language binding}}
* {{Annotated link|List of system quality attributes}}
* {{Annotated link|Poshlib}}
* {{Annotated link|Program transformation}}
* {{Annotated link|Software portability}}
* {{Annotated link|Port (computer networking)|Source port}}
* {{Annotated link|Source-to-source compiler}}
* {{Annotated link|Write once, compile anywhere}}

==References==
{{Reflist}}
* {{cite book |first1=Martin |last1=Richards |first2=Colin |last2=Whitby-Strevens |title=BCPL, the language and its compiler |year=1984 |publisher=Cambridge University Press |isbn=0-521-28681-6}}
* {{cite book |first=Andrew S. |last=Tanenbaum |title=Structured computer organization |year=1984 |publisher=Prentice Hall |isbn=0-13-854605-3}}

[[Category:Interoperability]]
[[Category:Source code]]

de:Portierung

{{Sourceattribution|Porting}}