OSDev

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

SII, всё познаётся в сравнении. Взять, например, мелкософтовскую Сингулярити: тут и управляемый код, и всякая страшная консистентность... Взять кембриджскую Немезиду: экзоядро, доменная защита и области видимости имён. Взять Л4: рекурсивное наследование памяти, конструкция адресных пространств, синхронные айписи. А в Винде что? - Да известно что...

Я считаю, что и открытые "без бюджетные" системы могут достаточно интенсивно развиваться. Всё дело в мотивации. В закрытых проектах мотиватор - деньги. В "форумных" системах мотиватором может выступать чувство принадлежности к сообщесву. Для многих такое чувство дороже всяких денег. Т.е. открытое сообщество разработчиков - это немного секта:) В нём люди занимаются любимым делом, с полной выкладкой, и так же, свои "скандалы, интриги, расследования". В коммерческих проектах руководитель должен планировать финансовые риски и регулировать потоки средств. В волонтерских проектах - поддерживать жизнь сообщества и подкреплять интересы. Вот чего непросто достичь, так это чёткой структуры добровольного сообщесва разработчиков. Хотя и здесь может быть своя система рангов и ответственностей, формальных правил и соглашений, короче: полный добровольный коммунизм.

Хотел бы я посмотреть на ось, в которой нет загрузчика, многозадачности и виртуальной памяти. Даже и прославляемых тобой виртуальных машинах всё это есть. Как пример - Андроид, надстроенный над линуксом.
Подход, исповедуемый тобой, грешит тем, что до самого конца, когда не будут реализованы все части проекта, нисходящий проект не может быть ни показан, ни опробован в работе. В восходящем же подходе могут быть сделаны модули, которые с одной стороны могут быть вполне независимыми и самодостаточными, с другой стороны, части проекта уже могут быть отлажены ещё задолго до запуска всего нисходящего монстра, ошибки которого станут видны, когда перепроектировать уже будет поздно.
Я же придерживаюсь точки зрения, что подход обязан быть встречным. То есть:
1. Глобальное проектирование обязательно должно быть ещё до начала работы. Иначе проект превратится в кучу лихорадочных заплаток а-ля Линукс.
2. Проект должен быть модульным. Вообще модульность отдельная тема для разговора. Мне очень нравится монография Майерса "Надёжность программного обеспечения" на эту тему. Каждый проектируемый модуль должен быть в значительной мере самостоятельным и универсальным.
3. Кодировать надо помодульно в восходящей последовательности, так чтобы весь проект в каждый момент работал и мог быть интенсивно тестируемым.
4. Вся сборка фактически первоначально состоит из комплекта модулей-заглушек, связанных идеологическим каркасом и должна уметь запускаться и создавать видимость работы на любом этапе работы. В таком случае разработку можно вести в любой точке - или кодировать модули, или править идеологический каркас. В то же время в любой момент времени система доступна для интенсивного тестирования.

Что касается видимости. Если, например, я публикую начальные загрузчики, это совершенно не обязательно означает, что я начал с них и кроме них больше ничего нет. Это может означать, например, что этот модуль вошёл в стадию финишной прямой и достаточно качественно спроектирован, чтобы быть самодостаточным и пригодным для независимого использования другими разработчиками. Заодно стороннее использование модуля может помочь его более тщательно отладить.
А избегать обсуждения рабочего проекта я, например, могу по той причине, что не хочу ввязываться в бесконечные идеологические войны, т.к. истина может быть установлена только практикой.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Упрощённо излагая:
- Нисходящая разработка изобилует ошибками реализации и не обеспечивает действительно качественное проектирование.
- Восходящая разработка даёт отвратительное проектирование.
- Только встречная и модульная разработка обеспечивает как хорошее проектирование, так и минимум глюков реализации.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

В моей оси нету многозадачности (таймер ещё не задействован), но я могу открывать несколько окошек, которые будут делать свои дела одновременно, одно музыку играть, другое файлы качать с диска, третье ещё что то. Почти все операции в современных компьютерах это отправка процессором команд устройствам, это миллисекундные операции для него, а устройства сами работают с оперативкой и побайтовых перегонов проц уже давно не делает. Причём если устройство уже занято, то на него другой процес не повесишь или сам потом будешь не рад от результата. На звукавуху можно посылать несколько звуков одновременно, на винты, флешки в очередь ставятся в их список задач, это всё не многозадачность. Таймер буду использовать только для анимации и будильника всем желающим приложениям. Виртуальной памяти тоже нету и мысли её создании нету, 4 гига я задействовать при всём желании не смогу, самые мои буйные фантазии прог запущенные несколько раз и одновременно с другими не выходят за пару соток метров, а они поинтереснее чем у винды.
Как винда раздулась до 7гигов на диске не понимаю, от 95ой отличается не сильно, то что она из себя представляет знаю прекрасно. Даже страничной адресации нету ещё, но много, что работает и понадобится ли она мне в итоге (не уверен ещё).
Проектировал как раз не с точки зрения драйверов, загрузчика, а с точки зрения вариантов механизма работоспособности системы и их быстродействии. После чего взял самый быстродействующий и стал думать о загрузчике, асме, драйверах.

Yoda

Андройд - плохой пример.. Даже самому себе.
ОС без загрузчика - Любая ОС, находящаяся в неразрушаемой памяти, ПЗУ, программном FLASH'е и т.д. Да хоть реализованная "в железе", на примере тех же Форт или Джава процессоров.
ОС без многозадачности: MS-DOS.
ОС без виртуальной памяти: AmigaOS, AROS, MorphOS, Angel, BMX, Mungi, Iguana, Texas, Nemesis, Opal, Sombrero, Torsion, Baremetal, Br1X, Scout, Singularity, IBM i, Symbolics Genera, Oberon, Forth, Jnode } Краткий список гениальнейших проектов в области OSDev'а. Так же, практически все встраиваемые и ОСРВ не имеют поддержки виртуальной памяти.
(Вообще, считаю достаточно кривой абстракцией эту вашу виртуальную память. Лежит у меня на полке AVR ATmega8A у которого 1Kб оперативы и 8Кб флеша (в котором лежит ВМ), а главная программа может исполняться напрямую с 32Мб внешней флешки. Это значит, что в микроконтроллере реализована виртуальная память? И кстати, в системе нет никакого загрузчика)

Я, конечно, понимаю, что из двух зол обычно выбирают оба, но всё познаётся в примерах. К тому же, любой метод, претендующий на универсальность, должен быть достаточно формализован (а порой и верифицирован). Т.е., если ты знаешь действительно эффективный метод проектирования систем, попробуй изложить его на языке математики, логики, в виде алгоритма, или ещё как нибудь. Чтобы можно было взять набор требований и правил, подать на вход того же алгоритма, а на выходе было некое подобие готовой системы. Компьютеры ведь уже давно компьютерами рассчитываются .. Чем операционные системы сложнее? А пока ты не привёл подобного примера, я буду придерживаться проверенного математикой "поиска с возвратом", в народе называемого: "метод проб и ошибок" или, ещё проще говоря: "метод тыка".

Процесс инициализации там всяк присутствует.

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


Фанатика переубеждать себе дороже.

Почему фанатика? - Вас тут несколько.

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