🚀 go-pugleaf

On Tue, 27 Nov 2018 06:14:46 -0800 (PST), immo wrote:

> Tak dla "zabawy" przenoszę sobie jeden obiekt z C++Buildera na Delphi.
> Łączy się on z Oracle przez funkcje zawarte w oci.dll.
> 
> I ogólnie wszystko działało do momentu przepisania funkcji OCILogon
> deklarowanej jako:
> 
> //sword   OCILogon (OCIEnv *envhp, OCIError *errhp, OCISvcCtx **svchp,
> //                  const OraText *username, ub4 uname_len,
> //                  const OraText *password, ub4 passwd_len,
> //                  const OraText *dbname, ub4 dbname_len);
>   function OCILogon(
>     envhp: Pointer;
>     errhp: Pointer;
>     var svchp: Pointer;
>     username: Pointer;
>     uname_len: ub4;
>     password: Pointer;
>     passwd_len: ub4;
>     dbname: Pointer;
>     dbname_len: ub4
>   ): sword; cdecl; external WINDOWS_DLL_LOCATION;

A nie powinno być może tak?

   function OCILogon(
     envhp: Pointer;
     errhp: Pointer;
     var svchp: Pointer;
     const username: Pointer;
     uname_len: ub4;
     const password: Pointer;
     passwd_len: ub4;
     const dbname: Pointer;
     dbname_len: ub4
   ): sword; cdecl; external WINDOWS_DLL_LOCATION;

I też warto sprawdzić stdcall, zdarzało mi się stdcall używać na dllkach
obcych, gdy cdecl nie działało. Choć głowy nie dam w czym były pisane, ale
warto sprawdzić.
 
> Niestety za nic nie chce mi to zadziałać w Delphi, pomimo że w C++Builderze działa poprawnie. W Delphi jako result dostaję zawsze -1.
> 
> Funkcję wywołuję tak:
>   _retCode := OCILogon(
>     OCIEnvHP,
>     OCIErrHP,
>     OCISrvCHP,
>     @_otu,
>     _otuL,
>     @_otp,
>     _otpL,
>     @_otd,
>     _otdL
>   );
> 
> Gdzie _otu, _otp, _otd to TByteArray

z zerem na końcu? Wiem, że jest len podany, ale może wewnątrz tej metody
ktoś zahardcodował kopiowanie bufora + 1 bajt null terminatora i jest
wyjście poza bufor? :-)


-- 
pozdrawiam
Roman Tyczka