Как операционная система понимает, что файл можно запускать

Двойной щелчок по файлу запускает программу — но почему один файл превращается в работающее приложение, а другой открывается как текст или вызывает ошибку? Операционная система принимает это решение не «по интуиции», а по вполне конкретным признакам: внутреннему формату файла, правам доступа, расширению и метаданным. Разберём, как именно устроена эта проверка в разных системах и почему иногда она даёт сбой.

Главный принцип такой: исполняемость определяется совокупностью условий. Файл должен иметь узнаваемый для системы формат (например, PE в Windows или ELF в Linux), а также проходить проверки безопасности и, в Unix-подобных системах, иметь право на выполнение. Отсутствие любого из этих условий делает файл «просто данными», даже если внутри него спрятана полноценная программа.

Что вообще значит «запустить файл»

Программа — это последовательность машинных инструкций, которые процессор умеет выполнять напрямую, плюс данные и служебная информация: где лежит код, какие библиотеки нужны, с какой точки начинать выполнение. Но большинство файлов на диске — картинки, документы, архивы — тоже состоят из байтов, и процессор физически может исполнить что угодно. Разница только в том, что система разрешает передавать процессору лишь те байты, которые распознаны как корректный исполняемый образ.

Когда вы запускаете файл, происходит примерно следующее:

1. Оболочка (Проводник, терминал) обращается к системе с запросом создать новый процесс из этого файла.
2. Ядро операционной системы читает начало файла и проверяет его сигнатуру — характерную «подпись» формата.
3. Если формат опознан, ядро разбирает заголовок: находит точку входа, сегменты кода и данных, список зависимостей.
4. Система выделяет память, загружает содержимое в адресное пространство нового процесса, подключает нужные библиотеки.
5. Управление передаётся на точку входа, и программа начинает работать.

Если на втором шаге сигнатура не распознана, запуск прерывается с ошибкой. Именно поэтому текстовый файл с кодом программы на Python нельзя «запустить» напрямую в Windows: для ядра это просто данные, а интерпретатор Python нужно вызывать отдельно.

Форматы исполняемых файлов: главные сигнатуры

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

Система	Основной формат	Начальные байты (сигнатура)
Windows	PE (Portable Executable): .exe, .dll, .sys	«MZ» (4D 5A)
Linux и другие Unix-подобные	ELF (Executable and Linkable Format)	0x7F 45 4C 46 («\x7fELF»)
macOS, iOS	Mach-O	0xfeedface или 0xfeedfacf (в зависимости от разрядности)
Кроссплатформенные скрипты	Текст с указанием интерпретатора	Строка вида «#!» (shebang) в начале

PE-формат в Windows

Все современные исполняемые файлы Windows начинаются с двух букв «MZ». Это наследие MS-DOS: буквы были инициалами Марка Збиковски, разработчика старого формата, и сохранились ради обратной совместимости. После DOS-заголовка идёт настоящий PE-заголовок, где описаны секции кода, таблица импорта (какие DLL требуются), ресурсы вроде иконок и точка входа.

Загрузчик Windows сверяет архитектуру: PE-файл под x86 не запустится на ARM без слоя эмуляции, а 64-битный файл не выполнится в 32-битной среде. Дополнительно система смотрит цифровую подпись издателя — не для решения «можно ли запускать», а для оценки доверия при проверках SmartScreen и антивирусом.

ELF-формат в Linux

В Linux решение о запуске принимает ядро, и оно опирается прежде всего на содержимое файла, а не на имя. Первые четыре байта ELF-файла однозначно говорят ядру: это исполняемый образ. Дальше ядро читает тип файла (исполняемая программа, разделяемая библиотека, объектный модуль), целевую архитектуру и таблицу программных заголовков, описывающую, какие части файла куда загрузить в память.

Важное следствие: в Linux файл с правильной ELF-структурой будет исполняемым независимо от того, какое у него расширение или есть ли оно вообще. Можно переименовать программу в «file.txt» — ядро всё равно её запустит, если стоит право на выполнение. И наоборот: файл с именем «program.exe» без ELF-заголовка ядро исполнять не станет.

Скрипты и shebang

Скрипты — особый случай. Bash-скрипт, Python-файл или Perl-сценарий не содержат машинного кода, поэтому ядро их напрямую выполнить не может. Здесь работает механизм shebang: если первая строка файла начинается с символов «#!», ядро читает дальше путь к интерпретатору, например:

#!/usr/bin/python3

После этого ядро запускает не сам скрипт, а указанную программу, передавая ей путь к файлу как аргумент. Если интерпретатора по этому пути нет, запуск завершится ошибкой, хотя сам файл полностью корректен. В Windows аналогичной роли служат ассоциации расширений: .py привязан к Python, .bat — к командному интерпретатору.

Права доступа: почему в Linux мало «исполняемого бита»

В Unix-подобных системах у каждого файла есть три ключевых права: чтение, запись и выполнение. Право выполнения — отдельный флаг, который можно посмотреть командой «ls -l» (буква «x» в строке прав) и установить командой «chmod +x файл».

Логика такая: право на выполнение — необходимое, но недостаточное условие. Ядро сначала проверяет флаг «x», и только потом пытается разобрать формат. Отсюда два типичных сценария:

• Скачанный бинарник без права выполнения выдаёт ошибку «Permission denied», даже если это абсолютно рабочая программа. Решение — добавить флаг через chmod.
• Текстовый файл с установленным битом выполнения попытается запуститься, но упадёт с ошибкой формата — либо, если в начале стоит shebang, будет передан соответствующему интерпретатору.

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

Расширения и ассоциации: механизм Windows

Windows исторически полагается на расширение имени файла. Когда вы дважды щёлкаете по значку, оболочка смотрит на расширение и ищет его в реестре среди зарегистрированных ассоциаций:

• «.exe» и «.com» обрабатываются как прямые команды запуска;
• «.msi» передаётся установщику Windows;
• «.bat» и «.cmd» — командному интерпретатору;
• «.ps1» — PowerShell (причём по умолчанию запуск двойным щелчком запрещён политикой выполнения);
• «.txt» открывается блокнотом, то есть запускается не сам файл, а программа-обработчик.

Отсюда важный практический вывод: расширение в Windows — это указание, чем открыть файл, а не гарантия, что он исполняемый. Злоумышленники этим пользуются: файл «photo.jpg.exe» в проводнике с отключённым показом расширений выглядит картинкой. Поэтому полезно включить отображение расширений в настройках Проводника и настороженно относиться к файлам с двойными расширениями.

Как проверить тип файла самостоятельно

Необязательно верить расширению — содержимое всегда можно проверить.

• В Linux и macOS команда «file имя_файла» анализирует первые байты и сообщает реальный тип: «ELF 64-bit executable» или «ASCII text».
• Команда «xxd файл | head» или «od -A x -t x1z файл | head» показывает первые байты в шестнадцатеричном виде — по ним видно сигнатуру MZ или ELF.
• В Windows утилита PowerShell «Get-Content -Encoding Byte -TotalCount 2» позволяет прочитать первые байты, а сторонние редакторы вроде hex-просмотрщиков показывают заголовок целиком.

Такая проверка особенно уместна, когда файл пришёл из ненадёжного источника и заявленный тип вызывает сомнения.

Дополнительные уровни проверки при запуске

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

Механизмы безопасности

• Цифровая подпись. Подпись подтверждает, что файл выпущен известным издателем и не изменён после подписания. Её отсутствие не мешает запуску напрямую, но влияет на репутацию файла в глазах защитных механизмов.
• SmartScreen в Windows. Файлы, скачанные из интернета, помечаются специальным атрибутом зоны. При первом запуске неподписанного или малоизвестного файла система показывает предупреждение.
• Gatekeeper в macOS. По умолчанию система разрешает запуск приложений из App Store или от разработчиков с заверенной подписью; остальные требуют явного подтверждения в настройках безопасности.
• Антивирусы. Проверяют исполняемые файлы по базам сигнатур и эвристикам до или во время запуска.
• Политики ограниченного использования ПО. В корпоративных средах администратор может разрешить выполнение только подписанных программ из определённых каталогов.

Зависимости

Исполняемый файл почти никогда не существует сам по себе. Загрузчик должен найти все указанные в нём библиотеки: DLL в Windows, .so в Linux, динамические фреймворки в macOS. Если хотя бы одной библиотеки нет или её версия несовместима, запуск завершится ошибкой уже после успешного распознавания формата. Классический пример — сообщение о отсутствующем «VCRUNTIME140.dll»: формат файла корректен, но окружение неполно.

Почему «не запускается»: типичные причины

Большинство проблем с запуском укладываются в несколько сценариев:

• Несовместимый формат. Попытка запустить Linux-бинарник в Windows или наоборот. Формат не распознаётся, система сообщает об ошибке, часто малопонятной.
• Нет права выполнения (Unix). Лечится командой chmod +x.
• Не тот интерпретатор. Скрипт со shebang, указывающим на несуществующий путь, или отсутствие ассоциации расширения в Windows.
• Неподходящая архитектура. 64-битная программа на 32-битной системе, ARM-бинарник на x86 без эмуляции.
• Блокировка системой безопасности. SmartScreen, Gatekeeper, корпоративные политики или антивирус остановили запуск.
• Повреждение файла. Оборванная загрузка или ошибка копирования ломают структуру, и сигнатура либо заголовки перестают быть корректными.

Диагностику удобно вести в этом же порядке: сначала проверить, тем ли инструментом вы пытаетесь запустить файл и той ли это платформы файл, затем права доступа, затем сообщения системы безопасности и, наконец, целостность скачивания.

Практические выводы

Операционная система решает вопрос «запускаемый ли этот файл» по цепочке проверок: распознавание формата по сигнатуре, проверка прав и политик, разрешение зависимостей. Понимание этой цепочки помогает быстро разбираться с ошибками запуска и безопаснее обращаться с файлами из внешних источников.

Полезные привычки:

• Оценивайте файл по содержимому, а не по имени: команда «file» в Unix-системах или просмотр первых байт дают объективный ответ.
• В Linux помните про бит выполнения: ошибка «Permission denied» у скачанной программы чаще всего означает именно его отсутствие.
• В Windows включите показ расширений и не запускайте файлы с подозрительными двойными расширениями.
• Предупреждения SmartScreen и Gatekeeper читайте внимательно: они сообщают не о поломке файла, а о том, что система не может подтвердить его происхождение.
• Ошибка про отсутствующую библиотеку означает проблему окружения, а не самого файла: ищите недостающий компонент или переустанавливайте приложение целиком.

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