DLLs: Invalid Pointer Operation

← →
^Sanya (2002-10-07 23:49) [0]

Определённый алгоритм, отменно работающий в модуле, в DLL выдаёт "Invalid Pointer Operation" ..
Причём DLL-овская функция срабатывает правильно... Но этот "Invalid Pointer Operation" смущает...
Как быть?

← →
^Sanya (2002-10-07 23:55) [1]

Ух!
Из DLL сыпятся и EConvertError, и Access Violation... :(

Почему, алгоритмы, помещаемые в DLL, вдруг такое говорят???
Что я мог не так сделать???
Есть DLL, есть интерфейсный модуль.... странно....
library crypt; {$DEFINE CRYPT} { Important note about DLL memory management: ShareMem must be the first unit in your library"s USES clause AND your project"s (select Project-View Source) USES clause if your DLL exports any procedures or functions that pass strings as parameters or function results. This applies to all strings passed to and from your DLL--even those that are nested in records and classes. ShareMem is the interface unit to the BORLNDMM.DLL shared memory manager, which must be deployed along with your DLL. To avoid using BORLNDMM.DLL, pass string information using PChar or ShortString parameters. } uses SysUtils, Classes, CryptInt in "CryptInt.pas"; {$R *.res} const MultKey = 24908; AddKey = 19045; function EnConvert(InString : string):string; var Str_Mod, Str_Div : string; i : word; begin result := ""; for i := 1 to length(InString) do begin //

← →
Gonza (2002-10-08 00:28) [2]

А потому-что в dll надо передавать PChar вместо string

← →
Юрий Зотов (2002-10-08 00:56) [3]

Вот там вверху Delphi написала здоровенный комментарий. Специально для Вас. Но не для того, чтобы Вы скопировали его в вопрос, а для того, чтобы Вы его прочитали.

Тогда и ошибок бы не возникло. И вопросов тоже.

← →
^Sanya (2002-10-08 08:48) [4]

Ай-яй-яй.....
Что-то я совсем уж....
Выходит как:
либо подключать ShareMem - либо использовать PChar?
с PChar всё ясно, а вот ShareMem что даст? Он что, сам по мебе мне всю память распределит как надо?....
Чувствую, что надо б не Вас спрашивать, а почитать Тейксейру с Пачеко...

Всем спасибо за совет.

← →
Юрий Зотов (2002-10-08 09:03) [5]

> либо подключать ShareMem - либо использовать PChar?

Совершенно верно. И так во всех случаях, когда используется динамическая память, которая может выделяться в одном программном модуле (например, в Exe), а освобождаться в другом (в DLL) - а все соглашения вызова, кроме cdecl, предусматривают освобождение параметров именно вызываемой стороной.

В частности, ShareMem нужен при передаче параметров - длинных строк или динамических массивов.

> а вот ShareMem что даст?

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

Но DLL с ShareMem может использоваться только Дельфишными Exe. Если же нужно написать DLL самого общего назначения - выбора нет, только PChar.

← →
^Sanya (2002-10-08 10:39) [6]

Как всегда Юрий Зотов подробно объяснил суть вопроса, за что ему огромное спасибо.
Хотел вот уточнить насчёт:

> Но DLL с ShareMem может использоваться только Дельфишными
> Exe. Если же нужно написать DLL самого общего назначения
> - выбора нет, только PChar

Если я выбираю PChar, то в проекте DLL слова типа string вообще запрещаются? То есть сделать преобразование параметров из PChar в string, затем работать со string, затем обратно преобразовать string в pchar и дать result функции равный pchar нельзя?

← →
^Sanya (2002-10-08 10:57) [7]

И ещё:
подключил ShareMem, все ок, только вот при завершении работы приложения выскакивает "Runtime error 217 at 00413C00" .
ShareMemя подключил (первый в списке uses) и в Dll-проекте и в интерфейсном модуле...
что не так?

← →
^Sanya (2002-10-08 11:03) [8]

И ещё к вышесказанному:
при завершении к тому же ещё имеется access violation

← →
Skier (2002-10-08 11:16) [9]

>^Sanya
Извини, конечно, но зачем ты вообще паришся с ShareMem
и String-ом. Если в их использовании нет острой необходимости,
то замени String на PChar и убери ShareMem.
Кстати, а если host-приложение будет написано например на
Borland С, ему вообще про дельфийский тип данных String ничего
не известно...

← →
Юрий Зотов (2002-10-08 11:20) [10]

ShareMem должен первым грузиться и последним выгружаться. Поэтому его надо указывать не "в интерфейсном модуле", а в самих DPR (в обоих - и Exe, и DLL), причем там и там СТРОГО самым первым. Из-за этого у Вас и идут 216 и 217.

> Если я выбираю PChar, то в проекте DLL слова типа string
> вообще запрещаются?

Нет, внутри DLL можно использовать string свободно.

> То есть сделать преобразование параметров из PChar в string,
> затем работать со string, затем обратно преобразовать string в
> pchar и дать result функции равный pchar нельзя?

Можно, только аккуратно следите, чтобы не было битых ссылок, особенно при возврате PChar, как результата функции (рекомендую вообще избегать таких функций - могут быть проблемы с выделением и освобождением памяти под тело результирующей строки).

← →
^Sanya (2002-10-08 11:52) [11]

> Skier © (08.10.02 11:16)
> >^Sanya
> Извини, конечно, но зачем ты вообще паришся с ShareMem
> и String-ом. Если в их использовании нет острой необходимости,
> то замени String на PChar и убери ShareMem.

Заменить string на pchar - это идеальный выход из ситуации, только вот проблема в том, что тут замешан алгоритм шифрования и париться с PChar"ом в данном случае коряво... Я ещё "кривоват на руки", чтобы грамотно xor-алгоритм шифрования строк в PChar"овский перевести... Я пробовал, но слишком много проблем т этого "#0" !

> Юрий Зотов © (08.10.02 11:20)

Даже не знаю, как отблагодарить. СПАСИБО!

> Можно, только аккуратно следите, чтобы не было битых ссылок,
> особенно при возврате PChar, как результата функции (рекомендую
> вообще избегать таких функций - могут быть проблемы с выделением
> и освобождением памяти под тело результирующей строки).

Пра вопросов:
1 - сто такое "битые ссылки"? (догадываюсь, но хочу уточнить)
2 - а как вы вообще рекомендуете строить функции, использующие строки, в DLL ?

← →
Юрий Зотов (2002-10-08 12:10) [12]

Битая ссылка - это указатель, содержащий неверный (или запрещенный) адрес. PChar - тоже указатель.

Как строить функции со строками.

Если планируется использовать DLL только с Delphi-программами, то проблем нет - спокойно используем ShareMem, string и ни о чем не заботимся - все разрулит компилятор.

Если нет, то я бы не рекомендовал использовать функции типа PChar вообще. Процедуры для этого лучше. Примеров - целая куча в API. Скажем, GetWindowText:

int GetWindowText(
HWND hWnd, // handle of window or control with text
LPTSTR lpString, // address of buffer for text
int nMaxCount // maximum number of characters to copy
);

Как видим, сама функция возвращает не строку, а число. Строка же возвращается в буфере, КОТОРЫЙ ВЫДЕЛЯЕТСЯ ВЫЗЫВАЮЩЕЙ СТОРОНОЙ И ЕЮ ЖЕ ДОЛЖЕН ОСВОБОЖДАТЬСЯ!!!

Функция принимает адрес буфера (LPTSTR lpString - в Delphi это и есть PChar) и его длину (int nMaxCount - в Delphi это integer). Затем она заполняет полученный буфер телом строки (не забыв дописать #0 в ее конце) и завершает работу, возвращая через Result фактическую длину этой строки. Все просто и надежно.

← →
Lmatveev (2002-10-08 12:50) [13]

Если твоя строка может содержать #0, то передавай в/из Dll не PChar, а просто указатель (pointer или нетипизированный параметр) и размер, а в коде сразу запихивай его в строку с помощью SetLength и move.
Кстати можно и PChar передавать, но в паскалевскою строку его запихивать именно с помощью move
Напрмер:
procedure Test(Src: PChar; SrcSize: integer); var SrcString: string; begin SetLength(SrcString, SrcSize); move(Src^, PChar(@SrcString[1])^, SrcSize); // и далее все со строкой end

DLLs: Invalid Pointer Operation Найти похожие ветки