Здравствуйте, Privalov, Вы писали:
C>>А чего у меня передо мной стоит такое с монитором? Под С++ НЕ НУЖНО C>>проектировать железо. P>И, кстати, под еще целую массу языков тоже не нужно.
Не подскажете, случайно, для каких языков потребовался защищенный режим, чтобы написанные на них программы друг друга не "убивали"?
21.01.05 11:53: Ветка выделена из темы Системность
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
AVC пишет:
> C>>А чего у меня передо мной стоит такое с монитором? Под С++ НЕ НУЖНО > C>>проектировать железо. > P>И, кстати, под еще целую массу языков тоже не нужно. > Не подскажете, случайно, для каких языков потребовался *защищенный > режим*, чтобы написанные на них программы друг друга не "убивали"?
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, Privalov, Вы писали: AVC>Не подскажете, случайно, для каких языков потребовался защищенный режим, чтобы написанные на них программы друг друга не "убивали"? :-\
Защита приложений — одна из функций многозадачной операционной системы. При этом не имеет никакого значения, на каком языке программирования реализовано то или иное приложение.
Кстати, это было известно задолго до появления защищенного режима (в Intel 80286), например, OS/360 ни разу не зависла из-за некорректно написанной пользоветельской программы.
Здравствуйте, Privalov, Вы писали:
P>Защита приложений — одна из функций многозадачной операционной системы. При этом не имеет никакого значения, на каком языке программирования реализовано то или иное приложение.
Имеет значение. Да еще какое!
Просто Вы лично не пишете операционных систем.
В Обероне нет "висячих" указателей и возможности нарушить систему безопасности типов (type safety). Вы серьезно хотите сказать, что это не упрощает дизайн системы и не повышает ее надежность?
P>Кстати, это было известно задолго до появления защищенного режима (в Intel 80286), например, OS/360 ни разу не зависла из-за некорректно написанной пользоветельской программы.
Я что-то не понял. Своими интересными аргументами Вы меня в конец запутали.
Когда это OS/360 на 80286 работала?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>Имеет значение. Да еще какое! AVC>Просто Вы лично не пишете операционных систем. AVC>В Обероне нет "висячих" указателей и возможности нарушить систему безопасности типов (type safety). Вы серьезно хотите сказать, что это не упрощает дизайн системы и не повышает ее надежность?
Что, в Оберон-системах приложение может свободно менять содержимое памяти, принадлежащей другому приложению? Или это однозадачная система?
P>>Кстати, это было известно задолго до появления защищенного режима (в Intel 80286), например, OS/360 ни разу не зависла из-за некорректно написанной пользоветельской программы.
AVC>Я что-то не понял. Своими интересными аргументами Вы меня в конец запутали. AVC>Когда это OS/360 на 80286 работала? :wow:
Возможно, я где-то некорректно выразился. Может быть, правильнее будет так.
В операционной системе OS/360 защита памяти не давала возможность пользовательскому приложению нарушить работоспособность системы, если оно некорректно написано. Приложение вылетало либо из-за неправильной адресации, либо из-за невозможности выделить память (GETMAIN), либо по тайм-ауту в случае зацикливания. При этом работа всей системы никак не нарушалась. И это работало задолго до появления защищенного режима.
Здравствуйте, Privalov, Вы писали:
P>Что, в Оберон-системах приложение может свободно менять содержимое памяти, принадлежащей другому приложению? Или это однозадачная система?
В Оберонах нет такого понятия как память (то бишь адресного пространства как такового), хотя указатели есть.
Все что можно сделать с указателем p так это присвоить ему значение другого указателя (соответствующего типа) p := q или NIL, p := NIL, сравнить его значение со значением другого указателя (аналогичного типа) p = q, p # q, или с NIL p = NIL, p # NIL, и, наконец, создать новый объект NEW(p) в том случае если тип объекта, на который он указывает позволяет это сделать, а также разыменовать его p^ получив доступ к объекту на который он указывает (причем сам символ "^", когда он очевиден, писать не обязательно).
Таким образом, вопрос "...менять содержимое памяти, принадлежащей другому приложению" не имеет физического смысла, поскольку в языке нет способа узнать что-либо про память, нельзя получить численное значение указателя (указатель — вещь в себе, его численное значение, если бы его можно было бы получить, оказалось бы вовсе не константой, а то и дело изменялось бы благодаря стараниям сборщика мусора).
А раз так, то необходимость в создании множества виртуальных адресных пространств (для безопасности) больше не существует — достаточно одного единого на всю систему адресного пространства, а безопасность гарантируется языком программирования, рантайм проверками индексов массивов, контролем приведения типов.
Сергей Губанов пишет:
> P>Что, в Оберон-системах приложение может свободно менять содержимое > памяти, принадлежащей другому приложению? Или это однозадачная система? > В Оберонах нет такого понятия как память (то бишь адресного > пространства как такового), хотя указатели есть.
Есть в Обероне понятие "память", как и в других языках. То что оно
/скрыто/ (слабенько так) вовсе не означает, что его нет.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>В Оберонах нет такого понятия как память (то бишь адресного пространства как такового), хотя указатели есть.
Указатели должны на что-то указывать. Стало быть, так или иначе, они хранят адрес указываемого объекта. Возможно, он недоступен пользователю, однако это вовсе не значит, что он не существует.
СГ>Таким образом, вопрос "...менять содержимое памяти, принадлежащей другому приложению" не имеет физического смысла, поскольку в языке нет способа узнать что-либо про память, нельзя получить численное значение указателя (указатель — вещь в себе, его численное значение, если бы его можно было бы получить, оказалось бы вовсе не константой, а то и дело изменялось бы благодаря стараниям сборщика мусора).
А это давно решается с помощью механизма трансляции адресов. По-моему, только в MS DOS реальный и виртуальный адреса всегда совпадают. Но MS DOS — примитивная однозадачная система. В нормальных многозадачных ОС пользовательская программа ничего не знает ни о реальных адресах, ни о других программах, выполняющихся параллельно.
СГ>А раз так, то необходимость в создании множества виртуальных адресных пространств (для безопасности) больше не существует — достаточно одного единого на всю систему адресного пространства, а безопасность гарантируется языком программирования, рантайм проверками индексов массивов, контролем приведения типов.
Выходит, что все приложения выполняются в едином адресном пространстве? Так мы это уже проходили. Windows 3.1 — первое, что приходит в голову.
А если немного поднапрячься, то можно вспомнить персональную ЭВМ "Искра-226" с ее ОС, погруженной в Бейсик-интерпретатор. Она, правда, однозадачная. Гораздо примитивнее MS DOS. Но она грузилась в адресное пространство, недоступное пользовательским программам. И это при том, что в том древнейшем диалекте Бейсика вообще не было указателей и динамического управления памятью. Вот не думаю, что разработчики этой машины (я имею в виду оригинал, "Искра" была с чего-то французского передрана) были глупее нас с вами, предусмотрев подобную "защиту от дурака".
Хотя после "Искры" PC раем земным казался. Это при том, что в нем что угодно можно было с памятью делать.
Сергей,
> В Оберонах нет такого понятия как память (то бишь адресного пространства как такового), хотя указатели есть. Все что можно сделать с указателем p так это <...> Таким образом, вопрос "...менять содержимое памяти, принадлежащей другому приложению" не имеет физического смысла <...> А раз так, то необходимость в создании множества виртуальных адресных пространств (для безопасности) больше не существует <...>
Это в теории. А на практике, как мы выяснили ранее, операции, требующие прямого доступа к памяти, не исчезают, а просто-напросто переносятся с уровня языка на уровень библиотек. Фактически, это означает, что никаких гарантий, что память не будет запорчена, нет. Это, в свою очередь означает, что, в принципе, одно приложение вполне может повлиять на работоспособность всей системы.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, AVC, Вы писали:
AVC>>Имеет значение. Да еще какое! AVC>>Просто Вы лично не пишете операционных систем. AVC>>В Обероне нет "висячих" указателей и возможности нарушить систему безопасности типов (type safety). Вы серьезно хотите сказать, что это не упрощает дизайн системы и не повышает ее надежность? P>Что, в Оберон-системах приложение может свободно менять содержимое памяти, принадлежащей другому приложению? Или это однозадачная система?
Правильно ли я понимаю, что Вы отождествляете приложение и процесс? (По крайней мере, такая логика прослеживается: одно приложение => одна задача.)
В Оберон-системе нет понятия приложение (=программа).
Есть понятия: модуль и команда. Команда — это экспортируемая модулем процедура без параметров. Если Вам приведется воспользоваться Оберон-системой, то вызвать команду легко: щелкаете мышью на строке вроде модуль.процедура.
Один модуль может использоваться сразу многими задачами.
Многозадачность в Обероне может быть как кооперативной так и вытесняющей.
Исторически первая Оберон-система обеспечивала кооперативную многозадачность (single-process multitasking). Отсюда происходит ряд недоразумений в головах критиков Оберона.
Некоторые полагают, что Оберон в принципе не может использовать вытесняющую многозадачность. Это заблуждение.
Вторые полагают, что кооперативная многозадачность должна приводить к обязательному подвисанию системы, если какой-нибудь горе-программист написал бесконечный цикл вроде LOOP END. Это тоже заблуждение.
Третьих беспокоит безопасность ядра Оберона. Это беспокойство мне вообще непонятно, т.к. объекты ядра спрятаны от модулей расширения, а если требуется предоставить к ним доступ (хэндлы), то они экспортирутся в скрытом режиме.
Четвертые (и их, кажется, большинство) не могут себе представить создание нового процесса без UNIX-овского примитива fork(). (При этом они спокойно пишут многопоточные приложения и вопросов у них не возникает.) В Модуле-2 и Обероне-2 каждый процесс безраздельно владеет своими локальными (стековыми) переменными, а для разделяемых переменных существуют мониторы и семафоры.
Пятые убеждены, что для использования механизма исключений необходымы расширения языка, вроде ключевых слов try, catch и throw. Это тоже заблуждение. В ETH Обероне используется другой механизм. С ним можно ознакомиться здесь: http://www.ssw.uni-linz.ac.at/Research/Papers/Hof97b.html
AVC>>Когда это OS/360 на 80286 работала? P>Возможно, я где-то некорректно выразился. Может быть, правильнее будет так.
Это напоминает мне фильм "Человек за бортом": "Ну, может быть, где-то самую малость ты права..."
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Hello, Павел!
You wrote on Thu, 20 Jan 2005 12:06:00 GMT:
??>> В Оберонах нет такого понятия как память (то бишь адресного
??>> пространства как такового), хотя указатели есть. Все что можно сделать
??>> с указателем p так это <...> Таким образом, вопрос "...менять
??>> содержимое памяти, принадлежащей другому приложению" не имеет
??>> физического смысла <...> А раз так, то необходимость в создании
??>> множества виртуальных адресных пространств (для безопасности) больше
??>> не существует <...>
ПК> Это в теории. А на практике, как мы выяснили ранее, операции, требующие ПК> прямого доступа к памяти, не исчезают, а просто-напросто переносятся с ПК> уровня языка на уровень библиотек. Фактически, это означает, что ПК> никаких гарантий, что память не будет запорчена, нет. Это, в ПК> свою очередь означает, что, в принципе, одно приложение вполне ПК> может повлиять на работоспособность всей системы.
Кстати, на практике и в системах с разделяемыми адресными пространствами
приложений нет никаких гарантий, что одно приложение не уронит всю систему.
Вот, например, не далее чем месяц назад у меня запуск Java Web Start
стабильно валил WinXP в синий экран
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Sergey,
> Кстати, на практике и в системах с разделяемыми адресными пространствами приложений нет никаких гарантий, что одно приложение не уронит всю систему.
Потому что на практике системы с разделяемыми адресными пространствами используют общие модули (ядро, драйверы и т.п.) с неизбежным наличием теоретической возможности порчи памяти/whatever...
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Hello, Павел!
You wrote on Thu, 20 Jan 2005 12:25:06 GMT:
??>> Кстати, на практике и в системах с разделяемыми адресными
??>> пространствами приложений нет никаких гарантий, что одно приложение не
??>> уронит всю систему.
ПК> Потому что на практике системы с разделяемыми адресными пространствами ПК> используют общие модули (ядро, драйверы и т.п.) с неизбежным наличием ПК> теоретической возможности порчи памяти/whatever...
Не только. Бага с buffer underflow в csrss.exe обходилась без порчи памяти в
общем адресном пространстве. Скорее уж можно сказать так "потому что на
практике все системы имеют ошибки".
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Павел Кузнецов, Вы писали:
>> Кстати, на практике и в системах с разделяемыми адресными пространствами приложений нет никаких гарантий, что одно приложение не уронит всю систему.
ПК>Потому что на практике системы с разделяемыми адресными пространствами используют общие модули (ядро, драйверы и т.п.) с неизбежным наличием теоретической возможности порчи памяти/whatever...
Действительно, о "разделяемых адресных пространствах" можно говорить с известной долей условности. (Раньше эрудиты писали "cum grano salis". )
Ядро — одно для всех. (Уже одно это должно было бы охладить пыл яростных сторонников отдельных "адресных пространств". )
Но падает все же система не от этого, а потому что ядро написано с ошибками.
Кроме того, именно отдельные "адресные пространства" приводят к экспоненциально растущему перерасходу памяти.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Sergey, Вы писали:
S>Кстати, на практике и в системах с разделяемыми адресными пространствами S>приложений нет никаких гарантий, что одно приложение не уронит всю систему. S>Вот, например, не далее чем месяц назад у меня запуск Java Web Start S>стабильно валил WinXP в синий экран
У меня тоже есть программа (сам написал на Delphi) использует графику GDI+ и DirectDraw7. Так вот, на всех компьютерах работает замечательно, но на ноутбуке шефа при попытке перерисовки мгновенно вываливается в синий экран смерти Windows XP SP2. Вот Вам и виртуальные адресные пространства... Чего я только ни делал пытаясь понять где ошибка. Даже каждую процедуру программы обернул дополнительным блоком try except — бесполезно, ни каких исключений не возникает, моя программа работает корректно, но просто вызывает мгновенную смерть виндос на том злосчастном ноутбуке.
Здравствуйте, Privalov, Вы писали:
P> Выходит, что все приложения выполняются в едином адресном пространстве? Так мы это уже проходили. Windows 3.1 — первое, что приходит в голову.
Повторяю, в оберон-системах, в отличие от Windows 3.1, приложения вообще не знают что такое сырая память. Указатели в них есть, но указывают они не на сырую память, а только на объекты или на массивы, соответственно, никакой адресной арифметики с указателями делать нельзя, а значит нельзя испортить память.
Сергей,
> У меня тоже есть программа (сам написал на Delphi) использует графику GDI+ и DirectDraw7. Так вот, на всех компьютерах работает замечательно, но на ноутбуке шефа при попытке перерисовки мгновенно вываливается в синий экран смерти Windows XP SP2. Вот Вам и виртуальные адресные пространства... Чего я только ни делал пытаясь понять где ошибка. Даже каждую процедуру программы обернул дополнительным блоком try except — бесполезно, ни каких исключений не возникает, моя программа работает корректно, но просто вызывает мгновенную смерть виндос на том злосчастном ноутбуке.
То, что в процессе работы программы никаких исключений не возникает, еще не означает, что она работает корректно. Вообще, с помощью DirectX "уронить" компьютер достаточно легко, т.к., фактически, это способ работать с драйверами почти напрямую. Естественно, вариант ошибки в драйверах на "злосчастном ноутбуке" тоже исключить нельзя.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Сергей Губанов, Вы писали:
СГ>У меня тоже есть программа (сам написал на Delphi) использует графику GDI+ и DirectDraw7. Так вот, на всех компьютерах работает замечательно, но на ноутбуке шефа при попытке перерисовки мгновенно вываливается в синий экран смерти Windows XP SP2. Вот Вам и виртуальные адресные пространства... Чего я только ни делал пытаясь понять где ошибка. Даже каждую процедуру программы обернул дополнительным блоком try except — бесполезно, ни каких исключений не возникает, моя программа работает корректно, но просто вызывает мгновенную смерть виндос на том злосчастном ноутбуке.
Думаешь если бы оно было на обероне было бучше
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Сергей Губанов пишет:
> P> Выходит, что все приложения выполняются в едином адресном > пространстве? Так мы это уже проходили. Windows 3.1 — первое, что > приходит в голову. > Повторяю, в оберон-системах, в отличие от Windows 3.1, приложения > вообще не знают что такое сырая память. Указатели в них есть, но > указывают они не на сырую память, а только на объекты или на массивы, > соответственно, никакой адресной арифметики с указателями делать > нельзя, а значит нельзя испортить память.
Hint: найдите все свои письма со словами "внешнаяя библиотека"...
AVC пишет:
> Четвертые (и их, кажется, большинство) не могут себе представить > создание нового процесса без UNIX-овского примитива *fork()*. (При > этом они спокойно пишут многопоточные приложения и вопросов у них не > возникает.) В Модуле-2 и Обероне-2 каждый процесс безраздельно владеет > своими локальными (стековыми) переменными, а для разделяемых > переменных существуют мониторы и семафоры.
Ах... Как все просто в теории. А теперь к суровой реальности:
Как в Обероне борются с ресурсожорами? Начнет какой-нибудь поток
бесконечно жрать память — упадет ВСЯ система. Значит нужны квоты. Но на
ЧТО ставить квоты, явных процессов ведь нет?
Точно так же — нужно обеспечить учет дефецитных ресурсов (сетевых
соединений, открытых файлов и т.п.), изоляцию приложений, работающих с
разными привиллегиями, механизмы обхода защиты и т.п. В итоге получится
тоже самое, что и в Юниксе/Винде.
