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

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

V>>Это меня еще в Сингулярити насторожило. Ты решил пойти этим же путем??? Сколько всего виртуальной памяти будет доступно суммарно для всех программ на 32-битной архитектуре? Или мы на эту архитектуру не позиционируемся?

V>>Насчет выигрыша в производительности — это понятно. Но более похоже на шаг назад.

М>Я же говорил только про изоляцию процессов, а насчёт виртуального адресного пространства ничего не говорил. Просто можно избежать проверок при обращении к памяти — уже не плохо.

Просто тебе не подойдет ни одно ядро/микроядро под 86-ю архитектуру при таком раскладе. С 0-ля придется делать.

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

Кстати, подкидываю еще одну идею.

Раз твоя ОС будет как Сингулярити работать в плоской модели памяти, то задача начального макетирования резко упрощается. Саму ОС можно будет разрабатывать прямо в виндах или в чем угодно.

Тебе необходимо будет разработать лишь некий высокоуровневый HAL и — вперед, с песней. А так же несколько адаптеров-эмуляторов устройств для основных оных ввода/вывода: диск, клава, мышь, экран.

ИМХО, не нужно связываться ни с ассемблером (пока) ни с регистрами и пр. Прямо на С++ можно накатать HAL и процедуры инициализации. Остальное — на C# и уже прямо сейчас.

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

V>ИМХО, не нужно связываться ни с ассемблером (пока) ни с регистрами и пр. Прямо на С++ можно накатать HAL и процедуры инициализации. Остальное — на C# и уже прямо сейчас.

Ага. Только в Сингулярити есть Барток. И это самое сложное.

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

V>>ИМХО, не нужно связываться ни с ассемблером (пока) ни с регистрами и пр. Прямо на С++ можно накатать HAL и процедуры инициализации. Остальное — на C# и уже прямо сейчас.

AVK>Ага. Только в Сингулярити есть Барток. И это самое сложное.

А в виндах есть C++/CLI

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

К Муравью — могу помочь накатать каркас такого HAL и несколько эмуляторов устройств к нему: диска, видео, мыши и клавы.

Технически реализовать так:
видео, клава и мышь — на основе сообщений нативного окна виндов
диск — как файл фиксированного размера.

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

AVK>>Ага. Только в Сингулярити есть Барток. И это самое сложное.

V>А в виндах есть C++/CLI

А при чем тут это?

V>На нем можно накатать эмулятор внешней аппаратуры для ОС и заодно выставить интерфейсы, понятные .Net. Если разработка созреет для чего-то более реального, то тогда уже можно будет смотреть на полудотнетный-полунативный Барток.

Я что то не понял. Кто в самом начале будет выполнять IL?

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

V>>На нем можно накатать эмулятор внешней аппаратуры для ОС и заодно выставить интерфейсы, понятные .Net. Если разработка созреет для чего-то более реального, то тогда уже можно будет смотреть на полудотнетный-полунативный Барток.

AVK>Я что то не понял. Кто в самом начале будет выполнять IL?

В самом начале кто-то должен загрузить в память VM .Net. Этот "кто-то" очевидно весьма нативен по отношению к конкретному процессору, так же же как и джит. Оставляем эту процедуру загрузки "за кадром", т.е. делаем ее в виде заглушки, скажем, использовав JIT от MONO. Не думаю, что загвоздка в этом. Нам даже не важно КАК ИМЕННО это будет сделано в конечном варианте.

Я просто предолжил Муравью сразу перейти к той части ОС, которая managed, не ломая голову над процедурой начальной загрузки. Т.е. предложил перейти к "интересной" части, оставив ненужные подробности на потом. Более того, "плоская" модель памяти позволит отлаживать все это на имеющихся ср-вах разработки.

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

V>Я просто предолжил Муравью сразу перейти к той части ОС, которая managed, не ломая голову над процедурой начальной загрузки. Т.е. предложил перейти к "интересной" части, оставив ненужные подробности на потом. Более того, "плоская" модель памяти позволит отлаживать все это на имеющихся ср-вах разработки.

Заходите на проект, он сейчас открытый, только всё теперь на английском языке.

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

V>Это меня еще в Сингулярити насторожило. Ты решил пойти этим же путем??? Сколько всего виртуальной памяти будет доступно суммарно для всех программ на 32-битной архитектуре? Или мы на эту архитектуру не позиционируемся?

А смысл на нее позиционироваться то? Ведь чисто 32-битных процессоров больше почти не выпускается.

V>Насчет выигрыша в производительности — это понятно. Но более похоже на шаг назад.

Гы-гы. По больше бы таких шагов! Полная защищенность с минимальными накладными расходами. Даже расширение не может убить приложение. (это я все о Сингулярити).

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

4wd>Во-первых, писать ОС с нуля нереально, значит надо где-то взять готовый код,

Нереально? Жаль создатели Сингулярити этого не знали.
Они написали полностью менеджед ОС с нуля.

4wd>симпатична лицензия BSD, которая не запрещает закрывать код.

В этом нет смысла, так как BSD — это уже микроядерная ОС построенная на принципе аппоратной защиты процессов.

4wd>За основу я решил взять NetBSD и интегрировать в ядро
4wd>поддержку .NET. Только вот с исходниками mono проблем куда больше — сегодня ты их используешь — завтра тебя
4wd>таскают по судам.

Это явное преувеличение.

4wd>Во-вторых, что делать с драйверами? На каком коде писать драйвера? Делать их модулями ядра?

Ну, ты крут. BSD не позволит тебе это сделать. Она микроядерная!

4wd> Тогда тоже придется писать
4wd>их на неуправляемом коде.

И в чем тогда управляемось ОС? ОС то как раз будет та же что и сейчас. А в польсзовательских процессах все так же будет болтаться дотнет.

Вот Сингулярити как раз полнсотью управляемая. Даже драйверы пишутся в безопасном коде.

4wd>Во-третьих, что делать с графикой?

Кремлевские мечтатели, блин. Вам бы хоть прототип запустить которых в двух процессах "Даров, мир!" выведет. А вы о графике?

4wd>mono сейчас работает через glib, который использует xlib и так далее. Если делать в ядре
4wd>поддержку .NET, то куда девать графическую систему?

Да, что уж там о графие. Ты лучше о 3D-играх подумай. Ведь они в 80% случаев через D3D работают. Вот это проблема. Его ведь и лицензионно спионерить не реально, и портировать на ОС отличную от Винды не просто.

4wd> Писать поддержку WinForms под Иксы

Иксы? Да ты хотя бы их реализуй. По сравнению с ними библиотечку накропать труда не представляет.

4wd> или графику в ядро интегрировать?

Ага. И для этого конечно за основу взять BSD. Куллл!

4wd>И наконец, объем работы нереальный. Некоммерческий проект такого не потянет, это очевидно.

Сингулярити проект чисто исследовательский. Правда под него скорее всего гранты есть.
Вот только мечты ваши не реальные. Знаний ваших явно недостаточно. Вы бы прежде чем мечать почитали бы базовую литературу.

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

V>Раз твоя ОС будет как Сингулярити работать в плоской модели памяти, то задача начального макетирования резко упрощается. Саму ОС можно будет разрабатывать прямо в виндах или в чем угодно.

Ага. Резко! Вот только остается написать свой:
1. Барток (компилятор в нэйтив код).
2. ЖЦ.
3. Шедулер задач.
...

В общем, много чего. Хотя конечно стартовать можно и по проще. Просто переделывать Моно или Ротор. Но это тоже задача еще та.

V>ИМХО, не нужно связываться ни с ассемблером (пока) ни с регистрами и пр. Прямо на С++ можно накатать HAL и процедуры инициализации. Остальное — на C# и уже прямо сейчас.

А зачем при этом связываться с С++? Такой ХАЛ можно и на Шарпе какатать. Даже в безопасном режиме, не говоря уже об небезопасном.

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

AVK>Ага. Только в Сингулярити есть Барток. И это самое сложное.

В приципе можно попробовать вмест Бартока задействовать Феникс. Но не факт что выйдет. Хотя очень даже может быть, так как Феникс же позволяет и нэйтив-код править.

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

V>А в виндах есть C++/CLI

И зачем он нужен?

V>На нем можно накатать эмулятор внешней аппаратуры для ОС и заодно выставить интерфейсы, понятные .Net.

Этулятор можно на JScript.Net написать. Хрет там делать то? Тоже мне задача проэмулировать порты процессора и т.п. Ведь никто не знает что там делается то внутри!

V> Если разработка созреет для чего-то более реального, то тогда уже можно будет смотреть на полудотнетный-полунативный Барток.

Барток написан на C#, к твоему сведению.

Блин, твое неверие в C# и жотнет смешит до изнеможения.

Проблема управляемой ОС в ГИГАНСТКИХ объемах работы! А так же в знаниях и неординарности ума тех кто будет делать эту работу. Хотя конечно работа уже не на ровном месте и многие идеи можно покомуниздить из Сингулярити и Оберон ОС.

V>К Муравью — могу помочь накатать каркас такого HAL и несколько эмуляторов устройств к нему: диска, видео, мыши и клавы.

Это то как раз не сложно. Он и сам справится. Ты ему лучше помоги сделать замену Бартоку, шедулер задач, управление памятью, интерфейс между процессами. Вот это задачи.

Я уверен на 100% что все это не выйдет за рамки обсуждения. Хотя в глубене души очень хочется чтобы вышло.

V>Технически реализовать так:
V>видео, клава и мышь — на основе сообщений нативного окна виндов
V>диск — как файл фиксированного размера.

Еще раз. Зачем нужна эта нэйтивная часть? Что ты не сможешь сэмулировать регисты видеокарты или SATA? Тут скорее нужно иметь знания о том как устроены эти устройства и о их протоколе. А неуправляемый код тут вовсе не нужен.

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

VD>А смысл на нее позиционироваться то? Ведь чисто 32-битных процессоров больше почти не выпускается.

Выпускаются. Младшие модели семпронов, целероны, VIAшный камень.

Здравствуйте, Аноним, Вы писали:

V>>Я просто предолжил Муравью сразу перейти к той части ОС, которая managed, не ломая голову над процедурой начальной загрузки. Т.е. предложил перейти к "интересной" части, оставив ненужные подробности на потом. Более того, "плоская" модель памяти позволит отлаживать все это на имеющихся ср-вах разработки.

А>Заходите на проект, он сейчас открытый, только всё теперь на английском языке.

УРЛ?

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

V>> Если разработка созреет для чего-то более реального, то тогда уже можно будет смотреть на полудотнетный-полунативный Барток.

VD> Барток написан на C#, к твоему сведению.

VD>Блин, твое неверие в C# и жотнет смешит до изнеможения.

Знаешь, что мне напоминает твое замечание?
Большинство современных FORT или LISP (Scheme) систем написаны соответственно на FORTH или LISP. Да, именно так. Даже компиляторы оных, которые компилируют слова Форта или лямбды Лиспа в нативный код... И каждая следующая версия пишется на предыдущей... Только вот незадача-то, с голых текстовых сырцов это все не поднимается само, как Мюнгаузен не мог вытянуть сам себя за волосы из болота. В поставке идут бинарники этих систем, с помощью которых будущие версии этих систем и собираются.

И при чем тут имеющийся C#??? Для такой ОС с плоской памятью нужен несколько другой джит (это отдельная тема). Т.е. эмулятор такой ОС — это нативное приложение, в которое загружается джит (вернее VM). Этот джит исполняет все остальное.

И уровней отладки в процессе разработки тут несколько:
1. Уровень отладки эмулятора и самого JIT
2. Уровень отладки managed-частей ядра
3. Уровень отладки приложений


VD>Проблема управляемой ОС в ГИГАНСТКИХ объемах работы! А так же в знаниях и неординарности ума тех кто будет делать эту работу. Хотя конечно работа уже не на ровном месте и многие идеи можно покомуниздить из Сингулярити и Оберон ОС.

А так же массу готового кода как джита, так и основных стандартных либ в MONO или других реализациях (MONO — самая зрелая ИМХО)

V>>К Муравью — могу помочь накатать каркас такого HAL и несколько эмуляторов устройств к нему: диска, видео, мыши и клавы.

VD>Это то как раз не сложно. Он и сам справится. Ты ему лучше помоги сделать замену Бартоку, шедулер задач, управление памятью, интерфейс между процессами. Вот это задачи.

В плоской модели памяти я это сделаю на C# Или тут уже ты не веришь в его возможности. По шедуллингу есть просто тонны инфы, на первых порах подойдут самые простые алгоритмы. Управление памятью — бери из WinNT (Microsoft подробно специфицировала алгоритм выделения и учета виртуальных страниц — более чем просто). Однако, это еще не все.. Сдается мне, что управляя плоской моделью памяти, никто не мешает "двигать" ее не только в рамках домена, но и в рамках вообще всей памяти. Т.е. проблема фрагментации "всей" памяти не должна стоять остро.

Кстати, зачем делать замену Бартоку? Барток был введен для удобства, я могу потерпеть и без удобств. Меня C# и его unsafe-расширение вполне устраивают.


VD>Я уверен на 100% что все это не выйдет за рамки обсуждения. Хотя в глубене души очень хочется чтобы вышло.

V>>Технически реализовать так:
V>>видео, клава и мышь — на основе сообщений нативного окна виндов
V>>диск — как файл фиксированного размера.

VD>Еще раз. Зачем нужна эта нэйтивная часть? Что ты не сможешь сэмулировать регисты видеокарты или SATA? Тут скорее нужно иметь знания о том как устроены эти устройства и о их протоколе. А неуправляемый код тут вовсе не нужен.

Хм... я вообще регистры эмулировать не буду. На первых порах я драйвер целиком эмулировать буду на основе сообщений виндов и GDI (целиком). Я же говорил о БЫСТРОМ старте. Все те подробности о которых ты говоришь, будучи выделенные в отдельную задачу для отдельного человека( если найдуться охотники) яйца выеденного не стоят. Речь идет о сборке чего-то работающего на коленке одним-двумя разработчиками за несколько вечеров.

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

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

V>>Раз твоя ОС будет как Сингулярити работать в плоской модели памяти, то задача начального макетирования резко упрощается. Саму ОС можно будет разрабатывать прямо в виндах или в чем угодно.

VD>Ага. Резко! Вот только остается написать свой:
VD>1. Барток (компилятор в нэйтив код).

не нужен (отдельная тема)

VD>2. ЖЦ.

Boehm — классика

VD>3. Шедулер задач.


нам прямо сейчас требуется самый качественный шедуллинг??? А если подойдет "обычный", то есть море инфы и реализаций


VD>В общем, много чего. Хотя конечно стартовать можно и по проще. Просто переделывать Моно или Ротор. Но это тоже задача еще та.

Ротор — нет, MONO — да. По Ротору самые интересные части не показаны (в первой версии, вторую не смотрел)

V>>ИМХО, не нужно связываться ни с ассемблером (пока) ни с регистрами и пр. Прямо на С++ можно накатать HAL и процедуры инициализации. Остальное — на C# и уже прямо сейчас.

VD>А зачем при этом связываться с С++?

А зачем Барток? А на чем, интересно ngen.exe написан? И кстати, во втором Роторе исходники ngen.exe присутствуют?

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

VD>>Блин, твое неверие в C# и жотнет смешит до изнеможения.

V>Знаешь, что мне напоминает твое замечание?
V>Большинство современных FORT или LISP (Scheme) систем написаны соответственно на FORTH или LISP. Да, именно так. Даже компиляторы оных, которые компилируют слова Форта или лямбды Лиспа в нативный код... И каждая следующая версия пишется на предыдущей... Только вот незадача-то, с голых текстовых сырцов это все не поднимается само, как Мюнгаузен не мог вытянуть сам себя за волосы из болота. В поставке идут бинарники этих систем, с помощью которых будущие версии этих систем и собираются.

Ты говорил о создании эмулятора HAL-а запускаемого внутри процесса имеющейся ОС чтобы по быстрому начать работать над управляемой частью ОС. И какие тогда могет быть проблемы с компиляцией? Используй себе рантайм от Моно или дотнета.

V>И при чем тут имеющийся C#??? Для такой ОС с плоской памятью нужен несколько другой джит (это отдельная тема). Т.е. эмулятор такой ОС — это нативное приложение, в которое загружается джит (вернее VM). Этот джит исполняет все остальное.

Мозги то не компостируй. Ты говоришь о эмуляторе ХАЛ-а. Вот о нем и говори.


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

VD>>Это то как раз не сложно. Он и сам справится. Ты ему лучше помоги сделать замену Бартоку, шедулер задач, управление памятью, интерфейс между процессами. Вот это задачи.

V>В плоской модели памяти я это сделаю на C# Или тут уже ты не веришь в его возможности...

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

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

VD>>1. Барток (компилятор в нэйтив код).

V>не нужен (отдельная тема)

А, ну-ну.

VD>>2. ЖЦ.

V>Boehm — классика

В лес такие ОС! Мало того что он дерьмо полное, так еще и пол кода вашей ОС будет на С++ написана. Причем это не ОО-код, а низкоуровневневая дергатня с указателями. Багодром, короче.

VD>>3. Шедулер задач.

V>
V>нам прямо сейчас требуется самый качественный шедуллинг??? А если подойдет "обычный", то есть море инфы и реализаций

Что значит сейчас? Это нужно в принципе. Без этого будет не ОС, а МС ДОС. А для старта можно действительно отдельные вещи делать просто под управлением CLR.

V>Ротор — нет, MONO — да. По Ротору самые интересные части не показаны (в первой версии, вторую не смотрел)

И каких же таких частей нет в Роторе, что есть в Моно? Единственное с чем могу согласиться, так это с тем, что можно содержит куда меньше неуправляемого кода.

V>А зачем Барток? А на чем, интересно ngen.exe написан? И кстати, во втором Роторе исходники ngen.exe присутствуют?

А что такое по твоему Барток? Это и есть ngen позволяющий получить законченный исполяемый образ, а не только скомпилированные методы которые без рантайма можно на помойку выбросить.

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

К тому же ты же Ротон не хотел брать в рассчет.

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

V>Здравствуйте, Аноним, Вы писали:

V>>>Я просто предолжил Муравью сразу перейти к той части ОС, которая managed, не ломая голову над процедурой начальной загрузки. Т.е. предложил перейти к "интересной" части, оставив ненужные подробности на потом. Более того, "плоская" модель памяти позволит отлаживать все это на имеющихся ср-вах разработки.

А>>Заходите на проект, он сейчас открытый, только всё теперь на английском языке.

V>УРЛ?

http://www.gotdotnet.com/workspaces/workspace.aspx?id=cc3191af-1b3c-425c-a21d-4729196ec37e

Здравствуйте, <Аноним>, Вы писали:

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

V>>Здравствуйте, Аноним, Вы писали:

V>>>>Я просто предолжил Муравью сразу перейти к той части ОС, которая managed, не ломая голову над процедурой начальной загрузки. Т.е. предложил перейти к "интересной" части, оставив ненужные подробности на потом. Более того, "плоская" модель памяти позволит отлаживать все это на имеющихся ср-вах разработки.

А>>>Заходите на проект, он сейчас открытый, только всё теперь на английском языке.

V>>УРЛ?

А>http://www.gotdotnet.com/workspaces/workspace.aspx?id=cc3191af-1b3c-425c-a21d-4729196ec37e

Будьте проще, коллега: здесь