Берем разбег.
DOS привлекает тем, что можно отследить "всю цепочку". BIOS живет в железе компа и умеет худо-бедно обращаться к этому железу. Например, он понимает диски, но не понимает файлов. DOS - надстройка над BIOS, живет в начале главного диска (так и ищется - по первым секторам) и понимает файлы. Среди файлов DOS есть Command, Edlin, Debug, Basic (или более современные их версии). Command - более или менее удобная оболочка для доступа к файловым операциям DOS (и немного - к другому железу). Edlin - умеет работать с короткими текстовыми файлами. Debug - позволяет управлять железом руками. Все три могут программироваться написанием текстовых файлов-программ. Причем, Command немного понимает в программную логику - переменные, условия, циклы. А Debug умеет писать простые программы для железа - в кодах этого самого железа. В принципе, эти четыре кубика могут укладываться друг на друга и комбинироваться в достаточно сложные конструкции. Basic - вещь в себе, в котором всего понемногу, но связанное более мощным языком программирования. Пристроить его к остальным кубикам сложновато, но можно научиться. Других средств программирования в DOS нет, но можно попытаться собрать комплект Masm: сам ассемблер, Make - разновидность Command, заточенная под контроль версий проекта, Symdeb - немного улучшенный Debug, Salut - забавное макрорасширение, Link - привязыватель результата работы Masm к DOS (на самом деле Link входит в сам DOS - на случай, если вы сами напишете свой компилятор?). Вот и все. Все остальное - это сторонние программы, украденные и заточенные под вашу текущую задачу. Иногда очень мощные и красивые.
Что такое программа? Я скажу ересь: это СООБЩЕНИЕ, которое один из ПРОЦЕССОВ тоже считает ПРОЦЕССОМ. Любой из "успешных программистов" скажет, что это "совсем не так": сначала ПОЛЬЗОВАТЕЛЬ запускает РЕДАКТОР, потом - КОМПИЛЯТОР, потом - ЗАГРУЗЧИК... И только потом... А я сразу и сказал - ... потом будет новый ПРОЦЕСС.
Самые старые компьютеры всего-то и имели два (аппаратных) ПРОЦЕССА - один загружал программу-СООБЩЕНИЕ, другой передавал ей управление, как новому ПРОЦЕССУ. Это потом Операционные Системы получили в свое распоряжение много разных ПРОЦЕССОВ для разных видов программ.
Мне же такое облыжное упрощение программы до дуализма СООБЩЕНИЕ-ПРОЦЕСС понадобилось дабы подчеркнуть, речь пойдет о совсем примитивных вещах. О старой доброй MS DOS.
Вскрыв ее, мы найдем целых четыре ПРОЦЕССА, готовых помочь ПОЛЬЗОВАТЕЛЮ писать свои программы: Command, Edlin, Debug и Basic. Первый - ИНТЕРПРЕТАТОР - готов считать ПРОЦЕССОМ все, что ему предложит ПОЛЬЗОВАТЕЛЬ, второй - РЕДАКТОР - готовит СООБЩЕНИЯ для остальных трех, третий - КОМПИЛЯТОР - умеет создавать ПРОЦЕССЫ на языке железа, а четвертый эмулирует ту самую старую машину с двумя ПРОЦЕССАМИ - РЕДАКТОРОМ и ИНТЕРПРЕТАТОРОМ.
Составлю табличку, кто из них как может "программировать" себя и других. Начну с самого простого - Editor-а.
Editor программирует Editor. Его входной и выходной форматы - обычный текст. Входной немного проще - там всего пара десятков команд, каждая из одной буквы. Казалось бы, в чем проблема? Пиши текст в одном, передавай другому. Во-первых, передачу осуществляет Command, а, во-вторых, входной язык содержит букву - Ctrl-Z,- которую Editor выводить не умеет (умеет Debug - нужно в нем немного подрихтовать). Зачем же вообще нужно программировать Edlin? Только для автоматизации операций, на которые не способен Command, когда нужно что-то покромсать внутри файлов, куда последний лазать почти не умеет. Разумеется, текстовых файлов.
Edlin -> Command. Для этого Edlin и задумывался. Править простые скрипты Command. Ну, еще файлы конфигурации, направляющие работу, опять же, Command.
Edlin -> Debug. Создавать текстовые программные файлы для Debug еще проще, чем для Edlin. И это имеет смысл. Например, для передачи/публикации исполняемых (или просто двоичных) файлов в текстовой форме.
Edlin -> Basic. Последний имеет собственный РЕДАКТОР для создания своих программ. Более удобный. Хотя, кому - как. Может, например, захотеться создавать Basic-программы автоматически. Или хранить в текстовом файле не только программу, но и команды ее запуска. И, конечно, Edlin может помочь создавать файлы данных/конфигураций для Basic-программ.
Command -> Command. Такое вполне возможно и не намного слабее писания скриптов в Edlin. Ведь это просто текст. Переназначив вывод с консоли в файл, можно создавать любые тексты. Да, и, конечно, можно, наоборот, расширять язык Command новыми командами-скриптами.
Command -> Edlin. Ввиду примерно одинаковой способности создавать текстовые файлы, речь скорее идет о выделении каких-то текстовых преобразований в отдельные Edlin-подпрограммы. Не будем забывать, что без Command мы практически не сможем связать программы остальных в нечто единое.
Command -> Debug. То же, что и с Edlin. Разве что, Debug-подпрограммы более необходимы и генерация их на лету, видимо, более полезна.
Command -> Basic. То же самое. Но более востребован другой путь. Команды Command могут быть встроены в программы на Basic (обычно, когда требуется сделать что-то с файлами).
Debug -> Debug. Писать программы для Debug на Debug просто неудобно. Однако, вполне возможно, редактируя программу, подгружать и запускать процедуры, облегчающие работу.
Debug -> Edlin. Как писал выше, это почти единственный способ вставить в текстовый файл служебные символы. Кроме того, иногда для преобразования текстового файла, например вырезания нужного куска, Debug удобнее Edlin.
Debug -> Сommand. Это нормальный способ расширения возможностей ОС программами, имеющими доступ к железу, например, просто к клавиатуре и таймеру.
Debug -> Basic. Тоже вполне общепринятый способ добавления в Basic-программу подпрограмм доступа к железу напрямую.
Basic -> Basic. Опять речь идет о добавлении в новую программу старых кусков. Причем, может использоваться промежуточный Basic-язык - и не текстовый, и не машинный. Но проще - текстом.
Basic -> Edlin. Проще написать на Basic более мощный редактор. Разве что, результат работы Basic-программы использовать как заготовку для Edlin-документа.
Basic -> Debug. Это путь для создания своего компилятора.
Basic -> Command. Ну скорее, они конкуренты. Basic умеет почти все то же самое, но в более игровой форме. Но, конечно, вставка Basic-программ в Command-скрипт часто полезна.
Очевидна большая избыточность. Огромное количество убогих способов создания (программных) текстов. Различные способы увязывания ПРОЦЕССОВ в одно целое. С другой стороны, жуткое ограничение на размеры отдельных кусков.
Самое узкое место - Edlin, почти не умеющий ничего полезного. Например, в Unix на этой позиции расположен целый комплекс программ обработки, разбора и генерации текста, а также, генерации подобных программ.
Попробовать собрать из этих DOS-кубиков что-то полезное? К сожалению, за прошедшие десятилетия от них ничего не осталось. Edlin и Debug отмерли. Заменить их можно практически только Basic-программами. Зато Basic-ов теперь много: и HTML, и WSH, и .NET. Не говоря уже о покупных/офисных VB и VBA. Зато, Command немного поумнел, позволяет чуть более сложные скрипты. Появились конкуренты - например Power Shell и другие средства администрирования.
Как-то так...
