Форматы в каких может храниться приложение

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


Чтобы получить исполняемый файл, мы проводим следующие манипуляции:

1. Пишем модули(части) нашего приложения на языке понятном для человека. На этой стадии наша программа выгладит в виде файлов с исходным кодом.
2. Проганяем эти файлы-модули через программу-компилятор, которая превращает их в обьектные модули, это уже файлы в двоичном формате. Только вот пока что обращения к функциям и переменным(константам) из других файлов-модулей хранится в конкретном файле в виде упоминаний имен.
3. Программа компоновщик(линкер) соединяет все модули в один файл, а упоминания имен внешних модулей заменяет на адресса, по которым в памяти будут находится ссылаемые функции/переменные/константы, после загрузки в эту память исполняемого файла. На этом этапе наше приложение находится в одном бинарном файле под названием исполняемый модуль(исполняемый файл).

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

После линковки всеже в нашем бинарном файле могут остаться импортируемые имена: это ссылки на функции ядра ОС и функции динамических библиотек. 

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

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

Кроме того в процессор команды приложения могут попасть не только из исполняемого файла. Приложения могут храниться в:

1. Сприптах -- символьные файлы на языках понятных человеку, а интерпретатор на лету трансформирует их в бинарные команды и передает процессору. Процессор работает с посредником
2. Бинарные файлы вирутальных машин. Процессор может получить свои бинарные команды от посредника, виртуальной машины, которая читает бинарные файлы, но их кода понятные для виртуальной машины, а не для процессора конкретной архитектуры. Так программа компилируется не под каждую возможную архитектуру процессоров, а только под виртуальную машину. А уже виртуальная машина имеет свою реализацию под каждую архитектуру. Так мы получаем приложение универсальное для всех архитектур, при этом более продуктивнее чем скприт - ведь не нужно выполнять на столько много преобразование кода, как в случае сприпта.