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

[captain cobalt]

А как насчет того, что одинаковые куски кода патчатся по разному в разных местах?

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

Таблицы релокации/экспорта/импорта должны быть. Без них никак.

Это просто список внешних символов.
Часто один символ нужно пропатчить более чем в одно место. Все эти места перечисляются в таблице пропатчивания. Так вот она не нужна. Каждое место пропатчивания определяется текущей точкой распаковки.

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

[elf/2]

Это чтобы хоть что-нибудь сказать?

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

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

[Vitamin]

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

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

Каждое место пропатчивания определяется текущей точкой распаковки.

Предлагаешь битовую карту пропатчивания? У нее фиксированный размер, явно зависящий от размера кода с коэффициентом 1/8. Не жирно ли? В предлагаемом мною методе на каждую точку пропатчивания расходуется 4 байта, при этом автоматически поддерживаются ссылки на внешние точки. В таком случае размер таблицы не привязан к размеру кода, а зависит от его структуры.

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

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

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

Лыжи! Лыжи!!!

Оффтоп: http://rsdn.ru/article/philosophy/languages.xml

[captain cobalt]

единственно что меня интересует в рамках новой темы обсуждения: где вам удалось найти этот термин "язык загрузки" и как это будет по английски.

Из советской кибернетики 70-80-х годов.
По английски наверное никак не будет.

Выше была дана ссылка на варезный .djvu где понятие объясняется и приводится конкретный пример языка загрузки (со стеком но без сжатия).

остальное в приложении к спеку - чистое теоретизирование

Практика обычно следует за теорией.

[captain cobalt]

Предлагаешь битовую карту пропатчивания?

Нет.

Пусть у нас есть LZ77 распаковщик. Он может выполнять команды (с аргументами) :
1. Скопировать из входного потока в выходной
2. Скопировать из выходного потока в выходной
3. Конец распаковки.

Теперь мы добавляем к нему стек и команды:

4. Положить константу на стек
5. Положить значение из таблицы импорта на стек
6. Переписать число со стека в выходной поток
7. Сложить два числа на стеке
... и т.д. команды стековой машины

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

Хорошо, пусть таблица импорта для простоты остаётся.
Всё равно она меньше чем таблица пропатчивания от которой мы избавились.

[acidrain]

ну и есть ли унифицированный способ их оттуда достать.

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

[Advertiser]

[elf/2]

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

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

[elf/2]

Выше была дана ссылка на варезный .djvu где понятие объясняется и приводится конкретный пример языка загрузки (со стеком но без сжатия).

ссылку не заметил можно повторить?

[Vitamin]

Но нахожу и некоторые плюсы в писизме. Хотя не вижу до сих пор видимых причин столь усложнять модули для спека.

Не усложнять, а упрощать.
Конкретный пример. Имеется гипотетическая библиотека печати шрифтом 6х8. Для пущей универсальности она должна печатать разными шрифтами. Встраивать бинарник какогото конкретного шрифта в модуль нелогично. Поэтому объявляем используемый шрифт внешней точкой. И прилинковываем модуль, содержащий только шрифт и экспортирующий его в виде точки данных. При линковке получаем щастье. Ферштейн? И заметь, при этом линкеру глубоко пофиг что склеивать- вызов с адресами функций или загрузку с адресом данных.

Теперь мы добавляем к нему стек и команды:

Вот. Уже чтото конкретное, более-менее понятное. Еще один ма-а-а-аленький вопросец- как автоматизировать создание таких вот модулей-стеков? Еще один спецкомпилятор не предлагать. Мои модули создаются на ура реально существующим компилятором. А если получится портировать, то и не одним. Создание модуля не такая частая штука как его использование.

[captain cobalt]

Еще один спецкомпилятор не предлагать.

Тогда предлагаю "ещё одну утилиту".

Она будет брать твои компилированные модули и упаковывать их.