Portabilidad

Comparación entre 7-Zip para Linux ( Ubuntu , arriba) y Windows XP (abajo).

En el desarrollo de software, la portabilidad es el proceso de adaptar un software para que se ejecute en un contexto diferente. A menudo implica modificar el código fuente para que un programa pueda ejecutarse en una plataforma diferente (es decir, en una CPU o sistema operativo diferente ) o en un entorno diferente (es decir, con una biblioteca o marco de trabajo diferente ). También describe la adaptación de un cambio o característica de una base de código a otra , incluso entre diferentes versiones del mismo software. ^{[ 1 ]}

Un software se clasifica como portable si puede alojarse en un contexto diferente sin modificar su código fuente. Se considera portable si el coste de adaptarlo a un contexto es significativamente menor que el de reescribirlo desde cero. Cuanto menor sea el coste de portabilidad en relación con el de reescribir el código, mayor será su portabilidad. El esfuerzo necesario depende de varios factores, como el grado de diferencia entre el contexto original y el nuevo, la habilidad de los programadores y la portabilidad del código fuente.

El término "port" deriva del latín portāre , que significa "llevar". ^{[ 2 ]} Cuando el código no es compatible con un sistema operativo o arquitectura en particular , el código debe ser "llevado" al nuevo sistema.

Actualmente, la cantidad de procesadores y sistemas operativos significativamente diferentes que se utilizan en los ordenadores de sobremesa es mucho menor que en el pasado. El predominio de la arquitectura x86 implica que la mayoría del software de sobremesa nunca se adapta a un procesador diferente. En ese mismo mercado, la oferta de sistemas operativos se ha reducido prácticamente a tres: Microsoft Windows , macOS y Linux . Sin embargo, en los mercados de sistemas embebidos y móviles , la portabilidad sigue siendo un problema importante, siendo la arquitectura ARM una alternativa ampliamente utilizada.

Los estándares internacionales, como los promulgados por la ISO , facilitan enormemente la portabilidad al especificar detalles del entorno informático de manera que se reducen las diferencias entre distintas plataformas que cumplen con los estándares . Escribir software que se ajuste a los límites especificados por estos estándares representa un esfuerzo práctico, aunque no trivial. Portar un programa de este tipo entre dos plataformas que cumplen con los estándares (como POSIX.1 ) puede ser tan sencillo como cargar el código fuente y recompilarlo en la nueva plataforma, pero los profesionales suelen encontrar que se requieren varias correcciones menores debido a sutiles diferencias entre plataformas. La mayoría de los estándares presentan "zonas grises" donde las diferencias en su interpretación dan lugar a pequeñas variaciones entre plataformas.

También existe un número cada vez mayor de herramientas para facilitar la portabilidad, como la GNU Compiler Collection , que proporciona lenguajes de programación consistentes en diferentes plataformas, y Autotools , que automatiza la detección de pequeñas variaciones en el entorno y adapta el software en consecuencia antes de la compilación.

Los compiladores de algunos lenguajes de programación de alto nivel (por ejemplo, Eiffel , Esterel ) ganan portabilidad al generar código fuente en otro lenguaje intermedio de alto nivel (como C ) para el cual generalmente existen compiladores disponibles para muchas plataformas.

En lugar de traducir directamente a código máquina , los compiladores modernos traducen a un código intermedio independiente de la máquina para mejorar la portabilidad del compilador y minimizar el esfuerzo de diseño. El lenguaje intermedio define una máquina virtual que puede ejecutar todos los programas escritos en dicho lenguaje (una máquina se define por su lenguaje y viceversa). ^{[ 3 ]} Las instrucciones del código intermedio se traducen a secuencias equivalentes de código máquina mediante un generador de código para crear código ejecutable . También es posible omitir la generación de código máquina implementando un intérprete o un compilador JIT para la máquina virtual. ^{[ 4 ]}

El uso de código intermedio mejora la portabilidad del compilador, ya que solo es necesario portar a la máquina de destino el código dependiente de la máquina (el intérprete o el generador de código). El resto del compilador puede importarse como código intermedio y luego ser procesado por el generador de código o intérprete portado, generando así el software del compilador o ejecutando directamente el código intermedio en el intérprete. La parte independiente de la máquina puede desarrollarse y probarse en otra máquina (la máquina anfitriona ). Esto reduce considerablemente el esfuerzo de diseño, ya que la parte independiente de la máquina solo necesita desarrollarse una vez para crear código intermedio portable. ^{[ 5 ]}

Un intérprete es menos complejo y, por lo tanto, más fácil de portar que un generador de código, ya que no puede realizar optimizaciones de código debido a su visión limitada del código del programa (solo ve una instrucción a la vez, y los usuarios necesitan una secuencia para realizar la optimización). Algunos intérpretes son extremadamente fáciles de portar, porque solo hacen suposiciones mínimas sobre el conjunto de instrucciones del hardware subyacente. Como resultado, la máquina virtual es incluso más simple que la CPU de destino. ^{[ 6 ]}

Escribir el código fuente del compilador completamente en el lenguaje de programación que el compilador debe traducir, hace que el siguiente enfoque, más conocido como arranque del compilador , sea factible en la máquina de destino:

1. Adapta el intérprete. Esto debe programarse en lenguaje ensamblador, utilizando un ensamblador ya presente en el sistema de destino.
2. Adapta el código fuente del generador de código a la nueva máquina.
3. Ejecute el código fuente adaptado utilizando el intérprete con el código fuente del generador de código como entrada. Esto generará el código máquina para el generador de código.

La parte más difícil de la codificación de las rutinas de optimización se realiza utilizando el lenguaje de alto nivel en lugar del lenguaje ensamblador del sistema objetivo.

Según los diseñadores del lenguaje BCPL , el código interpretado (en el caso de BCPL) es más compacto que el código máquina, generalmente en una proporción de dos a uno. Sin embargo, el código interpretado se ejecuta aproximadamente diez veces más lento que el código compilado en la misma máquina. ^{[ 7 ]}

Los diseñadores del lenguaje de programación Java intentan aprovechar la compacidad del código interpretado, ya que un programa Java puede necesitar ser transmitido a través de Internet antes de que pueda comenzar su ejecución en la máquina virtual Java (JVM) del destino.

Originalmente creado para Apple II en 1989, Prince of Persia ha sido adaptado a 26 plataformas diferentes. ^{[ 8 ]} En la imagen se muestran (de izquierda a derecha) la versión original para Apple II y las adaptaciones para MS-DOS , Atari ST y Sega CD, respectivamente.

El término "porting" también se utiliza cuando un videojuego diseñado para ejecutarse en una plataforma, ya sea una máquina recreativa , una consola de videojuegos o un ordenador personal , se convierte para ejecutarse en una plataforma diferente, quizás con algunas diferencias menores. ^{[ 9 ]} Desde los inicios de los videojuegos hasta la década de 1990, los "ports", en aquel entonces conocidos a menudo como " conversiones ", no eran verdaderas adaptaciones, sino versiones reelaboradas de los juegos debido a las limitaciones de los diferentes sistemas. Por ejemplo, el juego de 1982, El Hobbit , una aventura de texto con imágenes gráficas, presenta estilos gráficos significativamente diferentes en la gama de ordenadores personales para los que se desarrollaron sus versiones. ^{[ 10 ]} Sin embargo, muchos videojuegos del siglo XXI se desarrollan utilizando software (a menudo en C++ ) que puede generar código para una o más consolas, así como para un PC, sin necesidad de una adaptación propiamente dicha (en su lugar, recurren a la adaptación común de bibliotecas de componentes individuales ). ^{[ 10 ]}

Adaptar juegos arcade a sistemas domésticos con hardware inferior era difícil. La versión adaptada de Pac-Man para Atari 2600 omitió muchas de las características visuales del juego original para compensar la falta de espacio en la ROM , y el hardware tuvo problemas cuando aparecían varios fantasmas en la pantalla, creando un efecto de parpadeo. Algunos estudiosos citan el bajo rendimiento de Pac-Man para Atari 2600 como una de las causas del colapso de la industria de los videojuegos en 1983. ^{[ 11 ]}

Muchos de los primeros ports sufrieron problemas significativos de calidad de juego porque las computadoras eran muy diferentes. ^{[ 12 ]} Richard Garriott declaró en 1984 en la Origins Game Fair que Origin Systems desarrolló videojuegos para Apple II primero y luego los portó a las computadoras Commodore 64 y Atari de 8 bits , porque los sprites y otras características sofisticadas de estas últimas máquinas hicieron que portarlas a Apple fuera "mucho más difícil, quizás incluso imposible". ^{[ 13 ]} Las reseñas se quejaron de ports que sufrían de "conversión de Apple", ^{[ 14 ]} conservando el "sonido pésimo y los gráficos en blanco, negro, verde y morado" de Apple; ^{[ 15 ] [ 16 ]} después de la declaración de Garriott, cuando Dan Bunten preguntó "gente de Atari y Commodore en la audiencia, ¿están contentos con las reescrituras de Apple?" la audiencia gritó "¡No!" Garriott respondió, "[de lo contrario] la versión de Apple nunca se terminará. Desde el punto de vista de un editor, eso no es rentable". ^{[ 13 ]}

Otros trabajaron de manera diferente. Ozark Softscape, por ejemplo, escribió MULE primero para Atari porque prefería desarrollar para las computadoras más avanzadas, eliminando o modificando características según fuera necesario durante la adaptación. Esta política no siempre fue factible; Bunten afirmó que "MULE no se puede hacer para una Apple" ^{[ 12 ]} y que las versiones de The Seven Cities of Gold que no eran para Atari eran inferiores ^{[ 17 ]} . La revista Compute!'s Gazette escribió en 1986 que, al adaptar de Atari a Commodore, el original solía ser superior. La calidad de los juegos de este último mejoró cuando los desarrolladores comenzaron a crear nuevo software para él a finales de 1983 ^{[ 18 ].}

En las adaptaciones de juegos arcade , los términos "arcade perfecto" o "arcade exacto" se usaban a menudo para describir qué tan fielmente la jugabilidad, los gráficos y otros elementos de la versión adaptada coincidían con la versión arcade. Muchas adaptaciones de juegos arcade a principios de la década de 1980 distaban mucho de ser arcade perfectas, ya que las consolas domésticas y las computadoras carecían del hardware sofisticado de los juegos arcade, pero aun así podían aproximarse a la jugabilidad. En particular, Space Invaders para Atari VCS se convirtió en el juego estrella de la consola a pesar de sus diferencias, ^{[ 19 ]} mientras que la posterior adaptación de Pac-Man fue famosa por sus desviaciones de la versión arcade. ^{[ 20 ]} Los juegos arcade exactos se hicieron más comunes a partir de la década de 1990, cuando las consolas domésticas alcanzaron la potencia de los sistemas arcade. En particular, el sistema Neo Geo de SNK , que se presentó como un sistema arcade multijuego, también se ofreció como consola doméstica con las mismas especificaciones. Esto permitió jugar en casa a juegos arcade perfectos. ^{[ 10 ]}

Un "port de consola" es un juego que fue creado originalmente o principalmente para una consola antes de que se creara una versión para PC. El proceso de portar juegos de consola a PC suele verse con más escepticismo que otros tipos de porte. Esta percepción se debe a que algunos ports para PC no aprovechan al máximo el hardware más potente disponible en muchos PC, incluso en el momento del lanzamiento de la consola. Dado que el hardware de las consolas permanece invariable durante toda una generación , mientras que el hardware de los PC continúa evolucionando, los juegos diseñados para las limitaciones de las consolas pueden parecer poco optimizados al lanzarse para PC. Si bien son bastante similares hoy en día, persisten algunas diferencias arquitectónicas, como el uso de memoria unificada y sistemas operativos más pequeños en las consolas. Otras objeciones surgen de las diferencias de interfaz de usuario convencionales a las consolas, como los gamepads , las TFUI acompañadas de un FoV estrecho, los puntos de control fijos , el modo online restringido a servidores oficiales o P2P , el soporte para mods deficiente o inexistente , así como la dependencia generalmente mayor entre los desarrolladores de consolas de la codificación interna y los valores predeterminados en lugar de las API externas y la configurabilidad , todo lo cual puede requerir un rediseño profundo y costoso para evitar una adaptación a PC que dé la sensación de ser "perezosa". ^{[ 21 ]}

Los ports imposibles son ports de videojuegos en hardware significativamente más débil que el de lanzamiento original. ^{[ 22 ]} Ejemplos de ello son los ports de juegos de PlayStation 4 y Xbox One , como Nier: Automata y The Witcher 3: Wild Hunt , para Nintendo Switch . ^{[ 23 ] [ 24 ]}

• Retrocompatibilidad : desarrollo de una actualización para software antiguo basada en una actualización a una versión más reciente. 
• Emulador de consola de videojuegos : programa que reproduce el comportamiento de una consola de videojuegos. 
• Compilador cruzado : compilador de código máquina multiplataforma 
• Software multiplataforma : software informático instalado en múltiples plataformas informáticas. 
• Emulador : sistema que permite a un dispositivo imitar a otro. 
• Enlace de lenguaje : Interfaz que permite que un lenguaje de programación utilice una biblioteca escrita en otro. 
• Lista de atributos de calidad del sistema : requisitos no funcionales para la evaluación del sistema. 
• Poshlib : marco de software utilizado en el desarrollo de software multiplataforma. 
• Transformación de programas : generación automatizada de un programa informático. 
• Portabilidad del software : capacidad de un programa para ejecutarse en diferentes plataformas con pocas modificaciones. 
• Puerto de origen : punto final de comunicaciones en un sistema operativo. 
• Compilador de código fuente : traductor de código fuente informático. 
• Escribe una vez, compila en cualquier lugar : el objetivo de diseño es que el código fuente sea universalmente compilable. 

• Richards, Martin ; Whitby-Strevens, Colin (1984). BCPL, el lenguaje y su compilador . Cambridge University Press . ISBN 0-521-28681-6.
• Tanenbaum, Andrew S. (1984). Organización estructurada de computadoras . Prentice Hall . ISBN 0-13-854605-3.