Библиотеки-модули-программы...

[Vitamin]

зачем список? почему не искать все файлы удовлетворяющие маске и лежащие в определенном месте (каталоге?)

Ага. А там лежат несколько версий одной и той же библиотеки и линкер впадает в ступор перед проблемой выбора. Да память не резиновая вроде как...

Сам формат REL кажется даже документирован, т.е. где-то описание я встречал, но где - не помню. Скорее всего в документации к dev-средствам от Digital Research.

Спасибо, буду искать

[captain cobalt]

1. чаще всего да, но если очень надо то можно указывать зависимость с точностью до минорной версии. например при минорном update могла добавиться новая функци, это совместимости не вредит (при правильном использовании конечно)
2. значит не судьба или указывать указывать список возможных версий при импорте
3. значит это новая версия и звать функции с неизменившимися сигнатурами скорее всего опасно. т.к. они могут иметь side effects

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

Все гипотетические примеры очень хорошие.

Ну что тут сказать?

У каждого подхода есть недостатки.

С одной стороны, если целостность не контролируется - получается DLL hell. Если есть контроль версий - получаем несовместимость потенциально совместимого кода.

Контроль по сигнатурам - это некоторое промежуточное решение. И наследует достоинства и недостатки обоих подходов. Если это иметь ввиду, то подход весьма практичен.

зачем список? почему не искать все файлы удовлетворяющие маске и лежащие в определенном месте (каталоге?)

Самое главное в списке - то что из него можно так или иначе получить указатели на функции плагинов и вызывать их.

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

Ещё можно вообразить пользователя с одним дисководом. У него есть дискета с графическим редактором и плагинами. Он запускает редактор и автоматически загружаются плагины которые он настроил. Но все плагины не помещаются на дискету, и иногда он загружает плагины, которые хранятся на другой дискете. А ещё у него есть дискеты с его картинками. Не получится просто искать файлы в каталоге по маске.

[caro]

... буду искать

А чего искать, читай, думаю будет полезно.

[elf/2]

С одной стороны, если целостность не контролируется - получается DLL hell. Если есть контроль версий - получаем несовместимость потенциально совместимого кода.

блин, dll hell к целосности отношение имеет слабое. проблема в том что в свое время MS рекомендовала складывать все dll в папочку %windir%\system. при установке двух программ использующих одну библиотеку разных версий побеждала последняя. инсталятор мог проверить только дату/время изменения файла.
для борьбы с этим добавили version_info, чтобы опять же инсталятор мог грамотно сообщить пользователю что происходит и положить библиотеку в папку к программе откуда она будет грузиться в первую очередь

для того чтобы hell'а не было достаточно иметь возможность хранить несколько версий библиотеки на одной машине. это работает в linux и .net

Ага. А там лежат несколько версий одной и той же библиотеки и линкер впадает в ступор перед проблемой выбора. Да память не резиновая вроде как...

а вы так не делайте кстати наличие реестра с общим списком всех библиотек в системе от всего этого не спасает

Ещё можно вообразить пользователя с одним дисководом. У него есть дискета с графическим редактором и плагинами. Он запускает редактор и автоматически загружаются плагины которые он настроил. Но все плагины не помещаются на дискету, и иногда он загружает плагины, которые хранятся на другой дискете. А ещё у него есть дискеты с его картинками. Не получится просто искать файлы в каталоге по маске.

точно, но вот только где в таком случае будет лежать "реестр"? и как он поможет разрешить проблему

[elf/2]

А чего искать, читай, думаю будет полезно.

тогда просто ради коллекции ссылка на описание формата obj файлов от MS OMF (relocatable object module format):
http://www2.cs.uh.edu/~mirkovic/cosc2410/omf1_1.pdf

[captain cobalt]

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

Чтобы использовать перегруженные функции, нужно руками прописывать сигнатуры в клиентском коде.

Да? А таблицы релокации ты как будешь делать? Если ассемблер не поддерживает макросов, то необходимо будет создание дополнительных промежуточных таблиц с адресами адресозависимых точек.

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

для того чтобы hell'а не было достаточно иметь возможность хранить несколько версий библиотеки на одной машине. это работает в linux и .net

Можно ли на спеке позволить себе держать разные версии библиотеки в памяти? Скорее всего нет.

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

Каждая библиотека должна быть одна.

точно, но вот только где в таком случае будет лежать "реестр"? и как он поможет разрешить проблему

Пока не ясно.
Он может лежать на "системном диске", и после загрузки постоянно сидеть в памяти.
Или же каждый кусок может лежать рядом со своей программой в "файле конфигурации".

для того чтобы hell'а не было достаточно иметь возможность хранить несколько версий библиотеки на одной машине. это работает в linux и .net

Есть ещё один способ хранить несколько версий библиотек на одной машине.

Компоновать программы статически.

тогда просто ради коллекции ссылка

тоже подкину пару ссылок:

[Vitamin]

а вы так не делайте кстати наличие реестра с общим списком всех библиотек в системе от всего этого не спасает

Вполне можно так делать. Коренным образом поменялась библиотека- меняется имя/версия и она не прилинкуется "куда не надо". А реестр- это бред.

Чтобы использовать перегруженные функции, нужно руками прописывать сигнатуры в клиентском коде.

А чтобы использовать ассемблер надо вообще программы писать ручками! Прикинь, да?

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

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

[elf/2]

Можно ли на спеке позволить себе держать разные версии библиотеки в памяти?

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

Он может лежать на "системном диске", и после загрузки постоянно сидеть в памяти.

"Можно ли на спеке позволить себе держать ... в памяти?" нужное вставить

Или же каждый кусок может лежать рядом со своей программой в "файле конфигурации".

точно, и добавить в каждую программу парсер конфигурашек... "Можно ли на спеке позволить себе держать ... в памяти?"

[elf/2]

Коренным образом поменялась библиотека- меняется имя/версия и она не прилинкуется "куда не надо".

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

и линковка должна проходить/отваливаться на основе требований программы к версии библиотеки.

при этом не важно как мы эти библиотеки находим. насколько мне известно подход к поиску библиотек у винды/линукса различается, но:
1. можно указать руками где искать при запуске (LD_LIBRARY_PATH)
2. место специфичное для данной программы (каталог где лежит бинарик)
3. общая куча (%windir%\system)

А реестр- это бред.

как сейчас модно писать: +1

[Vitamin]

"Можно ли на спеке позволить себе держать ... в памяти?" нужное вставить

Я тоже было подумал, что черная кошка пробежала дважды, но ты меня опередил %)

Единственное что полезное вытащил из идей captain cobalt'а- это версионирование на уровне функций, а не модулей целиком. Но это только если будет возможность раздербанивать библиотеки, вытаскивая нужные функции. В противном случае это не имеет смысла.