Версия для печати :: Каким должен быть DOS Life CD

Внимание! Эта статья может показаться кому-то сказкой или утопией, однако автор абсолютно серьезен. Возможно, некоторые позиции рассматриваются с позиции исключительно пользователя (то есть, что бы хотелось видеть), а не с позиции программиста (что возможно сделать), однако автор еще раз напоминает, что он пока

не претендует на звание профессионала в программировании и надеется на помощь более квалифицированных людей.

По-моему, идея DOS настолько хороша, что прекращать ее развивать было бы довольно глупо. Почему бы не продолжить то, что Microsoft и IBM, заблуждаясь, бросили? Сейчас довольно модна идея написания очередной Unix-подобной системы с мощной защитой, системой безопасности и системой восстановления сбойных ситуаций. Я ничего такого не предлагаю. Все вышеизложенные функции ложатся на программиста, пишущего программы для нашей системы. Взамен он получит то, чего ему не даст ни Windows, ни Unix, ни другая подобная им система. Он получит полный контроль над всем, что работает в данный момент. Все будет зависеть только от его мастерства и умения...

Пока мне самому не под силу писать такой сложный проект, однако, я надеюсь, эту идею подхватят и другие, да и я сам буду совершенствоваться... Пока же я попробую сформулировать здесь основные свои представления о том, какой должна быть "возрожденная" DOS. Вы же присылайте свои дополнения, пожелания и вопросы. Также объявляется конкурс на лучшее название системы. Пишите автору - baldr@pisem.net.

Итак, что же должна уметь делать наша новая операционная система и каковы будут ее главные особенности?

Однозначно нужно писать для разных процессоров разные части процедур. То есть, при инсталляции будет определяться тип процессора и в зависимости от него, система будет компоноваться наиболее производительными частями, написанными специально для такого процессора. Однако, следует избегать большого числа файлов. В идеале - два-пять... А чтобы скомпоновать рабочую версию системы, также инсталлятор будет, определив процессор и "железо", вписыватЬ, например, в места вызова процедур (которые будут различаться по размеру и адресу) сами эти адреса. То есть, при инсталляции система будет почти что заново собираться... Долго, но практично и надежно. Конечно, блоки должны быть между собой совместимы. Пока еще я не решил, как быть с добавлением новых устройств или изъятием пользователем уже имевшихся... Возможно, идея технологии plug'n'play не так уж и плоха, однако, ее реализация должна быть ненавязчивой и ограниченной.

Мне нравится принцип системы, построенной на прерываниях. Также предлагается система прерываний, как и в нынешней DOS. Однако, следует отойти от принципа "главного" прерывания системы - 21h. Или хотя бы для начала (для первых альфа-версий!) реализовать в нем или похожем совершенно иную структуру вместо существующей. То есть, убрать редкоиспользуемые функции, а добавить новые. Об исправлении проблемы реентерабельности, думаю, говорить излишне! Механизм перехвата прерываний должен проходить через систему для нормальной работы с TSR-программами, которые могут выгружаться и загружаться произвольно. Загружаться, скорее всего, с конца, а выгружаться из произвольного места "цепочки". И корректно возвращать управление после завершения. Найдутся, конечно, такие программисты, которые захотят писать напрямую в таблицу прерываний, но этому помешать у системы не получится... И "слава Нортону", Ибо в этом основная идеология... Но о том, как можно исправить трудности с таким подходом - немного ниже...

Она должна будет уметь абсолютно корректно работать с уже существующими программами для MS-DOS (PC- и совместимыми). Это одно из главных условий, ибо программ для DOS написано огромное количество, и переходить на систему, в которой все придется писать "с нуля" не захочется никому. Однако, я предлагаю запускать их в режиме "эмуляции" то есть, для того, чтобы запустить exe- или com-файл старой DOS, нужно "замаскировать" следы присутствия нашей системы и создать иллюзию присутствия старой системы. Это значит - повесить ложный обработчик прерываний 21h, 20h, 2Fh и прочих, находившихся ранее в ведоме старой DOS и необязательно поддерживаемой нами. Не беда, если 10% из старых программ запускаться все-таки не будут, однако больше - это уже серьезно!

Наша система не должна зависать сама по себе!! DOS прекрасно в этом смысле организована (исключая некоторые моменты, вроде все той же повторной входимости и др.). И наша система должна это унаследовать! То есть, код системы должен быть наиболее чистым от "багов". Если система зависнет, то это уже - некорректная работа внешней программы, но сама по себе - не должна.

Далее... Работа с верхней памятью должна проходить абсолютно свободно и безупречно. Ибо даже на 386 компьютерах она уже есть... Хоть мало, но есть. И поддерживать ее надо!

Кстати, очень желательно, даже необходима работа не в защищенном, а в реальном режиме! Если получится организовать так называемый "нереальный" режим, то это будет очень даже прекрасно! Переход в защищенный режим по первому же приказу программы - это обязательно... Однако, там не обязательно предоставлять обширный сервис. Пускай сами думают. А может и получится? Но это в идеале...

Что касается такой вещи, как многозадачность, то это уже можно реализовать через все те же TSR-программы... Хотя, они не очень-то хорошо для этого подходят, по моему мнению.. Однако, что-нибудь также придумаем вместе!

А теперь я расскажу об одной полезной функции, которая, по замыслу, должна облегчить работу как программистам, так и пользователям... Это будет что-то вроде "автоматического инспектора системы". Он будет время от времени "проползать" по самым важным местам системы и исправлять по-возможности, "нехорошие" ситуации. Возьмем, к примеру, те же TSR-программы, запущенные в обход системы. Если автор такой программы хочет, чтобы его грубое вмешательство в механизм перехвата прерываний было исправлено, то после завершения работы его TSR-программа оставляет в памяти заглушку вроде jmp far oldvect и какого-нибудь идентификатора... По нему наш "инспектор" определит "честного диверсанта" и корректно его завершит с возвратом прерывания следующему по списку обработчику. Своеобразный "сантехник"!

Или, обнаружив какой-нибудь бесконечный цикл (а как его обнаружишь? но это только пример!), принять решение о вмешательстве... Обязательно такой "инспектор-сантехник" должен быть отключаемым... А то представьте себе, что ваша программа только начала изменять вектор прерывания, а тут вылезает "инспектор" и меняет какую-то часть на свою... Или еще чего похуже. Значит, программист должен установить что-то вроде системного флага о своем желании разрешить/ запретить такое вмешательство. Кстати, этот инспектор запускать часто совершенно ни к чему... Ибо противоречит он все той же идеологии... Раз в 5-10 минут или реже...

(Добавление)
Отсутствие многозадачности
Отсутствие графической оболочки
Отсутствие системы подкачки (свопинга)
Отсутствие кэширования
Объектно-событийная модель
Что необходимо реализовать в новой ОС

Рассмотрим первый пункт более подробно. Отсутствие многозадачности - на мой взгляд, серьезный недостаток данной ОС. Он вытекает как следствие того, что механизм работы DOS основан на прерываниях. Это делает весьма затруднительной (может быть даже невозможной) реализацию многозадачности. Как известно, многозадачные системы основаны на виртуальных машинах (ВМ). Каждый выполняющийся процесс работает в свой ВМ, управляемой менеджером ВМ. В ОС Windows этим менеджером является VMM32. Все процессы не работают напрямую ни с памятью, ни с другим оборудованием. Доступ ко всем устройствам обеспечивают драйверы виртуальных устройств. Это дает большие преимущества над прерываниями, так как любую возникшую ошибку можно обработать и генерировать Exception (исключение) и не допустить сбоя в выполняющемся процессе. Так же это дает преимущества и в защите, так как процессы выполняются в различных областях памяти (тоже виртуальных). И, наконец, сама многозадачность - это постоянное переключение между процессами. Некоторые, конечно, заблуждаются, думая что это переключение затормаживает систему. Но это неверно, поскольку каждый процесс имеет свой приоритет. Переключение на процессы с более низким приоритетом производится реже, чем на процессы с высоким приоритетом. Таким образом, время переключения несоизмеримо со временем выполнения самих процессов.
Все это отсутствует в DOS.
Теперь перейдем к графическому интерфейсу. Кто-то, возможно, скажет, что в DOS это легко поправить. Но сразу возникнет вопрос: ведь ОС DOS рассчитана на работу в текстовом режиме. Как будут работать в ней другие программы? К тому же, это не принесет большой пользы при отсутствии механизма ВМ, так как этот графический интерфейс не сможет делать ничего, кроме как служить в качестве файлового менеджера.
В DOS также не реализована система подкачки - использования диска в качестве оперативной памяти. Здесь надо заметить, что существующие программы DOS, которые якобы осуществляют подкачку при отсутствии свободной памяти, на самом деле просто записывают значения некоторых переменных в файл и освобождают место в памяти, храня их в файле до тех пор, пока они вновь не понадобятся. Это не есть подкачка. Возьмем для примера систему свопинга в Windows. Процессы, выполняющиеся при недостатке памяти, даже и не подозревают о том, что они используют диск, так как они работают (как уже было сказано выше) в виртуальной области памяти, которой управляет менеджер ВМ. Он и осуществляет подкачку в случае недостатка памяти. Это происходит совершенно без ведома самой программы. При этом совершенно необязательно, чтобы в файл подкачки помещались именно значения переменных. Туда может помещаться абсолютно все. То есть файл подкачки является как бы "продолжением" оперативной памяти. Таким образом, количество выполняющихся процессов в системе с ВМ и свопингом практически ограничено только объемом свободного места на диске или максимальным объемом файла подкачки.

Продолжение следует…

Андрей Лукичёв (pasprog@narod.ru), DNK Software 22 марта 2002 г.

Внимание! Все, кто согласен, можете также писать сюда, в этом разделе будем собирать всех недовольных... (baldr)

(Добавление)

Имхо, подобного рода публикации это в первую очередь дикларации о намерениях. Покуда не будет серьёзного подхода к решению вопроса, будут писать. Все эти плюсы и минусы давно известны. Исходя из них мы и пытались создать Life cd. Но, простите, есть вещи, которые могут реализовать на данный момент только профессиональные программисты и которые старым софтом не заменить.