Hello, S.Yu.Gubanov!
You wrote on Tue, 24 Aug 2004 07:53:21 GMT:

SG> Думаю, что лучше будет завести новую ветку форума для обсуждения этих
SG> вопросов.

SG> Попытаюсь дать понятие модульной системы.

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

Как нетрудно видеть, это требование бессмысленно, поскольку можно систему
разбить на гомогенные подсистемы и объявить модульной подсистему либо
отнести все не удовлетворяющие этому требованию части системы к среде
исполнения. Так, подсистемы ввода-вывода и управления памятью windows
являются частью среды исполнения для модульной оконной подсистемы windows.
Ну и, наконец, само требование гомогенности притянуто за уши.

SG> Причем, среда исполнения может динамически загружать и выгружать части
SG> системы.

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

SG> Почему Виндос с Юниксом не модульные — да потому что разные их части
SG> выполняются в разных средах исполнения — это не гомогенные, а
SG> гетерогенные системы. В тоже самое время Оберон системы являются именно
SG> модульными потому что они устроены "гомогенным способом": поверх железа
SG> работает среда исполнения в которой выполняются модули системы, причем
SG> между модулями, собственно, самой операционки и модулями приложений
SG> пользователя, с точки зрения среды исполнения, нет никакой разницы. В
SG> Виндосе же, поверх железа стоит ядро операционки, а среды исполнения
SG> Win32, DOS, COM и т.д. стоят поверх ядра.

На самом деле, нет никакой разницы в том, есть ли разница между модулями ОС
и приложений.

SG> Драйверы работают в режиме ядра практически не имея никакой среды
SG> исполнения (именно отсутствие среды исполнения заставляет писать
SG> драйверы под Виндос на Си, а не на Си++ т.к. для работы программ
SG> написанных на Си++, как и для работы любых других программ написанных
SG> на объектно ориентированных языках, неоходима среда исполнения Runtime
SG> system).

Это не так. Существует куча драйверов для windows, написанных на С++. И
рантайм для кернел моде тоже весьма кучеряв — тысченка-другая функций
наберется.

SG> Теперь попытаюсь дать понятие компонентной системы.

SG> Компонентная система — это объектно ориентированная модульная система.
SG>

SG> Компонентная система = Модульная система + ООП.

SG> Компонентная система состоит только из модулей и больше не из чего не
SG> состоит.

Здрасте — рантайм-то забыли

SG> Объекты создаются внутри модулей. Модули общаются друг с другом
SG> передавая друг другу объекты, но не просто сами объекты, а полиморфные
SG> переменные ассоциированные с объектами.

Осталось объяснить общественности, что ты понимаешь под "полиморфными
переменными".

SG> Виндос с Юниксом — не компонентные еще и потому что мало того что они
SG> не модульные, но они еще и не объектно ориентированные.

Файловый ввод/вывод и оконная подсистема в windows —
объектно-ориентированные. Если это тебе не очевидно, могу объяснить.

SG> Следствие 1

Следствие из чего?

SG> находящихся внутри одного модуля. Межмодульное наследование возможно
SG> только для абстрактных классов, то есть это даже и не наследование, а
SG> реализация интерфейса.

Дай определение абстрактного класса.

SG> Следствие 2
SG> В общем случае в динамической компонентной системе задача удаления
SG> более не нужных объектов может быть решена только во время исполнения,
SG> а не во время написания компонента. Таким образом, компонентные системы
SG> в общем случае не могут функционировать без встроенного в среду
SG> исполнения сборщика мусора. (В частных конкретных случаях могут, но в
SG> общем случае — нет)

Еще как могут.

SG> Следствие 3
SG> Поскольку между модулями операционной системы и модулями пользователя с
SG> точки зрения среды исполнения нет ни какой разницы, то вся
SG> ответственность за безопасность и надежность системы накладывается
SG> именно на среду исполнения.

Почему не на железо?

SG> 3.1 Программы должны быть написаны на безопасных модульных
SG> языках программирования. Так как в опасных, например на Си или Си++
SG> невозможно заставить среду исполнения пресекать ошибки переполнения
SG> буфера или некорректного приведения типов или разыменования повисших
SG> или каких либо других не корректных указателей.

Это ты Бабаяну расскажи

SG> Компонентные программы, например, можно писать на Оберонах.3.2

SG> http://www.inr.ac.ru/~info21/info/qtocop.htm

Гы-гы. Там написано, что Обероны не удовлетворяют в полной мере требованиям
КОП.

With best regards, Sergey.