Un binario gordo (o binario multiarquitectura ) es un programa o biblioteca ejecutable de computadora que se ha ampliado (o "engordado") con código nativo para múltiples conjuntos de instrucciones que, en consecuencia, pueden ejecutarse en múltiples tipos de procesadores. Esto da como resultado un archivo más grande que un archivo binario normal de una arquitectura, de ahí el nombre.
El método habitual de implementación es incluir una versión del código máquina para cada conjunto de instrucciones, precedido de un único punto de entrada con código compatible con todos los sistemas operativos, que ejecuta un salto a la sección correspondiente. Las implementaciones alternativas almacenan diferentes ejecutables en diferentes bifurcaciones , cada una con su propio punto de entrada que es utilizado directamente por el sistema operativo.
El uso de binarios gordos no es común en el software del sistema operativo ; Existen varias alternativas para resolver el mismo problema, como el uso de un programa de instalación para elegir un binario específico de la arquitectura en el momento de la instalación (como con varios APK de Android ), seleccionar un binario específico de la arquitectura en el tiempo de ejecución (como con Plan 9 y los grandes paquetes de GNUstep ), [1] [2] distribuir software en forma de código fuente y compilarlo en el lugar, o el uso de una máquina virtual (como con Java ) y compilación Just In Time .
Apolo
Los ejecutables compuestos de Apolo
En 1988, Apollo Computer 's dominio / OS SR10.1 introdujo un nuevo tipo de archivo, "cmpexe" (compuesto ejecutable), que los binarios para liado Motorola 680x0 y Apolo PRISM ejecutables. [3]
manzana
Binario gordo de Apple
Un esquema binario grueso suavizó la transición de Apple Macintosh , a partir de 1994, de microprocesadores 68k a microprocesadores PowerPC . Muchas aplicaciones para la plataforma anterior se ejecutaban de forma transparente en la nueva plataforma bajo un esquema de emulación en evolución , pero el código emulado generalmente se ejecuta más lento que el código nativo. Las aplicaciones lanzadas como "binarios gordos" ocuparon más espacio de almacenamiento, pero se ejecutaron a toda velocidad en cualquiera de las plataformas. Esto se logró empaquetando una versión compilada con 68000 y una versión compilada por PowerPC del mismo programa en sus archivos ejecutables. El código 68K más antiguo (CFM-68K o 68K clásico) continuó almacenándose en la bifurcación de recursos , mientras que el código PowerPC más nuevo estaba contenido en la bifurcación de datos , en formato PEF . [4]
Los binarios gordos eran más grandes que los programas que solo admitían PowerPC o 68k, lo que llevó a la creación de una serie de utilidades que eliminarían la versión innecesaria. En la era de los discos duros pequeños , cuando los discos duros de 80 MB eran de un tamaño común, estas utilidades a veces eran útiles, ya que el código del programa era generalmente un gran porcentaje del uso general del disco, y eliminar los miembros innecesarios de un binario pesado liberaría un cantidad significativa de espacio en un disco duro.
Binarios de arquitectura múltiple de NeXT / Apple
Binarios de arquitectura múltiple NeXTSTEP
Binarios de grasa eran una característica de NeXT 's NeXTSTEP sistema operativo / OPENSTEP, empezando por NeXTSTEP 3.1. En NeXTSTEP, se denominaron "binarios de arquitectura múltiple". Los binarios de arquitectura múltiple estaban destinados originalmente a permitir que el software se compilara para ejecutarse tanto en hardware basado en Motorola 68k de NeXT como en PC basadas en Intel IA-32 que ejecutan NeXTSTEP, con un solo archivo binario para ambas plataformas. Más tarde se utilizó para permitir que las aplicaciones OPENSTEP se ejecutaran en PC y las diversas plataformas RISC compatibles con OPENSTEP. Los archivos binarios de arquitectura múltiple están en un formato de archivo especial, en el que un solo archivo almacena uno o más subarchivos Mach-O para cada arquitectura compatible con el binario de arquitectura múltiple. Cada binario de arquitectura múltiple comienza con una estructura (struct fat_header) que contiene dos enteros sin signo. El primer entero ("mágico") se utiliza como un número mágico para identificar este archivo como un Fat Binary. El segundo entero ("nfat_arch") define cuántos archivos Mach-O contiene el archivo (cuántas instancias del mismo programa para diferentes arquitecturas). Después de este encabezado, hay nfat_arch número de estructuras fat_arch (struct fat_arch). Esta estructura define el desplazamiento (desde el inicio del archivo) en el que se encuentra el archivo, la alineación, el tamaño y el tipo y subtipo de CPU al que se dirige el binario Mach-O (dentro del archivo).
La versión de la colección de compiladores GNU incluida con las herramientas de desarrollo fue capaz de realizar una compilación cruzada de código fuente para las diferentes arquitecturas en las que NeXTStep podía ejecutarse. Por ejemplo, fue posible elegir las arquitecturas de destino con múltiples opciones de '-arch' (con la arquitectura como argumento). Esta fue una forma conveniente de distribuir un programa para NeXTStep que se ejecuta en diferentes arquitecturas.
También fue posible crear bibliotecas (por ejemplo, usando libtool) con diferentes archivos de objetos específicos.
Mach-O y Mac OS X
Apple Computer adquirió NeXT en 1996 y continuó trabajando con el código OPENSTEP. Mach-O se convirtió en el formato de archivo de objeto nativo en el sistema operativo gratuito Darwin de Apple (2000) y Mac OS X de Apple (2001), y los binarios de arquitectura múltiple de NeXT continuaron siendo compatibles con el sistema operativo. En Mac OS X, los archivos binarios de arquitectura múltiple se pueden utilizar para admitir múltiples variantes de una arquitectura, por ejemplo, para tener diferentes versiones de código de 32 bits optimizadas para las generaciones de procesadores PowerPC G3 , PowerPC G4 y PowerPC 970 . También se puede utilizar para admitir múltiples arquitecturas, como PowerPC de 32 y 64 bits , o PowerPC y x86 , o x86-64 y ARM64 . [5]
Binario universal de Apple
En 2005, Apple anunció otra transición, de los procesadores PowerPC a los procesadores Intel x86 . Apple promovió la distribución de nuevas aplicaciones compatibles con PowerPC y x86 de forma nativa mediante el uso de archivos ejecutables en formato binario de arquitectura múltiple. Apple llama a estos programas " aplicaciones universales " y llama al formato de archivo " binario universal " como quizás una forma de distinguir esta nueva transición de la transición anterior u otros usos del formato binario de arquitectura múltiple.
El formato binario universal no era necesario para la migración hacia adelante de aplicaciones PowerPC nativas preexistentes; de 2006 a 2011, Apple suministró Rosetta , un traductor binario dinámico de PowerPC (PPC) a x86 , para desempeñar esta función. Sin embargo, Rosetta tuvo una sobrecarga de rendimiento bastante elevada, por lo que se animó a los desarrolladores a ofrecer binarios de PPC e Intel, utilizando binarios universales. El costo obvio del binario universal es que cada archivo ejecutable instalado es más grande, pero en los años transcurridos desde el lanzamiento del PPC, el espacio en el disco duro ha superado con creces el tamaño del ejecutable; mientras que un binario universal puede tener el doble del tamaño de una versión de plataforma única de la misma aplicación, los recursos de espacio libre generalmente eclipsan el tamaño del código, lo que se convierte en un problema menor. De hecho, a menudo una aplicación binaria universal será más pequeña que dos aplicaciones de arquitectura única porque los recursos del programa se pueden compartir en lugar de duplicar. Si no se requieren todas las arquitecturas, la lipo y Las aplicaciones de línea de comandos ditto se pueden usar para eliminar versiones de la imagen binaria de arquitectura múltiple, creando así lo que a veces se llama un binario delgado .
Además, los ejecutables binarios de arquitectura múltiple pueden contener código para las versiones de 32 y 64 bits de PowerPC y x86, lo que permite que las aplicaciones se envíen en una forma que admita procesadores de 32 bits pero que haga uso del espacio de direcciones más grande y rutas de datos más amplias cuando se ejecuta en procesadores de 64 bits.
En las versiones del entorno de desarrollo Xcode de la 2.1 a la 3.2 (que se ejecutan en Mac OS X 10.4 a través de Mac OS X 10.6 ), Apple incluyó utilidades que permitieron que las aplicaciones estuvieran dirigidas tanto a la arquitectura Intel como a la PowerPC; Los binarios universales podrían eventualmente contener hasta cuatro versiones del código ejecutable (PowerPC de 32 bits, x86 de 32 bits, PowerPC de 64 bits y x86 de 64 bits ). Sin embargo, la compatibilidad con PowerPC se eliminó de Xcode 4.0 y, por lo tanto, no está disponible para los desarrolladores que ejecutan Mac OS X 10.7 o superior.
En 2020, Apple anunció otra transición, esta vez de los procesadores Intel x86 al silicio de Apple . Para suavizar la transición, Apple agregó soporte para el formato binario Universal 2 . Esto permite la creación de binarios que se ejecutan de forma nativa tanto en Intel de 64 bits como en silicio de Apple de 64 bits (una variante AArch64 ). Además, Apple introdujo la traducción binaria dinámica Rosetta 2 para x86 al conjunto de instrucciones Arm64 para permitir a los usuarios ejecutar aplicaciones que no tienen variantes binarias universales.
DOS
Binarios combinados de estilo COM para CP / M-80 y DOS
Los ejecutables CP / M-80 , MP / M-80 , Concurrent CP / M , CP / M Plus y Personal CP / M-80 para las familias de procesadores Intel 8080 (y Z80 ) usan la misma extensión de archivo .COM que compatible con DOS sistemas operativos para binarios Intel 8086 . [nb 1] En ambos casos, los programas se cargan con un desplazamiento de + 100h y se ejecutan saltando al primer byte del archivo. Como los códigos de operación de las dos familias de procesadores no son compatibles, intentar iniciar un programa con el sistema operativo incorrecto conduce a un comportamiento incorrecto e impredecible.
Para evitar esto, se han ideado algunos métodos para construir binarios gordos que contienen tanto un programa CP / M-80 como un programa DOS, precedidos por un código inicial que se interpreta correctamente en ambas plataformas. Los métodos combinan dos programas completamente funcionales, cada uno creado para su entorno correspondiente, o agregan códigos auxiliares que hacen que el programa se cierre correctamente si se inicia en el procesador incorrecto. Para que esto funcione, las primeras instrucciones en el archivo .COM deben ser un código válido para los procesadores 8086 y 8080, lo que provocaría que los procesadores se ramifiquen en diferentes ubicaciones dentro del código. Por ejemplo, las utilidades del emulador MyZ80 de Simeon Cran comienzan con la secuencia de código de operación EBh, 52h, EBh . Un 8086 ve esto como un salto y lee su siguiente instrucción desde el offset + 154h mientras que un 8080 o un procesador compatible pasa directamente y lee su siguiente instrucción desde + 103h. Una secuencia similar utilizada para este propósito es EBh, 03h, C3h . [6] [7]
Otro método para evitar que un sistema operativo compatible con DOS ejecute erróneamente programas .COM para máquinas CP / M-80 y MSX-DOS es iniciar el código 8080 con C3h, 03h, 01h , que se decodifica como una instrucción "RET" por los procesadores x86, saliendo así del programa con gracia, mientras que los procesadores 8080 lo decodificarán como instrucción "JP 103h" y simplemente saltará a la siguiente instrucción del programa.
Algunos archivos CP / M-80 3.0 .COM pueden tener una o más superposiciones RSX adjuntas por GENCOM. [8] Si es así, comienzan con un encabezado adicional de 256 bytes (una página ). Para indicar esto, el primer byte del encabezado se establece en C9h , que funciona como una firma que identifica este tipo de archivo COM para el cargador ejecutable CP / M 3.0 , así como una instrucción "RET" para procesadores compatibles con 8080 que conduce a una salida elegante si el archivo se ejecuta en versiones anteriores. de CP / M-80.
C9h nunca es apropiado como primer byte de un programa para cualquier procesador x86 (tiene diferentes significados para diferentes generaciones, [nb 2] pero nunca es un primer byte significativo); el cargador ejecutable en algunas versiones de DOS rechaza los archivos COM que comienzan con C9h , evitando un funcionamiento incorrecto.
Binarios combinados para CP / M-86 y DOS
CP / M-86 y DOS no comparten una extensión de archivo común para los ejecutables. [nb 1] Por lo tanto, normalmente no es posible confundir ejecutables. Sin embargo, las primeras versiones de DOS tenían tanto en común con CP / M en términos de su arquitectura que algunos de los primeros programas de DOS se desarrollaron para compartir binarios que contenían código ejecutable. Un programa conocido por hacer esto fue WordStar 3.2x , que usó archivos de superposición idénticos en sus puertos para CP / M-86 y MS-DOS , [9] y usó código fijo dinámicamente para adaptarse a las diferentes convenciones de llamadas de estos sistemas operativos. sistemas en tiempo de ejecución . [9]
Digital Research 's GSX para CP / M-86 y DOS también comparte controladores de 16 bits binarios idénticos. [10]
Archivos COM y SYS combinados
Los controladores de dispositivo DOS comienzan con un encabezado de archivo cuyos primeros cuatro bytes son FFFFFFFFh por convención, aunque esto no es un requisito. [11] Esto se soluciona dinámicamente por el sistema operativo cuando se carga el controlador (normalmente en el BIOS de DOS cuando ejecuta declaraciones DEVICE en CONFIG.SYS ). Dado que DOS no rechaza archivos con una extensión .COM para ser cargados por DISPOSITIVO y no prueba para FFFFFFFFh, es posible combinar un programa COM y un controlador de dispositivo en el mismo archivo [12] [11] colocando una instrucción de salto al punto de entrada del programa COM integrado dentro de los primeros cuatro bytes del archivo (tres bytes suelen ser suficientes). [11] Si el programa integrado y las secciones del controlador del dispositivo comparten una parte común de código, o datos, es necesario que el código se cargue en offset + 0100h como un programa de estilo .COM y en + 0000h como controlador de dispositivo. [12] Para el código compartido cargado en el desplazamiento "incorrecto", pero no diseñado para ser independiente de la posición , esto requiere una corrección de la dirección interna [12] similar a lo que de otra manera ya habría realizado un cargador de reubicación , excepto por que en este caso lo tiene que hacer el propio programa cargado; esto es similar a la situación con los controladores que se reubican automáticamente pero con el programa ya cargado en la ubicación de destino por el cargador del sistema operativo.
Archivos del sistema protegidos contra fallos
Bajo DOS, algunos archivos, por convención, tienen extensiones de archivo que no reflejan su tipo de archivo real. [nb 3] Por ejemplo, COUNTRY.SYS [13] no es un controlador de dispositivo DOS, [nb 4] sino un archivo de base de datos binario NLS para usar con la directiva CONFIG.SYS COUNTRY y el controlador NLSFUNC . [13] Los archivos de sistema de PC DOS y DR-DOS IBMBIO.COM e IBMDOS.COM son imágenes binarias especiales, no programas de estilo COM. [nb 4] Intentar cargar COUNTRY.SYS con una instrucción DEVICE o ejecutar IBMBIO.COM o IBMDOS.COM en el símbolo del sistema producirá resultados impredecibles. [nb 3] [nb 5]
A veces es posible evitar esto utilizando técnicas similares a las descritas anteriormente. Por ejemplo, DR-DOS 7.02 y versiones posteriores incorporan una característica de seguridad desarrollada por Matthias R. Paul: [14] Si estos archivos se llaman de manera inapropiada, pequeños stubs incrustados solo mostrarán información de la versión del archivo y saldrán sin problemas. [15] [14] [16] [13]
Una característica de protección similar fue la instrucción 8080 C7h ("RST 0") al comienzo de los archivos de superposición de idiomas del sistema Z, lo que daría como resultado un inicio en caliente (en lugar de un bloqueo) en CP / M-80 si se carga de manera inapropiada. [17]
De manera remotamente similar, muchos formatos de archivo (binarios) por convención incluyen un 1Ah byte ( ASCII ^ Z ) cerca del comienzo del archivo. Este carácter de control se interpretará como un marcador "suave" de fin de archivo (EOF) cuando se abre un archivo en modo no binario y, por lo tanto, en muchos sistemas operativos (incluidos RT-11 , VMS , CP / M, [ 18] [19] DOS, [20] y Windows [21] ), evita que se muestre "basura binaria" cuando se escribe accidentalmente un archivo en la consola.
Linux
FatELF: binarios universales para Linux
FatELF [22] es una implementación binaria robusta para Linux y otros sistemas operativos similares a Unix. Técnicamente, un binario FatELF es una concatenación de binarios ELF con algunos metadatos que indican qué binario usar en qué arquitectura. [23] Además de la abstracción de la arquitectura de la CPU ( orden de bytes , tamaño de palabra , conjunto de instrucciones de la CPU , etc.), existe la ventaja de los binarios con soporte para múltiples ABI y versiones del kernel .
FatELF tiene varios casos de uso, según los desarrolladores: [22]
- Las distribuciones ya no necesitan tener descargas separadas para varias plataformas.
- Los árboles / lib , / lib32 y / lib64 separados ya no son necesarios en la estructura de directorios del sistema operativo .
- El sistema elige de forma centralizada los archivos binarios y las bibliotecas correctos en lugar de los scripts de shell .
- Si el ELF ABI cambia algún día, los usuarios heredados aún pueden recibir soporte.
- Distribución de complementos de navegador web que funcionan de inmediato con múltiples plataformas.
- Distribución de un archivo de aplicación que funciona en las variantes de SO Linux y BSD , sin una capa de compatibilidad de plataforma en ellas.
- Se puede arrancar una partición de disco duro en diferentes máquinas con diferentes arquitecturas de CPU, para desarrollo y experimentación. Mismo sistema de archivos raíz, diferente kernel y arquitectura de CPU.
- Las aplicaciones proporcionadas por redes compartidas o memorias USB funcionarán en varios sistemas. Esto también es útil para crear aplicaciones portátiles y también imágenes de computación en la nube para sistemas heterogéneos. [24]
Hay disponible una imagen de prueba de concepto de Ubuntu 9.04 . [25] A 25 de abril de 2020[actualizar], FatELF no se ha integrado en el kernel principal de Linux. [ cita requerida ] [26] [27]
Ventanas
Fatpack
Aunque el formato Portable Executable utilizado por Windows no permite asignar código a plataformas, aún es posible hacer un programa cargador que distribuya basado en arquitectura. Esto se debe a que las versiones de escritorio de Windows en ARM admiten la emulación x86 de 32 bits , lo que la convierte en un destino de código de máquina "universal" útil. Fatpack es un cargador que demuestra el concepto: incluye un programa x86 de 32 bits que intenta ejecutar los ejecutables empaquetados en sus secciones de recursos uno por uno. [28]
Sistemas similares
Los siguientes enfoques son similares a los binarios gordos en que se proporcionan múltiples versiones de código de máquina con el mismo propósito en el mismo archivo.
Objetos gordos
GCC y LLVM no tienen un formato binario amplio, pero tienen archivos de objetos grandes para la optimización del tiempo de enlace (LTO). Dado que LTO implica retrasar la compilación hasta el tiempo de enlace, los archivos objeto deben almacenar la representación intermedia , pero por otro lado, es posible que el código de la máquina también deba almacenarse (por velocidad o compatibilidad). Un objeto LTO que contiene tanto IR como código de máquina se conoce como objeto fat . [29]
Función de múltiples versiones
Incluso en un programa o biblioteca diseñado para la misma arquitectura de conjunto de instrucciones , un programador puede desear hacer uso de algunas extensiones de conjunto de instrucciones más nuevas mientras mantiene la compatibilidad con una CPU más antigua. Esto se puede lograr con la función de múltiples versiones (FMV): las versiones de la misma función se escriben en el programa y un fragmento de código decide cuál usar al detectar las capacidades de la CPU (por ejemplo, a través de CPUID ). Intel C ++ Compiler , GNU Compiler Collection y LLVM tienen la capacidad de generar automáticamente funciones con múltiples versiones. [30] Esta es una forma de envío dinámico sin efectos semánticos.
Muchas bibliotecas matemáticas cuentan con rutinas de ensamblaje escritas a mano que se eligen automáticamente según la capacidad de la CPU. Los ejemplos incluyen glibc , Intel MKL y OpenBLAS . Además, el cargador de bibliotecas en glibc admite la carga desde rutas alternativas para funciones específicas de la CPU. [31]
Ver también
- Software multiplataforma
- Stub de DOS
- Puntero gordo
- Ejecutable lineal (LX)
- Nuevo ejecutable (NE)
- Ejecutable portátil (PE)
- Código independiente de la posición (PIC)
Notas
- ^ a b Esto no es un problema para los ejecutables de estilo CP / M-86 bajo CP / M-86 , CP / M-86 Plus , Personal CP / M-86 , S5-DOS , Concurrent CP / M-86 , Concurrent DOS , DOS 286 concurrentes , FlexOS , DOS 386 concurrentes , DOS Plus , DOS multiusuario , System Manager y REAL / 32 porque usan la extensión de archivo .CMD en lugar de .COM para estos archivos. (La extensión .CMD, sin embargo, entra en conflicto con la extensión de archivo para trabajos por lotes escritos para el procesador de línea de comandos CMD.EXE en las familias de sistemas operativos OS / 2 y Windows NT ).
- ^ En 8088 / 8086 procesadores, el código de operación C9h es un alias indocumentado para CBh ( "RETF"), mientras que decodifica como "Leave" en 80188 / 80186 y los nuevos procesadores.
- ^ a b Este problema podría haberse evitado eligiendo extensiones de archivo no conflictivas , pero, una vez introducidos, estos nombres de archivo en particular se conservaron de las primeras versiones de MS-DOS / PC DOS por razones de compatibilidad con herramientas (de terceros). -conectado para esperar estos nombres de archivo específicos.
- ^ a b Otros archivos de DOS de este tipo son KEYBOARD.SYS , un archivo de base de datos de distribución de teclado binario para el controlador de teclado KEYB en MS-DOS y PC DOS , IO.SYS que contiene el BIOS de DOS en MS-DOS y MSDOS.SYS , un archivo de configuración de texto en Windows 95 / MS-DOS 7.0 y superior, pero originalmente un archivo de sistema binario que contiene el kernel de MS-DOS . Sin embargo, MS-DOS y PC DOS no proporcionan archivos de sistema protegidos contra fallos, y estos nombres de archivo no se utilizan ni se necesitan en DR-DOS 7.02 y versiones posteriores, que de lo contrario proporcionan archivos de sistema protegidos contra fallos.
- ^ Esta es la razón por la que estos archivos tienen el atributo oculto establecido, de modo que no se enumeran de forma predeterminada, lo que reduce el riesgo de ser invocados accidentalmente.
Referencias
- ^ "PackagingDrafts / GNUstep" . Wiki del Proyecto Fedora .
- ^ "gnustep / tools-make: README.Packaging" . GitHub .
- ^ "Notas de la versión del software del sistema de dominio, versión del software 10.1" (PDF) (primera edición de impresión). Chelmsford, Massachusetts, Estados Unidos: Apollo Computer Inc. Diciembre de 1988. p. 2-16. Núm. De pedido 005809-A03. Archivado (PDF) desde el original el 27 de agosto de 2020 . Consultado el 17 de agosto de 2020 . (256 páginas)
- ^ Apple Computer (11 de marzo de 1997). "Creación de programas binarios de grasa" . Dentro de Macintosh: arquitecturas en tiempo de ejecución de Mac OS . Archivado desde el original el 7 de marzo de 2004 . Consultado el 20 de junio de 2011 .
- ^ Apple Computer (8 de marzo de 2006). "Binarios universales y binarios PowerPC de 32 bits / 64 bits" . Referencia de formato de archivo Mac OS X ABI Mach-O . Archivado desde el original el 4 de abril de 2009 . Consultado el 13 de julio de 2006 .
- ^ ChristW (14 de noviembre de 2012) [13 de noviembre de 2012]. Chen, Raymond (ed.). "Microsoft Money se bloquea durante la importación de transacciones de la cuenta o al cambiar un beneficiario de una transacción descargada" . Lo nuevo y viejo . Archivado desde el original el 5 de julio de 2018 . Consultado el 19 de mayo de 2018 .
[…] Secuencia de bytes […] EB 03 C3 yy xx […] Si crea un archivo .COM con esos 5 bytes como primeros […] verá 'JMP SHORT 3', seguido de 3 bytes de basura. […] Si miras un desmontaje Z80 […] que se traduce como 'EX DE, HL; INC BC; ' […] El tercer byte es 'JUMP' seguido de la dirección de 16 bits especificada como yy xx […] tendrás un archivo .COM que se ejecuta en MS-DOS y […] CP / M […]
(NB. Si bien el autor habla sobre el Z80, esta secuencia también funciona en el 8080 y procesadores compatibles). - ^ Brehm, Andrew J. (2016). "CP / M y MS-DOS Fat Binary" . DesertPenguin.org . Archivado desde el original el 19 de mayo de 2018 . Consultado el 19 de mayo de 2018 .(NB. Si bien el artículo habla sobre el Z80 , la secuencia de código también funciona en el 8080 y procesadores compatibles).
- ^ Elliott, John C .; Lopushinsky, Jim (2002) [11 de abril de 1998]. "Cabecera de archivo COM CP / M 3" . Seasip.info . Archivado desde el original el 30 de agosto de 2016 . Consultado el 29 de agosto de 2016 .
- ^ a b Necasek, Michal (30 de enero de 2018) [28 de enero de 2018, 26 de enero de 2018]. "WordStar otra vez" . Museo OS / 2 . Archivado desde el original el 28 de julio de 2019 . Consultado el 28 de julio de 2019 .
[…] La razón para sospechar tal diferencia es que la versión 3.2x también soporta CP / M-86 (las superposiciones son idénticas entre DOS y CP / M-86, solo el ejecutable principal es diferente) […] los archivos .OVR son 100% idéntico entre DOS y CP / M-86, con una bandera (que se muestra claramente en el manual de WordStar 3.20 ) que cambia entre ellos en tiempo de ejecución […] la interfaz del sistema operativo en WordStar es bastante estrecha y está bien abstraída […] las superposiciones son 100% idénticas entre las versiones DOS y CP / M-86. Hay un conmutador de tiempo de ejecución que elige entre llamar a INT 21h (DOS) e INT E0h (CP / M-86). WS.COM no es igual entre DOS y CP / M-86, aunque probablemente tampoco sea muy diferente. […]
- ^ Lineback, Nathan. "Capturas de pantalla de GSX" . Toastytech.com . Archivado desde el original el 15 de enero de 2020 . Consultado el 15 de enero de 2020 .
- ^ a b c Paul, Matthias R. (11 de abril de 2002). "Re: [fd-dev] ANUNCIO: CuteMouse 2.0 alpha 1" . freedos-dev . Archivado desde el original el 21 de febrero de 2020 . Consultado el 21 de febrero de 2020 .
[…] FreeKEYB es […] un verdadero controlador .COM y .SYS (modelo pequeño) en uno. Puede sobrescribir con seguridad el primer JMP, eso es parte de lo que quise decir con "encabezado complicado". […] Puede reemplazar el FFFFh: FFFFh por un salto de 3 bytes y un DB FFh pendiente. Funciona con MS-DOS, PC DOS, DR-DOS y probablemente también con cualquier otro problema de DOS. […]
- ^ a b c Paul, Matthias R. (6 de abril de 2002). "Re: [fd-dev] ANUNCIO: CuteMouse 2.0 alpha 1" . freedos-dev . Archivado desde el original el 7 de febrero de 2020 . Consultado el 7 de febrero de 2020 .
[…] Agregue un encabezado de controlador de dispositivo SYS al controlador, de modo que CTMOUSE pueda ser tanto en uno, un TSR normal como un controlador de dispositivo, similar a nuestro controlador de teclado avanzado FreeKEYB. […] Esto no es realmente necesario bajo DR DOS porque INSTALL = es compatible ya que DR DOS 3.41+ y DR DOS conserva el orden de las directivas [ D] CONFIG.SYS […] pero mejoraría […] la flexibilidad […] en sistemas MS-DOS / PC DOS , que […] siempre ejecutan las directivas DEVICE = antes de cualquier instrucción INSTALL =, independientemente de su orden en el archivo. […] El software puede requerir que el controlador del mouse esté presente como un controlador de dispositivo, ya que los controladores del mouse siempre han sido controladores de dispositivo en los viejos tiempos. Estos controladores de mouse han tenido nombres de controladores de dispositivo específicos según el protocolo que usaron (" PC $ MOUSE " para el modo de sistemas de mouse, por ejemplo), y algunos programas pueden buscar estos controladores para encontrar el tipo correcto de mouse que se utilizará. . […] Otra ventaja sería que los controladores de dispositivos generalmente consumen menos memoria (sin entorno , sin PSP ) […] Es básicamente un encabezado de archivo complicado, un código diferente para analizar la línea de comandos, un punto de entrada y una línea de salida diferentes, y algunos Magia de segmento para superar la diferencia ORG 0 / ORG 100h. Autocargar un controlador de dispositivo es un poco más complicado, ya que debe dejar el encabezado del controlador donde está y solo reubicar el resto del controlador […]
- ^ a b c Paul, Matthias R. (10 de junio de 2001) [1995]. "Formato de archivo DOS COUNTRY.SYS" (archivo COUNTRY.LST) (1.44 ed.). Archivado desde el original el 20 de abril de 2016 . Consultado el 20 de agosto de 2016 .
- ^ a b Paul, Matthias R. (30 de julio de 1997) [1 de mayo de 1994]. "Capítulo II.4. Undokumentierte Eigenschaften externer Kommandos - SYS.COM". NWDOS-TIPs - Tips & Tricks rund um Novell DOS 7, mit Blick auf undokumentierte Details, Bugs und Workarounds . MPDOSTIP . Release 157 (en alemán) (3 ed.). Archivado desde el original el 10 de septiembre de 2017 . Consultado el 6 de agosto de 2014 .
Für ein zukünftiges Update for Calderas OpenDOS 7.01 habe ich den Startcode von IBMBIO.COM so modifiziert, daß er - falls fälschlicherweise as normal Programm gestartet - ohne Absturz zur Kommandozeile zurückkehrt. Wann diese Sicherheitsfunktion in die offizielle Version Einzug halten wird, ist jedoch noch nicht abzusehen.
(NB. NWDOSTIP.TXT es un trabajo completo sobre Novell DOS 7 y OpenDOS 7.01, que incluye la descripción de muchas características y elementos internos no documentados. Es parte de laMPDOSTIP.ZIP
colección aún mayor del autor, mantenida hasta 2001 y distribuida en muchos sitios en ese momento. El enlace proporcionado apunta a una versión anterior delNWDOSTIP.TXT
archivo convertida en HTML ). [1] - ^ Paul, Matthias R. (2 de octubre de 1997). "Caldera OpenDOS 7.01 / 7.02 Actualización Alpha 3 IBMBIO.COM README.TXT" . Archivado desde el original el 4 de octubre de 2003 . Consultado el 29 de marzo de 2009 . [2]
- ^ DR-DOS 7.03 WHATSNEW.TXT - Cambios de DR-DOS 7.02 a DR-DOS 7.03 . Caldera, Inc. 24 de diciembre de 1998. Archivado desde el original el 8 de abril de 2019 . Consultado el 8 de abril de 2019 .
- ^ Sage, Jay (noviembre-diciembre de 1992). Carlson, Art; Kibler, Bill D. (eds.). "Función regular, soporte ZCPR, independencia del idioma, parte 2" . The Computer Journal (TCJ): programación, soporte al usuario, aplicaciones . La esquina del sistema Z. Lincoln, CA, EE. UU. (58): 7–10. ISSN 0748-9331 . arca: / 13960 / t70v9g87h . Consultado el 9 de febrero de 2020 .
[…] Había un código de operación de "RST 0", que, si se ejecuta, daría como resultado un arranque en caliente . Un archivo que contiene un módulo Z3TXT nunca debe ejecutarse, pero a un costo de un byte podríamos protegernos contra esa posibilidad externa. El encabezado también contenía la cadena de caracteres "Z3TXT" seguida de un byte nulo (0). Muchos módulos de Z-System incluyen tales identificadores. En esta categoría se encuentran los paquetes de comandos residentes (RCP), los paquetes de comandos de flujo (FCP) y los módulos descriptores de entorno (Z3ENV). Los programas, como Bridger Mitchell's […] JETLDR.COM, que cargan estos módulos desde archivos en la memoria pueden usar la cadena de ID para validar el archivo, es decir, para asegurarse de que es el tipo de módulo que el usuario ha indicado. ser - estar. De este modo se pueden detectar errores de usuario y archivos dañados. […] El encabezado, por lo tanto, ahora tiene el siguiente aspecto: […] rst […] db 'Z3TXT', 0; ID terminado en nulo […]; 12345678; debe tener 8 caracteres, […] db 'PROGNAME'; almohadilla con espacios […]; 123; debe tener 3 caracteres […] db 'ENG'; nombre del idioma […] dw LONGITUD; longitud del módulo […]
[3] [4] - ^ "2. Convenciones de llamadas al sistema operativo". Guía de interfaz CP / M 2.0 (PDF) (1 ed.). Pacific Grove, California, Estados Unidos: Investigación digital . 1979. p. 5. Archivado (PDF) desde el original el 28 de febrero de 2020 . Consultado el 28 de febrero de 2020 .
[…] El final de un archivo ASCII se indica mediante un carácter de control-Z (1AH) o un final real de archivo, devuelto por la operación de lectura CP / M. Sin embargo, los caracteres Control-Z incrustados en archivos de código de máquina (por ejemplo, archivos COM ) se ignoran y la condición de fin de archivo devuelta por CP / M se usa para terminar las operaciones de lectura. […]
(56 páginas) - ^ Hogan, Thom (1982). "3. Comandos transitorios CP / M". Osborne CP / M User Guide - Para todos los usuarios de CP / M (2 ed.). Berkeley, California, Estados Unidos: A. Osborne / McGraw-Hill . pag. 74. ISBN 0-931988-82-9. Consultado el 28 de febrero de 2020 .
[…] CP / M marca el final de un archivo ASCII colocando un carácter CONTROL-z en el archivo después del último carácter de datos. Si el archivo contiene un múltiplo exacto de 128 caracteres, en cuyo caso agregar CONTROL-Z desperdiciaría 127 caracteres, CP / M no lo hace. El uso del carácter CONTROL-Z como marcador de fin de archivo es posible porque CONTROL-z rara vez se usa como datos en archivos ASCII. En un archivo que no es ASCII, sin embargo, CONTROL-Z es tan probable que ocurra como cualquier otro carácter. Por lo tanto, no se puede utilizar como marcador de fin de archivo. CP / M utiliza un método diferente para marcar el final de un archivo no ASCII. CP / M asume que ha llegado al final del archivo cuando ha leído el último registro (unidad básica de espacio en disco) asignado al archivo. La entrada del directorio del disco para cada archivo contiene una lista de los registros del disco asignados a ese archivo. Este método se basa en el tamaño del archivo, más que en su contenido, para ubicar el final del archivo. […]
[5] [6] - ^ BC_Programmer (31 de enero de 2010) [30 de enero de 2010]. "Re: comando Copiar que fusiona varios archivos etiqueta la palabra SUB al final" . Foro Computer Hope . Archivado desde el original el 26 de febrero de 2020 . Consultado el 26 de febrero de 2020 .
- ^ "¿Cuáles son las diferencias entre los archivos .txt de Linux y Windows (codificación Unicode)" . Superusuario . 2011-08-03 [2011-06-08]. Archivado desde el original el 26 de febrero de 2020 . Consultado el 26 de febrero de 2020 .
- ^ a b Gordon, Ryan C. (octubre de 2009). "FatELF: binarios universales para Linux" . icculus.org . Archivado desde el original el 27 de agosto de 2020 . Consultado el 13 de julio de 2010 .
- ^ Gordon, Ryan C. (noviembre de 2009). "Especificación FatELF, versión 1" . icculus.org . Archivado desde el original el 27 de agosto de 2020 . Consultado el 25 de julio de 2010 .
- ^ Windisch, Eric (3 de noviembre de 2009). "Asunto: Grupos de noticias: gmane.linux.kernel, Re: parches FatELF ..." gmane.org. Archivado desde el original el 15 de noviembre de 2016 . Consultado el 8 de julio de 2010 .
- ^ "Imagen de VM de Ubuntu 9.04 con soporte Fat Binary" .
- ^ Holwerda, Thom (3 de noviembre de 2009). "Ryan Gordon detiene el proyecto FatELF" . osnews.com . Consultado el 5 de julio de 2010 .
- ^ Brockmeier, Joe (23 de junio de 2010). "YO: Anatomía de una (supuesta) falla" . Noticias semanales de Linux . Consultado el 6 de febrero de 2011 .
- ^ Mulder, Sijmen J. (28 de abril de 2020). "sjmulder / fatpack" . GitHub .
- ^ "Descripción general de LTO (componentes internos de la colección de compiladores GNU (GCC))" . gcc.gnu.org .
- ^ Wennborg VI, Hans (2018). "Atributos en Clang" . Documentación de Clang 7 .
- ^ "Uso transparente de paquetes de biblioteca optimizados para arquitectura Intel" . Borre el proyecto Linux * .
enlaces externos
- "Método y aparato para archivos ejecutables independientes de la arquitectura" . Patente de NeXT Software Inc. , 1993.