OSDev

Вопрос в том - что должна по минимому уметь операционная система, что бы называться таковой. Можно ли назвать осью программу которая стартует из другой оси и обеспечивает корректный возврат. По примеру Windows 9x. И главное - если такая как бы ось не может делать что-то обязательное - как её называть? И как расставить приоритеты в требованиях к оси. По моему главная задача любой операционной системы - облегчить разработку программ..? Что нужно сделать что бы можно было сказать что я написал свою операционную систему? Как определить качество своей работы? Вопросы в общем теоретические.

Вообще, задача оси -- предоставлять сервисы другим программам, которые работают в этой оси. Набор же сервисов, как и всего прочего -- понятие очень растяжимое и сильно зависит от сферы применения. Например, в МС-ДОС, как известно, не было никакой многозадачности (хотя реализовать её можно было бы без особых проблем), ни обеспечения защиты системы и прикладных программ друг от друга (это было невозможно в силу отсутствия аппаратуры управления памятью в 8086), ну а предоставляла она главным образом дисковые сервисы (чтение-запись блоков дисков плюс создание-удаление-переименование-чтение-запись файлов на дисках, использующих файловую систему FAT12, потом ещё FAT16, потом, в ДОСовской части Вынь 9х -- FAT32; с помощью дополнительных драйверов можно было обеспечить работу с другими файловыми системами, например, с лазерными дисками). Сравните это с Виндой -- насколько больше она всего предоставляет.

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

Чем больше сервиса - тем лучше ось? Минимально - чтение и запись файлов + ввод вывод + набор системных утилит. Это нижний предел набора для оси - по моему. Чем больше возможностей тем лучше.
А есть ли ещё критерии для оценки оси. Например энергопотребление. В промышленности это важно.
Множество разрабатываемых проектов решают одну и туже задачу максимально разными способами. При всём многообразии систем - они во многом делаются на основе уже существующих. При этом хотелось бы новых идей не по внутренней организации а по самому определению понятия операционная система. Можно ли написать надстройку над WinXP например и внутри её обеспечить сервис для приложений. Или это будет называется среда выполнения?

Никакой связи между количеством предоставляемых сервисов и качеством ОС нет и быть не может, поскольку к системам предъявляются совершенно разные требования в зависимости от того, для чего они нужны. Если создаётся система для встраиваемого контроллера, то нафига там поддержка графики (не говоря уже о 3Д), файловых систем, загружаемых драйверов и прочая? Зато там наверняка будет чрезвычайно важным малое и, главное, полностью предсказуемое время реакции на прерывания (то, что скрывается за термином "работа в жёстком реальном времени"), а из сервисов нужны главным образом механизмы взаимодействия между задачами (события, мьютексы, семафоры, посылка-получение сообщений и т.п.).

Ну а определения, что такое ОС и т.п., больше философские, так сказать. Например, упомянутая Вами Хрюша может прикидываться и унихом, и почти любой другой ОС -- достаточно создать соответствующую подсистему. Более того, АПИ Вин32, для которого создаются все программы под Винду, на самом деле технически не является родным АПИ той же Хрюши, как и всех прочих ОС семейства НТ -- это тоже подсистема, просто всегда присутствующая в Винде (хотя теоретически и её можно отковырять и выбросить, оставив голое ядро, с которым работать через его настоящий АПИ).

По качеству работы прикладных программ.
Касательно первого вопроса - ОС должна запускать программы (1), поддерживать их бессбойную работу (2), поддерживать их разным функционалом (3).

Где-то здесь на форуме было написано что без чёткого представления о том какая будет ось начинать писать код бессмысленно. Наверно соответствие реального кода и начальной идеи и будет характеризовать операционную систему в плане хорошая или плохая.
Когда определюсь собственно с тем что хочу написать - выложу в виде вопроса в форуме. Чем раньше выявить ошибки проектирования - тем качественнее будет конечный результат.

Вроде как я философствовал на эту тему... Но это вроде как и самоочевидно, если подумать: сделать то -- не знаю что можно только в сказках.



Вряд ли. В конце концов, требования к системе могут меняться в процессе разработки, и на выходе может в итоге получиться совсем не то, что задумывалось изначально.



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

Только не надо гнаться за попыткой объять всё при предварительном проектировании, особенно если проект создаётся в одиночку: всего не заметишь, глаз замыливается и т.п. Если проектируют несколько квалифицированных специалистов, тогда, конечно, намного лучший результат можно получить: то, что проморгает один, заметит второй и т.п. Но в любом случае идеального проекта не будет :)