Board.KolibriOS.org

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

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

Опыты показывают, что:
1. На ассемблере можно сделать объектный файл, который можно подлинковать к другим программам.
- Статически - в виде COFF для GCC, в виде ELF для TCC, возможно к другим языкам с поддержкой внешней линовки.
- Динамически в виде загружаемой COFF библиотеки с помощью SysFn68.19 к любым другим языкам.
Собственно, на данный момент COFF библиотеки являются наибольшим общим делителем межязыкового общения.

Важные моменты
- нужно заботится о реентерабельности, не использовать статических переменных
- крайне желательно выдерживать x86 calling convention - в вызываемой функции можно не сохранять только EAX, ECX, EDX
- принято соглашение stdcall

2. На C-- можно писать COFF библиотеки (и конечно использовать), а также имеем неплохую совместимость с GCC:
- из программ на С можно вызывать функции на С--
- с небольшим шаманством можно из С использовать объектные расширения С--
- из С-- функций можно вызывать функции clib (полезно, если основная программа на С)
Вариант использовать clib и построенные на ее базе библиотеки из основной программы на С-- затруднительно,
поскольку нет возможности линковать к программе сторонние объектники.

3. С помощью GCС тоже оказывается можно создавать COFF библиотеки. При этом достигается и компактность по размеру.
Обратить внимание нужно на:
- выравнивание в структурах с помощью __attribute__((__packed__))
- использование системного выделения памяти
- запрет использования функций clib, кроме built-in функций. Функции математики частично можно превратить в built-in
с помощью -ffast-math. Но в целом пробная линковка не должна показывать ни одной внешней функции

4.TinyC не совместим с GCC по формату объектных файлов. Совместимость можно обеспечить только на уровне исходного кода.
В помощь #ifdef __TINYC__ и __GNUC__
COFF библиотеки использовать можно.

5. Оберон - умеет использовать COFF библиотеки

6. FreeBasic - умеет использовать COFF библиотеки

Требует проработки - вариант генерации и использования PE DLL. Сейчас их загружать умеет только GCC, для остальных нет поддержки.
С другой стороны, их создание поддерживается С--, ASM, и любым С-компилятором.

Недостаток COFF библиотек - невозможно собрать из нескольких объектных файлов одну библиотеку (например на разных языках) и ручная привязка функций по именам.
....to be continued....

Ну по идее почти все так или иначе умеют использовать COFF библиотеки. К примеру, Delphi\FreePascal. Вот, например, XDS ещё умеет viewtopic.php?f=33&t=2280&p=52371#p47919 И даже такие самодельные трансляторы как этот viewtopic.php?f=4&t=761Такое и про COFF можно сказать. А вот для PE обычно ещё и линкер нужен(хотя и не всегда).Ну при желании можно было и по ординалам экспортировать\импортировать, но тогда это уже менее гибко получается.

Чтоб никто как я 15 минут своей жизни не потратил, вот спецификация того самого coff: http://www.ti.com/lit/an/spraao8/spraao8.pdf. M$ PE COFF, как я понял, не подходит.

Не, у нас как раз именно MS COFF.
А та самая спецификация есть, например, в прикреплённом файле(pecoff.pdf) этого сообщения viewtopic.php?f=9&t=3577#p69106
Да, COFF бывают разные, к примеру, вот выходные форматы NASM

valid output formats for -f are (`*' denotes default):
  * bin       flat-form binary files (e.g. DOS .COM, .SYS)
    ith       Intel hex
    srec      Motorola S-records
    aout      Linux a.out object files
    aoutb     NetBSD/FreeBSD a.out object files
    coff      COFF (i386) object files (e.g. DJGPP for DOS)
    elf32     ELF32 (i386) object files (e.g. Linux)
    elf64     ELF64 (x86_64) object files (e.g. Linux)
    as86      Linux as86 (bin86 version 0.3) object files
    obj       MS-DOS 16-bit/32-bit OMF object files
    win32     Microsoft Win32 (i386) object files
    win64     Microsoft Win64 (x86-64) object files
    rdf       Relocatable Dynamic Object File Format v2.0
    ieee      IEEE-695 (LADsoft variant) object file format
    macho32   NeXTstep/OpenStep/Rhapsody/Darwin/MacOS X (i386) object files
    macho64   NeXTstep/OpenStep/Rhapsody/Darwin/MacOS X (x86_64) object files
    dbg       Trace of all info passed to output stage
    elf       ELF (short name for ELF32)
    macho     MACHO (short name for MACHO32)
    win       WIN (short name for WIN32)

win32 — это и есть MS COFF, а coff — это, как и указано, DJGPP COFF.

Интересно... Я пришел к вышесказанному выводу после реверс-инжиниринга ARCHIVER.OBJ. Сигнатуры PE там нет, первым идет заголовок COFF (COFF FIle Header).

А, стоп, я неправильно спецификацию прочёл...
Извиняюс, всё стало по своим местам. Я просто подумал что объектные файлы MS COFF тоже имеют PE заголовок.