OberonCore

Познакомившись с системой BlueBottle (A2), я стал размышлять о способах внедрения в неё разных интересных GNU/non-GNU проектов, например, таких как: X11, GTK+. Портировать кросс-платформенные проекты в A2 и использовать проекты, написанные другими людьми.
Допустим, неплохо было бы запустить GNOME на A2. Ну и тому подобное. А то получается, нет моста между новой идеей и реальным миром; все нужно начинать с нуля, как учиться ходить.

Откорректировал.

Возможно "добавить ПО" и имеет свои плюсы, но добавив X-ы, в убъёте ZUI. А факт добавления всего остального постепенно приведёт к убиванию и других полезных вещей, ради которых переноска ПО и затевалась.

Я думаю, что принцип X Window System не отрицает существование ZUI. Ведь это вопрос реализации.
Идея совместной ПО-платформы давно используется в UNIX-системах. Благодаря кросс-платформенности можно переносить приложения с небольшими изменениями.
А при текущей ситуации с BlueBottle выходит, что нельзя использовать прежний человеческий труд (много проектов прикладных систем, библиотек и тому прочих). Итого, получаем систему, малоприспособленную под нужды сегодняшнего дня. Вместо эволюции системы и ПО получили революцию, а вот что с ними делать (кроме академических интересов) - вообще не ясно.
Если же построить мост к BlueBottle, то можно использовать уже придуманное до нас. Ведь, вправе выбирать между тем какие части стоит состыковывать, а какие - не браться вообще.

Зачем? Что это даст.
Я, к примеру, думаю сделать возможность использовать виновс-dll в A2, когда появиться свободное время. И это связано с тем, что некоторые вещи легче использовать чем портировать.

Но в портирование X Window System я не вижу никакого смысла...

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

прикидывал на SQLite - используется только файловые операции и операции со временем, что практически реализуемо.
Другой вопрос о стабильности SQLite, я сильно сомневаюсь, что удастся сделать защиту... это самая большая проблема.

VirtualAlloc наверняка тоже используется, как без этого..

А защита - да, тут проблемно.

Ввести изоляцию в систему, где она с ядра не предусмотрена, вряд ли легко.

Я не конкретно о X, а вообще. X - простой пример проекта, на котором построены многие проекты.

P.S. А на этом форуме принято не по теме писать? Илья?

Принято придерживаться темы.
Вопрос о перетаскивании native-DLL (разницы-то нет тут между виндузовскими и GNU-шными, по существу) связан с темой.

Меня это интересует чисто с теоретической части. Если подходить с практической, то действительно придется вносить изменения в ядро, для защиты памяти, что весьма непросто реализовать, т.к. в А2 вся память плоская и доступна для всех процессов.



Подождите, Вы не указали способ "скрещивания":
Вы написали:"я стал размышлять о способах внедрения в неё разных интересных GNU проектов", но не указали на уровне исходных текстов или бинарных модулей!
Т.ч. попрошу без намеков!
Я предложил один из вариантов. С учетом того, что PE является упрощенным вариантом ELF я ни на йоту не отступил от Вашего вопроса, просто я дополнил конкретикой сходной задачи.

их слишком много... и все придерживаются темы... теперь и я тоже

Вот Вирт когда-то вывел систему команд CPU из требования компиляции ЯВУ. И получилось гораздо лучше, чем выдумки из головы по принципу "добавим еще и такую штуку на всякий случай".

Какую-то такую же логику можно ведь провести и в отношении гуйного API оси -- т.е. вывести систему примитивов из требования обеспечить работу оболочек вроде ББ или ББ.

Как бы провести это дело систематически?
Наверное, что-то в этом роде фактически сделано в БлюБ?

Интересно. В последнее время как раз об этом думал. А где об этом можно почитать?

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

Если кто-то что-то знает, хорошо бы сюда инфу.

По обсуждаемой теме (от языка - к проектированию системы команд) точно было у новосибирцев-кроносистов. Там же могут быть и ссылки на Вирта.

http://kronos.ru/

Спасибо!

----

Улыбнула фраза из введения по архитектуре процессора:

В программировании, конечно, скрестить можно что угодно с чем угодно. Вот только в Native варианте ничего внедрить в А2 не получится, так как исполнение компонент на другом языке (тем более на Си) не укладывается в идеологию системы. А случаи скрещивания А2 on Win/Lin с тамошним окружением я не рассматриваю. Не интересно в принципе.

Если оживить проект JAOS http://www.ocp.inf.ethz.ch/forum/index.php/topic,170.0.html можно было-бы перенести в А2 что-то из Java приложений.
В конце октября мне пришла копия письма Бернарда Трютвейна (Bernhard Treutwein) к Патрику Райли (Patrik Reali) с просьбой оценить сколько усилий может потребоваться для оживления проекта JAOS

Тройтвайна

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