Подскажите пожалуйста, какого формата должны быть obj файлы, чтобы можно было их подгружать в HiAsm`е?
Т.е COFF или OMF формата?
Я слышал, что Delphi версии выше 3 создают несовместимый с Intel OMF формат, хотя и внешне похожий.
Так ли это?
Если да, то где можно посмотреть описание?
Что то похожее на это:
http://svn.shamangrad.net/codetools/trunk/link/info/pe_coff.xml.htm
Для РЕ файлов.

flint2, в папке HiAsmElementsDelphicode и поддиректориях можете найти и изучить примеры таких файлов. AFAIK, формат специфический, на базе OMF.

1nd1g0
Спасибо большое.

Информация ценная.
А файлы HiAsmElementsDelphicode*.obj я с них и начал.
Только разобраться в них весьма сложно.
Нашел хорошее описание OMF http://onembedding.bialix.com/info/omf-51/omf51.exe
но файлы, которые удалось найти в Hiasm ничего общего с этим форматом не имеют.
Может быть как раз начало заголовка другое, а без начала весь клубок не распутаешь.
Описания AFAIK формата, то что я нашел в сети, в основном используются для передачи картинок и музыки.
Другого не удалось найти.
Мне кажется, что должны существовать какие то Borland`овские описания.
Неужели они из этого делают тайну?

Редактировалось 8 раз(а), последний 2021-06-21 04:07:17

Это я понял.
AFAIK - as far as I know
Но меня с толку сбило часто встречающаяся фраза в различных статьях
"Apple Lossless закрытый AFAIK формат."
------------ Дoбавленo в 22.52:
Тем не менее, где взять описание формата или хотя бы заголовка???

Да, Borland-OMF, действительно несовместим Intel OMF. Описание формата в прищепке(англ.)

flint2, если не ошибаюсь, у dcc32 два разных формата объектных файлов (по ключам -J и -JP соответственно), второй "для C++" (дословно цитирую, что они имели в виду под этим можно догадываться, что для C-Builder, но утверждать не возьмусь). Может второй какой-нибудь линковщик поймёт.

ключ DCC32 -J создает .OBJ модуль для DCC32
ключ DCC32 -JP создает .OBJ модуль для BCC32 (формат Intel OMF для версии DCC32 10.0 и Borland OMF для Delphi 4 и выше).

[burl=ftp://ftp.styx.cabel.net/pub/UniLink]UniLink[/burl]

Minkovsky
Спасибо за описание.
Пока мельком посмотрел, в выходные буду пробовать.
Похоже, - то, что доктор прописал.
Теперь такой вопрос к гуру HiAsma - Такой формат OBJ HiAsm скушает?
P.S.
Чтобы было понятно, для чего это:
Есть самопальный продукт.
Формат выходных файлов которого можно сделать любым, если известен формат.
Во всяком случае создать PE (в том числе dll сишного и паскалевского формата)и COFF не составило труда.

Спасибо всем за ответы!
Думаю, что тема интересна не только мне.

Все недостающие функции и процедуры из этих obj придётся дописывать самому (т.е делать полные аналоги либо брать аналоги уже из
------------ Дoбавленo в 06.36:
существующих библиотек) а что за продукт если не секрет?

andrestudio

Да, это понятно. Спасибо.

http://narod.ru/disk/29165181001/forth.zip.html
Применяю для написания быстрых кусков программы, чтобы на Asme не писать.
Можно писать достаточно сложные программы.
Генерирует прямой шитый код, уступает по скорости только сшитому коду.
Но сшитый код тяжело переносить и объем кода получается больше.

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

AFAIK, ничем, это обычные библиотеки, просто свой интерфейс через несколько экспортируемых функций, можете рискнуть попросить у Автора прототип.

1nd1g0
Спасибо.
Вот именно интерфейс и интересует.

[b]Товарищи господа разработчики.
Пожалуйста, если возможно, дайте необходимую информацию по этому вопросу![/b]
Понятно, что можно и стандартные подключать, но "родные" было бы элегантней.
Т.е. можно было бы сделать элемент, инструмент или плагин, в стиле инлайн кода для сторонних продуктов, который создавал бы UseHidll не прибегая к языковым пакетам.

Мельком глянул, сплошное API похоже, могу порекомендовать purebasic для этих целей, делает маленькие шустрые dll которые при случае можно легко инжектировать в основную программу.
смотри исходники компонентов usedll, calldll
------------ Дoбавленo в 10.33:
[flood]с новой работы многострочие летит только в путь [/flood]

andrestudio

Делал сравнения, пузырьковую сортировку большого массива.
11 минут 37 секунд против 1 минута 57 секунд, разница ощутима.
Но колесо конечно не надо изобретать. Нашел готовую систему и очень быструю http://spf.sourceforge.net/
Вполне подходит для скриптового языка. То же самое делает за 48 секунд.
Сложность в интеграции состоит в том, что сам себя компилирует и надо тащить в объектный код и само ядро вместе со всяким мусором. Пока разобрался, как сделать из него dll (пока COFF)(тоже оказалось не просто ).
Попробую сделать элемент "вставка скрипта", правда придётся за собой таскать и DLL.

В выходные занимался, вроде бы понял, только теоретически, до практики руки не дошли.
С calldll вопросов вроде бы не возникает, а вот usedll надо пробовать.
Буду задавать вопросы.
------------ Дoбавленo в 15.12:
andrestudio

Не правильно.
API это чемодан, который тяжело таскать, а выбросить жалко.
Главное там адресный процессор:
Callr: pop eax ; Новый указатель команды

xchg eax, esi ; Получим адрес возврата
stosd ; и сохраним его в стеке возвратов.
Next



_Next: lodsd ; Считаем в регистр EAX адрес следующего слова,

; которое надо выполнить.

Jmp eax ; И передадим управление этому слову

_Exit: sub edi, 4 ; Передвинем указатель стека возвратов.

mov esi, [edi] ; восстановим адрес следующей команды.
Next ; продолжим выполнение программы.
Все примитивы на ассемблере, обмен данными через стек.