AVC>Не подскажете, случайно, для каких языков потребовался защищенный режим, чтобы написанные на них программы друг друга не "убивали"?
Правильный ответ — для языка ассемблера, точнее, для машинных кодов.
Так как большинство языков транслируются в машкоды — то, соответственно и для всех языков.
Если в Оберон-ОС предполагается, что для написания ВСЕХ программ поголовно используется Оберон-2, то можно несколько упростить защиту. Не дай Вам бог после этого написать что-то хитрое на встроенном ассемблере (который, насколько я помню, в Обероне есть)!
И не дай бог потребуется в Оберон-ОС переносить компилятор языка с меньшей типозащищенностью, (того же С)!
Здравствуйте, Cyberax, Вы писали:
C>То есть мне еще и нужно думать как "экспортировать" объекты между C>модулями, выполняющимися в одном треде? Если так, то В МОРГ.
Пользовательскому приложению думать не нужно.
Но операционке над этим приходится думать всегда. Процессор не делает в этом плане практически ничего. И разделяемую память, и маппинг файла в память, и OLE приходится настраиватиь или делать операционке.
C>Да еще учитывая, что повсюду используются глобальные переменные...
Они не глобальные в самом глобальном смысле. Это глобальные переменные в рамках модуля.
C>Короче говоря: BlueBottle — игрушка, без защиты памяти, разделения C>процессов, без нормальной поддержки потоков, исключений, C>многопользовательской работы. В качестве учебного примера или для C>специальных целей — сойдет, но на что-то большее — не потянет.
Ну конечно это не Win2003, (так же как и любая другая операционка )
Ты как-то странно относишься к этим понятиям. BlueBottle имеет и защиту памяти и разделение (модулей) и потоки и исключения (свои ). Только делается это на софтварном уровне.
Ты же в курсе про managed code. Всё там есть.
>> По поводу открытых файлов, соединений и пр — те же самые проблемы >> возникают и в обычной ОС. C>Где проблемы? При закрытии процесса прибиваются все открытые им handle'ы.
Ну я об этом и говорю: операционка за этим следит сама. Проц никакие сетевые подключения не мониторит. Я ваще не понимаю, к чему ты написал "А как насчет открытых
сетевых соединений?"
>> Вообще не нужно думать, что изоляция адресного пространства решает >> какие-то глобальные проблемы: по прежнему приходится отслеживать >> каждый "пук". C>Чего отслеживать? В нормальных ОС если одна программа сделает GPF, то C>это не скажется на работе остальных.
Здесь тоже не скажется. GPF не портит данные. А OC и пользовательские программы всё равно работают палаллельно и независимо.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Poudy пишет:
> C>То есть мне еще и нужно думать как "экспортировать" объекты между > C>модулями, выполняющимися в одном треде? Если так, то В МОРГ. > Пользовательскому приложению думать не нужно. > Но операционке над этим приходится думать всегда. Процессор не делает > в этом плане практически ничего. И разделяемую память, и маппинг файла > в память, и OLE приходится настраиватиь или делать операционке.
Ладно, попробую объяснить еще раз. Вот в Юниксе (да и в Винде) есть
дерево процессов, каждый процесс независим от другого (если не
используются специальные механизмы IPC). Если мы прибиваем один процесс
или дерево — это не влияет на остальные процессы.
А что будет у нас в Обероне, если прибить модуль System, например?
> C>Да еще учитывая, что повсюду используются глобальные переменные... > Они не глобальные в самом глобальном смысле. Это глобальные переменные > в рамках модуля.
Да, и модуль может быть загружен только один раз. Так что они
глобальные, просто с ограниченной зоной видимости.
> C>Короче говоря: BlueBottle — игрушка, без защиты памяти, разделения > C>процессов, без нормальной поддержки потоков, исключений, > C>многопользовательской работы. В качестве учебного примера или для > C>специальных целей — сойдет, но на что-то большее — не потянет. > Ну конечно это не Win2003, (так же как и любая другая операционка ) > Ты как-то странно относишься к этим понятиям. BlueBottle имеет и > защиту памяти и разделение (модулей) и потоки и исключения (свои ). > Только делается это на софтварном уровне. > Ты же в курсе про managed code. Всё там есть.
Несерьезно, так как в managed-код нельзя засунуть все, что нужно. А если
все-таки это попробовать сделать — получится точно то же самое, что уже
есть, только в managed-коде.
>>> По поводу открытых файлов, соединений и пр — те же самые проблемы >>> возникают и в обычной ОС. > C>Где проблемы? При закрытии процесса прибиваются все открытые им > handle'ы. > Ну я об этом и говорю: операционка за этим следит сама. Проц никакие > сетевые подключения не мониторит. Я ваще не понимаю, к чему ты написал > "А как насчет открытых сетевых соединений?"
Это означает, что Oberon-ОС должна следить за открытыми дефецитными
ресурсами (а они *будут*), а для этого "плоская модель процессов" уже не
подходит.
> C>Чего отслеживать? В нормальных ОС если одна программа сделает GPF, то > C>это не скажется на работе остальных. > Здесь тоже не скажется. GPF не портит данные. А OC и пользовательские > программы всё равно работают палаллельно и независимо.
GPF потом и не портит данные, что ОС предоставляет защиту. А кто помнит
времена ДОСа — знает, что там одна прога могла легко запортить всю память.
Здравствуйте, Borisman2, Вы писали:
B>Если в Оберон-ОС предполагается, что для написания ВСЕХ программ поголовно используется Оберон-2, то можно несколько упростить защиту. Не дай Вам бог после этого написать что-то хитрое на встроенном ассемблере (который, насколько я помню, в Обероне есть)! B>И не дай бог потребуется в Оберон-ОС переносить компилятор языка с меньшей типозащищенностью, (того же С)!
B>За все надо платить.
Может быть сейчас с и в OberonOS так и есть. Но в принципе это не так. См. здесь
Здравствуйте, AndrewVK, Вы писали:
P>>Ты же в курсе про managed code. Всё там есть. AVK>Есть. Но там путешествие через границу домена очень дорогое удовольствие.
Да, это так. Но во многом это благодаря ремотингу. Конечно, своя реализация взаимодействия через pipes будет экстремально быстрой. Просто там не будет всех фич ремотинга с синками и прочим. Т.е. принципиально проблемы-то нет.
Здравствуйте, Poudy, Вы писали:
P>Да, это так. Но во многом это благодаря ремотингу.
И что в нем не так?
P>Конечно, своя реализация взаимодействия через pipes будет экстремально быстрой.
В 2.0 есть IpcChannel.
P> Просто там не будет всех фич ремотинга с синками и прочим. Т.е. принципиально проблемы-то нет.
Ага, языком. А на практике GC работает в пределах домена и для передачи объекта хочешь-нехочешь, а сериализовать их придется. Ну или гонять unmanaged-куски памяти, но тогда ни о какой безопасности говорить не приходится.
Здравствуйте, DJ KARIES, Вы писали:
DK>Однозначно. DK>В настоящей Оберон-системе не было бы ни GDI+, ни DirectDraw7, ни Windows XP SP2. DK>Ибо нельзя испортить то, что не портится.
Я понял!
Оберон — он хороший. И Оберон-ОС — тоже хорошая.
Это только программисты плохие. И железо плохое. Поэтому нужно новое железо, и новые программисты.
И тогда будет все хорошо
Здравствуйте, Cyberax, Вы писали:
C>А что будет у нас в Обероне, если прибить модуль System, например?
Читать смешно.
1) Модуль можно загрузить и можно выгрузить, а прибить нельзя. Если модуль А в данный момент времени используется модулями Б, В, и Г, то выгрузить его нельзя (предварительно, надо выгрузить модули Б, В, Г, и лишь затем А. Ведь они прилинкованы друг к другу).
2) Ни потоков, ни процессов в объектно ориентированных операционных системах не бывает. Вместо них в объектно ориентированных операционных системах бывают АКТИВНЫЕ ОБЪЕКТЫ. То есть прибиванию подлежит не процесс и не поток, а активный объект (obj := NIL).
Здравствуйте, Borisman2, Вы писали:
B> Если в Оберон-ОС предполагается, что для написания ВСЕХ программ поголовно используется Оберон-2, то можно несколько упростить защиту.
Ну наконец-то!
Только всяких Оберонов много: Oberon, Oberon-V, Object Oberon, Oberon X, Active Oberon, Oberon SA, Oberon-2, Concurrent Oberon, Action Oberon, Oberon-D, Component Pascal, Active Oberon for .net, Zonnon, то есть вовсе не обязательно использовать именно Оберон-2. http://www.oberon.ethz.ch/genealogy.html
B> Не дай Вам бог после этого написать что-то хитрое на встроенном ассемблере (который, насколько я помню, в Обероне есть)! И не дай бог потребуется в Оберон-ОС переносить компилятор языка с меньшей типозащищенностью, (того же С)!
Естественно что невозможно перенести на safe систему unsafe язык программирования. Никаких Си/Си++ под оберонами никогда не будет и ассемблеров тоже, по тойже причине.
Сергей Губанов пишет:
> 1) Модуль можно загрузить и можно выгрузить, а прибить нельзя. Если > модуль А в данный момент времени используется модулями Б, В, и Г, то > выгрузить его нельзя (предварительно, надо выгрузить модули Б, В, Г, и > лишь затем А. Ведь они прилинкованы друг к другу).
А если прибить _НУЖНО_? Например, если, модуль начал неограниченно
отжирать память.
> 2) Ни потоков, ни процессов в объектно ориентированных операционных > системах не бывает.
Попрошу не обобщать, бывают и потоки, и процессы. В недооперационках —
да, не бывает.
> Вместо них в объектно ориентированных операционных системах бывают > *АКТИВНЫЕ ОБЪЕКТЫ*. То есть прибиванию подлежит не процесс и не поток, > а активный объект (*obj := NIL*).
Еще раз _МЕДЛЕННО_: КАК ИСПОЛНЯЕТСЯ КОД? КАК ЗАПУСТИТЬ _ПАРАЛЛЕЛЬНО_ ДВЕ
ЗАДАЧИ?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Poudy, Вы писали: P>>Да, это так. Но во многом это благодаря ремотингу. AVK>И что в нем не так?
Синки.
P>> Просто там не будет всех фич ремотинга с синками и прочим. Т.е. принципиально проблемы-то нет. AVK>Ага, языком. А на практике GC работает в пределах домена и для передачи объекта хочешь-нехочешь, а сериализовать их придется. Ну или гонять unmanaged-куски памяти, но тогда ни о какой безопасности говорить не приходится.
Да, IMHO сеализовать ObjRef и аргументы вызовов просто необходимо. Это правильный подход. Другое дело, что используется общая медленная сериализация, что происходит обязательная проверка типа всех аргументов и т.д.
To Moderator: сорри за мат, больше такого не повторится .
Здравствуйте, Cyberax, Вы писали:
C>Ладно, попробую объяснить еще раз. Вот в Юниксе (да и в Винде) есть C>дерево процессов, каждый процесс независим от другого (если не C>используются специальные механизмы IPC). Если мы прибиваем один процесс C>или дерево — это не влияет на остальные процессы.
Давай разложим всё по полочкам.
Идея №1 — изоляция процессов на уровне железа.
В данном случае мы используем первое пришедшее в голову решение о том, что проги, работающие на виртуальной машине, не могут портить память других процессов. Чтобы это работало быстро, придется всё заимплементить в железе. В итоге мы имеем ОС, которая работает с железом напрямую, и пользовательские процессы, которые работают через уровень аппаратной абстракции. Тут есть тонкие архитектурные вопросы.
1. Железо не стоит на месте, появляются всё новые и новые устройства. Это означает, что мы должны заклыдывать в железячную виртуальную машину только необходимый минимум — работа с памятью, с портами, вызовы, прерывания.
2. Процессы должны общаться. Это необходимо реализовать в отдельном порядке. Самое простое — устроить на одной машине локальную сеть виртуальных машин. Думаю, именно поэтому в UNIX процессы так часто общаются по tcp.
Ну вот как-то так
Плюсы:
+ гипотетически это должно работать быстрее, чем софтвар.
+ гипотетически изоляция идеальная.
Минусы:
— сложность такого проца мешает при построении хорошей масштабируемой архитектуры и её реализации.
— большой расход памяти на обустройство виртуальной памяти.
— потери производительности на переадресации.
— постоянное переключение контекста снижает производительность; и чем дальше, тем сильней, т.к. размер контекста от проца к процу растет.
— ошибки в самой ОС по-прежнему может завалить всю систему. а ОСь под такую архитектуру гипотетически более сложная.
Идея №2 — изоляция процессов на уровне софта.
Тут мы используем факт, что программа не запускается сама-собой. Её грузит загрузчик. Соответственно он может анализировать этот код и вставить в него запреты везде, где нужно. Разделение времени и прочее полностью должно разруливаться операционной системой.
Плюсы:
+ Можно запрещать всё, что захочется, и управлять этим отдельными настройками.
+ Баги ловятся на уровне софта, а не на эмуляции железа, и это дешевле и проще.
+ Можно сделать более простой (и поэтому гипотетически более быстрый) проц, качество которого будет чуть меньше страдать от качества производства.
Минусы:
— Гипотетически всё это довольно сложный софт.
— Программа в памяти занимает немного больше памяти, чем на диске.
— ОСь и драйвера по-прежнему могут завалить систему.
C>Да, и модуль может быть загружен только один раз. Так что они C>глобальные, просто с ограниченной зоной видимости.
Нуу.. да, это недоделка, видимо. Это они не подумали .
>> Ты же в курсе про managed code. Всё там есть. C>Несерьезно, так как в managed-код нельзя засунуть все, что нужно. А если C>все-таки это попробовать сделать — получится точно то же самое, что уже C>есть, только в managed-коде.
На самом деле это неверно. Потому что managed code не означает, что это должен быть обязательно какой-то другой код, отличный от x86. Можно сделать загрузчик, который сделает из x86 managed code, т.е. везде вставит нужные проверки.
C>Это означает, что Oberon-ОС должна следить за открытыми дефецитными C>ресурсами (а они *будут*), а для этого "плоская модель процессов" уже не C>подходит.
Не понимаю, откуда такой вывод. ВСЕГДА существуют как минимум два "процесса" — ось и пользовательский.
C>GPF потом и не портит данные, что ОС предоставляет защиту. А кто помнит C>времена ДОСа — знает, что там одна прога могла легко запортить всю память.
В ДОС не было managed code.
Здравствуйте, Cyberax, Вы писали:
C>А если прибить _НУЖНО_? Например, если, модуль начал неограниченно C>отжирать память.
Э-э-э..., модуль — не обладает "свободой воли" он не может что либо делать. Вот, например, в модуле может быть определена процедура внутри которой может быть код предназначенный для сжирания ресурсов. Так вот, тот кто вызовет эту процедуру — вот он то и будет сжирать, а модуль тут не причем.
>> 2) Ни потоков, ни процессов в объектно ориентированных операционных >> системах не бывает.
C>Попрошу не обобщать, бывают и потоки, и процессы. В недооперационках — C>да, не бывает.
А чего же Вы тогда так волнуетесь по поводу этих самых недооперационок-то?
>> Вместо них в объектно ориентированных операционных системах бывают >> *АКТИВНЫЕ ОБЪЕКТЫ*. То есть прибиванию подлежит не процесс и не поток, >> а активный объект (*obj := NIL*).
C>Еще раз _МЕДЛЕННО_: КАК ИСПОЛНЯЕТСЯ КОД? КАК ЗАПУСТИТЬ _ПАРАЛЛЕЛЬНО_ ДВЕ C>ЗАДАЧИ?
Каждый активный объект и есть задача. Как объекты создавать надо показывать? Вот так: NEW(obj).
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Только всяких Оберонов много: Oberon, Oberon-V, Object Oberon, Oberon X, Active Oberon, Oberon SA, Oberon-2, Concurrent Oberon, Action Oberon, Oberon-D, Component Pascal, Active Oberon for .net, Zonnon, то есть вовсе не обязательно использовать именно Оберон-2.
ты считаешь это плюсом?
СГ>Естественно что невозможно перенести на safe систему unsafe язык программирования. Никаких Си/Си++ под оберонами никогда не будет и ассемблеров тоже, по тойже причине.
Здравствуйте, AndrewVK, Вы писали:
P>>>>Да, это так. Но во многом это благодаря ремотингу. AVK>>>И что в нем не так? P>>Синки. AVK>И что синки? И которые кстати?
Есть у меня мнение, что для работы IClientChannelSink & IServerChannelSink приходится упаковывать аргументы в IMessage. Т.е. я говорю не о реализации каких-нибудь там конкретных синков, снижающих производительность, а о самом механизме с передачей IMessage. Если редуцировать IMessage до байт без метаинформации, использовать более быструю специальную сериализацию, то должно ворочиться шустро.
Сергей Губанов пишет:
> B> Не дай Вам бог после этого написать что-то хитрое на встроенном > ассемблере (который, насколько я помню, в Обероне есть)! И не дай бог > потребуется в Оберон-ОС переносить компилятор языка с меньшей > типозащищенностью, (того же С)! > Естественно что невозможно перенести на safe систему unsafe язык > программирования. Никаких Си/Си++ под оберонами никогда не будет и > ассемблеров тоже, по тойже причине.
И по той же причине такая система никому нужна не будет.
ЗЫ: поищи в гугде по слову JavaOS — будешь удивлен.
Сергей Губанов пишет:
> C>А если прибить _НУЖНО_? Например, если, модуль начал неограниченно > C>отжирать память. > Э-э-э..., модуль — не обладает "свободой воли" он не может что либо > делать. Вот, например, в модуле может быть определена процедура внутри > которой может быть код предназначенный для сжирания ресурсов. Так вот, > тот кто вызовет эту процедуру — вот он то и будет сжирать, а модуль > тут не причем.
Уже прогресс. Но КТО вызывает данную функцию? Правильно, функция другого
модуля, а ее вызвала функция еще одного модуля и т.д. По цепочке придем
к корневому процессу. Ну и как система должна определить КАКОЙ модуль ей
нужно прибить из-за превышения квоты?
> C>Попрошу не обобщать, бывают и потоки, и процессы. В недооперационках — > C>да, не бывает. > А чего же Вы тогда так волнуетесь по поводу этих самых недооперационок-то?
Чтобы других не совращали...
>>> Вместо них в объектно ориентированных операционных системах бывают >>> *АКТИВНЫЕ ОБЪЕКТЫ*. То есть прибиванию подлежит не процесс и не поток, >>> а активный объект (*obj := NIL*). > C>Еще раз _МЕДЛЕННО_: КАК ИСПОЛНЯЕТСЯ КОД? КАК ЗАПУСТИТЬ _ПАРАЛЛЕЛЬНО_ > ДВЕ > C>ЗАДАЧИ? > Каждый активный объект и есть задача. Как объекты создавать надо > показывать? Вот так: NEW(obj).
NEW(obj) создает блок в памяти, который ничего не делает. Кто-то должен
вызвать функцию, работающую с этим блоком. КТО?
приходится настраиватиь или делать операционке.
)
). Только делается это на софтварном уровне.
.