OberonCore

http://forum.oberoncore.ru/viewtopic.php?f=1&p=43647:


Это одно из возможных решений задачи использования DLL в программах на КП, которое использовано в Блэкбокс.

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

А что если рассмотреть другое решение (пока теоретически).
Цель интерфейсных модулей: привести Си-шные типы в соответствии с КП-шными. Но "если гора не идёт к Магомеду ..." Что нам мешает ввести ещё один псевдомодуль, который будет "понимать" Си-шные типы. Разумеется использование этого модуля будет ограничено: только там, где требуются вызовы из DLL. По идеологии Блэкбокс такие вызовы - это весьма специфическое действо. По идее они должны встречаться только в подсистемах Host, Dev и в модуле Kernel.

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

Можно ещё рассмотреть и третье решение: создать утилиту, которая будет автоматически генерить интерфейсные модули по входному DLL-файлу.

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

IMHO, это был бы хороший вариант, если бы "технология" DLL дотягивала до уровня оберонов (раздельная компиляция, символьные файлы, межмодульный контроль соответствия).
Но этого нет, поэтому имеет смысл рассмотреть генерацию интерфейсного модуля по файлам сишных заголовков (что поможет только частично).
Кажется, у XDS были какие-то наработки в этой области (если Александр Ильин это подтвердит).

Угу. Учитывая практики вида Требуется не только интерфейсный модуль к бинарной библ. и модуль-прослойка=интерфейс к стандарту библиотеки Тут, по-моему, может быть только управляемая/контролируемая автогенерация...

У XDS есть улитита H2D, которая конвертирует .h в .def:Это уже получится довольно близко к Оберону/КП. Насчёт обработки макросов точно сказать не могу, но не удивлюсь, если и это работает.

Если из DLL брать интерфейс, то там будут только имена функций, а с какими параметрами их вызывать - нет информации.

Эта мысль на уровне подсознания сверлила мне голову . То есть в самой DLL списки параметров и результат функции не специфицированны? Досадно . Наша гипотетическая утилита должна будет предварительно выучить весь MS SDK. В общем, утопия.

Но, наши никогда не сдаются!
В мире Windows+Си все же пользуются библиотеками DLL. У меня тут вопрос к знатокам Си и DLL. Как в программах на Си решается эта проблема: списки параметров DLL-функций предварительно специфицируются в специальных заголовочных файлах, или передача правильных фактических параметров целиком лежит на совести программиста клиентской программы?

Да, специфицируются в специальных заголовочных файлах.

Отлично. Значит у нас есть все необходимые спецификации для написания утилиты файл_DLL+заголовочный_файл TO интерфейсный_модуль_КП. Ведь все эти заголовочные файлы, я так понимаю, доступны через соответствующие development kit. Только представьте себе, несколько запусков такой утилиты, и вся DirectX (к примеру) портирована в Блэкбокс. Правда это не избавляет от необходимости написать соответствующее расширение каркаса. ("Остапа понесло", )

И тут ВНЕЗАПНО выясняется, что dll пишутся не только на Си

Хе! Должен признаться, что подавляющее большинство интересующих меня DLL написаны именно на C/C++ .

PS: Если верить документации DevLinker, то DLL можно написать и на КП. Но вряд ли кто-нибудь станет переписывать на КП какую-нибудь opengl32.dll