Жир двоичный - Fat binary

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

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

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

Использование жирных двоичных файлов в Операционная система программного обеспечения; есть несколько альтернатив для решения той же проблемы, например, использование установщик программа для выбора архитектурно-зависимого двоичного файла во время установки (например, с Android несколько APK), выбирая двоичный файл, зависящий от архитектуры, во время выполнения (например, с План 9 каталоги профсоюзов и GNUstep толстые пучки),[1][2] распространение программного обеспечения в исходный код форма и составление это на месте, или использование виртуальная машина (например, с Ява ) и Сборник Just In Time.

Аполлон

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

В 1988 г. Аполлон Компьютер с Домен / ОС SR10.1 представил новый тип файла, "cmpexe" (составной исполняемый файл), который объединяет двоичные файлы для Motorola 680x0 и ПРИЗМА Аполлона исполняемые файлы.[3]

яблоко

Жирный двоичный код Apple

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

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

Многоархитектурные двоичные файлы NeXT / Apple

Мультиархитектурные двоичные файлы NeXTSTEP

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

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

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

Mach-O и Mac OS X

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

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

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

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

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

Кроме того, двоичные исполняемые файлы с несколькими архитектурами могут содержать код как для 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. Чтобы сгладить переход, Apple добавила поддержку Универсальный 2 двоичный формат. Это позволяет создавать двоичные файлы, которые изначально работают как на 64-разрядном кристалле Intel, так и на 64-разрядном кристалле Apple ( Aarch64 вариант).

ДОС

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

CP / M-80, МП / М-80, Параллельные CP / M, CP / M Plus и Персональный CP / M-80 исполняемые файлы для Intel 8080 (и Z80 ) семейства процессоров используют одинаковые .COM расширение файла в качестве ДОС -совместимые операционные системы для Intel 8086 двоичные файлы.[nb 1] В обоих случаях программы загружаются со смещением + 100h и выполняются путем перехода к первому байту файла. Поскольку коды операций двух семейств процессоров несовместимы, попытка запустить программу в неправильной операционной системе приводит к неправильному и непредсказуемому поведению.

Чтобы избежать этого, были разработаны методы для создания толстых двоичных файлов, которые содержат как CP / M-80, так и программу DOS, которой предшествует исходный код, который правильно интерпретируется на обеих платформах. Эти методы либо объединяют две полностью функциональные программы, каждая из которых создана для соответствующей среды, либо добавляют заглушки что приводит к корректному завершению программы при запуске на неправильном процессоре. Чтобы это работало, первые несколько инструкций в файле .COM должны быть допустимым кодом для процессоров 8086 и 8080, что приведет к тому, что процессоры будут переходить в разные места в коде. Например, утилиты в эмуляторе Симеона Крана MyZ80 начать с последовательности кода операции EBh, 52h, EBh. 8086 воспринимает это как скачок и считывает свою следующую инструкцию со смещения + 154h, тогда как 8080 или совместимый процессор проходит напрямую и читает свою следующую инструкцию с + 103h. Аналогичная последовательность, используемая для этой цели, выглядит следующим образом: EBh, 03h, C3h.[6][7]

Другой способ предотвратить ошибочное выполнение DOS-совместимой операционной системой программ .COM для CP / M-80 и MSX-DOS машины должны начать код 8080 с C3h, 03h, 01h, который декодируется процессорами x86 как команда «RET», тем самым корректно завершая программу, а процессоры 8080 декодируют как команду «JP 103h» и просто переходят к следующей команде в программе.

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

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

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

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

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

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

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

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

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

Иногда этого можно избежать, используя методы, аналогичные описанным выше. Например, DR-DOS 7.02 и выше, включают функцию безопасности, разработанную Маттиасом Р. Полом:[14] Если эти файлы вызываются неправильно, крошечные встроенные заглушки просто отображают некоторую информацию о версии файла и корректно завершают работу.[15][14][16][13]

Аналогичным средством защиты была инструкция 8080 C7h ("RST 0") в самом начале файлов оверлея языка Z-System, что приведет к теплый старт (вместо вылета) под CP / M-80 при неправильной загрузке.[17]

Сходным образом многие (двоичные) форматы файлов по соглашению включать 1Ач байт (ASCII ^ Z ) рядом с началом файла. Этот управляющий персонаж будет интерпретироваться как «мягкий» конец файла (EOF), когда файл открывается в небинарном режиме, и, следовательно, во многих операционных системах (включая РТ-11, VMS, CP / M,[18][19] DOS,[20] и Windows[21]), он предотвращает отображение «двоичного мусора», когда файл случайно набирается на консоли.

Linux

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

FatELF логотип

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

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

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

Доказательство концепции Ubuntu 9.04 изображение доступно.[25] По состоянию на 25 апреля 2020 г., FatELF не был интегрирован в основное ядро ​​Linux.[нужна цитата ][26][27]

Windows

Жирпак

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

Подобные системы

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

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

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

Мультиверсификация функций

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

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

Смотрите также

Примечания

  1. ^ а б Это не проблема для исполняемых файлов в стиле CP / M-86 под CP / M-86, CP / M-86 Plus, Личный CP / M-86, S5-DOS, Параллельный CP / M-86, Параллельная DOS, Параллельный DOS 286, FlexOS, Параллельная DOS 386, DOS Plus, Многопользовательская DOS, Системный менеджер и РЕАЛЬНЫЙ / 32 потому что они используют расширение файла .CMD скорее, чем .COM для этих файлов. (Однако расширение .CMD конфликтует с расширением файла для пакетные работы написано для процессор командной строки CMD.EXE под OS / 2 и Windows NT семейства операционных систем.)
  2. ^ На 8088 /8086 процессоры, код операции C9h недокументированный псевдоним для CBh ("RETF"), тогда как он декодируется как "LEAVE" на 80188 /80186 и более новые процессоры.
  3. ^ а б Этой проблемы можно было избежать, выбрав неконфликтный расширения файлов, но после введения эти конкретные имена файлов были сохранены с очень ранних версий MS-DOS /ПК DOS по соображениям совместимости с инструментами (сторонних), жестко запрограммированных на использование этих конкретных имен файлов.
  4. ^ а б Другой ДОС файлы этого типа KEYBOARD.SYS, двоичный раскладка клавиатуры файл базы данных для драйвера клавиатуры KEYB под MS-DOS и ПК DOS, IO.SYS содержащий DOS BIOS под MS-DOS и MSDOS.SYS, текстовый файл конфигурации в Windows 95 /MS-DOS 7.0 и выше, но изначально это двоичный системный файл, содержащий MS-DOS ядро. Однако MS-DOS и PC DOS вообще не предоставляют защищенные от сбоев системные файлы, и эти имена файлов не используются и не нужны в DR-DOS 7.02 и выше, что в противном случае предоставляет системные файлы с защитой от сбоев.
  5. ^ Это причина, по которой эти файлы имеют скрытый атрибут set, чтобы они не указывались по умолчанию, что снижает риск случайного вызова.

Рекомендации

  1. ^ "PackagingDrafts / GNUstep". Вики проекта Fedora.
  2. ^ "gnustep / tools-make: README.Packaging". GitHub.
  3. ^ «Примечания к выпуску программного обеспечения системы домена, версия программного обеспечения 10.1» (PDF) (первое печатное изд.). Челмсфорд, Массачусетс, США: Apollo Computer Inc. Декабрь 1988 г. с. 2-16. Номер заказа 005809-A03. В архиве (PDF) из оригинала на 2020-08-27. Получено 2020-08-17. (256 страниц)
  4. ^ Компьютер Apple (1997-03-11). «Создание толстых двоичных программ». Внутри Macintosh: архитектуры среды выполнения Mac OS. Архивировано из оригинал на 2004-03-07. Получено 2011-06-20.
  5. ^ Компьютер Apple (2006-03-08). «Универсальные двоичные файлы и 32-разрядные / 64-разрядные двоичные файлы PowerPC». Справочник по формату файла Mac OS X ABI Mach-O. Архивировано из оригинал на 2009-04-04. Получено 2006-07-13.
  6. ^ ChristW (2012-11-14) [2012-11-13]. Чен, Раймонд (ред.). «Сбой Microsoft Money при импорте транзакций по счету или при смене получателя загруженной транзакции». Новая старая вещь. Архивировано из оригинал на 2018-07-05. Получено 2018-05-19. […] Байтовая последовательность […] EB 03 C3 yy xx […] Если вы создаете .COM файл с этими 5 байтами в качестве первых […] вы увидите «JMP SHORT 3», за которым следуют 3 мусорных байта. […] Если вы посмотрите на Z80 разборка […], что переводится как EX DE, HL; INC BC; ' […] Третий байт - «JUMP», за которым следует 16-битный адрес, указанный как yy xx […] у вас будет файл .COM, который будет работать MS-DOS и […] CP / M […] (NB. Хотя автор говорит о Z80, эта последовательность работает и на 8080 и совместимые процессоры.)
  7. ^ Брем, Эндрю Дж. (2016). "CP / M и MS-DOS Fat Binary". DesertPenguin.org. В архиве из оригинала на 2018-05-19. Получено 2018-05-19. (NB. Хотя в статье говорится о Z80, кодовая последовательность также работает на 8080 и совместимые процессоры.)
  8. ^ Эллиотт, Джон С.; Лопушинский, Джим (2002) [1998-04-11]. "Заголовок файла CP / M 3 COM". Seasip.info. В архиве из оригинала на 30.08.2016. Получено 2016-08-29.
  9. ^ а б Некасек, Михал (30.01.2018) [28.01.2018, 26.01.2018]. "WordStar Again". OS / 2 музей. В архиве из оригинала на 2019-07-28. Получено 2019-07-28. […] Причина подозревать такую ​​разницу в том, что версия 3.2x также поддерживает CP / M-86 (в накладки идентичны между ДОС и 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, хотя, вероятно, и не сильно отличается. […]
  10. ^ Полузащитник, Натан. "Снимки экрана GSX". Toastytech.com. В архиве из оригинала на 2020-01-15. Получено 2020-01-15.
  11. ^ а б c Пол, Матиас Р. (11 апреля 2002 г.). "Re: [fd-dev] ОБЪЯВЛЕНИЕ: CuteMouse 2.0 alpha 1". freedos-dev. В архиве из оригинала от 21.02.2020. Получено 2020-02-21. […] FreeKEYB - это […] настоящий драйвер .COM и .SYS (крошечная модель) в одном. Вы можете безопасно перезаписать первый JMP, это часть того, что я имел в виду под «хитрым заголовком». […] Вы можете заменить FFFFh: FFFFh 3-байтовым переходом и ожидающим DB FFh. Он работает с MS-DOS, PC DOS, DR-DOS и, скорее всего, с любой другой проблемой DOS. […]
  12. ^ а б c Пол, Маттиас Р. (2002-04-06). "Re: [fd-dev] ОБЪЯВЛЕНИЕ: CuteMouse 2.0 alpha 1". freedos-dev. В архиве из оригинала 07.02.2020. Получено 2020-02-07. […] Добавьте в драйвер заголовок драйвера устройства SYS, чтобы CTMOUSE мог быть одновременно в одном, обычном TSR и драйвер устройства - аналогичный нашему расширенному драйверу клавиатуры FreeKEYB. […] В этом нет необходимости DR DOS потому что УСТАНОВИТЬ = поддерживается, поскольку DR DOS 3.41+ и DR DOS сохраняет порядок [D] CONFIG.SYS директивы […], но это […] улучшит […] гибкость MS-DOS /ПК DOS системы, которые […] всегда выполняют УСТРОЙСТВО = директивы перед любыми операторами INSTALL =, независимо от их порядка в файле.[…] Программное обеспечение может потребовать, чтобы драйвер мыши присутствовал в качестве драйвера устройства, поскольку драйверы мыши всегда были драйверами устройств в старые времена. У этих драйверов мыши были определенные имена драйверов устройств в зависимости от того, какой протокол они использовали ("ПК $ МЫШЬ " за Режим мышиных систем например), и некоторое программное обеспечение может искать эти драйверы, чтобы определить, какой тип мыши будет использоваться. […] Еще одним преимуществом было бы то, что драйверы устройств обычно потребляют меньше памяти (нет среда, нет PSP ) […] По сути, это хитрый заголовок файла, другой код для синтаксического анализа командной строки, другая точка входа и строка выхода и некоторая магия сегментов для преодоления разницы ORG 0 / ORG 100h. Самостоятельная загрузка драйвер устройства немного сложнее, так как вам нужно оставить заголовок драйвера на месте и переместить только оставшуюся часть драйвера […]
  13. ^ а б c Пол, Маттиас Р. (2001-06-10) [1995]. "Формат файла DOS COUNTRY.SYS" (Файл COUNTRY.LST) (1.44 ред.). В архиве из оригинала от 20.04.2016. Получено 2016-08-20.
  14. ^ а б Пол, Матиас Р. (1997-07-30) [1994-05-01]. «Глава II.4. Undokumentierte Eigenschaften externer Kommandos - SYS.COM». NWDOS-TIPs - Советы и приемы для Novell DOS 7, с подробностями, исправлениями и обходными путями Blick auf undokumentierte. MPDOSTIP. Выпуск 157 (на немецком языке) (3-е изд.). В архиве из оригинала на 2017-09-10. Получено 2014-08-06. Für ein zukünftiges Update für Calderas OpenDOS 7.01 имеет стартовый код IBMBIO.COM so modifiziert, daß er - Fall fälschlicherweise als normales Programm gestartet - ohne Absturz zur Kommandozeile zurückkehrt. Wann diese Sicherheitsfunktion in die offizielle Version Einzug halten wird, ist jedoch noch nicht abzusehen. (NB. NWDOSTIP.TXT - это комплексная работа по Novell DOS 7 и OpenDOS 7.01, включая описание многих недокументированных функций и внутренних компонентов. Это часть еще более обширной работы автора. MPDOSTIP.ZIP Коллекция сохранялась до 2001 г. и распространялась на многих сайтах того времени. Предоставленная ссылка указывает на старую версию HTML-конвертированного NWDOSTIP.TXT файл.) [1]
  15. ^ Пол, Маттиас Р. (1997-10-02). "Caldera OpenDOS 7.01 / 7.02 Обновление Alpha 3 IBMBIO.COM README.TXT". Архивировано из оригинал на 2003-10-04. Получено 2009-03-29. [2]
  16. ^ DR-DOS 7.03 WHATSNEW.TXT - Изменения с DR-DOS 7.02 на DR-DOS 7.03. Caldera, Inc. 1998-12-24. Архивировано из оригинал на 2019-04-08. Получено 2019-04-08.
  17. ^ Сейдж, Джей (ноябрь – декабрь 1992 г.). Карлсон, Искусство; Киблер, Билл Д. (ред.). «Обычная функция, поддержка ZCPR, языковая независимость, часть 2». Компьютерный журнал (TCJ) - Программирование, поддержка пользователей, приложения. Уголок Z-System. Линкольн, Калифорния, США (58): 7–10. ISSN  0748-9331. ковчег: / 13960 / t70v9g87h. Получено 2020-02-09. […] Был код операции «RST 0», который в случае выполнения привел бы к теплый ботинок. Файл, содержащий модуль Z3TXT, никогда не должен выполняться, но ценой одного байта мы могли бы защитить себя от этого внешнего шанса. Заголовок также содержит строку символов «Z3TXT», за которой следует нулевой (0) байт. Многие модули Z-System включают такие идентификаторы. В эту категорию входят резидентные пакеты команд (RCP), пакеты команд потока (FCP) и модули дескрипторов среды (Z3ENV). Программы, такие как Bridger Mitchell's […] JETLDR.COM, которые загружают эти модули из файлов в память, могут использовать строку идентификатора для проверки файла, то есть, чтобы убедиться, что это именно тот модуль, который указал пользователь. быть. Таким образом можно обнаружить ошибки пользователя и поврежденные файлы. […] Заголовок, таким образом, теперь выглядит следующим образом: […] rst […] db 'Z3TXT', 0; идентификатор с завершающим нулем […]; 12345678; должен состоять из 8 символов, […] db 'PROGNAME'; блокнот с пробелами […]; 123; должно быть 3 символа […] db 'ENG'; название языка […] dw LENGTH; длина модуля […] [3][4]
  18. ^ «2. Соглашения о вызовах операционной системы». Руководство по интерфейсу CP / M 2.0 (PDF) (1-е изд.). Пасифик Гроув, Калифорния, США: Цифровые исследования. 1979. стр. 5. В архиве (PDF) из оригинала на 2020-02-28. Получено 2020-02-28. […] Конец ASCII файл обозначается Ctrl-Z символ (1AH) или реальный конец файла, возвращаемый CP / M читать операцию. Символы Control-Z, встроенные в файлы машинного кода (например, COM файлы ), однако, игнорируются, а условие конца файла, возвращаемое CP / M, используется для завершения операций чтения. […] (56 страниц)
  19. ^ Хоган, Том (1982). «3. Команды переходного процесса CP / M». Руководство пользователя Osborne CP / M - для всех пользователей CP / M (2-е изд.). Беркли, Калифорния, США: А. Осборн / Макгроу-Хилл. п. 74. ISBN  0-931988-82-9. Получено 2020-02-28. […] CP / M знаменует конец ASCII файл, поместив КОНТРОЛЬ-z символ в файле после последнего символа данных. Если файл содержит точное число, кратное 128 символам, и в этом случае добавление CONTROL-Z приведет к потере 127 символов, CP / M этого не сделает. Использование символа CONTROL-Z в качестве маркер конца файла возможно, потому что CONTROL-z редко используется в качестве данных в файлах ASCII. Однако в файле, отличном от ASCII, CONTROL-Z встречается с такой же вероятностью, как и любой другой символ. Следовательно, его нельзя использовать в качестве маркера конца файла. CP / M использует другой метод для обозначения конца файла, отличного от ASCII. CP / M предполагает, что он достиг конца файла, когда он прочитал последнюю запись (базовую единицу дискового пространства), выделенную для файла. Запись каталога диска для каждого файла содержит список дисковых записей, выделенных для этого файла. Этот метод зависит от размера файла, а не его содержимого, чтобы определить местонахождение конца файла. […] [5][6]
  20. ^ BC_Programmer (31.01.2010) [30.01.2010]. «Re: команда копирования, которая объединяет несколько файлов, в конце ставится слово SUB». Компьютерная надежда Forum. В архиве из оригинала на 26.02.2020. Получено 2020-02-26.
  21. ^ «В чем разница между файлами .txt для Linux и Windows (кодировка Unicode)». Суперпользователь. 2011-08-03 [2011-06-08]. В архиве из оригинала на 26.02.2020. Получено 2020-02-26.
  22. ^ а б Гордон, Райан С. (Октябрь 2009 г.). «FatELF: универсальные двоичные файлы для Linux». icculus.org. В архиве из оригинала на 2020-08-27. Получено 2010-07-13.
  23. ^ Гордон, Райан С. (Ноябрь 2009 г.). «Спецификация FatELF, версия 1». icculus.org. В архиве из оригинала на 2020-08-27. Получено 2010-07-25.
  24. ^ Виндиш, Эрик (2009-11-03). "Тема: Группы новостей: gmane.linux.kernel, Re: FatELF патчи ..." gmane.org. Архивировано из оригинал на 2016-11-15. Получено 2010-07-08.
  25. ^ «Образ виртуальной машины Ubuntu 9.04 с поддержкой Fat Binary».
  26. ^ Холверда, Том (2009-11-03). «Райан Гордон останавливает проект FatELF». osnews.com. Получено 2010-07-05.
  27. ^ Брокмайер, Джо (23.06.2010). «СЕБЯ: анатомия (предполагаемой) неудачи». Еженедельные новости Linux. Получено 2011-02-06.
  28. ^ Малдер, Сиджмен Дж. (28 апреля 2020 г.). "sjmulder / fatpack". GitHub.
  29. ^ «Обзор LTO (внутреннее устройство GNU Compiler Collection (GCC))». gcc.gnu.org.
  30. ^ Веннборг VI, Ганс (2018). "Атрибуты в Clang". Документация Clang 7.
  31. ^ «Прозрачное использование пакетов библиотек, оптимизированных для архитектуры Intel». Очистить проект Linux *.

внешняя ссылка