Здравствуйте, Serginio1, Вы писали:

S> А можно поподробнее про ABI. Нашел только http://stackoverflow.com/questions/3784389/difference-between-api-and-abi
Так там же ж вполне понятно написано. Под ABI понимается любое стабильное соглашение о том как программы взаимодействуют на бинарном уровне. COM в частности — это универсальный такой контракт (интерфейс). Они могут быть и специализированными. Все в итоге выливается в набор экспортируемых вызовов из динамической библиотеки, описания структур и желательно механизм валидации определения версий.
Понятно что для реализации этого нам необходимо предоставить C-like интерфейс, а в дотнете просто юзать PInvoke, при этом мы опускаем остальные детали т.к. обе среды остальное делают за нас (соглашение вызовов, упаковка/выравниевание структур и т.п.).

В том же CEF, например, для того что бы создать объект (реализуемый на стороне C#), я заполняю таблицу с адресами методов которые реализуют конкретные функции, что-то вроде VMT, но на каждый объект своя таблица. А при потреблении объектов — беру адрес функции, делегат и вперед вызывать. Т.е. тонны экспортов из dll нет.

Это и есть "наше" соглашение, используемое для:
1. построения этого самого слоя ABI, т.е. способ которым библиотека экспортирует свой функционал в виде динамической библиотеки (полностью автоматически).
2. построения клиента (C++) для библиотеки (т.е. API внешне выставляется такой же как и "внутри", но на самом деле там самый настоящий интероп с маршаллингом, например, с передачей строк по значению, ну и по ссылке когда надо) (полностью автоматически).
3. построения биндингов для (C#, Go, Python с той или иной степенью автоматизации), но не вокруг этой клиентской C++ обертки, а вокруг этого самого ABI. При этом, разумеется, выпуск патчей не ломает совместимость, хотя такой халявы как в дотнете с символическим связыванием — увы нет — метаданных то нет. Есть один идентификатор (хэш) — если не совпадает — значит другая версия ABI и работать с ней нельзя.

Механизм в целом тот ещё, но по факту довольно удобен, даж Servo к себе на вооружение взяли. Но это ж для демонстрации.

PS: Я возможно не верно понял, чего ты там не понял, или куда ещё подробнее?

UPD2: У WebKit2 на мой взгляд вменяемый интерфейс в этом плане, но правда не без своих таракашек, как и везде.

UPD3: Один из ответов на SO гласит:

ABI: Application Binary Interface

This is how the compiler builds an application.
It defines things (but is not limited to):

— How parameters are passed to functions (registers/stack).
— Who cleans parameters from the stack (caller/callee).
— Where the return value is placed for return.
— How exceptions propagate.

Конечно же это не так (это далеко не всё). Описанное — это соглашение вызова функции (call convention). Соглашение по исключениям... хм, а они есть / могут быть? Да даже C/C++ библиотеки имеют ABI, тот же libc которому следует компилятор (и может таргетиться на разные версии), дабы обеспечить максимальную совместимость. Ну т.е. на уровне того, чего именно финальный экзешник потребляет (в терминах импортов ну и связанных вещей, стуктуры, соглашение вызова и т.п.).

API же — это скорее то, что предоставляет библиотека, и как мы её потребляем в той или иной среде. API например может содержать 2 метода, однако на уровне ABI это будет один метод с параметром.