OSDev

Можно ввести поддержку приложений для другой оси на уровне ABI/API, и если такая система станет хоть сколько-нибудь популярной, можно начинать писать приложения с использованием родного ABI/API. Для завоевания популярности нужно наличие хоть каких-нибудь фишек, выгодно отличающих ваше творение от других ОС (особенно от той, из которой вы портируете/берете приложения). Узко специализированную нишу найти не трудно. Если у вас есть хоть одно приложение, которого нет ни под одну другую ось (которое чем-то выгодно отличается от аналогичных приложений под другие оси), то с этим приложением можно продвигать и систему в целом.

Разработчики самопальных осей пытаются объять необъятное, когда начинают писать под свою систему офисные приложения, браузеры, вьюверы и т.п. Нафига мне такая самопальная ось с такими же самопальными приложениями, когда я могу взять значительно более качественный аналог в виде какой-либо популярной системы?

Причём начинают их писать, не имея нормально работающего ядра и т.п. Моё ИМХО здесь простое: 1) делается нормальное ядро и некий минимум драйверов без особой оглядки на API популярных систем (но с достаточно функциональным родным API, чтобы сверху на него наложить другие); 2) делается прослойка для эмуляции некоторого популярного API (POSIX, Linux, Win32 -- не важно в данном случае), что даёт возможность использовать готовые программы; 3) по мере возможности и необходимости пишется прикладное ПО под родной API.

Во-во. А потом начинают ядро перекраивать под приложения и просто его "допиливать". Что мешало написать простые тестовые приложения для тестирования ядра, не понятно. Разве что пустить пыль в глаза наивным юзерам, что есть, дескать, браузер и т.п. (про качество такого ПО обычно скромно умалчивают).

Об этом я и говорил.

Абсолютно согласен!
Однако, есть грустные нюансы:

АПИ имеющихся систем может иметь такую кривизну, которую не сэмулируешь (по крайней мере, разумными средствами), а тащить это гуано в свой АПИ не хочется. Печально известный пример - системный вызов fork семейства Unix.

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

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

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

Что в fork такого особенного? Обычное создание процесса с дополнительными условиями и, соответственно, на основе этого вызова и может быть съэмулирован. Если в VM есть COW, создание процесса-копии выполняется достаточно быстро.

Гораздо хуже с драйверми. Они как правило очень много от ядра хотят в плане знаний о его внутреннем устройстве. Насколько можно использовать их? Я только два проекта находил по использованию драйверов линукс - в L4 и очень старый - для Mach (но там ещё от линукс 1.Х). Оба какие-то вялые - особых успехов не видно...

В том-то и дело, что это необычное создание процесса, реализованное через ж..., пардон, полное копирование всего адресного пространства имеющегося процесса, включая открытые файлы, обработчики сигналов и прочие ресурсы. Порождение весьма больной фантазии. И ладно бы, если бы существовал альтернативный механизм создания процесса, а этот атавизм медленно отмирал бы, но в архитектуре Unix это единственный способ создать новый процесс. К счастью, за системным вызовом fork почти всегда следует системный вызов exec. В этих условиях эмуляция возможна на уровне библиотек. Однако, на чистый fork я, пожалуй, забью.

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

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

D-S, насчет fork'а согласен - он больше тяжеловесный, чем труднореализуемый. Yoda, если делать прослойку на уровне ядра, а не на уровне прикладных библиотек, то реализовать fork не так уж и сложно. Он меня раздражает в принципе, а не из-за того, что его трудно реализовать.

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