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

[hinst]

I identified the problem........
Take a look at the function declaration plz:
Function GetProcAddress(Lib : TlibHandle; const ProcName : AnsiString) : Pointer; // from dynlibs
It internally uses this function: 
Function GetProcedureAddress(Lib : TLibHandle; const ProcName : AnsiString) : Pointer;

I changed type of ProcName parameter from const AnsiString to PChar and it _suddenly started to work.
Looks like FPC compiler generate some additional instructions for AnsiString which fail to work properly with invalid pointer. Perhaps it can not dereference pointer to 1. I don't know why it happens. It is strange because FPC should (perhaps) do reference counting only for arguments of type AnsiString but not _const_ AnsiString. It is also possible that reference counting happens here:

Function GetProcedureAddress(Lib : TLibHandle; const ProcName : AnsiString) : Pointer;
begin
  Result:=Windows.GetProcAddress(Lib,PChar(ProcName) { <- here} );

at PChar(ProcName)

@Fred van Stappen: you can create a copy of dynlibs unit, then make necessary changes to it (change type of ProcName from AnsiString to PChar or PAnsiChar), then place it into folder where your other sources are located; then your modified unit will get compiled instead of precompiled unit from FPC RTL.

@Fred van Stappen: also please note that including sysutils unit in your application may help to identify crashes because it enables exception support on higher level; and instead of RuntimeError message in console window you will get a more detailed exception message; you may also wish enable -gl command switch for FPC to get specific line numbers as well.

14.01.2014, 16:21, "Fred van Stappen" <fiens at hotmail.com>:
>>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 ;-) ).>Ewald
>
> Many thanks Ewald.
> I decided to use windows unit for Windows (it works so...).
> Sadly, for Linux, i do not find a solution...
> Many thanks.
>
> ,
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal