I have two C functions in a DLL which are defined in the definition file and are exported for using in Inno Setup.
char* __stdcall GetName()
{
return "Kishore";
}
void __stdcall getName(char* strName)
{
strcpy(strName, "Kishore");
}
The Inno Setup code will load the custom DLL and call the function/procedure to return the names
{ Inno Setup script }
[Code]
procedure getName(MacAddress: String);
external 'getName@files:MyDll.dll stdcall setuponly';
function GetName():PAnsiChar;
external 'GetName@files:MyDll.dll stdcall setuponly';
function NextButtonClick(CurPage: Integer): Boolean;
var
StrName: String;
begin
SetLength(StrName,15);
getName(StrName); { displaying only single character }
StrName := GetName(); { this call is crashing }
end
How can I retrieve the name in Inno Setup script without it crashing?
GetName
should return aconst char *
, however it is otherwise fine as written. Note however that returning a string like this can only ever possibly work for literal string constants, as shown above. You cannot use this pattern to return a calculated string value (if you try that, it will likely crash or give corrupted data); thusgetName
is wrong.Also note that while C is case sensitive, Pascal is not, so
getName
andGetName
are the same function in the Inno script. You might be getting away with this in the above case because the parameters are different, but I wouldn't rely on that -- you should give them distinct names. (Don't use the same name on the C side either, as DLL exports are sometimes looked up case-insensitively too.)To return a calculated string, you should use a pattern like this:
DLL code:
Inno code:
A few acceptable variations exist, for example you can make the DLL function return the number of characters actually written to the buffer, and use that in the subsequent SetLength rather than calling Pos to find the null terminator.
But you must:
String
type.AnsiString
or Unicode strings withString
.One of the constraints in play here is that memory allocated by one side must be freed by the same side. You cannot safely release memory allocated on the "wrong" side of the DLL boundary, in either direction.