StormDos - один из немногих проектов, которые в вечном в поиске идельной реализации. Выпустив множество редакций своей ос, автор всё равно не теряет веру в то, что лучший вариант ещё впереди! И давая интервью, тот предупредил - что всё это ещё не точно и может измениться...

Расскажите о той мысли, что привела вас к разработке собственной системы?
  Собственно говоря, давно это было. В мае 2001 года, когда я учился в выпускном классе, мне как-то пришла идея написать ради интереса программу, которая бы загружалась с дискеты и печатала что-нибудь на экране без помощи ОС. Причём, эта программа была написана на Си--. В то время очень интересовался низкоуровневым программированием, и данным языком/компилятором (http://c--sphinx.narod.ru). Первые успехи разбудили бурный интерес в дальнейшем развитии программы и вскоре к идее создания ОС типа MS-DOS, однако некоторая лень и нехватка времени (выпускной класс, вступительные экзамены и т.п.) свели на нет освоение мной Си--, т.к. язык очень отличался от Си и соответственно мной делалось множество ошибок, о которых я даже не подозревал. В итоге решил перейти на более мне знакомый ассемблер, а именно NASM. NASM очень прост в освоении и, как мне кажется, не страдает двусмысленностью записи, в отличие от более "навороченных" коммерческих аналогов (TASM, MASM). Море информации по 16-битным системам и относительная простота позволили быстро написать рабочий загрузчик ОС и мини-ядрышко SD-16, способное уже на многое. Исходные тексты этого ядра, интерпретатора команд и некоторых простых приложений можно загрузить с сайта www.stormdos.nm.ru . Однако, 16-битная архитектура имеет довольно серьёзные ограничения в адресации, ограничение в 64 киб довольно быстро начинает надоедать. Поэтому вскоре я занялся изучением 32-битного защищённого режима и архитектуры IA-32.

Сделайте обзор вашего инструментария
   Вопрос об инструментах разработки довольно трудный, т.к. я окончательно не могу заявить о том, что определился с выбором в пользу того или иного языка или компилятора. Уже SD-32 я пробовал писать и в Linux на GCC и на FPC, затем в Windows используя DJGPP, затем перешёл на FreePascal, недавно выбрал OpenWatcom C/C++. Одно знаю точно - писать ядро надо на языке высокого уровня, по крайней мере для начинающих, т.к. возможности отладки программы сильно ограничены в условиях "вне ОС", а алгоритмы в ядре довольно сложны, например менеджер памяти (с разделением на real-mode, DMA регионы) и файловая подсистема... Про паскаль могу сказать одно - глючный дебагер под Windows не позволил мне выявить ошибку в некоторых алгоритмах и я решил перейти на си, где я могу воспользоваться разными отладчиками и компиляторами. Кроме того паскаль не использую для написания других программ, т.к. не всё WinAPI переведено на паскаль и по другим причинам с этим связанным. Среди компиляторов я могу выбрать только бесплатные, поэтому на Delphi разработка ОС или тестирование частей не проводилось. OpenWatcom я выбрал т.к. он компилирует в несколько раз быстрее GCC, поддерживает вставки на ассемблере синтаксиса MASM, имеет нормальный отладчик для Windows, автоматическую обработку зависимостей в утилите WMAKE. Последнее явилось в итоге критическим аргументом - я не переношу мудрёные скрипты automake/configure, так широко распространённые в мире Linux GCC. Кроме того, OpenWatcom умеет создавать ELF файлы и не нужно забивать голову всякими там компоновочными скриптами и т.д., что нужно в случае LD (из binutils)...

Поведуйте нам о внутреннем устройстве вашей ОС.
   Пока ещё чётко не определена структура ОС, хотя есть пару десятков набросков и планов. Могу сказать только, что на совместимость с другими ОС расчитывать не стоит, главным образом из-за модели памяти, а именно в части использования динамически подключаемых библиотек. Я довольно долго размышлял над реализацией данного механизма, а именно организации страничной адресации, виртуальной памяти и т.п. и пришёл к выводу, что у меня никогда не будет столько свободного времени, чтобы реализовать всё это качественно и эффективно (программирование - это моё хобби, совсем не связанное с моим образованием и специализацией), поэтому модель памяти имеет схожий с SD-16 (и с MS-DOS) характер - все программы выполняются в одном адресном пространстве. Это в дальнейшем можно улучшить, добавив страничную адресацию и маскирование страниц при переключении процессов, но это уже, если и осуществимо, то в далёком будущем. Возмножности DLL будут предоставлены в виде глобальных объектов (интерфейсов), как это в SD-16. Т.е. программа регистрирует объект в системе с передачей указателей на функции, ведётся учёт используемых ресурсов и т.п.

Какие мысли вы уже превратили в явь?
   Реализовано мало, до самого необходимого костяка ещё далеко. А вообще уже есть: менеджер памяти (с учётом выделения из регионов, доступных для BIOS, DMA, получение информации о доступных областях от GRUB; "куча" в ядре); планировщик задач (вытесянющая многозадачность); вызов прерываний BIOS (через Virtual Mode 80x86).

Что задуманно на будущее?
  Cинхронизация процессов, драйверы, файловая подсистема, IPC, архитектура глобальных объектов, интерпретатор команд. Поскольку даже Линукс не позволяет использовать все возможности моего компьютера (нет драйверов под некоторые устройства, например сканер и модем), то я вообще не имею права расчитывать на сколь серьёзное положение моей ОС. Пишу её чисто для удовольствия и самосовершенствования.

Расскажите об участниках проекта
   Участник пока только я один ;) Да и на таком начальном этапе больше и не нужно - главное сделать костяк, а потом уже могут присоединяться другие люди и помогать наращивать систему. Дело в том, что сами части ядра настолько взаимосвязаны, что разрабатывать их в раздельности не представляется возможным. Ну вот например, ковыряю я модуль, отвечающий за вызов BIOS через VM86, а тут понадобилось подправить модуль, отвечающий за потоки и процессы... Т.е. поручить одному делать VM86, другому оброботчики исключений, третьему планировщик не получается...

Узнать больше об SD можно здесь - www.stormdos.nm.ru , www.stormdos.sf.net. Как видно даже после столь длительного опыта автор ещё не говорит смело об архитектуре ос. Но мы то точно скажем, что обязательно будем надеяться об её изменениях только в лучшую сторону!