Внимание! Эта статья может показаться кому-то сказкой или утопией, однако автор абсолютно серьезен. Возможно, некоторые позиции рассматриваются с позиции исключительно пользователя (то есть, что бы хотелось видеть), а не с позиции программиста (что возможно сделать), однако автор еще раз напоминает, что он пока :) не претендует на звание профессионала в программировании и надеется на помощь более квалифицированных людей.
По-моему, идея 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 минут или реже...