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

[captain cobalt]

Т.е. CLSID - это часть доки по винапи?

Это "закулисный механизм", который из клиентского кода не виден.
Сигнатура так и работает.

Ты писал на С? На разных компиляторах? Если писал, то знаешь, что разные компиляторы по-разному ведут себе с неиницализироваными переменными. Ничем не отличается от твоего примера. К чему я это сказал? К тому, что с этой проблемой не стоит заморачиваться.

На Ц можно поставить "хороший стиль".
А в ассемблере до сих пор иногда случается проблема.

Все так, но ты сам себе противоречишь. Невозможно добавлять новые виджеты (сиречь расширять функционал) уже готовой программы! Она использует только те понятия (библиотеки), о которых знает на момент компиляции. Так что расширение функционала готовых программ прямо так в лоб невозможно.

Модули, расширяющие функционал - это плагины.

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

Чтобы плагины можно было добавлять во время работы, нужно чтобы в этот список можно было добавлять элементы.

Где может располагаться этот список? Есть два основных способа:

1. В программе. Программа сама делает LoadLibrary и сама добавляет элемент себе в список.

2. В общеизвестном месте. Пользователь составляет нужный список и размещает в этом месте. Общеизвестное место загружает эти модули при запуске программы. Программа использует уже готовый список и не напрягается на LoadLibrary.

Что это за общеизвестное место? Это просто модуль. Точнее, список плагинов хранится не в модуле, а на диске. То есть сохраняется между выключениями машины. А модуль это просто интерфейс к этому дисковому хранилищу.

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

И название этому дисковому хранилищу - реестр.

[Advertiser]

[icebear]

Это "закулисный механизм", который из клиентского кода не виден.
Сигнатура так и работает.

Как это "закулисный"? Доступ к COM именно по CLSID происходит. Т.е. это и есть сигнатура.

На Ц можно поставить "хороший стиль".
А в ассемблере до сих пор иногда случается проблема.

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

[captain cobalt]

с этого момента поподробнее:
1. у нас есть библиотека xyz.lib
2. у нее в таблице экспорта есть функция get_scr_addr@r_v_q

3. пишем программу которая эту функцию должна звать:
----------
require 'xyz.lib'

ld a, 5
call xyz.get_scr_addr
----------
если мифический компилятор просто будет искать в таблице экспорта библиотеки функцию начинающуюся с get_scr_addr@ и прописывать ее полное имя в таблице импорта программы то это ничего не дает кроме тех случаев когда мы сильно поменяли интерфейс данной конкретной функции. а интерфейс - это святое! если мы начинаем его постояноо менять то это уже нельзя назвать библиотекой.

Всё правильно.

На спеке "весь код уже написан".
На продолжающих развитие платформах есть такие штуки как obsolete и deprecated.

причем если мы добавили в новую версию библиотеки функцию инициализации которая ДОЛЖНА вызываться первой, и пользователь об этом не знал/забыл то все эти сигнатуры не помогут. и линкер без ошибок все слинкует

Инициализация - это важно.
Функцию инициализации модуля должен вызывать линкер.

однако и на винде (activex, .net) и на линуксе используются именно версии библиотеки. обычно есть minor и major версии. и софт не будет собираться если поменялась major версия, но смена мажорной версии как-раз и говорит о том что совместимости нет. если поменялась минорная версия, то как правило все собирается

1. Если совместимость осталась, то линкеру не должно быть дела до minor номера?

2. Что если в данной версии совместимость нарушилась, а в следующей опять восстановилась?

3. Что если часть модуля осталась совместимой, а часть нет? Сигнатура для каждого символа модуля разруливает именно это.

[elf/2]

1. Если совместимость осталась, то линкеру не должно быть дела до minor номера?
2. Что если в данной версии совместимость нарушилась, а в следующей опять восстановилась?
3. Что если часть модуля осталась совместимой, а часть нет? Сигнатура для каждого символа модуля разруливает именно это.

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

Инициализация - это важно. Функцию инициализации модуля должен вызывать линкер.

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

Где может располагаться этот список? Есть два основных способа:
1. В программе. Программа сама делает LoadLibrary и сама добавляет элемент себе в список.

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

[Vitamin]

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

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

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

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

[caro]

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

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

[elf/2]

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

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

[captain cobalt]

Как это "закулисный"? Доступ к COM именно по CLSID происходит. Т.е. это и есть сигнатура.

Хорошо.
Осталось только выяснить связь между COM и WinAPI.

[captain cobalt]

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

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

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

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

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

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

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

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

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

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

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

[elf/2]

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

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

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

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

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

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

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