Portable Executable

редактировать
Формат файла
Portable Executable
Расширение имени файла .acm, .ax, .cpl, .dll, .drv, .efi, .exe, .mui, .ocx, .scr, .sys, .tsp
Тип интернет-носителя приложение / vnd.microsoft.portable-executable
РазработаноВ настоящее время: Microsoft
Тип форматаДвоичный, исполняемый файл, объект, разделяемые библиотеки
Расширен изисполняемого файла DOS MZ. COFF

Формат Portable Executable (PE) - это формат файла для исполняемых файлов, объектного кода, DLL и других, используемых в 32-битных и 64-битных версиях операционных систем Windows . Формат PE - это структура данных, которая инкапсулирует информацию, необходимую загрузчику ОС Windows для управления обернутым исполняемым кодом . Сюда входят ссылки на динамические библиотеки для связывания таблиц экспорта и импорта, API, данных управления ресурсами и данных локального хранилища потока (TLS). В операционных системах NT формат PE используется для EXE, DLL, SYS (драйвер устройства ), и другие типы файлов. В спецификации Extensible Firmware Interface (EFI) указано, что PE является стандартным исполняемым форматом в средах EFI.

В операционных системах Windows NT PE в настоящее время поддерживает x86, IA-32, x86-64 (AMD64 / Intel 64), IA-64, ARM и ARM64 архитектуры набора команд (ISA). До Windows 2000 Windows NT (и, следовательно, PE) поддерживала ISA MIPS, Alpha и PowerPC. Поскольку PE используется в Windows CE, он продолжает поддерживать несколько вариантов MIPS, ARM (включая Thumb ) и SuperH Как есть.

Форматы, аналогичные PE: ELF (используется в Linux и большинстве других версий Unix ) и Mach-O (используется в macOS и iOS ).

Содержание

  • 1 История
  • 2 Технические детали
    • 2.1 Схема
    • 2.2 Таблица импорта
    • 2.3 Перемещения
  • 3.NET, метаданные и формат PE
  • 4 Использование в другие операционные системы
  • 5 См. также
  • 6 Ссылки
  • 7 Внешние ссылки

История

Microsoft перешла на формат PE из 16-битных форматов NE с введение операционной системы Windows NT 3.1. Все более поздние версии Windows, включая Windows 95/98 / ME и Win32s в дополнение к Windows 3.1x, поддерживают файловую структуру. Формат сохранил ограниченную унаследованную поддержку для преодоления разрыва между системами на базе DOS и NT. Например, заголовки PE / COFF по-прежнему включают исполняемую программу DOS, которая по умолчанию является заглушкой DOS, которая отображает сообщение типа «Эта программа не может быть запущена в режиме DOS» (или аналогично), хотя это может быть полноценная версия программы для DOS (более поздний известный случай - установщик Windows 98 SE). Это представляет собой форму двоичного файла. PE также продолжает обслуживать меняющуюся платформу Windows. Некоторые расширения включают формат.NET PE (см. Ниже), 64-разрядную версию PE32 + (иногда PE +) и спецификацию для Windows CE.

Технические детали

Макет

Структура переносимого 32-битного исполняемого файла

PE-файл состоит из нескольких заголовков и разделов, которые сообщают динамическому компоновщику как отобразить файл в память. Исполняемый образ состоит из нескольких различных областей, каждая из которых требует разной защиты памяти; поэтому начало каждого раздела должно быть выровнено по границе страницы. Например, обычно секция.text (которая содержит программный код) отображается как выполнение / только для чтения, а секция.data (содержащая глобальные переменные) отображается как без выполнения / чтения-записи. Однако, чтобы не тратить лишнее место, разные разделы на диске не выравниваются по страницам. Часть работы динамического компоновщика состоит в том, чтобы сопоставить каждый раздел с памятью индивидуально и назначить правильные разрешения для результирующих областей в соответствии с инструкциями в заголовках.

Импортировать таблицу

Один Следует отметить таблицу адресов импорта (IAT), которая используется в качестве таблицы поиска, когда приложение вызывает функцию в другом модуле. Это может быть как импорт по порядковому номеру, так и импорт по имени. Поскольку скомпилированная программа не может знать расположение в памяти библиотек, от которых она зависит, при каждом вызове API требуется косвенный переход. Когда динамический компоновщик загружает модули и объединяет их вместе, он записывает фактические адреса в слоты IAT, так что они указывают на ячейки памяти соответствующих библиотечных функций. Хотя это добавляет дополнительный скачок к стоимости внутримодульного вызова, что приводит к снижению производительности, это дает ключевое преимущество: количество страниц памяти, которые необходимо копировать при записи, изменяет загрузчик минимизирован, экономя память и время ввода-вывода на диск. Если компилятор заранее знает, что вызов будет межмодульным (через атрибут dllimport), он может создать более оптимизированный код, который просто приведет к косвенному вызову opcode.

Relocations

PE files обычно не содержат позиционно-независимый код. Вместо этого они компилируются в предпочтительный базовый адрес, и все адреса, выдаваемые компилятором / компоновщиком, фиксируются заранее. Если PE-файл не может быть загружен по предпочтительному адресу (потому что он уже занят чем-то другим), операционная система перебазирует его. Это включает в себя пересчет каждого абсолютного адреса и изменение кода для использования новых значений. Загрузчик делает это, сравнивая предпочтительный и фактический адреса загрузки и вычисляя значение дельта. Затем он добавляется к предпочтительному адресу, чтобы получить новый адрес ячейки памяти. Базовые перемещения сохраняются в списке и добавляются, если необходимо, в существующую ячейку памяти. Результирующий код теперь является частным для процесса и больше не совместно используемым, поэтому в этом сценарии теряются многие преимущества экономии памяти DLL. Это также значительно замедляет загрузку модуля. По этой причине следует по возможности избегать перебазирования, а библиотеки DLL, поставляемые Microsoft, имеют предварительно вычисленные базовые адреса, чтобы не перекрываться. Таким образом, в случае отсутствия перебазирования PE имеет преимущество в виде очень эффективного кода, но при наличии перебазирования использование памяти может быть дорогостоящим. Это контрастирует с ELF, который использует полностью независимый от позиции код и глобальную таблицу смещений, которая жертвует временем выполнения в пользу меньшего использования памяти.

.NET, метаданные и формат PE

В исполняемом файле.NET раздел кода PE содержит заглушку, которая вызывает запись запуска виртуальной машины CLR, _CorExeMainили _CorDllMainв mscoree.dll, как и в исполняемых файлах Visual Basic. Затем виртуальная машина использует имеющиеся метаданные.NET, на корень которых, IMAGE_COR20_HEADER(также называемый «заголовок CLR») указывает запись IMAGE_DIRECTORY_ENTRY_COMHEADERв каталоге данных PE-заголовка.. IMAGE_COR20_HEADERочень похож на необязательный заголовок PE, по существу играя свою роль для загрузчика CLR.

Данные, связанные с CLR, включая саму корневую структуру, обычно содержатся в разделе общего кода, . Текст. Он состоит из нескольких каталогов: метаданных, встроенных ресурсов, строгих имен и нескольких каталогов для взаимодействия с собственным кодом. Каталог метаданных - это набор таблиц, в которых перечислены все отдельные сущности.NET в сборке, включая типы, методы, поля, константы, события, а также ссылки между ними и другими сборками.

Использование в других операционных системах

Формат PE также используется в ReactOS, поскольку ReactOS предназначен для двоичной совместимости с Windows. Исторически он также использовался рядом других операционных систем, включая SkyOS и BeOS R3. Однако и SkyOS, и BeOS в конечном итоге перешли на ELF.

Поскольку платформа разработки Mono намеревается быть двоично совместимой с Microsoft .NET Framework, она использует тот же PE формат как реализация Microsoft. То же самое касается собственной кроссплатформенности Microsoft .NET Core.

В x86 (-64) Unix-подобных операционных системах двоичные файлы Windows (в формате PE) могут выполняется с помощью Wine. HX DOS Extender также использует формат PE для собственных 32-битных двоичных файлов DOS, плюс он может до некоторой степени выполнять существующие двоичные файлы Windows в DOS, таким образом действуя как эквивалент Wine для DOS.

На IA-32 и x86-64 Linux также можно запускать Windows 'DLL в loadlibrary.

Mac OS X 10.5 имеет возможность загружать и анализировать PE-файлы, но не двоично совместим с Windows.

UEFI и встроенное ПО EFI используют переносимые исполняемые файлы, а также соглашение о вызовах Windows ABI x64 для приложений.

См. также

Ссылки

Внешние ссылки

Последняя правка сделана 2021-06-02 11:51:09
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте