[fpc-pascal] windows.GetProcAddress() vs DynLibs.GetProcAddress()

[Sven Barth]

Am 14.01.2014 00:12 schrieb "Ewald" <ewald at yellowcouch.org>:
>
>
> On 13 Jan 2014, at 23:06, Fred van Stappen wrote:
>
>> The SoundTouch.dll uses index to call the procedures.
>>
>> Like that :
>>  [Ordinal/Name Pointer]
>>     [   0] soundtouch_clear
>>     [   1] soundtouch_createInstance
>>     [   2] soundtouch_destroyInstance
>>
>
> That explains why it works in windows probably, there you can specify an
index to go with your exported procedures IIRC. I don't know if this is
possible though on *nix.

No, ordinals are not supported on non-Windows (or more precisely non-PE)
systems.

>
>> >> try `GetProcAddress(LibHandle,  'soundtouch_clear');
>>
>> I have try that, but it does not work...`
>>
>
> What is the result of the call (GetProcAddress)? nil? if so then try to
find the names of the symbols defined in the shared object (nm comes to
mind).
>
> Now, for the windows version, I don't know what underlying mechanism
dynlibs uses under windows, so I'm afraid I can't really comment on that
platform, except that you could try a similar approach as on linux (use
symbol names instead of indices). OTOH it could (?) be that the the
compiler inserts code to typecast PChar(1) to a string, which could result
in an access violation (try `var a: string; a:= pchar(1);` to try it out
;-) ).

The Windows version of dynlibs directly uses the Windows functions. The
only difference is that it takes an AnsiString as argument and thus one
can't pass an ordinal value.

Maybe an overload could be added to load functions by ordinal on Windows
and which simply returns Nil on other platforms.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20140114/f16fe5cd/attachment.html>