CP/M, DOS и их .COMманды

Вступление

Небольшое предупреждение! Субъективно, эта статья содержанием немного не удовлетворяет смыслу переданному в заголовке. Я буду говорить не просто о том «Как запускаются команды?», а покажу часть внутреннего мира операционных систем и покажу принципиальную разницу в их работе.

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

Взгляд на CP/M

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

Во времена 1970-ых годов, когда для процессоров Intel 8080 появилась на свет операционная система CP/M (полн. «Computer Program/Monitor»).

Процессор i8080 (полн. «Intel 8080») был 8-разрядным,
соответственно объемы обрабатываемой памяти были не такими уж и большими. Все написанные под эту ОС программы помещались в один файл команды и весили не больше чем 64Кб.

Раз глава про управление памятью, сразу вижу необходимым обозначить структуру оперативной памяти после загрузки CP/M.

+----------------------------+ <-- 0xFFFF |           BIOS             |         | Аппаратные драйвера BDOS   | +----------------------------+ <-- 0xF200 |           BDOS             | | CP/M двоичный интерфейс    | +----------------------------+ <-- 0xE400 |   Интерпретатор комманд    | +----------------------------+ <-- 0xDC00 |           TPA              |  |Область запущенной программы| +----------------------------+ <-- 0x0100 |        LowMem Storage      | | То, что нас интересует     | +----------------------------+ <-- 0x0000 

Объясняю по-порядку все, что может вогнать в тупик:

BDOS (полн. «Basic Disk Operating System») — это лишь часть CP/M, а не второе название системы.

Компонент BDOS действительно для первого раза лучше принять за двоичный интерфейс, так как команды CLOSE, READ, SELECT, и др, это «именно в эту дверь».

BIOS (полн. » Basic Input/Output System») это буквально то, о чём могут подумать практически все, кто это читает. Но сразу обозначусь, в понимании CP/M это её часть, а не отдельное «нечто» и POST.

Выглядит немного необычно, не так ли?
Интересно в организации ОЗУ самое первое (или последнее) пространство — «Low Memory Storage».
Низкоуровневая память или «Low Memory Storage»
бьется на разделы тоже.

На самом деле, эту часть лучше пропустить, поскольку много кого это загонит в тупик.
Я оставлю информацию, которую я нашел в архивах, но лучше пропустить это мимо глаз.

+----------------------------+ <-- 0xFF |       Файловый буфер       | <-- 0x80 длинна |                            |     0x81-0xFF |                            | Список ASCII строк +----------------------------+ | FCB (File Control Block)   | +----------------------------+ | ???                        | +----------------------------+ | BIOS рабочее пространство  | +----------------------------+ | Вектор перезагрузки #7     | <-- Использовался  | Вектор перезагрузки #6     |     отладчиком | .                          | | .                          | | Вектор перезагрузки #1     |      +--------+------+----+-------+      |   F200 | Disk | IO | E400  |  +--------+------+----+-------+ <-- 0x00 

Взгляд CP/M на Программы

И так, программа для CP/M это файл с расширением «.COM«.

Файл «.COM» (сокр. «Command») — это монолит кода. Внутри он никак не разграничен и не имеет опознавательных знаков или подписей. В CP/M может занимать адреса до верней границы TPA (полн. «Transistent Program Area»).

Напишем простой пример команды, чтобы показать структуру:

.z80               ; <-- Требуется Z80;  WRITE       equ 9h ; <-- CP/M функционал; _BDOS       equ 5h ; <-- "Системное прерывание";  org 100h           ; <-- Отступ в ОЗУ на 255 байт;     ld C, WRITE     ld DE, hello     call _BDOS     ; syscall;     rst 0h         ; Выход.  hello:     db "Hello World!$"     end 

На всякий случай, команда ld (полн. «LOAD») выполняется как mov из IA-32, а не как lea или push. Команда rst (полн. «RESET») переходит по адресу и запоминает предыдущее значение в стэке.

Стрелочками в комментариях я обозначил, что здесь определенно «делает погоду».
Для CP/M в структуре программы есть три
немало важные детали.

1. требование к архитектуре;

2. двоичный интерфейс (англ. «Application Binary Interface») системы;

3. смещение программы (ORG 100h) и установка входной точки.

     Начало TPA -->|                    | <-- Low Memstr  -->| +------------------+-----------------+ | ... | ... | ...  | Код программы   | +------------------+-----------------+ |<--  255 байт  -->|                 |  

Сама программа должна будет лежать в области TPA, как из таблицы видно, а выделенная область оказывается лежит в Low Memry Storage.
Эта таблица называется ZPCB (полн. «Zero Page Control Block») или PPA (полн. «Program Prefix Area») для поздних релизов этой системы.

Представьте себе почтовый ящик в подъезде по таковому адресу (адрес 0x0000-0x00FF это Low Memory Storage)… Когда приходит жилец (загружается комманда), почтальон (Операционная Система CP/M) кладет в этот ящик конверт с важной информацией именно для этого жильца. Конверт лежит в ящике. Жилец приходит «домой» (загружается по 0x0100 смещению) и первым делом заглядывает в свой ящик за конвертом (Содержит области памяти ещё и ZPCB).

Загрузка и регистрация .COMманды в CP/M

Когда CP/M загружает .COM файл
ОС инициализирует PPA/ZPCB в Low Storage. Она заполняет поля, относящиеся к запуску программы. Это могут быть текущий диск, FCB1, FCB2, хвост командной строки, системные векторы BDOS и BIOS для этого запуска.

ОС загружает бинарный образ .COM файла начиная с адреса 0x0100. Именно благодаря ORG 100h комманде процессору.
Код программы ожидает, что по 0x0000-0x00FF уже лежит корректно заполненная PPA.

ОС устанавливает регистры процессора: PC (полн. «Program Counter») становится по адресу точки входа, SP (полн. «Stack Pointer») — обычно глядит в конец доступной программе памяти (или в другое место, указанное в BDOS).

Zero Page Control Block или Program Prefix Area (CP/M)

Теперь более детально опишу структуру ZPCB/PPA. В документации к CP/M её действительно называют «нулевой страницей», поэтому непобоюсь написать так же.

Данную структуру в более полном виде (описания и типы данных) можно найти в архивах или на сайте с документацией.

Теперь укажу условные обозначениям:

• Префикс b... — это BYTE или машинное слово, размером в 8 бит.

• Префикс h... — это дескриптор (указатель) инкапсулирущий настоящий адрес данных.

• Нотация [type; n] взята из Rust, так как нахожу это правило универсальными и более понятными глазу, чем типы данных Windows. Это массив type-ячеек в n-ом колличестве.

• Префикс dw... — это DWORD, а не define WORD! Другими словами — машинное слово размером в 32-бит (на момент IA-32e).

• Тип данных size тоже взят из Rust. Путь Этот тип будет для всех, как максимально возможное машинное слово для процессоров тех времен и самой ОС. (имеется ввиду Intel 8080 и Intel 8086). Все зависит только от того «Где работает ОС и какая ОС».

Как видно, тот самый «конверт» с письмом на самом деле содержит вот такие поля данных.

Очень важно запомнить, что таблица PPA в CP/M
только одна. Она располагается в определенном месте,
имеет очень большой смысл в жизненном цикле программы.

Только в CP/M-86, ZPCB (или PPA) начинает поведением быть похожа на PSP таблицу из xx-DOS.

Взгляд на xx-DOS

Сейчас речь пойдет в основном про PC-DOS и MS-DOS 2.0,
так как тема разговора и подопытные совпадают.

В предыдущей главе было описано более-менее подробно, как же понимает CP/M файлы комманд. Раз уж выделена отдельная глава для DOS, логично предположить, что поведение COM
файлов в DOS и CP/M разное.

Внимание, здесь не будет описан механизм чтения OVERLAY
частей программ, потому что рассматриваются немного другие времена
и лишние объяснения про страницы памяти будет избыточно.

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

Очень важная отличительная черта от предыдущего «подопытного» в организации процессов. Положим, MS-DOS пусть и является однозадачной, по определению, но каким-то образом же может удерживать драйверы и DOS-extender’ы? Ведь да?

В оперативной памяти DOS держится приблизительно таким образом:

Здесь логика местами похожа на CP/M, но в глаза бросается строгое разграничение программной памяти. Отныне все нулевые страницы ~управляемой~ памяти пренадлежат области «Program Memory».

Писать про жизненно необходимые MSDOS.SYS, CONFIG.SYS, COMMAND.COM не буду. Они как раз видны на схеме вооруженным глазом.

…и Взгляд xx-DOS на программы

Для 16-разрядных DOS при выполнении файла код,
данные и стек находятся в одном и том же 16-битном сегменте.
Поэтому размер файла не может превышать 65280 байт (что на 256 байт меньше размера сегмента — или 216 байт).

Простейшая программа для DOS на Flat Assembly (сокр. «FASM»)
диалекте выглядит приблизительно так:

use16  DosWrite equ 9h     ;<-- Функционал DOS/2.0  org 100h            ;<-- Точка входа 0x100     mov dx, hello     mov ah, DosWrite;DOS call.     int 21h         ;syscall. (вызов DOS функции)       mov ax, 4C00h   ;AH = 4Ch, AL = 00h.     int 21h         ;syscall (вызов DOS функции)  hello db 'Hello, world!$' 

Стрелочками я обозначил практически те же самые места, такие как смещение и обозначение точки входа (не смещение точки входа), и ABI системы. С виду структурно это похоже на предыдущий образец. Разница только в архитектуре и в системном BI.

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

Загрузка регистрация .COMманд в MS-DOS 2

И так, идея комманды не меняется. .COM это все еще PIE-монолит (исполняемый файл независящий от точки входа).

При загрузке файла .COM в свободной области ОЗУ, операционная система
создает несколько структур.
Структура «перед» кодом программы — это PSP (полн. «Program Segment Prefix»), что отвечает за состояния
выполняемого файла и предоставляет список аргументов командной строки.

A:\> COMMAND.COM /A /B /C argv[     0     ][1][2][3] 

В области ОЗУ будет приблизительно такая схема ячеек:

+-----+-----+----------+----------------------------------+-----+ | ... | ... | PSP      | [Программа] [STACK]              | ... | +-----+-----+----------+----------------------------------+-----+             | 256 байт |         Размер Программы         |             |                                             |             |                                             |  Начало  -->|                  Конец области программы -->| 

Как видно из таблицы, именно поэтому образец программы начинался с org 100h.

Сама программа в ОЗУ разбивается по области кода, данных и стэка.
Ещё раз: здесь не рассматривается OVERLAY части, потому что это здесь избыточно.
Но в следующий раз, возможно про .EXE файлы и MS-DOS 2.0 я это обязательно возьмусь показательно разбирать.

В документации DOS я не встретил упоминания «нулевой страницы», поэтому назову структуру «как есть».

Program Segment Prefix (PSP)

Теперь спускаемся ещё дальше в специфику DOS и CP/M семейств.
С первых интернет ресурсов буквально представляется полная информация о PSP секции. Представлена ниже:

В CP/M и DOS главах упомянались FileControl-блоки, но почему-то ни слуху — ни духу, о них в разборе… Исправляюсь.

Специально выделю два подраздела для неизвестных структур.

File Control Block (FCB)

FCB (File Control Block) в DOS — структура, в которой поддерживается состояние открытого файла. Она находится внутри памяти программы, которая использует файл, а не в памяти операционной системы.
Такое решение позволяет процессу иметь одновременно несколько файлов, если он может выделить достаточно памяти для FCB на каждый файл

В зависимости от версии MS-DOS сама структура потерпела изменения:
Я показываю структуру FCB такой, какая она есть в MS-DOS 2.0, поскольку там присутствуют поля случайного доступа.

#pragma pack(push, 1) struct FCB_STANDARD {     unsigned char drive;        // 00: 0 = default, 1=A, 2=B, ...     char filename[8];           // 01-08: имя файла (лево выровнено, пробелы в конце)     char extension[3];          // 09-0B: расширение (лево выровнено, пробелы)     unsigned short current_block; // 0C-0D: текущий блок (начиная с 0)     unsigned short record_size;   // 0E-0F: размер логической записи в байтах     unsigned long file_size;      // 10-13: размер файла в байтах     unsigned short date;          // 14-15: дата (формат: см. выше)     unsigned short time;          // 16-17: время (формат: см. выше)     unsigned char reserved[8];    // 18-1F: зарезервировано (зависит от версии)     unsigned char current_record; // 20:   текущая запись в блоке (0-127)          // MS-DOS 1.25 не имеет поля случайных записей     unsigned long random_record;  // 21-24: случайная запись (относительно начала файла) } #pragma pack(pop) 

У блока управления файлом в DOS 2.0 есть расширенный (мне кажется лучше расширяющий) подраздел.

#pragma pack(push, 1) struct FCB {     unsigned char signature;     // -7: 0xFF     unsigned char reserved[5];   // -6 - -2: зарезервировано     unsigned char attribute;     // -1: атрибут файла     FCB_STANDARD fcb;             // 00-24: стандартный FCB } #pragma pack(pop) 

Советую думать, что FCB это своеобразная карточка книги в библиотеке,
а расширенный FCB это пометка [СЕКРЕТНО]. Увы, подробнее об этом в другой раз.

Таблицы процесса (JFT и SFT)

Изначально этот материал я долго не мог уложить в голове, и взял его практически «как есть», без обработки. Но со временем дополнения появились.

Для обеспечения доступа к открытым файлам MS-DOS использует системные таблицы двух типов.

Таблица SFT (полн. «System File Table») содержит записи о всех файлах, в данный момент открытых программами пользователя и самой ОС.

Эта таблица хранится в системной памяти, число записей в ней определяется параметром FILES в файле конфигурации CONFIG.SYS, но не может превышать 255.

Если один и тот же файл был открыт несколько раз (неважно, одной и той же программой или разными), то для него будет несколько записей в SFT.

Каждая запись содержит подробную информацию о файле, достаточную для выполнения операций с ним. В частности, в записи SFT содержатся:

• копия информации о файле;

• адрес записи (сектор и номер записи в секторе);

• текущее положение указателя чтения/записи;

• номер последнего записанного или прочитанного кластера файла;

• адрес в памяти программы, открывшей файл;

• режим доступа, заданный при открытии.

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

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

Теперь к одному из главных вопросов: «Откуда в однозадачной MS-DOS могут взяться одновременно
несколько программ?»
Ответ прост: когда одна программа запускает другую,
то в памяти присутствуют обе.

Таблица JFT имеет простейшую структуру: она состоит из однобайтовых
записей, причем значение каждой записи представляет
собой индекс (номер записи) в таблице SFT.
Неиспользуемые записи содержат значение 0xFF.
Размер таблицы по умолчанию составляет 20 записей (байт),
но может быть увеличен до 255.

Сама JFT находится в PSP области. Если рассматривать поближе
часть ОЗУ где находится процесс, его структура будет такова:

+-----+-----------------------------------------+-----------+-----+ | ... | [argv]; argc.....[1; 6; 2; FF; FF;].... | Программа | ... | +-----|------------------|----------------|-----|-----------+-----+       |                  | <--   JFT  --> |     |           |       |                        20 байт          |           |       |                                         |           |       | <-- Начало PSP             Конец PSP -->|           |        | <-- Начало             Конец управляемой памяти --> | 

Что происходит с файлами при завершении программы,
которая их открыла? Это не важно.

В любом случае ОС должна при завершении программы закрыть
все её файлы. Как ОС узнает, какие файлы следует закрыть?
Достаточно просмотреть таблицу JFT завершаемой программы и
найти там все записи, отличные от 0xFF.

Вывод

Это было большое и насыщенное для меня путешествие в NTVDM (полн. «Windows NT Virtual DOS Machine»), тонкости MS-DOS и её предков, но то, что я нашел на просторах интернета, возможно скоро канет в Лету. Пытаться найти мелочи жизни и как-то уложить их в голову, а потом и сюда.

Я приведу таблицу итогов для .COMманд, и это самая последняя таблица в этом документе.

В целом, и так понятно, что загрузить программу из MS-DOS 2.0 в чужеродной среде не получится, поскольку нет слоя совместимости системного интерфейса.
Если бы даже архитектуры программ были одинаковы (например сборщик для Intel 8086), то разногласия в вызовах уже бы помешали злодеянию.

Обратная совместимость для CP/M комманд в DOS была, и некоторые поля PSP структуры существуют только для её обеспечения.

Со временем ZPCB/PPA таблица в CP/M-86 станет похожа на .PSP раздел, а сам формат таблицы .PSP станет родителем таблицы релокаций и первых файлов .EXE — MZ-исполняемых файлов.
DOS системы продолжут существовать и станут самостоятельнее, появится BW-DOS с новым форматом исполняемых файлов, а Microsoft и IBM придумают NE-сегментные файлы.

Источники

• File Control Block MS-DOS 2.0;

• CP/M

• CP/M ZeroPage control block;

• MS-DOS PSP section;

• MS-DOS Web Archive