Здравствуйте, vdimas, Вы писали:

V>В виндах имеет значение. Почитай MSDN на предмет приоритетов worker-тредов и GUI-тредов, а так же как шедуллинг управляет последними. Шедуллинг напрямую на состояние окошек завязан.

Можно ссылку?

V>На самом деле идея такова: есть некий "пояс безопасности" внутри которого есть unsafe и unmanaged-код. Этот пояс: микроядро ОС, HAL, джит и GC. Все остальное должно быть safe managed.

Слишком много неуправляемого кода. Как минимум джит и GC можно сделать управляемыми. "Управляемая" операцинонка с полностью неуправляемым ядром вряд ли кого-то заинтересует. Сие вполне можно сотворить на базе уже существующих ОС + Rotor||Mono.

Что подразумевается под микроядром?

V>Как я понимаю, торг идет относительно долей managed/unmanaged и safe/unsafe внутри пояса безопасности?
V>Это абсолютно неважно на начальном этапе.

При правильном подходе к проектированию архитектуры ОС — возможно. Однако такой подход в данном проекте к сожалению не наблюдается.

V>Правильно мыслишь. Остается вполне обозримый объем работ. Иначе я бы даже не обсуждал это все. И кстати, я не отбросил, а предположил способ реализовать "малой кровью".

Остается командная оболочка?

А что очень удобный подход...

VD>>Значит хреново смотерл. Ключевое слово fjit. Там есть С++-ные и ассемблерные части. Плюс куча всего генерируется при инсталляции с помощью скритов и макросов.

V>Я уверен, что если кто-то будет пытаться разрабатывать эту ОС "по вечерам", то начать такую разработку с собственной разработки джита и GC — заведомо провалить дело. Надо использовать то, что есть. А для того, что есть Барток не нужен.

Начинать разработку надо с проектирования архитектуры ОС. Чтобы понять, что уже "есть", а что нужно будет разрабатывать. Чтобы начать проработку архитектуры, нужно понимать, какие задачи призвана решать будущая ОС. Иными словами знать "зачем?" все это делать. И пока нет архитектуры и плана разработки...