Комментарии 12
ой, да я случайно опубликовал вперые в жизни
function WriteNet(s: string): boolean; stdcall; external PathDll;
Ну да, гонять managed type(строки, string) из dll в дельфи - это перевейший выстрел в ногу :) не делайте так...
Как уже написали выше, это, мягко говоря, совсем не API.
Вот хорошая статья про то, как делать свой API:
https://www.gunsmoker.ru/2019/06/developing-DLL-API.html
Спасибо автору, а как этот код превратить в длл-файл?
Достаточно создать проект типа "Динамическая библиотека". И собирать под нужную платформу (Windows 32/64 - dll, Linux64 - so, Android 32/64 - o и т.д.). Такой проект - это пустой файл-шаблон, с которым работаем как обычно, создаем модули, если надо или даже формы.
К сожалению, авторе не упомянул, что, чтобы функции были доступны снаружи, их нужно перечислить в секции exports.
Hidden text
library Project44;
procedure Test;
begin
end;
exports //Секция экспорта процедур или функций из библотеки
Test;
begin
end.Так же автором не затронут тот факт, что можно использовать интерфейсы как инструмент API
Вместо string, следует использовать, например тип WideString или RawString. Т.к. использование string в данном случае накладывает ограничение, что корректно dll будет работать только с проектом на Delphi и как правило собранных компилятором одной версии.
Вот в статье функция возвращает строку:
function ReadNet: string;
Если вы попытаетесь освободить ее память, то будет ошибка EInvalidPointer. Если не будете освобождать, то будет утечка памяти. В любом случае это не правильное поведение.
Не совсем так. Если dll и ехе одного компилятора, то работа будет корректной, до тех пор, пока вы не будете хранить ссылку на строку "с другой стороны". Если ехе возьмет себе строку из dll, то освобождать он её не будет. Её освободит dll сама, проблема будет тогда, когда мы будем пытаться сохранять ссылку на строку в другой переменной (тем самым увеличивая кол-во ссылок на строку). Если строку просто получить и скопировать, то ни утечек, ни ошибок доступа не будет. Что по сути и является основной проблемой. Лучше бы сразу были ошибки при работе с "чужой" (по факту со своей, только не подконтрольной) памятью.
API для своей программы (Delphi)