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

[acidrain]

говорящих что это есть "как в амиге".

Я не говорил, что либман - есть как в амиге. Это полностью творение рук Шаоса. Как он его реализовал - не вдавался. А вот в начале (первый толчек к созданию) я поучаствовал. Но это не говорит о том, что это копия с амиги.
По поводу переходов - на амиге никаких вычислений, догадайся почему 8)

[elf/2]

Например в дотнете сборки контролируются по номеру версии.
На спеке предлагается контроль сигнатур по хэшам

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

Хранить внутри файла библиотеки. Если жалко места на строку вида
memcpy[сигнатура в бешеном формате], то можно делать хеширование в 3-4 байта и не мучаться. Само собой, линковщик должен это учитывать

даже комментировать не хочется если все это про динамические библиотеки.
1. генерация/проверка сигнатур должна делаться автоматически. на асме типов нет, и параметры передаются как бог на душу положит. значит автомат идет лесом
2. кто видел нормально комментированый код на спеке?
3. проверка будет жрать кучу времени... а вы только что плющили амижников по поводу "тормозов аналогичных ООП"

[captain cobalt]

я слышал что dll hell был связан с несовместимостью версий библиотек... но тем неменее чудеса техники в студию. как теперь с этим борються?

Вот более подробное изложение:

История программных революций от Microsoft, вкратце: Сначала были Windows API и DLL Hell. Революцией №1 было DDE — помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION INFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток — его писали не они!

Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием "по месту", при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC решившая все наши проблемы еще раз.

Но OLE не собиралась, сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда — и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток — его писали не они! Они немедленно исправили этот недочет, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через браузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!).

Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они не представляли концепции "System File Protection", исключающей DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java — её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие.

Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно — недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили "COM" или "Active" или "X" или "+" — они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про "Windows DNA" (почему не DINA) и "Windows Washboard", и вопил некоторое время, но все это почило раньше, чем все поняли, что это было.

К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернет. Недавно они пришли к пониманию, что у Интернет есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET (произносится как "doughnut (пончик по-нашему)", но по-другому), похожей на Интернет, но с большим количеством пресс- релизов. Главное, что нужно очень четко понимать — .NET исключает DLL Hell.

В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.

[captain cobalt]

генерация/проверка сигнатур должна делаться автоматически.

Да.

кто видел нормально комментированый код на спеке?

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

параметры передаются как бог на душу положит

Передача параметров описывается в документации. Из этих кусков документации генерируются проверочные хэши.

проверка будет жрать кучу времени...

Для каждого экспортированного-импортированного символа сравнить два числа.

Никаких накладных расходов во время выполнения.

значит автомат идет лесом

Значит автомат не идёт лесом.

на асме типов нет

Плохо.

Есть два основных выхода:
1. Подсмотреть ООП на ПЦ (в TASM и т. п.).
2. Использовать typed assembly language, "типизированный ассемблер", сокращённо TAL. Идея в принципе прикручиваема к Z80. Но это - как раз сильно отдалённое будущее, о котором будем говорить гораздо позже. Ссылки здесь.

[Vitamin]

По поводу переходов - на амиге никаких вычислений, догадайся почему 8)

И что с того? От осознавания мною того факта, что на амиге не делаются вычисления, на спектруме они не исчезнут. Так что смотреть на все возможные варианты создания релоцируемых бинарников надо через призму возможностей спектрума.
ЗЫ. Доки получил?

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

Откуда компилятор должен брать исходные данны для генерации сигнатуры? Из астрала чтоли? Ручками прописать. А типы на асме есть, стыдно говорить что нету! %) И передача параметров (распределение регистров) прекрасно можно описать в сигнатуре. В связи с этим отпадает необходимость тянуть мегабайт документации с описанием в какие регистры надо засовывать параметры и постоянно в нее шариться.
ЗЫ. Чета идея генерации хеша по документации не вставляет- а ну запятую переставишь в описании и все, новая версия?

3. проверка будет жрать кучу времени... а вы только что плющили амижников по поводу "тормозов аналогичных ООП"

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

Кстати я тут подумал по поводу применения полиморфизма для уменьшения размера бинарников.
Предположим, мы имеем абстрактную библиотеку GUI с кучей разных типов виджетов. Как это обычно делается? Некоторая структурка в памяти, у которой есть числовой идентификатор. А гдето в функции вывода (создания, удаления и т.д.) висит здоровое такое ветвление с кучей проверок и кучей переходов на разные функции. Что мы имеем в итоге? Что придется тянуть всю библиотеку, даже если мы используем всего один-два вида виджета. Если библиотека распространяется в виде исходников, можно применить ключи для включения/отключения некоторых возможностей (я так у себя делал). В бинарнике такое, ясное дело, не получится.
Зато если мы имеем полиморфизм, мы полностью отделяем реализацию от типа и имеем возможность неограниченного расширения путем наследования. При этом из бинарника можно будет вырезать ненужный (сиречь неиспользуемый) код. Правда проверка на используемость получается очень и очень ресурсоемкая- все портят таблицы виртуальных функций, которые по идее уже прошиты в бинарнике, но явно нигде не светятся...

[captain cobalt]

Чета идея генерации хеша по документации не вставляет- а ну запятую переставишь в описании и все, новая версия?

Не по всей документации, а только по "ключевым кускам".

Сигнатура - это всё равно неотъемлемая часть документации.
Нужно лишь её определённым образом отмечать, чтобы хэш считался только от неё.

Кстати я тут подумал по поводу применения полиморфизма для уменьшения размера бинарников.
Предположим, мы имеем абстрактную библиотеку GUI с кучей разных типов виджетов.

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

[elf/2]

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

проверка сигнатур нормально работает только на этапе компиляции.

в динамике у нас есть только два имени и все. в этом случае я не вижу чем имя функции memcpy хуже memcpy_VI#43543 (написанной руками) с точки зрения безопасности и отсутствия dll hell. и главное никто проверить уже не сможет что мы ее зовем правильно просто сравнивая имена.

а нормальная проверка сигнатуры т.е. парсинг и сравнение пока не понятно с чем точно кучу времени съест.

[Vitamin]

Сигнатура - это всё равно неотъемлемая часть документации.
Нужно лишь её определённым образом отмечать, чтобы хэш считался только от неё.

Зачем сюда вообще прилеплять документацию? Да ни в жизни библиотеки не различались по версии описания.

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

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

проверка сигнатур нормально работает только на этапе компиляции.

Чего???? Как раз только на этапе линковки. Чтобы знать что и с чем склеивать.

в динамике у нас есть только два имени и все. в этом случае я не вижу чем имя функции memcpy хуже memcpy_VI#43543 (написанной руками) с точки зрения безопасности и отсутствия dll hell. и главное никто проверить уже не сможет что мы ее зовем правильно просто сравнивая имена.

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

[captain cobalt]

в этом случае я не вижу чем имя функции memcpy хуже memcpy_VI#43543

memcpy - это имя. VI#43543 - это то самое проверочное магическое число. Оно остаётся "за кулисами". В клиентском коде используется только memcpy. VI#43543 просто копируется в клиентский модуль с объектным кодом во время компиляции. Во время динамической компоновки они просто проверяются на равенство.

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

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

[captain cobalt]

Зачем сюда вообще прилеплять документацию? Да ни в жизни библиотеки не различались по версии описания.

Сигнатура - это часть документации.
Документация всё равно понадобится.
Поэтому - чтобы не плодить сущностей.

Чего???? Как раз только на этапе линковки. Чтобы знать что и с чем склеивать.

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

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