OSDev

Честно говоря, не думаю, что общих представлений достаточно. Вон, у приснопоминаемого Максимыча эти представления были -- "Вындовз-подобная ось" :) Скорей, сначала нужен, так сказать, эскизный проект, в котором детально проработана "глобальная" архитектура и т.п. вещи.

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

Ну так "общие представления" можно по-разному подразумевать. В том числе как "эскизный проект".

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

ОС слишком абстрактная вещь, так что не просто взять написать проект. ОС это не приложение.

Не настолько она абстрактна. А точнее, она, в общем-то, нередко более конкретна, чем сложное бизнес-приложение на ранних стадиях разработки: потому что заказчики бизнес-приложений зачастую плохо понимают, что они хотят и что нужно написать, в то время как ОС пишутся фактически программистами для программистов (ведь основной "экспортный продукт" ОС -- это API).

Это понятно. Говоря здесь об ОС, думаю, мы все-таки имеем в виду ядро и варианты его использования совместно с другим базовым ПО (вторичными загрузчиками, драйверами, различными менеджерами/системными сервисами и, максимум, оболочкой), не более того. Лично я по большому счету занимаюсь не разработкой ОС, а именно разработкой ядра. Все, что я написал сверх того, мне было нужно лишь для того, чтобы тестировать ядро во взаимодействии с другим ПО и просто в комфортных условиях.

Так и есть, по большому счёту. Однако ядро само по себе не имеет никакого смысла, так что, ИМХО, нужно начинать именно с определения того, какие сервисы ядро будет предоставлять прикладным программам и как будет осуществляться взаимодействие. Фактически нужно описать API, однако голых заголовков функций здесь недостаточно. Так, следует описать методы управления памятью, которые ОС предоставляет в распоряжение прикладных программ (например, поддерживается ли совместное использование одной области памяти несколькими программами и если да, то как это дело разруливается).

Понятно, что сходу создать достаточно полное описание не удастся: для этого нужен приличный опыт, а его надо нарабатывать на практике. Но, тем не менее, бросаться в кодирование очертя голову не следует даже начинающим, всегда полезно сначала подумать, порисовать схемки на бумаге, почитать умные книжки (не зубрить, а ознакомиться с темой, так сказать -- всё равно без практики многие вещи останутся недопонятыми, даже если в теории всё вроде бы ясно).

В зависимости от архитектуры ОС, приложение может даже и не иметь прямого контакта с ядром, если в ОС многоуровневая система сервисов. Поэтому на начальном этапе проектирования лучше не зарываться в дебри, а начать с ядра, которое управляет только аппаратными ресурсами (но это ещё не ОС, и даже не похожа на неё). После этого можно придумывать различные сервисы и API, начать делать ОС.

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