✖


Jump to content

Жирный двоичный файл

Не путать с портативным исполняемым файлом или портативным приложением .

Толстый двоичный файл (или мультиархитектурный двоичный файл ) — это компьютерная исполняемая программа или библиотека , которая была расширена (или «увеличена») кодом, собственным для нескольких наборов команд , которые, следовательно, могут запускаться на процессорах разных типов. [1] В результате файл получается больше, чем обычный двоичный файл с одной архитектурой, отсюда и название.

Обычный метод реализации заключается во включении версии машинного кода для каждого набора команд, которой предшествует одна точка входа с кодом, совместимым со всеми операционными системами, которая выполняет переход к соответствующему разделу. Альтернативные реализации хранят разные исполняемые файлы в разных ветвях , каждый из которых имеет свою собственную точку входа, которая напрямую используется операционной системой.

Использование толстых двоичных файлов не распространено в программном обеспечении операционной системы ; существует несколько альтернатив для решения одной и той же проблемы, например использование программы установки для выбора двоичного файла для конкретной архитектуры во время установки (например, с Android несколькими APK-файлами ), выбор двоичного файла для конкретной архитектуры во время выполнения (например, с Plan 9 объединенные каталоги и толстые пакеты GNUstep ), [2] [3] распространение программного обеспечения в виде исходного кода и его компиляция на месте или использование виртуальной машины (например, с Java ) и компиляция «точно в срок» .

Аполлон

[ редактировать ]

Составные исполняемые файлы Apollo

[ редактировать ]

В 1988 году Apollo Computer SR10.1 компании в домене/ОС был представлен новый тип файла «cmpexe» (составной исполняемый файл), который включал в себя двоичные файлы для Motorola 680x0 и исполняемых файлов Apollo PRISM . [4]

Яблоко

[ редактировать ]

Толстый двоичный файл Apple

[ редактировать ]

Толсто-двоичная схема сгладила Apple Macintosh начавшийся в 1994 году переход от микропроцессоров 68k к микропроцессорам PowerPC . Многие приложения для старой платформы прозрачно работали на новой платформе в соответствии с развивающейся схемой эмуляции , но эмулируемый код обычно работает медленнее, чем собственный код. Приложения, выпущенные в виде «толстых двоичных файлов», занимали больше места для хранения, но работали на полной скорости на любой платформе. Это было достигнуто путем упаковки версии одной и той же программы, скомпилированной 68000 , и версии, скомпилированной PowerPC, в их исполняемые файлы. [5] [6] Более старый код 68K (CFM-68K или классический 68K) продолжал храниться в вилке ресурсов , тогда как более новый код PowerPC содержался в вилке данных , в PEF . формате [7] [8] [9]

Бинарные файлы в формате Fat были больше, чем программы, поддерживающие только PowerPC или 68k, что привело к созданию ряда утилит, удаляющих ненужные версии. [5] [6] В эпоху небольших жестких дисков , когда обычным размером были жесткие диски емкостью 80 МБ, эти утилиты иногда были полезны, поскольку программный код обычно занимал большой процент от общего использования диска, а удаление ненужных членов толстого двоичного файла освобождало бы значительный объем места на жестком диске.

Бинарные файлы NeXT/Apple для мультиархитектуры

[ редактировать ]

Бинарные файлы NeXTSTEP для мультиархитектуры

[ редактировать ]

Двоичные файлы в формате Fat были особенностью NeXT компании операционной системы NeXTSTEP / OPENSTEP , начиная с NeXTSTEP 3.1. В NeXTSTEP они назывались «двоичные файлы с мультиархитектурой». Двоичные файлы с несколькими архитектурами изначально предназначались для того, чтобы обеспечить возможность компиляции программного обеспечения для работы как на оборудовании NeXT на базе Motorola 68k, так и на Intel IA-32, на базе ПК работающих под управлением NeXTSTEP, с одним двоичным файлом для обеих платформ. [10] Позже он использовался для запуска приложений OPENSTEP на ПК и различных RISC- платформах, поддерживаемых OPENSTEP. Бинарные файлы с несколькими архитектурами имеют специальный формат архива, в котором в одном файле хранится один или несколько подфайлов Mach-O для каждой архитектуры, поддерживаемой двоичным файлом с несколькими архитектурами. Каждый двоичный файл мультиархитектуры начинается со структуры ( struct fat_header), содержащий два целых числа без знака. Первое целое число («магическое») используется как магическое число для идентификации этого файла как Fat Binary. Второе целое число ( nfat_arch ) определяет, сколько файлов Mach-O содержит архив (сколько экземпляров одной и той же программы для разных архитектур). После этого заголовка есть nfat_arch количество структур fat_arch ( struct fat_arch). Эта структура определяет смещение (от начала файла), по которому можно найти файл, выравнивание, размер, а также тип и подтип ЦП, на который нацелен двоичный файл Mach-O (внутри архива).

Версия коллекции компиляторов GNU , поставляемая с инструментами разработчика, могла выполнять кросс-компиляцию исходного кода для различных архитектур, на которых NeXTStep мог работать . Например, можно было выбрать целевые архитектуры с помощью нескольких опций «-arch» (с указанием архитектуры в качестве аргумента). Это был удобный способ распространения программы для NeXTStep, работающей на разных архитектурах.

Также можно было создавать библиотеки (например, используя NeXTStep's libtool ) с различными целевыми объектными файлами.

Mach-O и Mac OS X

[ редактировать ]

Apple Computer приобрела NeXT в 1996 году и продолжила работу с кодом OPENSTEP. Mach-O стал собственным форматом объектных файлов в бесплатной операционной системе Apple Darwin (2000 г.) и Apple Mac OS X (2001 г.), а бинарные файлы NeXT с несколькими архитектурами продолжали поддерживаться операционной системой. В Mac OS X двоичные файлы с несколькими архитектурами можно использовать для поддержки нескольких вариантов архитектуры, например, для оптимизации различных версий 32-битного кода для PowerPC G3 , PowerPC G4 и PowerPC 970 процессоров поколений . Его также можно использовать для поддержки нескольких архитектур, таких как 32-битные и 64-битные PowerPC, или PowerPC и x86 , или x86-64 и ARM64 . [11]

Универсальный двоичный файл Apple

[ редактировать ]
Основная статья: Универсальный двоичный файл
Apple Универсальный двоичный логотип

В 2005 году Apple объявила об очередном переходе с процессоров PowerPC на процессоры Intel x86 . Apple способствовала распространению новых приложений, которые изначально поддерживают как PowerPC, так и x86, используя исполняемые файлы в двоичном формате с несколькими архитектурами. [12] Apple называет такие программы « универсальными приложениями » и называет формат файла « универсальным двоичным », возможно, для того, чтобы отличить этот новый переход от предыдущего перехода или других вариантов использования бинарного формата с несколькими архитектурами.

Универсальный двоичный формат не был необходим для прямой миграции ранее существовавших собственных приложений PowerPC; с 2006 по 2011 год Apple поставляла Rosetta PowerPC (PPC) в x86 , динамический двоичный транслятор , который выполнял эту роль. Однако у Rosetta были довольно высокие затраты на производительность, поэтому разработчикам было предложено предлагать двоичные файлы как PPC, так и Intel, используя двоичные файлы Universal. Очевидная цена универсального двоичного файла заключается в том, что каждый установленный исполняемый файл становится больше, но за годы, прошедшие после выпуска PPC, пространство на жестком диске значительно превысило размер исполняемого файла; хотя размер универсального двоичного файла может быть в два раза больше, чем одноплатформенная версия того же приложения, ресурсы свободного пространства обычно затмевают размер кода, что становится незначительной проблемой. Фактически, часто универсально-двоичное приложение будет меньше, чем два приложения с одной архитектурой, поскольку программные ресурсы можно использовать совместно, а не дублировать. Если не все архитектуры необходимы, липо и Приложения командной строки ditto можно использовать для удаления версий из двоичного образа с несколькими архитектурами, создавая тем самым то, что иногда называют тонким двоичным файлом .

Кроме того, исполняемые файлы Multi-Architecture Binary могут содержать код как для 32-битных, так и для 64-битных версий PowerPC и x86, что позволяет поставлять приложения в форме, поддерживающей 32-битные процессоры, но использующей большее адресное пространство и более широкие пути данных при работе на 64-битных процессорах.

В версии среды разработки Xcode с 2.1 по 3.2 (работающие на Mac OS X 10.4 – Mac OS X 10.6 ) Apple включила утилиты, которые позволяли настраивать приложения как для архитектуры Intel, так и для PowerPC; универсальные двоичные файлы могут в конечном итоге содержать до четырех версий исполняемого кода (32-битный PowerPC, 32-битный x86, 64-битный PowerPC и 64-битный x86 ). Однако поддержка PowerPC была удалена из Xcode 4.0 и поэтому недоступна для разработчиков, работающих под Mac OS X 10.7 или более поздней версии.

В 2020 году Apple объявила об очередном переходе , на этот раз с процессоров Intel x86 на кремний Apple (архитектура ARM64). Чтобы сгладить переход, Apple добавила поддержку двоичного формата Universal 2 ; Двоичные файлы Universal 2 — это двоичные файлы с несколькими архитектурами, содержащие исполняемый код как x86-64, так и ARM64, что позволяет двоичному файлу работать как на 64-битном процессоре Intel, так и на 64-битном процессоре Apple. Кроме того, Apple представила набор команд динамической двоичной трансляции Rosetta 2 для x86 в Arm64, позволяющий пользователям запускать приложения, не имеющие универсальных двоичных вариантов.

Бинарный файл Apple Fat EFI

[ редактировать ]

В 2006 году Apple перешла с PowerPC на процессоры Intel и заменила открытую прошивку на EFI . Однако к 2008 году некоторые из их компьютеров Mac использовали 32-битный EFI, а некоторые — 64-битный EFI. По этой причине Apple расширила спецификацию EFI «толстыми» двоичными файлами, которые содержали как 32-битные, так и 64-битные двоичные файлы EFI. [13]

КП/М и ДОС

[ редактировать ]

Комбинированные двоичные файлы в стиле COM для CP/M-80 и DOS.

[ редактировать ]

Исполняемые файлы CP/M-80 , MP/M-80 , Concurrent CP/M , CP/M Plus , Personal CP/M-80 , SCP и MSX-DOS для семейств процессоров Intel 8080 (и Zilog Z80 ) используют один и тот же файл . COM Расширение файла как DOS -совместимые операционные системы для двоичных файлов Intel 8086 . [номер 1] В обоих случаях программы загружаются по смещению +100h и выполняются путем перехода к первому байту файла. [14] [15] Поскольку коды операций двух семейств процессоров несовместимы, попытка запустить программу в неправильной операционной системе приводит к неправильному и непредсказуемому поведению.

Чтобы избежать этого, были разработаны некоторые методы создания полных двоичных файлов, содержащих как программу CP/M-80, так и программу DOS, которым предшествует исходный код, который правильно интерпретируется на обеих платформах. [15] Эти методы либо объединяют две полнофункциональные программы, каждая из которых создана для соответствующей среды, либо добавляют заглушки , которые позволяют программе корректно завершить работу, если она запущена на неправильном процессоре. Чтобы это работало, необходимо выполнить несколько первых инструкций (иногда называемых заголовками гаджетов) . [16] ) в файле .COM должен быть действительный код для процессоров 8086 и 8080, что приведет к разветвлению процессоров в разные места кода. [16] Например, утилиты эмулятора MyZ80 Симеона Крана начинаются с последовательности кода операции ЭБх, 52h, ЭБх . [17] [18] 8086 воспринимает это как переход и считывает следующую инструкцию со смещения +154h, тогда как 8080 или совместимый процессор проходит прямо и считывает следующую инструкцию со смещения +103h. Для этой цели используется аналогичная последовательность: ЭБх, 03h, C3h . [19] [20] FATBIN Джона К. Эллиотта [21] [22] [23] это утилита для объединения файлов CP/M-80 и DOS .COM в один исполняемый файл. [17] [24] Его производная от оригинального PMsfx Ёсихико Мино, модифицирует архивы, созданные PMarc чтобы они были самораспаковывающимися под как CP/M-80, так и под DOS, начиная с EBh, 18h, 2Dh, 70h, 6Dh, 73h, 2Dh, чтобы также включать подпись «-pms-» для самораспаковывающихся архивов PMA , [25] [17] [24] [18] тем самым также представляя собой форму исполняемого кода ASCII .

Еще один способ предотвратить ошибочное выполнение программ .COM в DOS-совместимой операционной системе для машин CP/M-80 и MSX-DOS. [15] это начать код 8080 с C3h, 03h, 01h , который декодируется как инструкция «RET» процессорами x86, тем самым корректно завершая программу, [номер 2] в то время как процессоры 8080 будут декодировать ее как инструкцию «JP 103h» и просто перейти к следующей инструкции в программе. Аналогично, ассемблер CP/M Z80ASM+ от SLR Systems отображал сообщение об ошибке при ошибочном запуске в DOS. [17]

Некоторые CP/M-80 3.0 файлы .COM могут иметь одно или несколько наложений RSX, прикрепленных к ним с помощью GENCOM . [26] Если да, то они начинаются с дополнительного 256-байтового заголовка (одна страница ). Чтобы указать это, первый байт в заголовке устанавливается на магический байт. C9h , который работает как подпись, идентифицирующая этот тип COM-файла для исполняемого загрузчика CP/M 3.0 , а также как инструкция «RET» для 8080-совместимых процессоров, которая приводит к корректному выходу, если файл выполняется в более старых версиях. КП/М-80. [номер 2]

C9h никогда не подходит в качестве первого байта программы для любого процессора x86 (для разных поколений он имеет разное значение, [номер 3] но никогда не является значимым первым байтом); исполняемый загрузчик в некоторых версиях DOS отклоняет COM-файлы, начинающиеся с C9h , чтобы избежать неправильной работы.

Подобные перекрывающиеся кодовые последовательности также были разработаны для комбинированных Z80/ 6502 . [17] 8086/ 68000 [17] или двоичные файлы x86/ MIPS / ARM . [16]

Комбинированные двоичные файлы для CP/M-86 и DOS

[ редактировать ]

CP/M-86 и DOS не имеют общего расширения файлов для исполняемых файлов. [номер 1] Таким образом, обычно невозможно перепутать исполняемые файлы. Однако ранние версии DOS имели так много общего с CP/M с точки зрения архитектуры, что некоторые ранние программы DOS были разработаны для совместного использования двоичных файлов, содержащих исполняемый код. Известно, что одной из программ, делавших это, была WordStar 3.2x , которая использовала идентичные файлы наложения в своих портах для CP/M-86 и MS-DOS . [27] и использовал динамически исправленный код для адаптации к различным соглашениям о вызовах этих операционных систем во время выполнения . [27]

Digital Research компании GSX для CP/M-86 и DOS также использует идентичные двоичные 16-битные драйверы. [28]

Комбинированные файлы COM и SYS

[ редактировать ]

DOS Драйверы устройств (обычно с расширением файла .SYS ) начинаются с заголовка файла, первые четыре байта которого по соглашению равны FFFFFFFFh , хотя это не является обязательным требованием. [29] Это динамически исправляется операционной системой при загрузке драйвера (обычно в DOS BIOS , когда она выполняет операторы DEVICE в CONFIG.SYS ). Поскольку DOS не отклоняет загрузку файлов с расширением .COM для каждого УСТРОЙСТВА и не проверяет наличие FFFFFFFFh, можно объединить программу COM и драйвер устройства в один файл. [30] [29] путем размещения инструкции перехода к точке входа встроенной программы COM в первые четыре байта файла (обычно достаточно трех байтов). [29] Если встроенная программа и разделы драйвера устройства имеют общую часть кода или данных, необходимо, чтобы код загружался по смещению +0100h как программа в стиле .COM и по +0000h как драйвер устройства. [30] Для общего кода, загруженного с «неправильным» смещением, но не предназначенного для независимости от позиции , требуется исправление внутреннего адреса. [30] аналогично тому, что в противном случае уже было бы выполнено перемещающимся загрузчиком , за исключением того, что в этом случае это должна выполняться самой загруженной программой; это похоже на ситуацию с самоперемещающимися драйверами , но программа уже загружена в целевое место загрузчиком операционной системы.

Системные файлы с защитой от сбоев

[ редактировать ]

В DOS некоторые файлы по соглашению имеют расширения, которые не соответствуют их фактическому типу файлов. [номер 4] Например, COUNTRY.SYS. [31] не является драйвером устройства DOS, [номер 5] а двоичный файл базы данных NLS для использования с директивой CONFIG.SYS COUNTRY и драйвером NLSFUNC . [31] Аналогично, PC DOS и DR-DOS системные файлы IBMBIO.COM и IBMDOS.COM представляют собой специальные двоичные образы, загружаемые загрузчиками начальной загрузки , а не программами в стиле COM. [номер 5] Попытка загрузить COUNTRY.SYS с помощью инструкции DEVICE или выполнение IBMBIO.COM или IBMDOS.COM из командной строки приведет к непредсказуемым результатам. [номер 4] [номер 6]

Иногда этого можно избежать, используя методы, аналогичные описанным выше. Например, DR-DOS 7.02 и выше включают функцию безопасности, разработанную Маттиасом Р. Полом: [32] Если эти файлы вызываются неправильно, крошечные встроенные заглушки просто отображают некоторую информацию о версии файла и корректно завершают работу. [33] [32] [34] [31] Кроме того, сообщение специально создано с учетом определенных «магических» шаблонов, распознаваемых внешней утилитой идентификации файлов NetWare и DR-DOS VERSION . [31] [32] [номер 7]

Аналогичной функцией защиты была инструкция 8080. C7h («RST 0») в самом начале программ Джея Сейджа и Джо Райта Z-System типа 3 и типа 4 «Z3ENV». [35] [36] а также файлы языковых наложений «Z3TXT», [37] что приведет к «горячей» загрузке (вместо сбоя) под CP/M-80 при неправильной загрузке. [35] [36] [37] [номер 2]

Подобным образом многие (двоичные) форматы файлов по соглашению включают в себя 1Ah Байт ( ASCII ^Z ) в начале файла. Этот управляющий символ будет интерпретироваться как «мягкий» маркер конца файла (EOF), когда файл открывается в недвоичном режиме и, следовательно, во многих операционных системах (включая PDP-6) . монитор [38] и РТ-11 , ВМС , ТОПС-10 , [39] КП/М, [40] [41] ПРИНАДЛЕЖАЩИЙ, [42] и Windows [43] ), он предотвращает отображение «двоичного мусора» при случайной печати файла на консоли.

Линукс

[ редактировать ]

FatELF: универсальные двоичные файлы для Linux

[ редактировать ]
FatELF Логотип

FatELF [44] представлял собой толстую бинарную реализацию для Linux и других Unix-подобных операционных систем. Технически двоичный файл FatELF представлял собой объединение двоичных файлов ELF с некоторыми метаданными, указывающими, какой двоичный файл на какой архитектуре использовать. [45] В дополнение к абстракции архитектуры ЦП ( порядок байтов , размер слова , набор инструкций ЦП и т. д.) есть преимущество двоичных файлов с поддержкой нескольких ABI и версий ядра.

По словам разработчиков, FatELF имеет несколько вариантов использования: [44]

  • Дистрибутивы больше не требуют отдельных загрузок для разных платформ.
  • Отдельные деревья /lib , /lib32 и /lib64 больше не требуются в структуре каталогов ОС .
  • Правильные двоичные файлы и библиотеки выбираются системой централизованно вместо сценариев оболочки .
  • Если ELF ABI когда-нибудь изменится, устаревшие пользователи по-прежнему смогут поддерживаться.
  • Распространение плагинов веб-браузера, которые готовы к использованию на нескольких платформах.
  • Распространение одного файла приложения, который работает в вариантах ОС Linux и BSD , без уровня совместимости платформ.
  • Один раздел жесткого диска можно загружать на разные машины с разной архитектурой ЦП для разработки и экспериментирования. Та же корневая файловая система, другая архитектура ядра и процессора.
  • Приложения, предоставляемые сетевым ресурсом или USB-накопителями, будут работать на нескольких системах. Это также полезно для создания портативных приложений , а также образов облачных вычислений для гетерогенных систем. [46]

пробный образ Ubuntu 9.04 . Доступен [47] По состоянию на 2021 год , FatELF не интегрирован в основное ядро ​​Linux. [ нужна ссылка ] [48] [49]

Окна

[ редактировать ]

толстый пакет

[ редактировать ]

Хотя формат переносимого исполняемого файла, используемый в Windows, не позволяет назначать код платформам, все же можно создать программу-загрузчик, которая распределяется на основе архитектуры. Это связано с тем, что настольные версии Windows на ARM поддерживают 32-битную эмуляцию x86 , что делает ее полезной «универсальной» целью машинного кода. Fatpack — это загрузчик, демонстрирующий эту концепцию: он включает в себя 32-битную программу x86, которая пытается один за другим запустить исполняемые файлы, упакованные в ее разделы ресурсов. [50]

Arm64X

[ редактировать ]

При разработке Windows 11 ARM64 компания Microsoft представила новый способ расширения формата переносимого исполняемого файла под названием Arm64X. [51] Бинарный файл Arm64X содержит все содержимое, которое было бы в отдельных двоичных файлах x64/Arm64EC и Arm64, но объединено в один более эффективный файл на диске. Набор инструментов Visual C++ был обновлен для поддержки создания таких двоичных файлов. А когда создание двоичных файлов Arm64X технически сложно, разработчики могут вместо этого создавать библиотеки Arm64X с чистым перенаправлением. [52]

Похожие концепции

[ редактировать ]

Следующие подходы аналогичны «толстым» двоичным файлам тем, что в одном файле предоставляется несколько версий машинного кода одной и той же цели.

Гетерогенные вычисления

[ редактировать ]

С 2007 года некоторые специализированные компиляторы для гетерогенных платформ создают файлы кода для параллельного выполнения на нескольких типах процессоров, например, компилятор CHI ( C для гетерогенной интеграции) из пакета разработки Intel EXOCHI (Exoskeleton Sequencer) расширяет OpenMP концепцию прагмы для многопоточности для создания толстые двоичные файлы, содержащие разделы кода для различных архитектур набора команд (ISA), из которых загрузчик среды выполнения может динамически инициировать параллельное выполнение на нескольких доступных ядрах ЦП и графического процессора в гетерогенной системной среде. [53] [54]

Представленная в 2006 году Nvidia платформа параллельных вычислений CUDA (Compute Unified Device Architecture) представляет собой программное обеспечение, позволяющее выполнять вычисления общего назначения на графических процессорах ( GPGPU ). Его LLVM компилятор на основе NVCC может создавать толстые двоичные файлы на основе ELF, содержащие так называемую PTX виртуальную сборку (в виде текста), которую драйвер времени выполнения CUDA может позже оперативно скомпилировать в некоторый двоичный исполняемый код SASS (Streaming Assembler) для фактически существующего целевой графический процессор. Исполняемые файлы также могут включать в себя так называемые двоичные файлы CUDA (также известные как файлы cubin ), содержащие выделенные разделы исполняемого кода для одной или нескольких конкретных архитектур графического процессора, из которых среда выполнения CUDA может выбирать во время загрузки. [55] [56] [57] [58] [59] [60] Двоичные файлы в формате Fat также поддерживаются GPGPU-Sim [ de ] , симулятором графического процессора , также представленным в 2007 году. [61] [62]

Multi2Sim (M2S), платформа симулятора гетерогенной системы OpenCL (первоначально только для процессоров MIPS или x86, но позже расширена для поддержки ARM процессоров и графических процессоров , таких как AMD / ATI Evergreen и Southern Islands , а также Nvidia Fermi и Kepler ) семейства [63] также поддерживает бинарные файлы на основе ELF. [64] [63]

Жирные предметы

[ редактировать ]

GNU Compiler Collection (GCC) и LLVM не имеют расширенного двоичного формата, но у них есть расширенные объектные файлы для оптимизации времени компоновки (LTO). Поскольку LTO предполагает задержку компиляции до времени компоновки, объектные файлы должны хранить промежуточное представление (IR), но, с другой стороны, может потребоваться сохранение и машинного кода (для скорости или совместимости). Объект LTO, содержащий как IR, так и машинный код, известен как « толстый объект» . [65]

Функция многоверсионности

[ редактировать ]

Даже в программе или библиотеке, предназначенной для той же архитектуры набора команд , программист может захотеть использовать некоторые новые расширения набора команд, сохраняя при этом совместимость со старым процессором. Этого можно достичь с помощью многоверсионности функций (FMV): версии одной и той же функции записываются в программу, и фрагмент кода решает, какую из них использовать, путем определения возможностей ЦП (например, через CPUID ). Компилятор Intel C++ , GCC и LLVM имеют возможность автоматически генерировать многоверсионные функции. [66] Это форма динамической отправки без каких-либо смысловых эффектов.

Многие математические библиотеки содержат рукописные процедуры ассемблера, которые автоматически выбираются в зависимости от возможностей процессора. Примеры включают glibc , Intel MKL и OpenBLAS . Кроме того, загрузчик библиотек в glibc поддерживает загрузку по альтернативным путям для определенных функций ЦП. [67]

Подобный подход, но с детализацией на уровне байтов, первоначально разработанный Маттиасом Р. Полом и Акселем К. Фринк, заключается в том, чтобы позволить небольшому самоудаляющемуся, расслабляющемуся и перемещающемуся загрузчику, встроенному в исполняемый файл вместе с любым количеством альтернативных фрагментов двоичного кода, условно построить образ времени выполнения программы или драйвера, оптимизированный по размеру или скорости, необходимый для выполнения (или невыполнения) определенной функции в определенной целевой среде во время загрузки посредством формы динамического устранения мертвого кода (DDCE). [68] [69] [70] [71]

См. также

[ редактировать ]

Примечания

[ редактировать ]
  1. ^ Jump up to: а б Это не проблема для исполняемых файлов в стиле CP/M-86 под CP/M-86 , CP/M-86 Plus , Personal CP/M-86 , S5-DOS , Concurrent CP/M-86 , Concurrent DOS , Concurrent DOS 286 , FlexOS , Concurrent DOS 386 , DOS Plus , Multiuser DOS , System Manager и REAL/32 , поскольку они используют расширение .CMD, а не .COM для этих файлов . (Однако расширение .CMD конфликтует с расширением файлов пакетных заданий, написанных для процессора командной строки CMD.EXE в семействах операционных систем OS/2 и Windows NT .)
  2. ^ Jump up to: а б с Это работает, потому что (подходящая) инструкция возврата может использоваться для выхода из программ под CP/M-80 , CP/M-86 и DOS , хотя коды операций , точные условия и основные механизмы различаются: В CP/M-80 программы могут завершить (то есть выполнить теплую загрузку в BIOS ) путем перехода к 0 на нулевой странице либо напрямую с помощью RST 0 ( код операции 8080 / 8085 / Z80 C7h), либо путем вызова BDOS- функции 0 через интерфейс CALL 5 . В качестве альтернативы, поскольку стек подготовлен для хранения адреса возврата 0 перед передачей управления загруженной программе, они могут, пока стек плоский, также выйти, выдав команду RET (код операции C9h), тем самым попадая в стек. завершающий код по смещению 0 на нулевой странице. Хотя в DOS есть специальное прерывание INT 20h , а также INT 21h API подфункции для завершения программ (которые предпочтительнее для более сложных программ), для программ с машинным переводом DOS также в некоторой степени эмулирует поведение CP/M: программа может завершиться себя, перейдя на смещение 0 в своем PSP (эквивалент нулевой страницы CP/M), куда система ранее поместила инструкцию INT 20h. Кроме того, первоначальный стек загруженной программы подготовлен для хранения слова 0, так что программа выдает ближайший возврат RETN ( 8088/8086 , код операции C3h) также неявно перейдет к началу своего сегмента кода, тем самым в конечном итоге также достигнув INT 20h. [а] В CP/M-86 нулевая страница структурирована по-другому и нет интерфейса CALL 5, но метод возврата стека и BDOS-функция 0 (но теперь через INT E0h ) тоже работают.
  3. ^ На 8088/8086 ​ процессорах операции код C9h — это недокументированный псевдоним для CBh («RETF», извлечение CS:IP из стека ), тогда как он декодируется как «LEAVE» (установите SP в BP и извлеките BP) на и 80188/80186 процессорах новее.
  4. ^ Jump up to: а б Этой проблемы можно было бы избежать, выбрав неконфликтующие расширения файлов , но после их появления эти конкретные имена файлов были сохранены из самых ранних версий MS-DOS / PC DOS из соображений совместимости с (сторонними) инструментами, жестко встроенными в ожидайте этих конкретных имен файлов.
  5. ^ Jump up to: а б Другими файлами DOS этого типа являются KEYBOARD.SYS , двоичный файл базы данных раскладки клавиатуры для драйвера клавиатуры KEYB в MS-DOS и PC DOS , IO.SYS, содержащий BIOS DOS в MS-DOS, и MSDOS.SYS , текстовая конфигурация. файл под Windows 95 / MS-DOS 7.0 ​​MS-DOS и выше, но изначально это двоичный системный файл, содержащий ядро . Однако MS-DOS и PC DOS вообще не предоставляют защищенные от сбоев системные файлы, и эти имена файлов не используются и не нужны в DR-DOS 7.02 и выше, которая в противном случае обеспечивает защищенные от сбоев системные файлы.
  6. ^ Именно по этой причине для этих файлов «скрытый» установлен атрибут , поэтому они не отображаются в списке по умолчанию, что снижает риск случайного вызова.
  7. ^ ​ COUNTRY.SYS Форматы файлов, поддерживаемые семействами операционных систем MS-DOS / PC DOS и DR-DOS , содержат схожие данные, но организованы по-разному и несовместимы. Поскольку точки входа в структуры данных находятся по разным смещениям в файле, можно создать «толстые» COUNTRY.SYS базы данных, которые можно было использовать в обоих семействах DOS. [б] Однако DR-DOS 7.02 и ее NLSFUNC 4.00 (и выше) включают улучшенный анализатор, способный читать оба типа форматов (и варианты) даже одновременно, так что файлы с заголовком Janus не нужны. [с] [д] Тем не менее, поставляемые файлы являются «толстыми» из-за включения крошечной исполняемой заглушки, просто отображающей встроенное сообщение при ненадлежащем вызове. [д] [б]

Ссылки

[ редактировать ]
  1. ^ Деванбу, Премкумар Т.; Фонг, Филип В.Л.; Стабблбайн, Стюарт Г. (19–25 апреля 1998 г.). «3.3 Java и TH » (PDF) . Методы разработки надежного программного обеспечения . Материалы 20-й Международной конференции по программной инженерии . Материалы Международной конференции по программной инженерии . Киото, Япония. п. 131. дои : 10.1109/ICSE.1998.671109 . ISBN  0-8186-8368-6 . ISSN   0270-5257 . Архивировано (PDF) из оригинала 16 января 2014 г. Проверено 29 сентября 2021 г. (10 страниц)
  2. ^ Перо, Никола (18 декабря 2008 г.). "gnustep/tools-make: README.Packaging" . Гитхаб . Архивировано из оригинала 25 мая 2022 г. Проверено 26 мая 2022 г.
  3. ^ «PackagingDrafts/GNUstep» . Вики проекта Fedora . 25 февраля 2009 г. Архивировано из оригинала 25 мая 2022 г. Проверено 26 мая 2022 г.
  4. ^ «Примечания к выпуску программного обеспечения доменной системы, версия программного обеспечения 10.1» (PDF) (первая печатная редакция). Челмсфорд, Массачусетс, США: Apollo Computer Inc., декабрь 1988 г., с. 2-16. Заказ № 005809-А03. Архивировано (PDF) из оригинала 26 мая 2023 г. Проверено 24 июля 2022 г. (256 страниц)
  5. ^ Jump up to: а б Энгст, Адам К. (22 августа 1994 г.). «Следует ли соблюдать диету жирными бинарниками?» . TidBITS . № 240. TidBITS Publishing Inc. ISSN   1090-7017 . Архивировано из оригинала 29 сентября 2021 г. Проверено 29 сентября 2021 г.
  6. ^ Jump up to: а б Энгст, Адам К. (29 августа 1994 г.). «Жирные бинарные комментарии» . TidBITS . № 241. TidBITS Publishing Inc. ISSN   1090-7017 . Архивировано из оригинала 29 сентября 2021 г. Проверено 29 сентября 2021 г.
  7. ^ «Глава 1 — Менеджер ресурсов / Справочник по менеджеру ресурсов — Формат файла ресурсов» . Внутри Macintosh: Архитектура времени выполнения Mac OS . Компьютер Apple . 06.07.1996. Архивировано из оригинала 29 сентября 2021 г. Проверено 29 сентября 2021 г.
  8. ^ «Глава 7 — Двоичные программы в формате Fat — Создание двоичных программ в формате Fat» . Внутри Macintosh: Архитектура времени выполнения Mac OS . Компьютер Apple . 11 марта 1997 г. Архивировано из оригинала 29 сентября 2021 г. Проверено 20 июня 2011 г. [1]
  9. ^ «Глава 8 – Структура ФПИ» . Внутри Macintosh: Архитектура времени выполнения Mac OS . Компьютер Apple . 11 марта 1997 г. Архивировано из оригинала 29 сентября 2021 г. Проверено 29 сентября 2021 г.
  10. ^ Теванян, Авадис; ДеМани, Майкл; Эндерби, Кевин; Вибе, Дуглас; Снайдер, Гарт (11 июля 1995 г.) [20 августа 1993 г.]. «Метод и устройство для создания исполняемых файлов, независимых от архитектуры» (PDF) . Редвуд-Сити, Калифорния, США: Патент США NeXT Computer, Inc. 5432937A. Архивировано (PDF) из оригинала 14 декабря 2020 г. Проверено 26 мая 2022 г. [2] (9 страниц); Теванян, Авадис; ДеМани, Майкл; Эндерби, Кевин; Вибе, Дуглас; Снайдер, Гарт (18 февраля 1997 г.) [28 февраля 1995 г.]. «Метод и устройство для создания исполняемых файлов, независимых от архитектуры» (PDF) . Редвуд-Сити, Калифорния, США: Патент США NeXT Computer, Inc. 5604905A. Архивировано (PDF) из оригинала 26 мая 2022 г. Проверено 26 мая 2022 г. (9 страниц)
  11. ^ «Универсальные двоичные файлы и 32-битные/64-битные двоичные файлы PowerPC» . Справочник по форматам файлов Mac OS X ABI Mach-O . Apple Inc. , 04 февраля 2009 г. [2003 г.]. Архивировано из оригинала 27 апреля 2012 г.
  12. ^ Сингх, Амит (19 июня 2006 г.). «2.6.2 Жирные двоичные файлы» . Внутреннее устройство Mac OS X — системный подход . Образование Пирсона . п. 66. ИСБН  978-0-13270226-3 . Проверено 28 сентября 2021 г.
  13. ^ «reFIt — бинарные файлы EFI Fat» . refit.sourceforge.net . Проверено 18 октября 2022 г.
  14. ^ Пол, Матиас Р. (07.10.2002) [2000]. «Re: Запуск COM-файла» . Группа новостей : alt.msdos.programmer . Архивировано из оригинала 3 сентября 2017 г. Проверено 3 сентября 2017 г. [3] (Примечание. Содержит подробную информацию о соглашениях о вызовах программ DOS COM.)
  15. ^ Jump up to: а б с Уилкинсон, Уильям «Билл» Альберт (02 апреля 2005 г.) [2003, 16 февраля 1999 г., февраль 1987 г., 15 ноября 1986 г., 10 ноября 1986 г.]. Написано в Heath Company, США. «Кое-что общее о MS-DOS и CP/M» . РЕМарк . Том. 8, нет. 2. Сент-Джозеф, Мичиган, США: Группа пользователей Хит/Зенит (HUG). стр. 55–57. №85. Артикул 885-2085. Архивировано из оригинала 13 декабря 2021 г. [4]
  16. ^ Jump up to: а б с Ча, Санг Киль; Пак, Брайан; Брамли, Дэвид ; Липтон, Ричард Джей (8 октября 2010 г.) [04 октября 2010 г.]. Платформонезависимые программы (PDF) . Материалы 17-й конференции ACM по компьютерной и коммуникационной безопасности (CCS'10). Чикаго, Иллинойс, США: Университет Карнеги-Меллон , Питтсбург, Пенсильвания, США / Технологический институт Джорджии , Атланта, Джорджия, США. стр. 547–558. дои : 10.1145/1866307.1866369 . ISBN  978-1-4503-0244-9 . Архивировано (PDF) из оригинала 26 мая 2022 г. Проверено 26 мая 2022 г. [5] (12 страниц) (См. также: [6] ) (Примечание. Не рассматривается сценарий конкретно для 8080 и 8086 архитектур набора команд (как для CP / M и DOS ), но описывается общий «самоидентифицирующийся программа» концепция платформо-независимых программ (PIP) через то, что авторы называют заголовком гаджета (то есть фрагментами программной логики, не путать с гаджетами ROP ) для x86 , MIPS и ARM : т.е. 0Eh, B2h, 02h, A9h, 0Eh, B2h, 02h, 3Ah, 24h, 77h, 01h, 04h или 90ч, ЭБч, 20ч, 2Ач, 90ч, ЭБч, 20ч, 3Ач, 24ч, 77ч, 01ч, 04ч .)
  17. ^ Jump up to: а б с д и ж Уилкинсон, Уильям «Билл» Альберт; Селигман, Кори; Друшель, Ричард Ф.; Харстон, Джонатан Грэм; Эллиотт, Джон К. (17 февраля 1999 г.). «Двоичные файлы, совместимые с MS-DOS и CP/M» . Группа новостей : comp.os.cpm . Архивировано из оригинала 13 декабря 2021 г. Проверено 13 декабря 2021 г. (Примечание. Некоторые коды операций в примере кода Эллиотта ( EBh, 44h, EBh и EBh, 04h, ... ) можно перепутать.)
  18. ^ Jump up to: а б Эллиотт, Джон К. (27 октября 2009 г.). «Информационная программа CP/M» . Группа новостей : comp.os.cpm . Архивировано из оригинала 13 декабря 2021 г. Проверено 13 декабря 2021 г. […] Функция защиты от DOS […] Идея основана на утилитах эмулятора MYZ80 Симеона Крана; заголовок DOS-защиты в них работает на порядок лучше, поскольку не изменяются никакие регистры Z80 . Магическая последовательность — EB 52 EB: […] XCHG […] MOV D,D […] XCHG […] но это означает, что код DOS оказывается довольно далеко от начала программы. […] Еще больше удовольствия можно получить с самораспаковывающимися архивами PMArc . Запустите его с помощью […] defb 0EBh, 018h, '-pms-' […], и утилиты PMA рассматривают его как действительный архив, отправляя процессоры 8086 на 011Ah, а процессоры Z80 на 0130h. […]
  19. ^ ChristW (14 ноября 2012 г.) [13 ноября 2012 г.]. Чен, Раймонд (ред.). «Microsoft Money аварийно завершает работу во время импорта транзакций по счету или при изменении получателя платежа загруженной транзакции» . Новая старая вещь . Архивировано из оригинала 5 июля 2018 г. Проверено 19 мая 2018 г. […] Последовательность байтов […] EB 03 C3 yy xx […] Если вы создадите файл .COM с этими 5 байтами в качестве первых […] вы увидите «JMP SHORT 3», за которым следуют 3 мусорных байта. […] Если вы посмотрите на разборку Z80 […], это переводится как «EX DE,HL; ИНК БК;' […] Третий байт — это «JUMP», за которым следует 16-битный адрес, указанный как yy xx […] у вас будет файл .COM, который работает под управлением MS-DOS и […] CP/M […] (NB . Пока автор говорит о Z80, эта последовательность работает и на 8080 и совместимых процессорах.)
  20. ^ Брем, Эндрю Дж. (2016). «Толстый двоичный файл CP/M и MS-DOS» . DesertPenguin.org . Архивировано из оригинала 19 мая 2018 г. Проверено 19 мая 2018 г. (Примечание. Хотя в статье говорится о Z80 , кодовая последовательность также работает на 8080 и совместимых процессорах.)
  21. ^ Эллиотт, Джон К. (13 июня 1996 г.). «Загрузить на micros.hensa.ac.uk» . Группа новостей : comp.os.cpm . Архивировано из оригинала 13 декабря 2021 г. Проверено 13 декабря 2021 г. […] FATBIN 1.00 — объедините файл CP/M .COM и файл DOS .COM, чтобы создать файл, работающий на обеих платформах. […] Он использовался для создания: […] MSODBALL 2.05 — конвертирования дискет между форматом Amstrad 706k и форматом DOS 706k. […] Обе программы работают под CP/M-80 и DOS. […]
  22. ^ Эллиотт, Джон К. (28 июня 1998 г.) [1 апреля 1997 г.]. «ФАТБИН v1.01» . Архивировано из оригинала 28 июня 1998 г. (Примечание. FATBN101.COM 22k 1997-04-01 FATBIN v1.01. Создает толстые двоичные файлы, которые будут работать как под CP/M, так и под DOS. Распространяется в самораспаковывающемся архиве для CP/M-80 и DOS.)
  23. ^ Эллиотт, Джон К. (11 марта 2002 г.). «DSKWRITE v1.00» . Fossies — архив свежего программного обеспечения с открытым исходным кодом . Архивировано из оригинала 12 декабря 2021 г. Проверено 12 декабря 2021 г. […] DSKWRITE.Z80 содержит исходный код версии CP/M . […] DSKWRITE.ASM содержит исходный код версии для DOS . […] Чтобы получить один файл .COM , вам нужно использовать FBMAKE: […] [7] (Примечание. Упоминается FBMAKE из пакета FATBNSEA.COM.)
  24. ^ Jump up to: а б Эллиотт, Джон К. (20 июня 2012 г.) [05 января 2005 г.]. «Общий CP/M» . Seasip.info . Архивировано из оригинала 17 ноября 2021 г. Проверено 12 декабря 2021 г. […] Самораспаковывающиеся архивы представляют собой файлы .COM , содержащие несколько файлов меньшего размера. Когда вы запустите одну из них, она создаст файлы меньшего размера […] Программы самораспаковки архивов будут работать под DOS (2 или более поздней версии) или CP/M с идентичным эффектом. Чтобы извлечь их в Unix , вы можете использовать ZXCC […] FATBNSEA.COM […] FATBIN объединяет файл CP/M-80 .COM и файл DOS .COM для создания файла, который будет работать в обеих системах. […] M3C4SEA.COM […] M3CONV версии 4 — конвертирует снимки Spectrum в формате .Z80 или .SNA в формат Multiface 3 или из него (Multiface 3 -> Z80 только на ПК). […] PMSFX21X.COM […] PMSFX — это программа, которая использовалась для создания этих самораспаковывающихся архивов. Эта версия (2.11) может создавать архивы, которые распаковываются под CP/M или DOS. Для использования PMSFX вам понадобится PMARC . Новое: в DOS поддерживаются точные размеры файлов. […] SP2BMSEA.COM […] Преобразует файл холста Stop Press в Windows .BMP […] [8]
  25. ^ Эллиотт, Джон К. (18 января 1997 г.) [11 января 1997 г.]. «ПМСФКС 2» . Группа новостей : comp.os.cpm . Архивировано из оригинала 13 декабря 2021 г. Проверено 13 декабря 2021 г. […] Я написал версию PMSFX , которая создает файлы .COM , неупаковываемые в DOS и CP/M (первые три байта представляют собой легальный Z80 код , допустимый код 8086 и допустимый заголовок PMA ) […] в виде самораспаковывающегося файла. архив . […]
  26. ^ Эллиотт, Джон К.; Лопушинский, Джим (2002) [11 апреля 1998]. «Заголовок COM-файла CP/M 3» . Seasip.info . Архивировано из оригинала 30 августа 2016 г. Проверено 29 августа 2016 г.
  27. ^ Jump up to: а б Некасек, Михал (30 января 2018 г.) [28 января 2018 г., 26 января 2018 г.]. «Снова WordStar» . Музей OS/2 . Архивировано из оригинала 28 июля 2019 г. Проверено 28 июля 2019 г. […] Причина подозревать такую ​​разницу заключается в том, что версия 3.2x также поддерживает CP/M-86 ( оверлеи идентичны между DOS и CP/M-86, отличается только основной исполняемый файл) […] .OVR файлы На 100% идентично DOS и CP/M-86, с флагом (четко показанным в руководстве WordStar 3.20 ), переключающимся между ними во время выполнения […] интерфейс ОС в WordStar довольно узкий и хорошо абстрагированный […] WordStar 3.2x оверлеи на 100% идентичны в версиях DOS и CP/M-86. Существует переключатель времени выполнения, который выбирает между вызовом INT 21h (DOS) и INT E0h (CP/M-86). WS.COM не одинаков для DOS и CP/M-86, хотя, вероятно, и не сильно отличается. […]
  28. ^ Полузащитник, Натан. «Снимки экрана GSX» . Toastytech.com . Архивировано из оригинала 15 января 2020 г. Проверено 15 января 2020 г.
  29. ^ Jump up to: а б с Пол, Матиас Р. (11 апреля 2002 г.). «Re: [fd-dev] АНОНС: CuteMouse 2.0 альфа 1» . freedos-dev . Архивировано из оригинала 21 февраля 2020 г. Проверено 21 февраля 2020 г. […] FreeKEYB — это […] настоящий драйвер .COM и .SYS (миниатюрная модель) в одном. Вы можете безопасно перезаписать первый JMP, это часть того, что я имел в виду под «сложным заголовком». […] вы можете заменить FFFFh:FFFFh 3-байтовым переходом и ожидающей БД FFh. Он работает с MS-DOS, PC DOS, DR-DOS и, скорее всего, с любыми другими проблемами DOS. […]
  30. ^ Jump up to: а б с Пол, Матиас Р. (6 апреля 2002 г.). «Re: [fd-dev] АНОНС: CuteMouse 2.0 альфа 1» . freedos-dev . Архивировано из оригинала 07 февраля 2020 г. Проверено 7 февраля 2020 г. […] Добавьте в драйвер заголовок устройства SYS, чтобы CTMOUSE мог быть одновременно обычным TSR и драйвером устройства — аналогично нашему расширенному драйверу клавиатуры FreeKEYB. это на самом деле не требуется […] В DR DOS , поскольку INSTALL = поддерживается начиная с DR DOS 3.41+ и DR DOS сохраняет порядок директив [D]CONFIG.SYS […], но это […] улучшит […] гибкость в системах MS-DOS / PC DOS , которые […] всегда выполняют директивы DEVICE = перед любыми инструкциями INSTALL=, независимо от их порядка в файле. […] программное обеспечение может потребовать, чтобы драйвер мыши присутствовал в качестве драйвера устройства, поскольку в старые времена драйверы мыши всегда были драйверами устройств. Эти драйверы мыши имели определенные имена драйверов устройств в зависимости от того, какой протокол они использовали (« PC$MOUSE » для режима системы мыши , например), и некоторые программы могут искать эти драйверы, чтобы определить правильный тип используемой мыши. . […] Еще одним преимуществом является то, что драйверы устройств обычно потребляют меньше памяти (нет Environment , нет PSP ) […] По сути, это сложный заголовок файла, другой код для анализа командной строки, другая точка входа и строка выхода, а также некоторая магия сегментов для преодоления разницы ORG 0 / ORG 100h. Самостоятельная загрузка драйвера устройства немного сложнее, так как вам придется оставить заголовок драйвера там, где он есть, и переместить только оставшуюся часть драйвера […]
  31. ^ Jump up to: а б с д Пол, Маттиас Р. (10 июня 2001 г.) [1995]. «Формат файла DOS COUNTRY.SYS» (файл COUNTRY.LST) (изд. 1.44). Архивировано из оригинала 20 апреля 2016 г. Проверено 20 августа 2016 г.
  32. ^ Jump up to: а б с Пол, Матиас Р. (30 июля 1997 г.) [1 мая 1994 г.]. «Глава II.4. Недокументированные свойства внешних команд - SYS.COM». NWDOS-TIPs — Советы и рекомендации по Novell DOS 7 с учетом недокументированных подробностей, ошибок и обходных путей . MPDOSTIP (на немецком языке) (3-е изд.). Архивировано из оригинала 10 сентября 2017 г. Проверено 6 августа 2014 г. Для будущего обновления Calderas OpenDOS 7.01 я изменил код запуска IBMBIO.COM так, чтобы в случае неправильного запуска как обычной программы он возвращался в командную строку без сбоев. Однако пока неясно, когда эта функция безопасности будет включена в официальную версию. (Примечание. NWDOSTIP.TXT — это обширная работа по Novell DOS 7 и OpenDOS 7.01, включая описание многих недокументированных функций и внутренних устройств. Это часть еще более обширной работы автора. MPDOSTIP.ZIP Коллекция сохранялась до 2001 года и в то время распространялась на многих сайтах. Предоставленная ссылка указывает на более старую версию файла, преобразованную в HTML. NWDOSTIP.TXT файл.) [9]
  33. ^ Пол, Матиас Р. (2 октября 1997 г.). «Обновление Caldera OpenDOS 7.01/7.02 Alpha 3 IBMBIO.COM README.TXT» . Архивировано из оригинала 4 октября 2003 г. Проверено 29 марта 2009 г. [10]
  34. ^ DR-DOS 7.03 WHATSNEW.TXT — изменения с DR-DOS 7.02 на DR-DOS 7.03 . Кальдера, Инк. 24 декабря 1998 г. Архивировано из оригинала 08 апреля 2019 г. Проверено 08 апреля 2019 г.
  35. ^ Jump up to: а б Сейдж, Джей (май – июнь 1988 г.). Карлсон, Арт (ред.). «ZCPR 3.4 — Программы типа 4» . Компьютерный журнал (TCJ) — Программирование, поддержка пользователей, приложения . ЗЦПР3 Уголок (32). Водопад Колумбия, Монтана, США: 10–17 [ 16 ]. ISSN   0748-9331 . ковчег:/13960/t1wd4v943 . Проверено 29 ноября 2021 г. [11] [12]
  36. ^ Jump up to: а б Сейдж, Джей (май – июнь 1992 г.) [март – июнь 1992 г.]. Карлсон, Арт; МакИвен, Крис (ред.). «Программы типа 3 и типа 4» . Компьютерный журнал (TCJ) — Программирование, поддержка пользователей, приложения . Уголок Z-системы - Некоторые новые применения программ типа 4 (55). С. Плейнфилд, Нью-Джерси, США: Socrates Press: 13–19 [14, 16 ]. ISSN   0748-9331 . ковчег:/13960/t4dn54d22 . Проверено 29 ноября 2021 г. [13] [14]
  37. ^ Jump up to: а б Сейдж, Джей (ноябрь – декабрь 1992 г.). Карлсон, Арт; Киблер, Билл Д. (ред.). «Обычная функция, поддержка ZCPR, независимость от языка, часть 2» . Компьютерный журнал (TCJ) — Программирование, поддержка пользователей, приложения . Уголок Z-системы (58). Линкольн, Калифорния, США: 7–10. ISSN   0748-9331 . ковчег:/13960/t70v9g87h . Проверено 9 февраля 2020 г. […] существовал код операции «RST 0», который, если бы он был выполнен, привел бы к « горячей» загрузке . Файл, содержащий модуль Z3TXT , никогда не должен выполняться, но ценой одного байта мы можем защитить себя от этого внешнего шанса. Заголовок также содержал строку символов «Z3TXT», за которой следовал нулевой (0) байт. Многие модули Z-System включают такие идентификаторы. В эту категорию входят резидентные пакеты команд (RCP), пакеты команд потока (FCP) и модули дескрипторов среды ( Z3ENV ). Программы, такие как […] JETLDR.COM Бриджера Митчелла, которые загружают эти модули из файлов в память, могут использовать строку идентификатора для проверки файла, то есть, чтобы убедиться, что это именно тот тип модуля, который указал пользователь. быть. Таким образом можно обнаружить ошибки пользователя и поврежденные файлы. […] Заголовок, таким образом, теперь выглядит следующим образом: […] rst […] db 'Z3TXT',0 ; ID с нулевым завершением […] ; 12345678 ; должно быть 8 символов, […] db 'PROGNAME' ; накладка с пробелами […] ; 123 ; должно быть 3 символа […] db 'ENG' ; название языка […] dw LENGTH ; длина модуля […] [15] [16]
  38. ^ «Таблица характеристик устройств ввода-вывода — консоль или телетайп». Руководство по системе мультипрограммирования PDP-6 (PDF) . Мейнард, Массачусетс, США: Корпорация цифрового оборудования (DEC). 1965. с. 43. DEC-6-0-EX-SYS-UM-IP-PRE00. Архивировано (PDF) из оригинала 14 июля 2014 г. Проверено 10 июля 2014 г. (1+84+10 страниц)
  39. ^ «5.1.1.1. Функции, зависящие от устройства — Режимы данных — Полнодуплексное программное обеспечение A (ASCII) и AL (строка ASCII)». Справочное руководство PDP-10: Связь с монитором — Мониторы с разделением времени (PDF) . Том. 3. Корпорация цифрового оборудования (DEC). 1969. С. 5-3–5-6 [5-5 (431)]. Архивировано (PDF) из оригинала 15 ноября 2011 г. Проверено 10 июля 2014 г. (207 страниц)
  40. ^ «2. Соглашения о вызовах операционной системы». Руководство по интерфейсу CP/M 2.0 (PDF) (1-е изд.). Пасифик Гроув, Калифорния, США: Цифровые исследования . 1979. с. 5. Архивировано (PDF) из оригинала 28 февраля 2020 г. Проверено 28 февраля 2020 г. […] Конец файла ASCII обозначается символом Control-Z (1AH) или реальным концом файла, возвращаемым операцией чтения CP/M . Однако символы Control-Z, встроенные в файлы машинного кода (например, COM-файлы ), игнорируются, а условие конца файла, возвращаемое CP/M, используется для завершения операций чтения. […] (56 страниц)
  41. ^ Хоган, Том (1982). «3. Временные команды CP/M». Руководство пользователя Osborne CP/M - Для всех пользователей CP/M (2-е изд.). Беркли, Калифорния, США: А. Осборн/МакГроу-Хилл . п. 74. ИСБН  0-931988-82-9 . Проверено 28 февраля 2020 г. […] CP/M отмечает конец файла ASCII , помещая CONTROL-Z в файл символ после последнего символа данных. Если файл содержит число, кратное 128 символам, и в этом случае добавление CONTROL-Z приведет к потере 127 символов, CP/M этого не сделает. Использование символа CONTROL-Z в качестве маркера конца файла возможно, поскольку CONTROL-Z редко используется в качестве данных в файлах ASCII. Однако в файле, отличном от ASCII, CONTROL-Z встречается с такой же вероятностью, как и любой другой символ. Поэтому его нельзя использовать в качестве маркера конца файла. CP/M использует другой метод для обозначения конца файла, отличного от ASCII. CP/M предполагает, что он достиг конца файла, когда прочитал последнюю запись (базовую единицу дискового пространства), выделенную для файла. Запись каталога диска для каждого файла содержит список записей диска, выделенных этому файлу. Этот метод использует размер файла, а не его содержимое, чтобы найти конец файла. […] [17] [18]
  42. ^ BC_Programmer (31 января 2010 г.) [30 января 2010 г.]. «Re: Команда копирования, которая объединяет несколько файлов, помечает в конце слово SUB» . Форум компьютерной надежды . Архивировано из оригинала 26 февраля 2020 г. Проверено 26 февраля 2020 г.
  43. ^ «В чем разница между файлами .txt Linux и Windows (кодировка Unicode)» . Суперпользователь . 03 августа 2011 г. [08 июня 2011 г.]. Архивировано из оригинала 26 февраля 2020 г. Проверено 26 февраля 2020 г.
  44. ^ Jump up to: а б Гордон, Райан К. (октябрь 2009 г.). «FatELF: универсальные двоичные файлы для Linux» . icculus.org . Архивировано из оригинала 27 августа 2020 г. Проверено 13 июля 2010 г.
  45. ^ Гордон, Райан К. (ноябрь 2009 г.). «Спецификация FatELF, версия 1» . icculus.org . Архивировано из оригинала 27 августа 2020 г. Проверено 25 июля 2010 г.
  46. ^ Виндиш, Эрик (3 ноября 2009 г.). «Тема: Группы новостей: gmane.linux.kernel, Re: Патчи FatELF...» gmane.org. Архивировано из оригинала 15 ноября 2016 г. Проверено 8 июля 2010 г.
  47. ^ Гордон, Райан С. (2009). «FatELF: универсальные двоичные файлы для Linux. — Страница загрузки экспериментальной виртуальной машины» . icculus.org . Архивировано из оригинала 21 мая 2022 г. Проверено 26 мая 2022 г. (Обратите внимание: образ виртуальной машины Ubuntu 9.04 с поддержкой Fat Binary.)
  48. ^ Холверда, Том (5 ноября 2009 г.). «Райан Гордон прекращает проект FatELF» . Линукс. osnews.com. Архивировано из оригинала 26 мая 2022 г. Проверено 5 июля 2010 г.
  49. ^ Брокмайер, Джо «Зонкер» (23 июня 2010 г.). «САМ: Анатомия (предполагаемой) неудачи» . LWN.net . Еженедельные новости Linux. Архивировано из оригинала 26 мая 2022 г. Проверено 6 февраля 2011 г.
  50. ^ Малдер, Сиджмен Дж. (06 марта 2021 г.) [25 апреля 2018 г.]. «sjmulder/fatpack — сборка многоархитектурных «толстых» двоичных файлов для Windows» . Гитхаб . Архивировано из оригинала 26 мая 2022 г. Проверено 26 мая 2022 г.
  51. ^ «PE-файлы Arm64X» . Learn.microsoft.com . Майкрософт . 13 августа 2022 г. Архивировано из оригинала 20 августа 2023 г. Проверено 31 марта 2023 г.
  52. ^ «Сборка двоичных файлов Arm64X» . Learn.microsoft.com . Майкрософт . 10 марта 2023 г. Архивировано из оригинала 20 августа 2023 г. Проверено 31 марта 2023 г.
  53. ^ Ван, Перри Х.; Коллинз, Джеймисон Д.; Чинья, Гаутам Н.; Цзян, Хун; Тянь, Синьминь; Гиркар, Милинд; Ян, Ник Ю.; Люэ, Гуй-Юань; Ван, Хун (июнь 2007 г.). «EXOCHI: архитектура и среда программирования гетерогенной многоядерной многопоточной системы» . Уведомления ACM SIGPLAN . 42 (6): 156–166. дои : 10.1145/1273442.1250753 . (11 страниц)
  54. ^ Ван, Перри Х.; Коллинз, Джеймисон Д.; Чинья, Гаутам Н.; Цзян, Хун; Тянь, Синьминь; Гиркар, Милинд; Пирс, Лиза; Люэ, Гуй-Юань; Якушкин, Сергей; Ван, Хун (22 августа 2007 г.). «Экзоскелет-ускоритель» (PDF) . Журнал технологий Intel . 11: Вычисления терамасштаба (3). Корпорация Intel : 185–196. дои : 10.1535/itj.1103 . ISSN   1535-864X . Архивировано (PDF) из оригинала 26 мая 2022 г. Проверено 26 мая 2022 г. (12 из 1+vii+90+1 страниц)
  55. ^ «cudaFatFormat.h/ptxomp.c» . 1.13. Корпорация Нвидиа . 15 ноября 2004 г. Архивировано из оригинала 26 мая 2022 г. Проверено 26 мая 2022 г.
  56. ^ Харрис, Марк Дж. (08 мая 2014 г.) [05 июня 2013 г.]. «Техническое руководство: Совет CUDA Pro: понимание бинарных файлов Fat и JIT-кэширования» . Разработчик Нвидиа . Нвидиа . Архивировано из оригинала 23 марта 2022 г. Проверено 26 мая 2022 г.
  57. ^ «Двоичные утилиты CUDA» (PDF) (примечания по применению). 6.0. Нвидиа . Февраль 2014 г. DA-06762-001_v6.0. Архивировано (PDF) из оригинала 25 мая 2022 г. Проверено 25 мая 2022 г.
  58. ^ "fatbinary - помогите" . helpmanual.io . 8.0. 2016. Архивировано из оригинала 25 мая 2022 г. Проверено 25 мая 2022 г.
  59. ^ «Драйвер компилятора CUDA NVCC — Справочное руководство» (PDF) . 11.7. Нвидиа . Май 2022 г. TRM-06721-001_v11.7. Архивировано (PDF) из оригинала 25 мая 2022 г. Проверено 25 мая 2022 г.
  60. ^ Браун, Лоренц; Фрёнинг, Хольгер (18 ноября 2019 г.). CUDA Flux: легкий профилировщик инструкций для приложений CUDA (PDF) . Моделирование производительности IEEE/ACM, сравнительный анализ и моделирование высокопроизводительных компьютерных систем (PMBS). Денвер, Колорадо, США: IEEE . дои : 10.1109/PMBS49563.2019.00014 . ISBN  978-1-7281-5977-5 . Архивировано (PDF) из оригинала 21 марта 2022 г. Проверено 26 мая 2022 г.
  61. ^ Фунг, Уилсон В.Л.; Шам, Иван; Юань, Джордж; Аамодт, Тор М. (2007). «Динамическое формирование деформации и планирование для эффективного потока управления графическим процессором» (PDF) . Ванкувер, Британская Колумбия, Канада. Архивировано (PDF) из оригинала 26 мая 2022 г. Проверено 26 мая 2022 г. (12 страниц)
  62. ^ Бахода, Али; Юань, Джордж Л.; Фунг, Уилсон В.Л.; Вонг, Генри; Аамодт, Тор М. (28 апреля 2009 г.) [26 апреля 2009 г.]. Анализ рабочих нагрузок CUDA с помощью подробного симулятора графического процессора (PDF) . Материалы Международного симпозиума IEEE по анализу производительности систем и программного обеспечения (ISPASS). Бостон, Массачусетс, США. стр. 163–174. дои : 10.1109/ISPASS.2009.4919648 . Архивировано (PDF) из оригинала 26 мая 2022 г. Проверено 6 мая 2022 г. [19]
  63. ^ Jump up to: а б «13.4 Оболочка компилятора AMD: толстые двоичные файлы». Среда моделирования Multi2Sim — модель CPU-GPU для гетерогенных вычислений (PDF) . v4.2. Мульти2Сим. 2013. С. 173–176 [176]. Архивировано (PDF) из оригинала 25 мая 2022 г. Проверено 25 мая 2022 г. (4 из 210 страниц)
  64. ^ Убал, Рафаэль; Чан, Бёнхён; Мистри, Перхаад; Шаа, Дана; Каэли, Дэвид Р. (23 сентября 2012 г.) [19 сентября 2012 г.]. «Multi2Sim: среда моделирования для вычислений CPU-GPU» (PDF) . 21-я Международная конференция по параллельным архитектурам и методам компиляции (PACT) . Миннеаполис, Миннесота, США: IEEE . ISBN  978-1-4503-1182-3 . Архивировано (PDF) из оригинала 25 мая 2022 г. Проверено 25 мая 2022 г. (10 страниц)
  65. ^ «Обзор LTO (внутреннее устройство коллекции компиляторов GNU (GCC))» . gcc.gnu.org . Архивировано из оригинала 12 сентября 2021 г. Проверено 12 сентября 2021 г.
  66. ^ Веннборг, Ганс (2018). «Атрибуты в Clang» . Документация Clang 7 . Архивировано из оригинала 7 апреля 2022 г. Проверено 26 мая 2022 г.
  67. ^ Бахена, Виктор Родригес (3 апреля 2018 г.). «Прозрачное использование пакетов библиотек, оптимизированных для архитектуры Intel» . Мощность и производительность. Очистить проект Linux . Корпорация Интел . Архивировано из оригинала 26 мая 2022 г. Проверено 26 мая 2022 г.
  68. ^ Пол, Матиас Р.; Фринке, Аксель К. (13 октября 1997 г.) [1991], FreeKEYB - Расширенная клавиатура и драйвер консоли DOS (Руководство пользователя) (изд. v6.5) [20] (Примечание. FreeKEYB - это Unicode динамически настраиваемый преемник на основе K3PLUS поддерживает большинство раскладок клавиатуры , кодовых страниц и кодов стран . Использование готового ассемблера макросов , а также системы инструментов автоматического анализа предварительной и постобработки для генерации зависимостей и морфинга кода метаданных для встраивания в них. исполняемый файл вместе с двоичным кодом и самоудаляющимся, расслабляющим и перемещающим загрузчиком , драйвер реализует мертвого кода детального динамического устранения и перемещения методы на уровне байтов во время загрузки , а также самомодифицирующийся код и возможность реконфигурации во время выполнения для минимизировать объем памяти, чтобы закрыть каноническую форму, в зависимости от базового оборудования, операционной системы и конфигурации драйверов, а также выбранного набора функций и языкового стандарта (около шестидесяти переключателей конфигурации с сотнями опций для почти неограниченного числа возможных комбинаций). Эта сложность и динамика скрыты от пользователей, которые имеют дело с одним исполняемым файлом так же, как с обычным драйвером.)
  69. ^ Пол, Матиас Р. (6 апреля 2002 г.). «[fd-dev] Ctrl+Alt+Del» . freedos-dev . Архивировано из оригинала 27 апреля 2019 г. Проверено 27 апреля 2019 г. […] FreeKEYB создает образ времени выполнения драйвера во время инициализации в зависимости от типа компьютера, на котором он загружается, типа клавиатуры, раскладки, страны и используемой кодовой страницы, типа установленной мыши и видеоадаптеров, другие драйверы, загруженные в эту систему, операционную систему и используемые методы загрузки и перемещения, включенные отдельные функции и параметры конфигурации, указанные в командной строке. Из-за большого количества поддерживаемых переключателей и опций командной строки […] (около пятидесяти переключателей […] с несколькими возможными настройками) существует большое количество комбинаций функций с бесчисленными зависимостями […], что приводит к […] бесконечному количеству [ …] разные целевые изображения. Технология динамического устранения мертвого кода FreeKEYB позволяет разрешить […] эти […] зависимости и […] удалить мертвый код и данные […] не ограничивается […] включением или исключением несколько ограниченного количества модулей или целых подпрограмм. и исправить некоторые таблицы диспетчеризации, как в классическом программировании TSR, но […] работает […] на [...] уровне байтов […] способно удалять […] отдельные инструкции в середине более крупных процедур […] распределенных по всему код для обработки конкретного случая или поддержки определенной функции […] специальные инструменты используются для анализа кода […] и создания […] таблиц исправлений […] автоматически […] с использованием условных определений […] для объявления различных случаев […] не только необязательно во время сборки, но и во время инициализации […] без […] накладных расходов, связанных с наличием хотя бы некоторого количества мертвого кода в образе времени выполнения […] для отслеживания всех зависимостей между […] эти условия, динамически создавать и перемещать образ времени выполнения, исправлять все ссылки между этими небольшими, изменяющимися и перемещающимися двоичными частями […] по-прежнему позволяя использовать крошечный стиль .COM/.SYS […] модель […] готова во время инициализации […]
  70. ^ Пол, Матиас Р. (21 августа 2001 г.). «[fd-dev] Изменение кодовых страниц во FreeDOS» . freedos-dev . Архивировано из оригинала 19 апреля 2019 г. Проверено 20 апреля 2019 г. […] […] уникальная функция […] мы называем динамическое устранение мертвого кода , поэтому вы можете во время установки […] указать, какие компоненты драйвера вам нужны, а какие нет. Это касается динамической загружаемой модульности и позднего связывания, которых я до сих пор не видел в DOS. Если вам не нравится заставка, макросы, калькулятор или поддержка мыши или <почти что-нибудь еще>, вы можете указать это в командной строке, и FreeKEYB, принимая во внимание все зависимости между подпрограммами, полностью это сделает. удалите все фрагменты кода, которые связаны с этой функцией и не являются необходимыми для обеспечения запрошенной функциональности, прежде чем драйвер переместит образ в целевое местоположение и станет резидентным. […]
  71. ^ Пол, Матиас Р. (10 апреля 2001 г.). «[ANN] Выпущена бета-версия 6 FreeDOS» (на немецком языке). Группа новостей : de.comp.os.msdos . Архивировано из оригинала 9 сентября 2017 г. Проверено 2 июля 2017 г. [...] совершенно новая функция, динамическое устранение мертвого кода , которая собирает и перемещает необходимые компоненты драйвера только во время установки, так что неиспользуемый код или области данных не остаются резидентными (например, если у кого-то есть определенная функция FreeKEYB не требуется). […]

Дальнейшее чтение

[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Fat_binary&oldid=1237708198"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 5655dbe60f797e17bd057eeffd4447df__1722386160
URL1:https://arc.ask3.ru/arc/aa/56/df/5655dbe60f797e17bd057eeffd4447df.html
Заголовок, (Title) документа по адресу, URL1:
Fat binary - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)