Ответ на »сообщение 2916« (Alexey Veselovsky)
___________________________

Гм... Об этом не знал. Насколько подробно в документации к BB это описано (если там есть что-то, то лучше там и почитаю, зачем замусоривать форум?)?

Посмотрите, как устроен модуль Files -- фабричные объекты dir, stdDir, и процедура SetDir.

Кстати, кроме этой процедуры там (почти) и нет исполнимого кода -- вся реализация в HostFiles, который в своем Init (в конце модуля) производит инсталляцию вызовом

  Files.SetDir(dir);

Как считаете, то что я предложил чуть ниже (про полное имя модуля) - имело бы смысл в ББ? Тем более что это же не моя идея, это стандартная практика поиска необходимых файлов и библиотек в разнообразных ОС.

Нельзя назвать неразумным, но существующая простая схема пока никого не ограничила. Тут вопрос цены -- полезет сложность, путаница... ну его на фиг...

Ответ на »сообщение 2908« (Alexey Veselovsky)
___________________________

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

Кстати, в Обероне сделать несколько "виртуальных" Оберонов -- таки довольно несложно. Без потери производительности.

Ответ на »сообщение 2922« (Сергей Губанов)
___________________________

Ответ на »сообщение 2905« (Alexey Veselovsky)

имею некую программу А (представленую каким-то множеством модулей), предположим выходит новая персия программы А (А')

В оберонах Вы имеете не программу А, а подсистему А.

Эта подсистема внутри себя делится, будем так говорить, на "каркас" и "плагины". Модули составляющие "каркас" в А и А' должны быть либо одинаковыми, либо в А' каркас может быть расширен путём добавления новых каркасных модулей; в то же время "модули-плагины" могут (и должны) иметь разные имена что бы их можно было загружать в различных комбинациях. Модули каркаса, понятно, не импортируют модули "плагинов", а загружают их динамически, по текстовому имени. В качестве примера смотрите подсистему Comm в BlackBox. Там "каркас" - это модуль CommStreams, а модули CommTCP и CommV24 - "плагины"; загружаются по их текстовым именам "CommTCP" и "CommV24".

А если имена плагинов совпадут? Например есть модуль-плагин некий TextEdit в двух разных подсистемах. И что тогда?

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

Ответ на »сообщение 2921« ()
___________________________

Ответ на »сообщение 2909« (Руслан Богатырев)
___________________________
рассуждения 2906-2909 не верны. В "класической ОС Oberon"  нет никаких проблнм ни в запуске двух копий одного приложения ни в запуске двух немного отличающихся копий. Пример к первой ситуации - одновременный просмотр / редактирование двух текстов с помощью Edit. Пример к второй ситуации - Edit и XE.
О необходимости учить матчасть даже не напоминаю.

А как там это реализовано?

Ответ на »сообщение 2905« (Alexey Veselovsky)

имею некую программу А (представленую каким-то множеством модулей), предположим выходит новая персия программы А (А')

В оберонах Вы имеете не программу А, а подсистему А.

Эта подсистема внутри себя делится, будем так говорить, на "каркас" и "плагины". Модули составляющие "каркас" в А и А' должны быть либо одинаковыми, либо в А' каркас может быть расширен путём добавления новых каркасных модулей; в то же время "модули-плагины" могут (и должны) иметь разные имена что бы их можно было загружать в различных комбинациях. Модули каркаса, понятно, не импортируют модули "плагинов", а загружают их динамически, по текстовому имени. В качестве примера смотрите подсистему Comm в BlackBox. Там "каркас" - это модуль CommStreams, а модули CommTCP и CommV24 - "плагины"; загружаются по их текстовым именам "CommTCP" и "CommV24".

Ответ на »сообщение 2909« (Руслан Богатырев)
___________________________
рассуждения 2906-2909 не верны. В "класической ОС Oberon"  нет никаких проблнм ни в запуске двух копий одного приложения ни в запуске двух немного отличающихся копий. Пример к первой ситуации - одновременный просмотр / редактирование двух текстов с помощью Edit. Пример к второй ситуации - Edit и XE.
О необходимости учить матчасть даже не напоминаю.

Ответ на »сообщение 2918« (Руслан Богатырев)
___________________________

Ответ на »сообщение 2917« (Alexey Veselovsky)
___________________________

Выглядит логично, но где проходит граница между библиотечными (общими для разных приложений, но не системными, например OberonDotNET и OberonEclipse) и прикладными модулями (модулями конкретного приложения)? Если следовать логике, то после завершения приложения должен выгрузиться его головной модуль (с главной точкой входа) и остальной куст (остаток приложения). Но кто и где определяет этот куст? Когда остаются общие ресурсы, а когда они выгружаются?

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

Более того - как я понимаю, автоматического "выгружателя" модулей у нас нет, поэтому  поведение А' будет зависеть не только от того, запущена ли А в данный момент, но и от ИСТОРИИ запусков А и А'.

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

См. выше. Разве так нельзя?

Ответ на »сообщение 2915« (Руслан Богатырев)
___________________________

Ну если только чисто теоретический, то несложно догадаться, что если оставаться на уровне модуля и не вводить более объемлющего понятия (task) именно под случай разнесения пространств кода и данных между клонами, то это -- наглядная уязвимость модульного подхода в исполнении Оберонов.

Недостаток, разумеется на уровне ОС, а не языка.

Ответ на »сообщение 2917« (Alexey Veselovsky)
___________________________

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

Выглядит логично, но где проходит граница между библиотечными (общими для разных приложений, но не системными, например OberonDotNET и OberonEclipse) и прикладными модулями (модулями конкретного приложения)? Если следовать логике, то после завершения приложения должен выгрузиться его головной модуль (с главной точкой входа) и остальной куст (остаток приложения). Но кто и где определяет этот куст? Когда остаются общие ресурсы, а когда они выгружаются?

Более того - как я понимаю, автоматического "выгружателя" модулей у нас нет, поэтому  поведение А' будет зависеть не только от того, запущена ли А в данный момент, но и от ИСТОРИИ запусков А и А'.

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

Ответ на »сообщение 2914« (Руслан Богатырев)
___________________________

Ответ на »сообщение 2911« (Alexey Veselovsky)
___________________________

Что есть, в общем то, стандартная практика.
Если не задано в списке импорта полное имя модуля, то сначала ищется в том же каталоге, где лежит импортирующий модуль, затем (если не найдено) в списках глобально видимых модулей (списков может быть несколько с разными приоритетами). В реестре загруженых модулей все модули фигурируют только с полными именами.

Так Вам нужно одновременно запускать старую и новую версии или по очереди? Тут есть разница...

Предположим, что у нас есть библиотечный модуль CallCounter (библиотечный), экспортирующий процедуры Inc и Total -- то бишь простейший ресурс. Считаем, что поведение приложения зависит от того, четное значение счетчика или нет. Оба приложения полезут к счетчику и их поведение будет детерминировано при независимом исполнении и недетерминировано при одновременном. Чем спасает подход с указанием полного пути (или стратегией поиска) в этом элементарном случае?

Ситуация симметрична в обоих случаях т.к. раз это библиотечный модуль, то его использовать могут не только наши А и А', но и какие-то другие программы(модули) поэтому при запуске А' вне засивимости от того запущена ли у нас А, в этом счетчике может оказаться как четное, так и не четное число. Более того - как я понимаю, автоматического "выгружателя" модулей у нас нет, поэтому  поведение А' будет зависеть не только от того, запущена ли А в данный момент, но и от ИСТОРИИ запусков А и А'.