Разработка концептуально новой ОС

Цитата Vilmor, 11.09.03, 14:10:59

По-хорошему, надо завести на каждую проблему по отдельному треду, в идеале - на отдельном форуме. Ещё лучше - на отдельном сайте.

По этому поводу есть у кого-нибудь какие-нибудь соображения? Сами сделаем, или помощи ждать будем?

Есть предложение: не "распыляться".
То есть, сначала полностью согласовать только ядро.
И сделать его полностью универсальным, чтобы потом можно было на него "навесить" любую архитектуру верхнего уровня ОС.

А если сейчас начать сайт делать, то большая вероятность, что им и закончится... (то, что закончится и без сайта - тоже вероятно  :(, но ..се ля ви)

Цитата Vilmor, 11.09.03, 12:42:56

Люди! Читайте внимательнее! Я уже устал повторять одно и то же!

Взаимно..  ;)

Цитата

Во-первых, если он открывает диалоги, то он должен знать о GUI, который ему СОВЕРШЕННО НЕ НУЖЕН. Это значит, что на бездисплейных машинах прийдётся запускать GUI. Более того, даже тогда ничего не выйдет, поскольку пользователь не сможет работать с диалогом (нет дисплея!), и значит, ПП не сможет получить результат работы диалога SaveAs. Вообще, тогда приложение обламывается, потому что оно не может использовать диалог SaveAs, работающий в GUI. А файлы-то по-прежнему сохранять куда-то надо! Что делать? Понапихать в ПП до кучи разных вариантов выбора файла. Эти варианты потребуют не только GUI, но и ещё чёрт знает что.... Ваш ПП раздувается и приобретает поистине громадные размеры, потому что содержит тысячу бессмысленных зависимостей от ненужных здесь модулей и интерфейсов. А если понадобится тысяче первый?  Если у того же модуля будет расширен интерфейс? Вы кинетесь обновлять ПП, чтобы и приложение смогло иметь доступ к этим позможностям?

Вот к чему приводит смешение функциональности разных компонент в одной-единственной компоненте!
Я вам говорил, а вы не хотите слушать.

Поймите, я же не против ПП! Я толко против такой глупой реализации!
Пусть будет ПП! Он, конечно же, нужен! Но зачем его привязывать к GUI?

Ну что за напасть: идеи понимаются чуть ли не с точностью до наоборот..

С чего Вы взяли, что диалог FileSave связан с GUI ??? Он появился за десятки лет до GUI !
И через консоль он реализуется, как правило, следующим образом:
MCR> Enter File Name:
path\myfile.ext <enter>

Путаница возникает из-за того, что термин "пользовательский интерфейс" тоже содержит слово "интерфейс", хотя с точки зрения ООП это объект со своим (программным!) интерфейсом.
Так как система объектная, то в ней должен существовать Интерфейс пользовательского интерфейса (ИПИ).
GUI или консоль - это лишь частные РЕАЛИЗАЦИИ ИПИ.

В системе должен быть единый ИПИ (по крайней мере, нужен достаточно функциональный базовый предок - но вопросов наследования я пока не касаюсь).
Это позволит даже в консольном режиме запустить аналог MS Word-а (который даже не будет знать, что работает с консолью, а не GUI !), открыть в нем документ и даже редактировать его.
Конечно, пользователь сможет лишь догадываться, как выглядит применяемое им форматирование, но текст он увидит правильно. В конце концов, он может воспользоваться одним из стандартных стилей, и "довериться" ему.

В консольном режиме можно будет запустить даже PhotoShop!!
Конечно, придется работать "вслепую", но, например, сохранить рисунок в другом графическом формате или сделать негатив можно и не видя его.

Цитата

И потом, вы предложили идею ПП, но не сказали, на каком основании он будет решать, каким из приложений пользователя он будет давать тот или иной ключ, а каким - нет. Если не знаете - посмотрите, как это сделано в UNIX - там это предусмотренно. Не хотите делать как в UNIX - всё равно посмотрите, может, у вас мысли какие-нибудь новые идеи появятся.

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

Цитата

Пожалуйста, если хотите сделать настоящую ОС, а не самоделку, то узнайте об этом побольше. Одного знания ключей явно не хватит!

Узнавать и делать - часто жестко конкурирующие процессы.
По идее, для того и форум, чтобы объединять знания..

Но есть еще один момент.
Все ОС писали все же не глупые люди.
Поэтому шанс сделать что-то лучше есть только  если в идейном плане "подняться над" всеми наработками и делать принципиально новое.

Концептуальный момент.

В системе Unix понятие файла приобрело некоторую нагрузку понятия ключа.
Возникает очевидное желание объединить эти понятия в одно.
Лет пять назад я тоже думал, что так и надо, но.. это невозможно.
То есть объявить их одним и тем же, конечно, можно - но возникнут неустранимы неувязки.

Понятие ключа нужно строго разграничить с понятием файла - между ними есть только внешнее сходство (иерархичность), но не содержательное.

Файл - это просто именованный кусок данных и НИЧЕГО более. Это НЕ интерфейс, НЕ устройство и НЕ точка монтирования.

Все эти "НЕ" переносятся (уже в виде "да") в понятие ключа.

Ключ - это в первую очередь идентификатор интерфейса. Между интерфейсами и ключами взаимно-однозначное соответствие.
Существенным отличием ключа от файла является то, что иерархия ключей генерируется динамически (с "нуля") в процессе работы системы.

Ссылка на файл теперь представляется в виде: ключ\\имя.
Это не то, чтобы ново - достаточно вспомнить URL.

Лучше не распыляться на разные темы, а сконцентрироваться на архитектуре ядра.
Ядро предполагается универсальным.
Здесь уместна аналогия с Интернет. В системе ядро - это то же самое, что TCP/IP в Интернете.
А на одном протоколе можно построить почти любую сеть.
Поэтому создание ядра - совершенно обособленный этап (если соблюсти универсальность).

Первоначально нужно определить архитертурные элементы.

Предложения.

Для ядра понятие объекта должно быть тождественно приложению (=процесс=задача).
Это не запрещает объекту средствами своего интерфейса эмулировать внутри себя подобъекты.

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

Все сообщения для ядра имеют вид WM_COPY_DATA (произвольная последовательность байтов) - то есть, имеем аналог TCP/IP.
Содержимое и внутренний формат сообщений находится вне компетенции ядра, поэтому являются темой отдельного обсуждения (как технически "оформлять" интерфейсы).

Первые технические вопросы.
1) Какими инструкциями делать системный вызов.
2) Где хранить очередь сообщений (Post- и SendMessage, для RunMessage очереди нет).

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

Цитата

Люди! Читайте внимательнее! Я уже устал повторять одно и то же!

Даже трижды.

Цитата

Первые технические вопросы.
1) Какими инструкциями делать системный вызов.
2) Где хранить очередь сообщений (Post- и SendMessage, для RunMessage очереди нет).

На это эже здесь мы отвечали.
1) через int.
2) В структуре задачи(потока-процесса) будет стек сообщений (сортированный по приоритетам.).
struct task{
...
     Queue *queue;
...
}
и примерно
struct Queue{
   Queue *next;
    dword MessageCode
    void * buffer
    ...
}
При обработке сообщения буффер копируется в адресное пространство процесса. (При посылке сообщения из процесса). При синхронных сообщениях, копирование можно попробовать избежать.

Сообщение отредактировано: rcz - 11.09.03, 18:35

Цитата rcz, 11.09.03, 22:34:40

На это эже здесь мы отвечали.
1) через int.
2) В структуре задачи(потока-процесса) будет стек сообщений (сортированный по приоритетам.).
При обработке сообщения буффер копируется в адресное пространство процесса. (При посылке сообщения из процесса). При синхронных сообщениях, копирование можно попробовать избежать.

Я не утверждал, что не отвечали. Но обсуждения этого вопроса по сути не было. Желательна аргументация. Потом, вероятно, у кого-то есть другие варианты.

Предложения не бесспорны.

1) Почему int, а не call? Функционально эти команды полностью эквивалентны, и различие только в используемой таблице дескрипторов. (Или есть тонкости?)
Но у меня есть подозрение, что команда int (по логике) должна быть привилегированной - тогда чисто технически останется call.
Еще нужно определиться с передачей параметров: использовать ли для этого регистры, или все через стек.

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

Цитата

1) Почему int, а не call? Функционально эти команды полностью эквивалентны, и различие только в используемой таблице дескрипторов. (Или есть тонкости?)
Но у меня есть подозрение, что команда int (по логике) должна быть привилегированной - тогда чисто технически останется call.
Еще нужно определиться с передачей параметров: использовать ли для этого регистры, или все через стек.

Можно и шлюз вызова call, Но IMHO int удобней. Передача параметров: На пользовательском уровне используется стек, при переходе в ядро, ему передаются регистры, указывающие на стек.
Привилегии int (как и привилегии любого дескриптора i386) можно установить.

Цитата

2) Сортировка сообщений - очень спорный момент. Это нарушает причинность (временную последовательность) - есть смысл, чтобы сообщения приходили в порядке их отправки. Правда, придется предусмотреть меры против "спама".

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

Цитата

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

Тут будет ясней при реализации. Т.е. у процессов разные адресны пространства, придется их по-разному проецировать. Желательно, чтоб копирование было только однократным.

Цитата nvm, 11.09.03, 20:01:43

Ну что за напасть: идеи понимаются чуть ли не с точностью до наоборот..

С чего Вы взяли, что диалог FileSave связан с GUI ??? Он появился за десятки лет до GUI !

Потому что он использует программный интерфейс пользовательского интерфейса.

Цитата nvm, 11.09.03, 20:01:43

И через консоль он реализуется, как правило, следующим образом:
MCR> Enter File Name:
path\myfile.ext <enter>

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

Наверное, я чего-то недопонял в вашей идее, но скажите мне, пожалуйста, вы знаете, что таким образом нарушается один из основных принципов программирования - не допускать ненужных зависимостей между компонентами ПО?

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

Цитата nvm, 11.09.03, 20:01:43

Путаница возникает из-за того, что термин "пользовательский интерфейс" тоже содержит слово "интерфейс", хотя с точки зрения ООП это объект со своим (программным!) интерфейсом.

Вот этого я никогда не путал.

Цитата nvm, 11.09.03, 20:01:43

Так как система объектная, то в ней должен существовать Интерфейс пользовательского интерфейса (ИПИ).
GUI или консоль - это лишь частные РЕАЛИЗАЦИИ ИПИ.

1. Следовательно, ПП будет зависеть от "частных реализаций ИПИ". И в этом весь ужас!
2. Объектно-ориентированная среда (ООС) никогда не подразумевала обязательного, необходимого наличия ИПИ, и вообще какого-либо пользовательского интерфейса (ПИ). ПИ может быть только результатом использования ООС для сугубо прикладных нужд, но не может и не должен обслуживать нужды самой ООС.

Извините, но для меня это настолько очевидные вещи, что мне трудно подвергать их сомнению.

Цитата nvm, 11.09.03, 20:01:43

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

ИМХО, этим самым мы ограничиваем применение нашей ОС до рамок систем с обязательным, интерактивным пользовательским интерфейсом.

Предлагаю всем ознакомиться с этим документом:
http://www.cis.upenn.edu/~KeyKOS/OSRpaper.html

Цитата rcz, 12.09.03, 00:44:18

Можно и шлюз вызова call, Но IMHO int удобней. Передача параметров: На пользовательском уровне используется стек, при переходе в ядро, ему передаются регистры, указывающие на стек.
Привилегии int (как и привилегии любого дескриптора i386) можно установить.

Тогда действительно нет разницы int или call. Вопрос становится чисто идеологическим: как "красивее"  :)
А указатель на стек и так доступен в TSS - там же, кстати, и все остальные регистры.

Цитата

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

Это все предусмотренно в типе сообщений RunMessage. Они создают новый поток, поэтому обрабатываются без очереди. По сути RunMessage это и есть прерывание.

Цитата rcz, 11.09.03, 17:47:11

Хост надо искать. ( Платные -  8-20$ в мес. Есть и бесплатные. Но их качество - образно говоря MySQL нет)

Я готов оплатить свою часть.

Цитата rcz, 11.09.03, 17:47:11

форум можно какой-нить phpBB (Или как здесь YaBB).
Помимо HTML немного только знаю о ASP и ASP.NET. Опыта создания сайтов нет.
IRC - пока не обязателен.

phpBB или YaBB SE (PHP + MySQL)

Здешний YaBB написан на Perl, что не может не радовать, но для хранения использует плоские файлы, и это SUXX.

Кстати, свой mailing list нам не повредит.

Цитата

Предлагаю всем ознакомиться с этим документом:
http://www.cis.upenn.edu/~KeyKOS/OSRpaper.html

Только что мы изобрели велосипед

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

Цитата

Я готов оплатить свою часть.

Будем платить.

Сообщение отредактировано: rcz - 12.09.03, 07:55

Цитата rcz, 12.09.03, 11:39:03

Только что мы изобрели велосипед

Угу. Там много чего интересного. Не всё оттуда для нас годится, но и там высказывается мысль, что всё аппаратное I/O прячется от посторонних в режим ядра (типа HAL). Конечно же, не это там главное... Внимательно читая, узнаещь много интересного. Например, вполне оправданный отказ от очередей сообщений и механизм RETURNа. Но в KeyKOS в одном процессе может сидеть только один объект, а если надо больше - то это уже другой уровень абстракций, которого там нет

Цитата rcz, 12.09.03, 11:39:03

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

Кстати, об имени. Хорошо бы каждый придумал своё, а потом бы мы проголосовали.

Цитата rcz, 12.09.03, 11:39:03

Будем платить.

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

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

Думаю, нам потребуется:

1. SSH-доступ.
2. FTP-доступ.
3. Perl5.
4. PHP4.
5. MySQL - отдельная БД с одним аккаунтом.
6. Хостинг - можно виртуальный.
7. Массовая рассылка через Sendmail.

Цитата Vilmor, 12.09.03, 10:40:11

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

Да ни от чего он не зависит!!

Цитата

Наверное, я чего-то недопонял в вашей идее

Да.. причем, наверное, основное.. :-[

Цитата

Я считаю, что ПП не может требовать внимания пользователя для одобрения открытия каждого файла приложения.

А я разве предлагал хоть что-то подобное?!
Я рассматривал пример, когда пользователь САМ (по своей инициативе) хочет сохранить файл.
Эта ситуация не имеет никакого отношение к той, когда инициатива обращения к файлу исходит от приложения!

Цитата

Поэтому самому ПП и не нужно работать какими-либо средствами взаимодействия с пользователем.

В общем случае не нужно. В основном, приложение взаимодействует с ИПИ напрямую.
Но если приложению нужно убедить систему, что некоторое действие санкционировано пользователем - только в этом случае используется посредничество ПП (при этом ПП обращается к пользователю через свой интерфейс - а может вообще не обращаться).
Вообще, это только одна из возможностей, которую вовсе не обязательно использовать.

Цитата

И следовательно, модулю подсистемы безопасности не нужно использовать программные интерфейсы пользовательских интерфейсов - GUI и консоли.

Если пользователь реально никогда не будет логиниться в системе - то не нужно.
Но если физическое присутствие пользователя за монитором в принципе допускается, то ПП желательно с ним "общаться".

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

Здесь как раз гибкость - никто никого ни к чему не обязывает: ПП может знать ИПИ, а может и не знать.

Цитата

1. Следовательно, ПП будет зависеть от "частных реализаций ИПИ". И в этом весь ужас!

А это с чего???
Во-первых ИПИ хоть для консоли, хоть для GUI абсотютно одинаков (то есть на консоль вполне можно послать картинку - правда, уйдет она на null).
Все частные реализации как раз скрыты. Общаясь через ИРИ программа даже не знает, что на "том конце": telnet, GUI или просто другое приложение.

Цитата

2. Объектно-ориентированная среда (ООС) никогда не подразумевала обязательного, необходимого наличия ИПИ, и вообще какого-либо пользовательского интерфейса (ПИ). ПИ может быть только результатом использования ООС для сугубо прикладных нужд, но не может и не должен обслуживать нужды самой ООС.

Извините, но для меня это настолько очевидные вещи, что мне трудно подвергать их сомнению.

Так я их не то чтобы подвергаю сомнению - наоборот, пытаюсь довести до абсолютизма  :-[

Цитата

ИМХО, этим самым мы ограничиваем применение нашей ОС до рамок систем с обязательным, интерактивным пользовательским интерфейсом.

Ничего подобного.
Если программа не находит желаемого интерфейса - она пытается обойтись теми, что есть.
Вообще, по замыслу в системе обязательно только ядро  :D

Цитата nvm, 12.09.03, 13:15:29

Да ни от чего он не зависит!!

Мы понимаем под этим разные вещи.
Насколько я понял, вы имеете в виду, что ПП может обойтись без ПИ, но он в любом случае знает и поддерживает ИПИ.
Я же под этим подразумеваю, что ПП вообще ничего не знает об ИПИ. Если он всё же его знает и как-то его пытается использовать, то он уже зависит от ИПИ.

Грубая аналогия: мы линкуем программу с библиотеками. Даже если мы никогда не используем ни одной ф-ции из библиотеки, но в программе где-то есть ссылка на неё, библиотека обязательно прилинкуется, даже если это и не нужно. Вот вам и зависимость.

Цитата nvm, 12.09.03, 13:15:29

А я разве предлагал хоть что-то подобное?!
Я рассматривал пример, когда пользователь САМ (по своей инициативе) хочет сохранить файл.
Эта ситуация не имеет никакого отношение к той, когда инициатива обращения к файлу исходит от приложения!

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

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

Цитата nvm, 12.09.03, 13:15:29

В общем случае не нужно. В основном, приложение взаимодействует с ИПИ напрямую.
Но если приложению нужно убедить систему, что некоторое действие санкционировано пользователем - только в этом случае используется посредничество ПП (при этом ПП обращается к пользователю через свой интерфейс - а может вообще не обращаться).

Это было бы здорово, если бы для приложения имело смысл убеждать в этом систему. Но как я сказал выше, в этом необходимости нет - дыра в заборе совсем рядом.

Цитата nvm, 12.09.03, 13:15:29

Здесь как раз гибкость - никто никого ни к чему не обязывает: ПП может знать ИПИ, а может и не знать.

Думаю. правильнее было бы сказать, что ПП может использовать ИПИ, а может и не использовать. Но знать оно должно всегда, если, конечно мы не собираемся делать 2 разных варианта ОС. А поскольку ПП будет обязан всегда знать об ИПИ, то мы будем обязаны с каждой новой версией ИПИ исправлять код в ПП.

Цитата nvm, 12.09.03, 13:15:29

А это с чего???
Во-первых ИПИ хоть для консоли, хоть для GUI абсотютно одинаков (то есть на консоль вполне можно послать картинку - правда, уйдет она на null).
Все частные реализации как раз скрыты. Общаясь через ИРИ программа даже не знает, что на "том конце": telnet, GUI или просто другое приложение.

Хотелось бы верить, что можно было бы создать универсальное ИПИ, поддерживающее и консоль, и окошки, и вообще всё-всё-всё... но не верится

Цитата nvm, 12.09.03, 13:15:29

Так я их не то чтобы подвергаю сомнению - наоборот, пытаюсь довести до абсолютизма  :-[

Мне кажется, что такое решение - шаг вперёд, но два шага назад. Стремясь сделать лучше, в результате получаем ещё хуже.