Un binario fat (o binario multiarquitectura ) es un programa o biblioteca ejecutable de computadora que se ha expandido (o "engordado") con código nativo para múltiples conjuntos de instrucciones que, en consecuencia, se pueden ejecutar en múltiples tipos de procesadores. [1] 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 consiste en 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 adecuada. Las implementaciones alternativas almacenan distintos ejecutables en diferentes forks , cada uno con su propio punto de entrada que es utilizado directamente por el sistema operativo.
El uso de binarios fat 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 los múltiples APK de Android ), seleccionar un binario específico de la arquitectura en el momento de la ejecución (como con los directorios de unión de Plan 9 yLos paquetes gordos de GNUstep ), [2] [3] distribuyendo software en forma de código fuente y compilándolo en el lugar, o el uso de una máquina virtual (como con Java ) y la compilación justo a tiempo .
En 1988, el Domain/OS SR10.1 de Apollo Computer introdujo un nuevo tipo de archivo, "cmpexe" (ejecutable compuesto), que incluía binarios para los ejecutables Motorola 680x0 y Apollo PRISM . [4]
Un esquema fat-binary facilitó la transición de Apple Macintosh , a partir de 1994, de los microprocesadores 68k a los microprocesadores PowerPC . Muchas aplicaciones para la antigua plataforma 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 ejecutaba más lento que el código nativo. Las aplicaciones publicadas como "binarios fat" ocupaban más espacio de almacenamiento, pero se ejecutaban a toda velocidad en ambas plataformas. Esto se logró empaquetando una versión compilada en 68000 y una versión compilada en PowerPC del mismo programa en sus archivos ejecutables. [5] [6] 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 . [7] [8] [9]
Los binarios fat 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 eliminaban la versión innecesaria. [5] [6] En la era de los discos duros pequeños , cuando los discos duros de 80 MB eran un tamaño común, estas utilidades a veces eran útiles, ya que el código del programa generalmente era un gran porcentaje del uso general del disco, y eliminar los miembros innecesarios de un binario fat liberaría una cantidad significativa de espacio en un disco duro.
Los binarios Fat fueron una característica del sistema operativo NeXTSTEP / OPENSTEP de NeXT , a partir de NeXTSTEP 3.1. En NeXTSTEP, se denominaban "Binarios multiarquitectura". Los binarios multiarquitectura se diseñaron originalmente para permitir que el software se compilara para ejecutarse tanto en el hardware basado en Motorola 68k de NeXT como en PC basados en Intel IA-32 que ejecutaban NeXTSTEP, con un solo archivo binario para ambas plataformas. [10] Más tarde se utilizó para permitir que las aplicaciones OPENSTEP se ejecutaran en PC y en las diversas plataformas RISC compatibles con OPENSTEP. Los archivos binarios multiarquitectura 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 multiarquitectura. Cada binario multiarquitectura comienza con una estructura ( ) 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 binario Fat. 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 ( ). 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 está destinado el binario Mach-O (dentro del archivo).struct fat_headerstruct fat_arch
La versión de la colección de compiladores GNU incluida con las herramientas para desarrolladores podía compilar código fuente de forma cruzada para las diferentes arquitecturas en las que NeXTStep podía ejecutarse. Por ejemplo, era posible elegir las arquitecturas de destino con múltiples opciones '-arch' (con la arquitectura como argumento). Esta era una forma conveniente de distribuir un programa para NeXTStep que se ejecutaba en diferentes arquitecturas.
También fue posible crear bibliotecas (por ejemplo, utilizando libtool de NeXTStep ) con diferentes archivos de objetos específicos.
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 multiarquitectura de NeXT continuaron siendo compatibles con el sistema operativo. En Mac OS X, los binarios multiarquitectura se pueden usar 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 usar para admitir múltiples arquitecturas, como PowerPC de 32 bits y 64 bits , o PowerPC y x86 , o x86-64 y ARM64 . [11]
En 2005, Apple anunció otra transición, de procesadores PowerPC a procesadores Intel x86 . Apple promovió la distribución de nuevas aplicaciones que soportan tanto PowerPC como x86 de forma nativa mediante el uso de archivos ejecutables en formato binario multiarquitectura. [12] Apple llama a dichos 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 multiarquitectura.
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 tenía una sobrecarga de rendimiento bastante pronunciada, por lo que se animó a los desarrolladores a ofrecer binarios tanto de PPC como de 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 en gran medida el tamaño del ejecutable; mientras que un binario universal puede ser 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, se pueden usar las aplicaciones de línea de comandos lipo y ditto para eliminar versiones de la imagen binaria multiarquitectura, creando así lo que a veces se denomina un binario delgado .
Además, los ejecutables binarios multiarquitectura pueden contener código para versiones de 32 y 64 bits de PowerPC y x86, lo que permite enviar aplicaciones en un formato que admita procesadores de 32 bits pero que haga uso del mayor espacio de direcciones y rutas de datos más amplias cuando se ejecuten en procesadores de 64 bits.
En las versiones del entorno de desarrollo Xcode de la 2.1 a la 3.2 (que se ejecutaban en Mac OS X 10.4 a Mac OS X 10.6 ), Apple incluyó utilidades que permitían que las aplicaciones se adaptaran tanto a la arquitectura Intel como a la PowerPC; los binarios universales podían llegar a 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 posterior.
En 2020, Apple anunció otra transición , esta vez de procesadores Intel x86 a silicio de Apple (arquitectura ARM64). Para suavizar la transición, Apple agregó soporte para el formato binario Universal 2 ; los archivos binarios Universal 2 son archivos binarios multiarquitectura que contienen código ejecutable x86-64 y ARM64, lo que permite que el binario se ejecute de forma nativa tanto en Intel de 64 bits como en silicio de Apple de 64 bits. Además, Apple presentó la traducción binaria dinámica Rosetta 2 para el conjunto de instrucciones x86 a Arm64 para permitir que los usuarios ejecuten aplicaciones que no tienen variantes binarias universales.
En 2006, Apple cambió de PowerPC a CPU Intel y reemplazó Open Firmware con EFI . Sin embargo, en 2008, algunas de sus Mac usaban EFI de 32 bits y otras de 64 bits. Por este motivo, Apple extendió la especificación EFI con binarios "fat" que contenían binarios EFI de 32 y 64 bits. [13]
Los ejecutables CP/M-80 , MP/M-80 , Concurrent CP/M , CP/M Plus , Personal CP/M-80 , SCP y MSX-DOS para las familias de procesadores Intel 8080 (y Zilog Z80 ) utilizan la misma extensión de archivo .COM que los sistemas operativos compatibles con DOS para los binarios Intel 8086. [nb 1] En ambos casos, los programas se cargan en el desplazamiento +100h y se ejecutan saltando al primer byte del archivo. [14] [15] Como los códigos de operación de las dos familias de procesadores no son compatibles, intentar iniciar un programa bajo el sistema operativo incorrecto conduce a un comportamiento incorrecto e impredecible.
Para evitar esto, se han ideado algunos métodos para construir binarios gruesos 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. [15] Los métodos combinan dos programas completamente funcionales, cada uno creado para su entorno correspondiente, o añaden stubs que hacen que el programa salga correctamente si se inicia en el procesador incorrecto. Para que esto funcione, las primeras instrucciones (a veces también llamadas encabezados de gadget [16] ) en el archivo .COM tienen que ser código válido para los procesadores 8086 y 8080, lo que haría que los procesadores se ramifiquen en diferentes ubicaciones dentro del código. [16] Por ejemplo, las utilidades en el emulador MyZ80 de Simeon Cran comienzan con la secuencia de código de operación EBh, 52h, EBh . [17] [18] Un 8086 ve esto como un salto y lee su siguiente instrucción desde el desplazamiento +154h, mientras que un procesador 8080 o compatible pasa directamente y lee su siguiente instrucción desde +103h. Una secuencia similar utilizada para este propósito es EBh, 03h, C3h . [19] [20] FATBIN de John C. Elliott [21] [22] [23] es una utilidad para combinar un archivo CP/M-80 y un archivo .COM de DOS en un ejecutable. [17] [24] Su derivado del PMsfx original modifica los archivos creados por PMarc de Yoshihiko Mino para que sean autoextraíbles tanto en CP/M-80 como en DOS, comenzando con EBh, 18h, 2Dh, 70h, 6Dh, 73h, 2Dh para incluir también la firma "-pms-" para archivos PMA autoextraíbles , [25] [17] [24] [18] representando así también una forma de código ASCII ejecutable .
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 [15] es iniciar el código 8080 con C3h, 03h, 01h , que los procesadores x86 decodifican como una instrucción "RET", lo que permite salir del programa sin problemas [nb 2], mientras que los procesadores 8080 lo decodificarán como una instrucción "JP 103h" y simplemente saltarán a la siguiente instrucción del programa. De manera similar, el ensamblador CP/M Z80ASM+ de SLR Systems mostraría un mensaje de error cuando se ejecutara erróneamente en DOS. [17]
Algunos archivos .COM de CP/M-80 3.0 pueden tener una o más superposiciones RSX adjuntas a ellos por GENCOM . [26] 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 el byte mágico C9h , que funciona tanto como una firma que identifica este tipo de archivo COM para el cargador de ejecutables de CP/M 3.0 , 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. [nb 2]
C9h nunca es apropiado como el primer byte de un programa para ningún procesador x86 (tiene diferentes significados para diferentes generaciones, [nb 3] pero nunca es un primer byte significativo); el cargador de ejecutables en algunas versiones de DOS rechaza los archivos COM que comienzan con C9h , evitando una operación incorrecta.
También se han ideado secuencias de código superpuestas similares para binarios combinados Z80/ 6502 , [17] 8086/68000 [17] o x86/ MIPS / ARM . [16]
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 los 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 usaba archivos de superposición idénticos en sus puertos para CP/M-86 y MS-DOS , [27] y usaba código corregido dinámicamente para adaptarse a las diferentes convenciones de llamada de estos sistemas operativos en tiempo de ejecución . [27]
El GSX de Digital Research para CP/M-86 y DOS también comparte controladores binarios idénticos de 16 bits. [28]
Los controladores de dispositivos DOS (normalmente con extensión de archivo .SYS ) comienzan con un encabezado de archivo cuyos primeros cuatro bytes son FFFFFFFFh por convención, aunque esto no es un requisito. [29] Esto lo arregla dinámicamente el sistema operativo cuando se carga el controlador (normalmente en el BIOS DOS cuando ejecuta instrucciones DEVICE en CONFIG.SYS ). Dado que DOS no rechaza la carga de archivos con extensión .COM por DEVICE y no prueba FFFFFFFFh, es posible combinar un programa COM y un controlador de dispositivo en el mismo archivo [30] [29] colocando una instrucción de salto al punto de entrada del programa COM incorporado dentro de los primeros cuatro bytes del archivo (normalmente tres bytes son suficientes). [29] Si el programa incorporado y las secciones del controlador de dispositivo comparten una porción común de código o datos, es necesario que el código se ocupe de cargarse en el desplazamiento +0100h como un programa de estilo .COM y en +0000h como un controlador de dispositivo. [30] Para el código compartido cargado en el desplazamiento "incorrecto" pero no diseñado para ser independiente de la posición , esto requiere una reparación de dirección interna [30] similar a lo que de otro modo ya habría llevado a cabo un cargador reubicador , excepto que en este caso debe hacerlo el propio programa cargado; esto es similar a la situación con los controladores auto-reubicadores pero con el programa ya cargado en la ubicación de destino por el cargador del sistema operativo.
En DOS, algunos archivos, por convención, tienen extensiones de archivo que no reflejan su tipo de archivo real. [nb 4] Por ejemplo, COUNTRY.SYS [31] no es un controlador de dispositivo DOS, [nb 5] sino un archivo de base de datos NLS binario para usar con la directiva CONFIG.SYS COUNTRY y el controlador NLSFUNC . [31] De la misma manera, los archivos de sistema PC DOS y DR-DOS IBMBIO.COM e IBMDOS.COM son imágenes binarias especiales cargadas por cargadores de arranque , no programas de estilo COM. [nb 5] Intentar cargar COUNTRY.SYS con una sentencia DEVICE o ejecutar IBMBIO.COM o IBMDOS.COM en el indicador de comandos causará resultados impredecibles. [nb 4] [nb 6]
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 función de seguridad desarrollada por Matthias R. Paul: [32] Si estos archivos se llaman de forma inapropiada, pequeños fragmentos incrustados mostrarán simplemente información sobre la versión del archivo y saldrán sin problemas. [33] [32] [34] [31] Además, el mensaje está diseñado específicamente para seguir ciertos patrones "mágicos" reconocidos por la utilidad externa de identificación de archivos NetWare & DR-DOS VERSION . [31] [32] [nb 7]
Una característica de protección similar fue la instrucción 8080 C7h ("RST 0") al comienzo de los programas "Z3ENV" tipo 3 y tipo 4 de Z-System de Jay Sage y Joe Wright [35] [36] así como los archivos de superposición de lenguaje "Z3TXT", [37] que darían como resultado un arranque en caliente (en lugar de un bloqueo) bajo CP/M-80 si se cargaban de manera inapropiada. [35] [36] [37] [nb 2]
De manera similar, muchos formatos de archivos (binarios) incluyen por convención un byte 1Ah ( 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 (incluido el monitor PDP-6 [38] y RT-11 , VMS , TOPS-10 , [39] CP/M, [40] [41] DOS, [42] y Windows [43] ), evita que se muestre "basura binaria" cuando se imprime un archivo accidentalmente en la consola.
FatELF [44] fue una implementación binaria fat para Linux y otros sistemas operativos similares a Unix . Técnicamente, un binario FatELF era una concatenación de binarios ELF con algunos metadatos que indicaban qué binario usar en qué arquitectura. [45] 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: [44]
Está disponible una imagen de prueba de concepto de Ubuntu 9.04 . [47] A partir de 2021 [actualizar], FatELF no se ha integrado en el núcleo principal de Linux. [ cita requerida ] [48] [49]
Aunque el formato Portable Executable utilizado por Windows no permite asignar código a plataformas, aún es posible crear un programa cargador que ejecute el código en función de la arquitectura. Esto se debe a que las versiones de escritorio de Windows en ARM tienen soporte para la emulación x86 de 32 bits , lo que lo convierte en un objetivo 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. [50]
Al desarrollar Windows 11 ARM64, Microsoft introdujo una nueva forma de extender el formato Portable Executable llamado Arm64X. [51] Un binario Arm64X contiene todo el contenido que estaría en binarios x64/Arm64EC y Arm64 separados, pero fusionados en un archivo más eficiente en el disco. El conjunto de herramientas de Visual C++ se ha actualizado para admitir la producción de dichos binarios. Y cuando la creación de binarios Arm64X es técnicamente difícil, los desarrolladores pueden crear en su lugar DLL de reenvío puro Arm64X. [52]
Los siguientes enfoques son similares a los binarios fat en que se proporcionan múltiples versiones de código de máquina con el mismo propósito en el mismo archivo.
Desde 2007, algunos compiladores especializados para plataformas heterogéneas producen archivos de código para ejecución paralela en múltiples tipos de procesadores, es decir, el compilador CHI ( C para Integración Heterogénea) de la suite de desarrollo Intel EXOCHI (Secuenciador de Exoesqueleto) extiende el concepto de pragma OpenMP para subprocesamiento múltiple para producir binarios gruesos que contienen secciones de código para diferentes arquitecturas de conjuntos de instrucciones (ISA) desde las cuales el cargador en tiempo de ejecución puede iniciar dinámicamente la ejecución paralela en múltiples núcleos de CPU y GPU disponibles en un entorno de sistema heterogéneo. [53] [54]
Introducida en 2006, la plataforma de computación paralela CUDA (Compute Unified Device Architecture) de Nvidia es un software que permite la computación de propósito general en GPU ( GPGPU ). Su compilador NVCC basado en LLVM puede crear binarios fat basados en ELF que contienen el llamado ensamblaje virtual PTX (como texto) que el controlador de tiempo de ejecución de CUDA puede compilar más tarde en un código ejecutable binario SASS (Streaming Assembler) para la GPU de destino realmente presente. Los ejecutables también pueden incluir los llamados binarios CUDA (también conocidos como archivos cubin ) que contienen secciones de código ejecutable dedicadas para una o más arquitecturas de GPU específicas de las que el tiempo de ejecución de CUDA puede elegir en el momento de la carga. [55] [56] [57] [58] [59] [60] Los binarios fat también son compatibles con GPGPU-Sim , un simulador de GPU introducido también en 2007. [61] [62]
Multi2Sim (M2S), un marco de simulación de sistema heterogéneo OpenCL (originalmente solo para CPU MIPS o x86, pero luego se amplió para admitir también CPU ARM y GPU como las familias AMD / ATI Evergreen y Southern Islands , así como Nvidia Fermi y Kepler ) [63] también admite binarios fat basados en ELF. [64] [63]
GNU Compiler Collection (GCC) y LLVM no tienen un formato binario fat, pero sí tienen archivos de objetos fat para la optimización en tiempo de enlace (LTO). Dado que LTO implica retrasar la compilación hasta el momento del enlace, los archivos de objetos deben almacenar la representación intermedia (IR), pero por otro lado, puede ser necesario almacenar también el código de máquina (por razones de velocidad o compatibilidad). Un objeto LTO que contiene tanto IR como código de máquina se conoce como un objeto fat . [65]
Incluso en un programa o biblioteca destinados a la misma arquitectura de conjunto de instrucciones , un programador puede desear hacer uso de algunas extensiones de conjunto de instrucciones más nuevas manteniendo la compatibilidad con una CPU más antigua. Esto se puede lograr con el multiversionado de funciones (FMV): se escriben versiones de la misma función en el programa y un fragmento de código decide cuál usar detectando las capacidades de la CPU (por ejemplo, a través de CPUID ). Intel C++ Compiler , GCC y LLVM tienen la capacidad de generar automáticamente funciones multiversionadas. [66] Esta es una forma de envío dinámico sin ningún efecto semántico.
Muchas bibliotecas matemáticas cuentan con rutinas de ensamblaje escritas a mano que se eligen automáticamente según la capacidad de la CPU. Algunos ejemplos son glibc , Intel MKL y OpenBLAS . Además, el cargador de bibliotecas de glibc admite la carga desde rutas alternativas para funciones específicas de la CPU. [67]
Un enfoque similar, pero granular a nivel de bytes, ideado originalmente por Matthias R. Paul y Axel C. Frinke es dejar que un pequeño cargador autodescartable, relajante y reubicable integrado en el archivo ejecutable junto con cualquier número de fragmentos de código binario alternativos construya condicionalmente una imagen de tiempo de ejecución optimizada en tamaño o velocidad de un programa o controlador necesario para realizar (o no realizar) una función particular en un entorno de destino particular en el momento de la carga a través de una forma de eliminación dinámica de código muerto (DDCE). [68] [69] [70] [71]
COUNTRY.SYSformatos de archivo soportados por las familias de sistemas operativos MS-DOS / PC DOS y DR-DOS contienen datos similares pero están organizados de forma diferente y son incompatibles. Dado que los puntos de entrada a las estructuras de datos están en diferentes desplazamientos en el archivo, es posible crear COUNTRY.SYSbases de datos "gordas", que podrían usarse en ambas familias DOS. [b] Sin embargo, DR-DOS 7.02 y su NLSFUNC 4.00 (y superiores) incluyen un analizador mejorado capaz de leer ambos tipos de formatos (y variantes), incluso al mismo tiempo, de modo que los archivos con encabezado Janus no son necesarios. [c] [d] Los archivos incluidos son, no obstante, "gordos" por incluir un pequeño fragmento ejecutable que simplemente muestra un mensaje incrustado cuando se invoca de forma inapropiada. [d] [b][…] Función de protección DOS […] La idea se basa en las utilidades del emulador MYZ80 de Simeon Cran; el encabezado de protección DOS en ellos va un paso más allá al no cambiar ningún registro
Z80 . La secuencia mágica es EB 52 EB: […] XCHG […] MOV D,D […] XCHG […] pero eso significa que el código DOS termina bastante lejos del inicio del programa. […] Se puede tener más diversión con los archivos
PMArc
autoextraíbles
. Comience uno con […] defb 0EBh, 018h, '-pms-' […] y las utilidades PMA lo tratan como un archivo válido, envía los procesadores
8086
a 011Ah y los procesadores Z80 a 0130h. […]
[…] secuencia de bytes […] EB 03 C3 yy xx […] Si crea un
archivo .COM
con esos 5 bytes como los primeros […] verá 'JMP SHORT 3', seguido de 3 bytes basura. […] Si observa un desensamblado
Z80
[…] que se traduce a 'EX DE,HL; INC BC;' […] El tercer byte es 'JUMP' seguido de la dirección de 16 bits especificada como yy xx […] tendrá un archivo .COM que se ejecuta en
MS-DOS
y […]
CP/M
[…](NB. Aunque el autor habla del Z80, esta secuencia también funciona en el 8080 y procesadores compatibles).
[…] FATBIN 1.00: combina un
archivo .COM de
CP/M
y un archivo .COM
de DOS
para crear uno que funcione en ambas plataformas. […] Se utilizó para crear: […] MSODBALL 2.05: convierte disquetes entre el formato
Amstrad
706k y un formato DOS 706k. […] Ambos programas funcionan en CP/M-80 y DOS. […]
[…] DSKWRITE.Z80 contiene el código fuente de la versión
CP/M
. […] DSKWRITE.ASM contiene el código fuente de la versión
DOS
. […] Para obtener el
archivo .COM
único , debe utilizar FBMAKE: […][7] (NB. Menciona FBMAKE del paquete FATBNSEA.COM).
[…]
Los archivos autoextraíbles
son
archivos .COM
que contienen varios archivos más pequeños. Cuando ejecuta uno, creará sus archivos más pequeños […] Los programas de archivos autoextraíbles se ejecutarán en
DOS
(2 o posterior) o
CP/M
, con efectos idénticos. Para extraerlos en
Unix
, puede usar ZXCC […] FATBNSEA.COM […] FATBIN combina un archivo .COM CP/M-80 y un archivo .COM DOS para producir uno que funcione en ambos sistemas. […] M3C4SEA.COM […] M3CONV versión 4: convierte instantáneas
de Spectrum
en formato .Z80 o .SNA al
formato
Multiface 3 o desde él (Multiface 3 ->
Z80
solo en una PC). […] PMSFX21X.COM […]
PMSFX
es el programa que se utilizó para generar estos archivos autodescomprimidos. Esta versión (2.11) puede generar archivos que se descomprimen automáticamente en CP/M o DOS. Necesitará
PMARC
para utilizar PMSFX. Nuevo: en DOS, admite tamaños de archivo exactos. […] SP2BMSEA.COM […] Convierte un archivo de lienzo de Stop Press en un archivo
.BMP
de Windows […][8]
[…] He escrito una versión de
PMSFX
que produce
archivos .COM
que se pueden descomprimir en
DOS
y
CP/M
(los primeros tres bytes son
código
Z80 legal, código
8086 legal y encabezado
PMA
legal
) […] como un
archivo autoextraíble
. […]
[…] La razón para sospechar tal diferencia es que la versión 3.2x también soportaba
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énticos entre DOS y CP/M-86, con una bandera (claramente mostrada en el manual
de WordStar 3.20
) que cambia entre ellos en tiempo de ejecución […] la interfaz del SO en WordStar es bastante estrecha y bien abstraída […] las superposiciones de WordStar 3.2x son 100% idénticas entre las versiones DOS y CP/M-86. Hay un interruptor de tiempo de ejecución que elige entre llamar a INT 21h (DOS) e INT E0h (CP/M-86). WS.COM no es lo mismo entre DOS y CP/M-86, aunque probablemente tampoco sea muy diferente. […]
[…] FreeKEYB es […] un verdadero controlador .COM y .SYS (modelo pequeño) en uno. Puede sobrescribir de forma segura el primer JMP, eso es parte de lo que quise decir con "encabezado complicado". […] puede reemplazar FFFFh:FFFFh por un salto de 3 bytes y un FFh de base de datos pendiente. Funciona con MS-DOS, PC DOS, DR-DOS y, muy probablemente, también con cualquier otro problema de DOS. […]
[…] Agregue un encabezado de controlador de dispositivo SYS al controlador, de modo que CTMOUSE pueda ser a la vez un
TSR
normal y un controlador de dispositivo, similar a nuestro controlador de teclado avanzado FreeKEYB. […] Esto no es realmente necesario en
DR DOS
porque
INSTALL
= es compatible desde DR DOS 3.41+ y DR DOS conserva el orden de las directivas
[D]CONFIG.SYS
[…] pero mejoraría […] la flexibilidad en los 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 de mouse siempre han sido controladores de dispositivo en los viejos tiempos. Estos controladores de mouse han tenido nombres de controlador de dispositivo específicos según el protocolo que usaron ("
PC$MOUSE
" para
el modo de sistemas de mouse
, por ejemplo), y algún software puede buscar estos controladores para averiguar el tipo correcto de mouse que se debe usar. […] Otra ventaja sería que los controladores de dispositivo generalmente consumen menos memoria (sin
entorno
, sin
PSP
) […] Básicamente, es un encabezado de archivo complicado, un código diferente para analizar la línea de comando, un punto de entrada y una línea de salida diferentes, y algo de magia de segmento para superar la diferencia ORG 0 / ORG 100h.
La carga automática
de un controlador de dispositivo es un poco más complicada, ya que debe dejar el encabezado del controlador donde está y solo reubicar el resto del controlador […]
Para una actualización zukünftiges para Calderas OpenDOS 7.01, he modificado el código de inicio de
IBMBIO.COM
, ya que es incorrecto como programa normal gestado, sin abrir el comando. Si esta función de seguridad está incluida en la versión oficial, se detendrá la función, pero no se abrirá.(NB. NWDOSTIP.TXT es un trabajo exhaustivo sobre Novell DOS 7 y OpenDOS 7.01, que incluye la descripción de muchas características y componentes internos no documentados. Es parte de la
MPDOSTIP.ZIPcolección aún más grande del autor, mantenida hasta 2001 y distribuida en muchos sitios en ese momento. El enlace proporcionado apunta a una versión anterior del NWDOSTIP.TXTarchivo convertida a HTML). [9][…] había un código de operación "RST 0", que, si se ejecutaba, daría como resultado un
arranque en caliente
. Un archivo que contiene un módulo
Z3TXT
nunca debería 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
Z-System
incluyen dichos 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 el de Bridger Mitchell […] JETLDR.COM, que cargan estos módulos desde archivos a la memoria pueden usar la cadena de identificación para validar el archivo, es decir, para asegurarse de que es el tipo de módulo que el usuario ha indicado que es. De esta manera, se pueden detectar errores del usuario y archivos dañados. […] El encabezado, por lo tanto, ahora queda de la siguiente manera: […] rst […] db 'Z3TXT',0 ; ID con terminación nula […] ; 12345678 ; debe tener 8 caracteres, […] db 'PROGNAME' ; rellenar con espacios […] ; 123 ; debe tener 3 caracteres […] db 'ENG' ; nombre del idioma […] dw LENGTH ; longitud del módulo […][15][16]
…] El final de un archivo
ASCII
se indica mediante un carácter
Ctrl-Z
(1AH) o un final de archivo real, devuelto por la operación de lectura de
CP/M
. Sin embargo, los caracteres Ctrl-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 utiliza para finalizar las operaciones de lectura. […](56 páginas)
[…] 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 el 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. Sin embargo, en un archivo que no es ASCII, es tan probable que CONTROL-Z aparezca como cualquier otro carácter. Por lo tanto, no se puede usar como marcador de fin de archivo. CP/M usa un método diferente para marcar el final de un archivo que no es ASCII. CP/M asume que ha llegado al final del archivo cuando ha leído el último registro (unidad básica de espacio de disco) asignado al archivo. La entrada del directorio de disco para cada archivo contiene una lista de los registros de disco asignados a ese archivo. Este método se basa en el tamaño del archivo, en lugar de su contenido, para localizar el final del archivo. […][17][18]
[…] FreeKEYB crea la imagen de ejecución del controlador en el momento de la inicialización según el tipo de máquina en la que se carga, el tipo de teclado, el diseño, el país y la página de códigos utilizados, el tipo de mouse y adaptador(es) de video instalados, los otros controladores cargados en ese sistema, el sistema operativo y el método(s) de carga y reubicación utilizados, las características individuales incluidas y las opciones de configuración especificadas en la línea de comandos. Debido a la gran cantidad de opciones y parámetros de línea de comandos admitidos […] (alrededor de cincuenta parámetros […] con múltiples configuraciones posibles), existe una gran cantidad de combinaciones de características con incontables dependencias […] lo que resulta en […] un número infinito de […] imágenes de destino diferentes. La técnica de Eliminación Dinámica de Código Muerto de FreeKEYB logra resolver […] estas […] dependencias y […] eliminar código muerto y datos […] no se limita a […] incluir o excluir un número algo limitado de módulos o subrutinas completas y arreglar algunas tablas de despacho como en la programación TSR clásica, sino que […] funciona […] a nivel de byte […] capaz de eliminar […] instrucciones individuales en medio de rutinas más grandes […] distribuidas por todo el código para manejar un caso particular o soportar una característica específica […] se utilizan herramientas especiales para analizar el código […] y crear […] tablas de reparación […] automatizadas […] usando definiciones condicionales […] para declarar los diversos casos […] no solo opcionales en tiempo de ensamblaje sino en tiempo de inicialización […] sin la […] sobrecarga de tener al menos alguna cantidad de código muerto restante en la imagen de tiempo de ejecución […] para realizar un seguimiento de todas las dependencias entre […] estos condicionales, construir y reubicar dinámicamente la imagen de tiempo de ejecución, arreglar todas las referencias entre estas pequeñas partes binarias cambiantes y móviles […] aún permitiendo usar el pequeño modelo de estilo .COM/.SYS […] se realiza en tiempo de inicialización […]
[…] una […] característica única […] que llamamos
eliminación dinámica de código muerto
, por lo que puede en el momento de la instalación […] especificar qué componentes del controlador desea y cuáles no. Esto llega a un punto de modularización cargable dinámica y vinculación tardía que no he visto en DOS hasta ahora. Si no le gusta el protector de pantalla, las macros, la calculadora o el soporte del mouse, o <casi cualquier otra cosa>, puede especificarlo en la línea de comandos y FreeKEYB, al tiempo que tiene en cuenta todas las dependencias entre las rutinas, eliminará por completo todos los fragmentos de código que se ocupan de esa característica y no son necesarios para proporcionar la funcionalidad solicitada, antes de que el controlador reubique la imagen en la ubicación de destino y se convierta en residente. […]
[…] Brandneue[s] Feature, der
dynamischen Dead-Code-Elimination
, die die jeweils notwendigen Bestandteile des Treibers erst zum Installationszeitpunkt zusammenbastelt und reloziert, so daß keine ungenutzten Code- oder Datenbereiche mehr residente bleiben (zB wenn jemand ein bestimmtes FreeKEYB- Característica no benötigt). […]