stringtranslate.com

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

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

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

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

Аполлон

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

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

Яблоко

Жирный бинарник Apple

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

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

Бинарные файлы NeXT/Apple с поддержкой нескольких архитектур

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

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

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

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

Mach-O и Mac OS X

Apple Computer приобрела NeXT в 1996 году и продолжила работать с кодом OPENSTEP. Mach-O стал собственным форматом объектных файлов в бесплатной операционной системе Darwin от Apple (2000) и Mac OS X от Apple (2001), а Multi-Architecture Binaries от NeXT продолжали поддерживаться операционной системой. В Mac OS X Multi-Architecture Binaries могут использоваться для поддержки нескольких вариантов архитектуры, например, для оптимизации различных версий 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, используя исполняемые файлы в формате Multi-Architecture Binary. [12] Apple называет такие программы « универсальными приложениями » и называет формат файла « универсальным двоичным », возможно, чтобы отличить этот новый переход от предыдущего перехода или других вариантов использования формата Multi-Architecture Binary.

Универсальный двоичный формат не был необходим для прямой миграции уже существующих собственных приложений PowerPC; с 2006 по 2011 год Apple поставляла Rosetta , динамический двоичный транслятор PowerPC (PPC)-to-x86 , для выполнения этой роли. Однако Rosetta имела довольно высокие накладные расходы на производительность, поэтому разработчикам было предложено предлагать как двоичные файлы PPC, так и Intel, используя универсальные двоичные файлы. Очевидная стоимость универсального двоичного файла заключается в том, что каждый установленный исполняемый файл больше, но за годы, прошедшие с момента выпуска PPC, место на жестком диске значительно превзошло размер исполняемого файла; в то время как универсальный двоичный файл может быть вдвое больше одноплатформенной версии того же приложения, ресурсы свободного пространства обычно затмевают размер кода, что становится незначительной проблемой. Фактически, часто универсальное двоичное приложение будет меньше, чем два одноархитектурных приложения, поскольку программные ресурсы могут использоваться совместно, а не дублироваться. Если требуются не все архитектуры, можно использовать приложения командной строки lipo и 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 Silicon (архитектура ARM64). Чтобы сгладить переход, Apple добавила поддержку двоичного формата Universal 2 ; двоичные файлы Universal 2 представляют собой двоичные файлы Multi-Architecture, содержащие исполняемый код как x86-64, так и ARM64, что позволяет двоичному коду работать изначально как на 64-разрядных процессорах Intel, так и на 64-разрядных процессорах Apple Silicon. Кроме того, Apple представила динамическую двоичную трансляцию Rosetta 2 для набора инструкций x86 в Arm64, чтобы пользователи могли запускать приложения, не имеющие универсальных двоичных вариантов.

Apple Fat EFI двоичный файл

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

CP/M и DOS

Объединенные двоичные файлы в стиле 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 начинаются с последовательности кодов операций EBh, 52h, EBh . [17] [18] 8086 видит это как переход и считывает следующую инструкцию со смещения +154h, тогда как 8080 или совместимый процессор проходит напрямую и считывает следующую инструкцию со смещения +103h. Похожая последовательность, используемая для этой цели, — EBh, 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, тем самым изящно выходя из программы, [nb 2] в то время как он будет декодирован как инструкция "JP 103h" процессорами 8080 и просто перейдет к следующей инструкции в программе. Аналогично, ассемблер 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-совместимых процессоров, которая приводит к корректному выходу, если файл выполняется в старых версиях CP/M-80. [nb 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 не имеют общего расширения файла для исполняемых файлов. [nb 1] Таким образом, обычно невозможно спутать исполняемые файлы. Однако ранние версии DOS имели так много общего с CP/M с точки зрения архитектуры, что некоторые ранние программы DOS были разработаны для совместного использования двоичных файлов, содержащих исполняемый код. Одной из известных программ, которая делала это, была WordStar 3.2x , которая использовала идентичные файлы оверлея в своих портах для CP/M-86 и MS-DOS , [27] и использовала динамически исправленный код для адаптации к различным соглашениям о вызовах этих операционных систем во время выполнения . [27]

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

Объединенные файлы COM и SYS

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

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

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

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

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

В отдаленно похожей манере многие (двоичные) форматы файлов по соглашению включают байт 1Ah ( ASCII ^Z ) около начала файла. Этот управляющий символ будет интерпретироваться как маркер "мягкого" конца файла (EOF), когда файл открывается в недвоичном режиме, и, таким образом, во многих операционных системах (включая монитор PDP-6 [38] и RT-11 , VMS , TOPS-10 , [39] CP/M, [40] [41] DOS, [42] и Windows [43] ), он предотвращает отображение "двоичного мусора" при случайном выводе файла на консоль.

Линукс

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

Логотип FatELF

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

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

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

Окна

Fatpack

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

Arm64X

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

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

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

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

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

Представленная в 2006 году, параллельная вычислительная платформа Nvidia CUDA (Compute Unified Device Architecture) представляет собой программное обеспечение для выполнения вычислений общего назначения на графических процессорах ( GPGPU ). Ее компилятор на основе LLVM NVCC может создавать двоичные файлы fat на основе ELF, содержащие так называемую виртуальную сборку PTX (в виде текста), которую драйвер среды выполнения CUDA может позже скомпилировать just-in-time в некоторый исполняемый двоичный код 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] также поддерживает двоичные файлы fat на основе 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. ^ ab Это не проблема для исполняемых файлов в стиле 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. ^ abc Это работает, потому что (подходящая) инструкция возврата может использоваться для выхода из программ в 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 , а также подфункции API INT 21h для завершения программ (которые предпочтительны для более сложных программ), для программ, транслируемых машиной, DOS также в некоторой степени эмулирует поведение CP/M: программа может завершить себя, перейдя на смещение 0 в своем PSP (эквивалент нулевой страницы CP/M), где система ранее поместила инструкцию INT 20h. Кроме того, начальный стек загруженной программы подготовлен для хранения слова 0, так что программа, выдающая близкий возврат RETN ( код операции 8088/8086 C3h ), также неявно перейдет к началу своего сегмента кода, тем самым в конечном итоге достигнув INT 20h. [a] В CP/M-86 нулевая страница структурирована по- другому , и нет интерфейса CALL 5, но метод возврата стека и функция BDOS 0 (но теперь через INT E0h ) также работают.
  3. ^ На процессорах 8088/8086 код операции C9h является недокументированным псевдонимом для CBh («RETF», извлечение CS:IP из стека ) , тогда как на процессорах 80188/80186 и более новых он декодируется как «LEAVE» (установить SP в BP и извлечь BP) .
  4. ^ ab Эту проблему можно было бы избежать, выбрав неконфликтующие расширения файлов , но после своего появления эти конкретные имена файлов были сохранены из самых ранних версий MS-DOS / PC DOS по соображениям совместимости со сторонними инструментами, жестко запрограммированными на ожидание этих конкретных имен файлов.
  5. ^ ab Другие файлы DOS этого типа — KEYBOARD.SYS , двоичный файл базы данных раскладки клавиатуры для драйвера клавиатуры KEYB под MS-DOS и PC 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 и выше, которые в противном случае предоставляют защищенные от сбоев системные файлы.
  6. ^ Вот почему для этих файлов установлен атрибут «скрытый» , чтобы они не отображались по умолчанию, тем самым снижая риск случайного вызова.
  7. ^ Форматы COUNTRY.SYSфайлов, поддерживаемые семействами операционных систем MS-DOS / PC DOS и DR-DOS, содержат похожие данные, но организованы по-разному и несовместимы. Поскольку точки входа в структуры данных находятся в разных смещениях в файле, можно создавать «толстые» COUNTRY.SYSбазы данных, которые можно использовать в обоих семействах DOS. [b] Однако DR-DOS 7.02 и его NLSFUNC 4.00 (и выше) включают улучшенный парсер, способный читать оба типа форматов (и варианты), даже одновременно, так что файлы с заголовком Janus не нужны. [c] [d] Тем не менее, поставляемые файлы являются «толстыми», поскольку включают крошечную исполняемую заглушку, которая просто отображает встроенное сообщение при неправильном вызове. [d] [b]

Ссылки

  1. ^ Devanbu, Premkumar T.; Fong, Philip WL; Stubblebine, Stuart G. (19–25 апреля 1998 г.). "3.3 Java и TH" (PDF) . Методы надежной разработки программного обеспечения . Труды 20-й Международной конференции по разработке программного обеспечения. Труды - Международная конференция по разработке программного обеспечения . Киото, Япония. стр. 131. doi :10.1109/ICSE.1998.671109. ISBN 0-8186-8368-6. ISSN  0270-5257. Архивировано (PDF) из оригинала 2014-01-16 . Получено 2021-09-29 .(10 страниц)
  2. ^ Перо, Никола (18.12.2008). "gnustep/tools-make: README.Packaging". GitHub . Архивировано из оригинала 25.05.2022 . Получено 26.05.2022 .
  3. ^ "PackagingDrafts/GNUstep". Fedora Project Wiki . 2009-02-25. Архивировано из оригинала 2022-05-25 . Получено 2022-05-26 .
  4. ^ "Domain System Software Release Notes, Software Release 10.1" (PDF) (первое печатное издание). Челмсфорд, Массачусетс, США: Apollo Computer Inc. Декабрь 1988 г. стр. 2-16. Заказ № 005809-A03. Архивировано (PDF) из оригинала 2023-05-26 . Получено 2022-07-24 .(256 страниц)
  5. ^ ab Engst, Adam C. (1994-08-22). "Should Fat Binaries Diet?". TidBITS . № 240. TidBITS Publishing Inc. ISSN  1090-7017. Архивировано из оригинала 29-09-2021 . Получено 29-09-2021 .
  6. ^ ab Engst, Adam C. (1994-08-29). "Fat Binary Comments". TidBITS . № 241. TidBITS Publishing Inc. ISSN  1090-7017. Архивировано из оригинала 29-09-2021 . Получено 29-09-2021 .
  7. ^ "Глава 1 - Менеджер ресурсов / Справочник по менеджеру ресурсов - Формат файла ресурсов". Внутри Macintosh: Архитектуры среды выполнения Mac OS . Apple Computer . 1996-07-06. Архивировано из оригинала 29-09-2021 . Получено 29-09-2021 .
  8. ^ "Глава 7 - Двоичные программы Fat - Создание бинарных программ Fat". Внутри Macintosh: Архитектуры среды выполнения Mac OS . Apple Computer . 1997-03-11. Архивировано из оригинала 2021-09-29 . Получено 2011-06-20 .[1]
  9. ^ "Глава 8 - Структура PEF". Внутри Macintosh: Архитектуры среды выполнения Mac OS . Apple Computer . 1997-03-11. Архивировано из оригинала 2021-09-29 . Получено 2021-09-29 .
  10. ^ Tevanian, Avadis; DeMoney, Michael; Enderby, Kevin; Wiebe, Douglas; Snyder, Garth (11.07.1995) [20.08.1993]. "Метод и аппарат для архитектурно-независимых исполняемых файлов" (PDF) . Редвуд-Сити, Калифорния, США: NeXT Computer, Inc. Патент США 5432937A. Архивировано (PDF) из оригинала 14.12.2020 . Получено 26.05.2022 .[2] (9 страниц); Теванян, Авадис; ДеМани, Майкл; Эндерби, Кевин; Вибе, Дуглас; Снайдер, Гарт (18.02.1997) [28.02.1995]. "Метод и аппарат для архитектурно-независимых исполняемых файлов" (PDF) . Редвуд-Сити, Калифорния, США: NeXT Computer, Inc. Патент США 5604905A. Архивировано (PDF) из оригинала 26.05.2022 . Получено 26.05.2022 .(9 страниц)
  11. ^ "Универсальные двоичные файлы и двоичные файлы PowerPC 32-bit/64-bit". Справочник по формату файлов Mac OS X ABI Mach-O . Apple Inc. 2009-02-04 [2003]. Архивировано из оригинала 2012-04-27.
  12. ^ Сингх, Амит (2006-06-19). "2.6.2 Fat Binaries". Внутреннее устройство Mac OS X - Системный подход . Pearson Education . стр. 66. ISBN 978-0-13270226-3. Получено 28.09.2021 .
  13. ^ "rEFIt - EFI Fat Binaries". refit.sourceforge.net . Получено 2022-10-18 .
  14. ^ Пол, Маттиас Р. (2002-10-07) [2000]. "Re: Запуск COM-файла". Группа новостей : alt.msdos.programmer. Архивировано из оригинала 2017-09-03 . Получено 2017-09-03 .[3] (Примечание. Содержит подробную информацию о соглашениях о вызовах программ DOS COM.)
  15. ^ abc Wilkinson, William "Bill" Albert (2005-04-02) [2003, 1999-02-16, Февраль 1987, 1986-11-15, 1986-11-10]. Написано в Heath Company, США. "Something COMmon About MS-DOS and CP/M". REMark . Том 8, № 2. Сент-Джозеф, Мичиган, США: Heath/Zenith Users' Group (HUG). стр. 55–57. № 85. P/N 885-2085. Архивировано из оригинала 2021-12-13.[4]
  16. ^ abc Cha, Sang Kil; Pak, Brian; Brumley, David ; Lipton, Richard Jay (2010-10-08) [2010-10-04]. Платформонезависимые программы (PDF) . Труды 17-й конференции ACM по компьютерной и коммуникационной безопасности (CCS'10). Чикаго, Иллинойс, США: Университет Карнеги-Меллона , Питтсбург, Пенсильвания, США / Технологический институт Джорджии , Атланта, Джорджия, США. стр. 547–558. doi :10.1145/1866307.1866369. ISBN 978-1-4503-0244-9. Архивировано (PDF) из оригинала 2022-05-26 . Получено 2022-05-26 .[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 или 90h, EBh, 20h, 2Ah, 90h, EBh, 20h, 3Ah, 24h, 77h, 01h, 04h .)
  17. ^ abcdef Уилкинсон, Уильям "Билл" Альберт; Селигман, Кори; Друшель, Ричард Ф.; Харстон, Джонатан Грэм; Эллиотт, Джон К. (1999-02-17). "MS-DOS & CP/M-Compatible Binaries". Группа новостей : comp.os.cpm. Архивировано из оригинала 2021-12-13 . Получено 2021-12-13 .(Примечание. Некоторые коды операций в примере кода Эллиотта ( EBh, 44h, EBh и EBh, 04h, ... ) могут быть перепутаны.)
  18. ^ ab Elliott, John C. (2009-10-27). "CP/M info program". Группа новостей : comp.os.cpm. Архивировано из оригинала 2021-12-13 . Получено 2021-12-13 . […] Функция защиты 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 (2012-11-14) [2012-11-13]. Чен, Рэймонд (ред.). «Microsoft Money аварийно завершает работу во время импорта транзакций по счету или при изменении получателя загруженной транзакции». The New Old Thing . Архивировано из оригинала 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 […](Примечание. Хотя автор говорит о Z80, эта последовательность также работает на 8080 и совместимых процессорах.)
  20. ^ Brehm, Andrew J. (2016). "CP/M and MS-DOS Fat Binary". DesertPenguin.org . Архивировано из оригинала 2018-05-19 . Получено 2018-05-19 .(Примечание. Хотя в статье говорится о Z80 , кодовая последовательность также работает на 8080 и совместимых процессорах.)
  21. ^ Эллиотт, Джон К. (1996-06-13). "Загрузить на micros.hensa.ac.uk". Группа новостей : comp.os.cpm. Архивировано из оригинала 2021-12-13 . Получено 2021-12-13 . […] FATBIN 1.00 — объединяет файл CP/M .COM и файл DOS .COM для создания одного, работающего на обеих платформах. […] Он использовался для создания: […] MSODBALL 2.05 — преобразует дискеты между форматом Amstrad 706k и форматом DOS 706k. […] Обе программы работают под управлением CP/M-80 и DOS. […]
  22. ^ Эллиотт, Джон К. (1998-06-28) [1997-04-01]. "FATBIN v1.01". Архивировано из оригинала 1998-06-28.(Примечание. FATBN101.COM 22k 1997-04-01 FATBIN v1.01. Создает двоичные файлы fat, которые будут работать как под CP/M, так и под DOS. Распространяется в самораспаковывающемся архиве для CP/M-80 и DOS.)
  23. ^ Эллиотт, Джон К. (11.03.2002). "DSKWRITE v1.00". Fossies - the Fresh Open Source Software Archive . Архивировано из оригинала 12.12.2021 . Получено 12.12.2021 . […] DSKWRITE.Z80 содержит исходный код для версии CP/M . […] DSKWRITE.ASM содержит исходный код для версии DOS . […] Чтобы получить один файл .COM , вам нужно использовать FBMAKE: […][7] (Примечание. Упоминается FBMAKE из пакета FATBNSEA.COM.)
  24. ^ ab Elliott, John C. (2012-06-20) [2005-01-05]. "Generic CP/M". Seasip.info . Архивировано из оригинала 2021-11-17 . Получено 2021-12-12 . […] Самораспаковывающиеся архивы — это файлы .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 Canvas в файл Windows .BMP […][8]
  25. ^ Эллиотт, Джон К. (1997-01-18) [1997-01-11]. "PMSFX 2". Группа новостей : comp.os.cpm. Архивировано из оригинала 2021-12-13 . Получено 2021-12-13 . […] Я написал версию PMSFX , которая создает файлы .COM , распаковываемые под DOS и CP/M (первые три байта являются как допустимым кодом Z80 , так и допустимым кодом 8086 и допустимым заголовком PMA ) […] в виде самораспаковывающегося архива . […]
  26. ^ Эллиотт, Джон К.; Лопушински, Джим (2002) [11.04.1998]. "Заголовок файла CP/M 3 COM". Seasip.info . Архивировано из оригинала 30.08.2016 . Получено 29.08.2016 .
  27. ^ ab Necasek, Michal (2018-01-30) [2018-01-28, 2018-01-26]. "WordStar Again". Музей OS/2 . Архивировано из оригинала 2019-07-28 . Получено 2019-07-28 . […] Причина подозревать такую ​​разницу в том, что версия 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 Screen Shots". Toastytech.com . Архивировано из оригинала 2020-01-15 . Получено 2020-01-15 .
  29. ^ abc Paul, Matthias R. (2002-04-11). "Re: [fd-dev] ОБЪЯВЛЕНИЕ: CuteMouse 2.0 alpha 1". freedos-dev . Архивировано из оригинала 2020-02-21 . Получено 2020-02-21 . […] FreeKEYB — это […] настоящий драйвер .COM и .SYS (крошечная модель) в одном. Вы можете безопасно перезаписать первый JMP, это часть того, что я имел в виду под «хитрым заголовком». […] вы можете заменить FFFFh:FFFFh на 3-байтовый переход и ожидающий DB FFh. Он работает с MS-DOS, PC DOS, DR-DOS и, скорее всего, с любой другой проблемой DOS. […]
  30. ^ abc Paul, Matthias R. (2002-04-06). "Re: [fd-dev] ОБЪЯВЛЕНИЕ: CuteMouse 2.0 alpha 1". freedos-dev . Архивировано из оригинала 2020-02-07 . Получено 2020-02-07 . […] Добавьте заголовок драйвера устройства SYS в драйвер, чтобы CTMOUSE мог быть как в одной, обычной TSR , так и в драйвере устройства - аналогично нашему расширенному драйверу клавиатуры FreeKEYB. […] Это на самом деле не нужно в DR DOS , поскольку INSTALL = поддерживается с DR DOS 3.41+, а DR DOS сохраняет порядок директив [D]CONFIG.SYS […] но это […] улучшит […] гибкость в системах MS-DOS / PC DOS , которые […] всегда выполняют директивы DEVICE = перед любыми операторами INSTALL=, независимо от их порядка в файле. […] программное обеспечение может потребовать, чтобы драйвер мыши присутствовал в качестве драйвера устройства, поскольку драйверы мыши всегда были драйверами устройств в старые времена. Эти драйверы мыши имели определенные имена драйверов устройств в зависимости от используемого ими протокола (« PC$MOUSE » для режима систем мыши , например), и некоторое программное обеспечение может искать эти драйверы, чтобы узнать правильный тип используемой мыши. […] Другим преимуществом было бы то, что драйверы устройств обычно потребляют меньше памяти (нет среды , нет PSP ) […] Это в основном сложный заголовок файла, другой код для разбора командной строки, другая точка входа и строка выхода, и некоторая магия сегментов для преодоления разницы ORG 0 / ORG 100h. Самостоятельная загрузка драйвера устройства немного сложнее, поскольку вам нужно оставить заголовок драйвера там, где он есть, и только переместить остальную часть драйвера […]
  31. ^ abcd Пол, Маттиас Р. (2001-06-10) [1995]. "Формат файла DOS COUNTRY.SYS" (файл COUNTRY.LST) (ред. 1.44). Архивировано из оригинала 2016-04-20 . Получено 2016-08-20 .
  32. ^ abc Пол, Матиас Р. (30 июля 1997 г.) [1 мая 1994 г.]. «Глава II.4. Undocumentierte Eigenschaften externer Kommandos - SYS.COM». NWDOS-TIPs — советы и подсказки для Novell DOS 7, с просмотром недокументированных подробностей, ошибок и обходных путей. MPDOSTIP (на немецком языке) (3-е изд.). Архивировано из оригинала 10 сентября 2017 г. Проверено 6 августа 2014 г. Для обновления для Calderas OpenDOS 7.01 я должен использовать стартовый код на IBMBIO.COM , чтобы его модифицировать, поэтому он становится нестандартным для нормальной программы. Если эта функция Sicherheitsfunktion в официальной версии Einzug Halten Wird, ist jedoch noch nicht abzusehen.(Примечание. NWDOSTIP.TXT — это комплексная работа по Novell DOS 7 и OpenDOS 7.01, включающая описание многих недокументированных функций и внутренних компонентов. Она является частью еще более обширной MPDOSTIP.ZIPколлекции автора, которая поддерживалась до 2001 года и распространялась на многих сайтах в то время. Приведенная ссылка указывает на более старую версию файла, преобразованную в HTML NWDOSTIP.TXT.) [9]
  33. ^ Пол, Маттиас Р. (1997-10-02). "Caldera OpenDOS 7.01/7.02 Update Alpha 3 IBMBIO.COM README.TXT". Архивировано из оригинала 2003-10-04 . Получено 2009-03-29 .[10]
  34. ^ DR-DOS 7.03 WHATSNEW.TXT — Изменения с DR-DOS 7.02 на DR-DOS 7.03. Кальдера, Инк . 24 декабря 1998 г. Архивировано из оригинала 8 апреля 2019 г. Проверено 08 апреля 2019 г.
  35. ^ ab Sage, Jay (май–июнь 1988 г.). Carlson, Art (ред.). "ZCPR 3.4 - Программы типа 4". The Computer Journal (TCJ) - Программирование, Поддержка пользователей, Приложения . ZCPR3 Corner (32). Columbia Falls, Montana, USA: 10–17 [16]. ISSN  0748-9331. ark:/13960/t1wd4v943 . Получено 29.11.2021 .[11][12]
  36. ^ ab Sage, Jay (май–июнь 1992 г.) [март–июнь 1992 г.]. Carlson, Art; McEwen, Chris (ред.). "Программы Type-3 и Type-4". The Computer Journal (TCJ) - Программирование, Поддержка пользователей, Приложения . Z-System Corner - Некоторые новые приложения программ Type-4 (55). S. Plainfield, New Jersey, USA: Socrates Press: 13–19 [14, 16]. ISSN  0748-9331. ark:/13960/t4dn54d22 . Получено 29.11.2021 .[13][14]
  37. ^ ab Sage, Jay (ноябрь–декабрь 1992 г.). Carlson, Art; Kibler, Bill D. (ред.). "Regular Feature, ZCPR Support, Language Independence, часть 2". The Computer Journal (TCJ) - Programming, User Support, Applications . The Z-System Corner (58). Lincoln, CA, USA: 7–10. ISSN  0748-9331. ark:/13960/t70v9g87h . Получено 09.02.2020 . […] был код операции "RST 0", выполнение которого привело бы к горячей загрузке . Файл, содержащий модуль Z3TXT, никогда не должен выполняться, но за один байт мы могли бы защитить себя от этой внешней случайности. Заголовок также содержал строку символов "Z3TXT", за которой следовал нулевой (0) байт. Многие модули Z-System включают такие идентификаторы. В эту категорию входят резидентные пакеты команд (RCP), пакеты потоковых команд (FCP) и модули дескрипторов среды ( Z3ENV ). Программы, такие как […] JETLDR.COM Бриджера Митчелла, которые загружают эти модули из файлов в память, могут использовать строку идентификатора для проверки файла, то есть для того, чтобы убедиться, что это тот тип модуля, который указал пользователь. Таким образом, можно обнаружить ошибки пользователя и поврежденные файлы. […] Таким образом, заголовок теперь выглядит следующим образом: […] rst […] db 'Z3TXT',0 ; идентификатор с завершающим нулем […] ; 12345678 ; должно быть 8 символов, […] db 'PROGNAME' ; дополнить пробелами […] ; 123 ; должно быть 3 символа […] db 'ENG' ; название языка […] dw LENGTH ; длина модуля […][15][16]
  38. ^ "Таблица характеристик устройств ввода-вывода — консоли или телетайпы". Руководство по многопрограммной системе PDP-6 (PDF) . Мейнард, Массачусетс, США: Digital Equipment Corporation (DEC). 1965. стр. 43. DEC-6-0-EX-SYS-UM-IP-PRE00. Архивировано (PDF) из оригинала 2014-07-14 . Получено 2014-07-10 .(1+84+10 страниц)
  39. ^ "5.1.1.1. Зависящие от устройства функции - Режимы данных - Полнодуплексное программное обеспечение A(ASCII) и AL(ASCII Line)". Справочник PDP-10: Связь с монитором - Мониторы с разделением времени (PDF) . Том 3. Digital Equipment Corporation (DEC). 1969. стр. 5-3–5-6 [5-5 (431)]. Архивировано (PDF) из оригинала 2011-11-15 . Получено 2014-07-10 .(207 страниц)
  40. ^ "2. Соглашения о вызовах операционной системы". Руководство по интерфейсу CP/M 2.0 (PDF) (1-е изд.). Pacific Grove, Калифорния, США: Digital Research . 1979. стр. 5. Архивировано (PDF) из оригинала 2020-02-28 . Получено 2020-02-28 . […] Конец файла ASCII обозначается символом control-Z (1AH) или реальным концом файла, возвращаемым операцией чтения CP/M . Однако символы Control-Z, встроенные в файлы машинного кода (например, файлы COM ), игнорируются, а условие конца файла, возвращаемое CP/M, используется для завершения операций чтения. […](56 страниц)
  41. ^ Hogan, Thom (1982). "3. CP/M Transient Commands". Osborne CP/M User Guide - For All CP/M Users (2-е изд.). Беркли, Калифорния, США: A. Osborne/McGraw-Hill . стр. 74. ISBN 0-931988-82-9. Получено 28.02.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 (2010-01-31) [2010-01-30]. "Re: Команда копирования, которая объединяет несколько файлов, добавляет в конце слово SUB". Форум Computer Hope . Архивировано из оригинала 2020-02-26 . Получено 2020-02-26 .
  43. ^ "В чем разница между файлами .txt Linux и Windows (кодировка Unicode)". Superuser . 2011-08-03 [2011-06-08]. Архивировано из оригинала 2020-02-26 . Получено 2020-02-26 .
  44. ^ ab Gordon, Ryan C. (октябрь 2009 г.). "FatELF: Universal Binaries for Linux". icculus.org . Архивировано из оригинала 2020-08-27 . Получено 2010-07-13 .
  45. ^ Гордон, Райан С. (ноябрь 2009 г.). "Спецификация FatELF, версия 1". icculus.org . Архивировано из оригинала 2020-08-27 . Получено 2010-07-25 .
  46. ^ Windisch, Eric (2009-11-03). "Тема: Группы новостей: gmane.linux.kernel, Re: FatELF patches..." gmane.org. Архивировано из оригинала 2016-11-15 . Получено 2010-07-08 .
  47. ^ Гордон, Райан С. (2009). "FatELF: Универсальные двоичные файлы для Linux. - Страница загрузки виртуальной машины для проверки концепции". icculus.org . Архивировано из оригинала 21.05.2022 . Получено 26.05.2022 .(Примечание. Образ виртуальной машины Ubuntu 9.04 с поддержкой Fat Binary.)
  48. ^ Холверда, Том (2009-11-05). "Райан Гордон останавливает проект FatELF". Linux. osnews.com. Архивировано из оригинала 2022-05-26 . Получено 2010-07-05 .
  49. ^ Брокмейер, Джо "Зонкер" (2010-06-23). ​​"SELF: Анатомия (предполагаемой) неудачи". LWN.net . Linux Weekly News. Архивировано из оригинала 2022-05-26 . Получено 2011-02-06 .
  50. ^ Малдер, Сиджмен Дж. (2021-03-06) [2018-04-25]. "sjmulder/fatpack - Сборка многоархитектурных 'fat' двоичных файлов для Windows". GitHub . Архивировано из оригинала 2022-05-26 . Получено 2022-05-26 .
  51. ^ "Arm64X PE files". learn.microsoft.com . Microsoft . 2022-08-13. Архивировано из оригинала 2023-08-20 . Получено 2023-03-31 .
  52. ^ "Сборка двоичных файлов Arm64X". learn.microsoft.com . Microsoft . 2023-03-10. Архивировано из оригинала 2023-08-20 . Получено 2023-03-31 .
  53. ^ Ван, Перри Х.; Коллинз, Джеймисон Д.; Чинья, Гаутам Н.; Цзян, Хун; Тянь, Синьминь; Гиркар, Милинд; Ян, Ник Й.; Люэ, Гуэй-Юань; Ван, Хун (июнь 2007 г.). «EXOCHI: архитектура и среда программирования для гетерогенной многоядерной многопоточной системы». ACM SIGPLAN Notices . 42 (6): 156–166. doi :10.1145/1273442.1250753.(11 страниц)
  54. ^ Ван, Перри Х.; Коллинз, Джеймисон Д.; Чинья, Гаутам Н.; Цзян, Хун; Тянь, Синьминь; Гиркар, Милинд; Пирс, Лиза; Люэ, Гуэй-Юань; Якушкин, Сергей; Ван, Хун (2007-08-22). "Accelerator Exoskeleton" (PDF) . Intel Technology Journal . 11: Tera-scale Computing (3). Intel Corporation : 185–196. doi :10.1535/itj.1103. ISSN  1535-864X. Архивировано (PDF) из оригинала 2022-05-26 . Получено 2022-05-26 .(12 из 1+vii+90+1 страниц)
  55. ^ "cudaFatFormat.h / ptxomp.c". 1.13. Nvidia Corporation . 2004-11-15. Архивировано из оригинала 2022-05-26 . Получено 2022-05-26 .
  56. ^ Харрис, Марк Дж. (2014-05-08) [2013-06-05]. "Техническое пошаговое руководство: CUDA Pro Tip: Understanding Fat Binaries and JIT Caching". Разработчик Nvidia . Nvidia . Архивировано из оригинала 2022-03-23 ​​. Получено 2022-05-26 .
  57. ^ "CUDA Binary Utilities" (PDF) (Application Note). 6.0. Nvidia . Февраль 2014. DA-06762-001_v6.0. Архивировано (PDF) из оригинала 2022-05-25 . Получено 2022-05-25 .
  58. ^ "fatbinary - help". helpmanual.io . 8.0. 2016. Архивировано из оригинала 2022-05-25 . Получено 2022-05-25 .
  59. ^ "CUDA Compiler Driver NVCC - Reference Guide" (PDF) . 11.7. Nvidia . Май 2022. TRM-06721-001_v11.7. Архивировано (PDF) из оригинала 2022-05-25 . Получено 2022-05-25 .
  60. ^ Браун, Лоренц; Фрёнинг, Хольгер (2019-11-18). CUDA Flux: облегченный профилировщик инструкций для приложений CUDA (PDF) . IEEE/ACM Performance Modeling, Benchmarking and Simulation of High Performance Computer Systems (PMBS). Денвер, Колорадо, США: IEEE . doi :10.1109/PMBS49563.2019.00014. ISBN 978-1-7281-5977-5. Архивировано (PDF) из оригинала 2022-03-21 . Получено 2022-05-26 .
  61. ^ Fung, Wilson WL; Sham, Ivan; Yuan, George; Aamodt, Tor M. (2007). "Dynamic Warp Formation and Scheduling for Efficient GPU Control Flow" (PDF) . Ванкувер, Британская Колумбия, Канада. Архивировано (PDF) из оригинала 2022-05-26 . Получено 2022-05-26 .(12 страниц)
  62. ^ Бахода, Али; Юань, Джордж Л.; Фунг, Уилсон В. Л.; Вонг, Генри; Амодт, Тор М. (2009-04-28) [2009-04-26]. Анализ рабочих нагрузок CUDA с использованием подробного симулятора GPU (PDF) . Труды Международного симпозиума IEEE по анализу производительности систем и программного обеспечения (ISPASS). Бостон, Массачусетс, США. стр. 163–174. doi :10.1109/ISPASS.2009.4919648. Архивировано (PDF) из оригинала 2022-05-26 . Получено 2022-05-06 .[19]
  63. ^ ab "13.4 AMD Compiler Wrapper: Fat binaries". The Multi2Sim Simulation Framework - A CPU-GPU Model for Heterogeneous Computing (PDF) . v4.2. Multi2Sim. 2013. стр. 173–176 [176]. Архивировано (PDF) из оригинала 2022-05-25 . Получено 2022-05-25 .(4 из 210 страниц)
  64. ^ Ubal, Rafael; Jang, Byunghyun; Mistry, Perhaad; Schaa, Dana; Kaeli, David R. (2012-09-23) [2012-09-19]. "Multi2Sim: фреймворк моделирования для вычислений CPU-GPU" (PDF) . 21-я международная конференция по параллельным архитектурам и методам компиляции (PACT) . Миннеаполис, Миннесота, США: IEEE . ISBN 978-1-4503-1182-3. Архивировано (PDF) из оригинала 2022-05-25 . Получено 2022-05-25 .(10 страниц)
  65. ^ "Обзор LTO (GNU Compiler Collection (GCC) Internals)". gcc.gnu.org . Архивировано из оригинала 2021-09-12 . Получено 2021-09-12 .
  66. ^ Wennborg, Hans (2018). "Атрибуты в Clang". Документация Clang 7. Архивировано из оригинала 2022-04-07 . Получено 2022-05-26 .
  67. ^ Бахена, Виктор Родригес (2018-04-03). "Прозрачное использование библиотечных пакетов, оптимизированных для архитектуры Intel". Мощность и производительность. Clear Linux Project . Intel Corporation . Архивировано из оригинала 2022-05-26 . Получено 2022-05-26 .
  68. ^ Пол, Маттиас Р.; Фринк, Аксель К. (1997-10-13) [1991], FreeKEYB - Расширенный драйвер клавиатуры и консоли DOS (Руководство пользователя) (редакция v6.5)[20] (Примечание. FreeKEYB — это динамически настраиваемый преемник K3PLUS на основе Unicode , поддерживающий большинство раскладок клавиатуры , кодовых страниц и кодов стран . Используя готовый макроассемблер , а также структуру инструментов анализа автоматической предварительной и последующей обработки для генерации метаданных о зависимости и морфинге кода , которые будут внедрены в исполняемый файл вместе с двоичным кодом и самоотбрасывающимся, релаксирующим и перемещающимся загрузчиком , драйвер реализует методы гранулярного динамического устранения и перемещения мертвого кода на уровне байтов во время загрузки, а также самомодифицирующийся код и реконфигурируемость во время выполнения для минимизации занимаемой памяти, чтобы закрыть каноническую форму в зависимости от базового оборудования, операционной системы и конфигурации драйвера, а также выбранного набора функций и локали (около шестидесяти переключателей конфигурации с сотнями опций для почти неограниченного числа возможных комбинаций). Эта сложность и динамика скрыты от пользователей, которые имеют дело с одним исполняемым файлом так же, как они делали бы с обычным драйвером.)
  69. ^ Пол, Маттиас Р. (2002-04-06). "[fd-dev] Ctrl+Alt+Del". freedos-dev . Архивировано из оригинала 2019-04-27 . Получено 2019-04-27 . […] FreeKEYB создает образ среды выполнения драйвера во время инициализации в зависимости от типа машины, на которую он загружается, типа клавиатуры, раскладки, страны и используемой кодовой страницы, типа установленного(ых) адаптера(ов) мыши и видео, других загруженных в эту систему драйверов, операционной системы и используемых методов загрузки и перемещения, включенных отдельных функций и параметров конфигурации, указанных в командной строке. Из-за большого количества поддерживаемых ключей и параметров командной строки […] (около пятидесяти ключей […] с несколькими возможными настройками) существует большое количество комбинаций функций с неисчислимыми зависимостями […], что приводит к […] бесконечному количеству […] различных целевых образов. Методика устранения динамического мертвого кода FreeKEYB позволяет разрешить […] эти […] зависимости и […] удалить мертвый код и данные […] не ограничивается […] включением или исключением ограниченного числа модулей или целых подпрограмм и исправлением некоторых таблиц диспетчеризации, как в классическом программировании TSR, но […] работает […] на […] уровне байтов […] способна удалять […] отдельные инструкции в середине более крупных подпрограмм […] распределенных по всему коду для обработки конкретного случая или поддержки определенной функции […] специальные инструменты используются для анализа кода […] и создания […] таблиц исправлений […] автоматизированных […] с использованием условных определений […] для объявления различных случаев […] не только необязательными во время сборки, но и во время инициализации […] без […] накладных расходов, связанных с наличием хотя бы некоторого количества мертвого кода в образе среды выполнения […] для отслеживания всех зависимостей между […] этими условными операторами, динамически создавать и перемещать образ среды выполнения, исправлять все ссылки между этими небольшими, изменяющимися и движущимися двоичными частями […] по-прежнему позволяя использовать крошечную модель стиля .COM/.SYS […] выполняется во время инициализации […]
  70. ^ Пол, Маттиас Р. (2001-08-21). "[fd-dev] Изменение кодовых страниц в FreeDOS". freedos-dev . Архивировано из оригинала 2019-04-19 . Получено 2019-04-20 . […] […] уникальная функция […] мы называем динамическим устранением мертвого кода , поэтому вы можете во время установки […] указать, какие компоненты драйвера вам нужны, а какие нет. Это доходит до динамической загружаемой модуляризации и позднего связывания, которые я пока не видел в DOS. Если вам не нравится заставка, макросы, калькулятор или поддержка мыши, или <почти что-либо еще>, вы можете указать это в командной строке, и FreeKEYB, принимая во внимание все зависимости между процедурами, полностью удалит все фрагменты кода, которые имеют дело с этой функцией и не являются необходимыми для предоставления запрошенной функциональности, прежде чем драйвер переместит изображение в целевое местоположение и сделает себя резидентным. […]
  71. ^ Пол, Матиас Р. (10 апреля 2001 г.). «[ANN] Выпущена бета-версия 6 FreeDOS» (на немецком языке). Группа новостей : de.comp.os.msdos. Архивировано из оригинала 9 сентября 2017 г. Проверено 2 июля 2017 г. […] Brandneue[s] Feature, der dynamischen Dead-Code-Elimination , die die die jeweils notwendigen Bestandteile des Treibers erst zum Installationszeitpunkt zusammenbastelt und reloziert, so daß keine ungenutzten Code- или Datenbereiche mehr sid bleiben (zB wenn jemand ein bestimmtes FreeKEYB- Функция nicht benötigt). […]

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