Ron Howard

Struggling to identify what the difference is in Delphi 10.4 and Delphi 11.3 in regards to the use of a DLL function. I have some legacy code that uses a security library. Works fine when compiled with Delphi 10.4 both for 32-bit and 64-bit. In Delphi 11.3 it works fine for 32-bit, but not for 64-bit. No changes to the code, nor project settings. Code: Interface Function pp_lfopen (filename: PAnsiChar; lfflags: LongInt; lftype: LongInt; password: PAnsiChar; handle: PLongInt): LongInt; stdcall; Implementation const {$IFDEF WIN32} KeyLibModuleName = 'KEYLIB32.dll'; {$ELSEIF Defined(WIN64)} KeyLibModuleName = 'KEYLIB64.dll'; {$ENDIF} Function pp_lfopen; external KeyLibModuleName; Usage: var LHandle: Longint; begin Lresult := pp_lfopen(PAnsiChar(FlicFilePath), 0, LF_FILE, PAnsiChar(FlicPassword), @Lhandle); if Lresult = PP_SUCCESS then begin // additional DLL calls, which fail due to the invalid handle end; end; The path and password are correct and valid text constants. My analysis so far has shown that the Lhandle returned is not valid, even though the function result indicates success. Just recently switched over to Delphi 11.3, but I cannot pinpoint the cause so far. Anyone with knowledge about the differences in 11.3 compared to 10.4 that could explain this? Or ideas to find the cause?

I indeed realized that the second point was the real issue. Better be complete and explicit though, that's why I included it. Personally I also prefer the translation of the header matching the original as close as possible, but I am aware that many Pascal implementations prefer the use of 'var' for the byreference type of parameters. I have also used the JvSetupApi quite a bit and there it is all 'var'. But thanks for pointing out the options, including the use of 'out' being more applicable in this case than the 'var'. And it all cetainly helps! Thanks again.

Things are working. For the third time, but now with the correct implementation.

Again, thanks David. Appreciate the answer with the suggested code changes. But I indeed want to make sure I understand the behind the scene workings, so I looked at the HGLOBAL definition. And I got there through: HGLOBAL -> THandle -> System.THandle -> NativeUInt. Which I understand from the link DelphiUdIT shared earlier, is the only(?) built-in type that actually varies in size for the 32/64 bit compilation (apart from pointers as you already mentioned). So this would give me: 1) a pointer - LPPPLFHANDLE - that changes size with the compiler option (32/64) 2) a memory area where it is pointing to that also varies size with the compiler option (4 bytes or 8 byte) Is that correct? Will implement these changes and test it on both platforms!

Hmmm. Interesting how many changes one can make, settings or code, and they work, and are still not right. But I certainly want to get it right, hence my questions earlier. I do have the C++ version of the header definition if that helps. #ifndef PPPEXPORT #define PPPEXPORT #endif #ifndef _WINDOWS #ifndef LONG #define LONG long #endif #ifndef LPLONG #define LPLONG LONG * #endif #ifndef CHAR #define CHAR char #endif #ifndef LPSTR #define LPSTR CHAR * #endif #ifndef VOID #define VOID void #endif #ifndef HINSTANCE #define HINSTANCE LONG #endif #ifndef HANDLE #define HANDLE VOID * #endif #ifndef HGLOBAL #define HGLOBAL HANDLE #endif #endif #ifndef PPLFHANDLE #ifdef _WIN64 #define PPLFHANDLE HGLOBAL #else #define PPLFHANDLE LONG #endif #endif #ifndef LPPPLFHANDLE #ifdef _WIN64 #define LPPPLFHANDLE HGLOBAL * #else #define LPPPLFHANDLE LPLONG #endif #endif LONG PPPEXPORT WINAPI PP_LFOPEN( LPSTR filename, LONG flags, LONG type, LPSTR password, LPPPLFHANDLE handle ); So, with that, and with your feedback earlier on the 64-bit to 32-bit value truncation, I concluded that for the 64 bit version the Int64 was required to cater to the size. Think I am just as puzzled as before...

Thank you! Already changed it to Int64 from Longint just before your reply... glad I found the same thing. And that works with the ASLR turned on. Appreciate the help though. This was something I did a while ago, and did not look at until the problem showed with the new Delphi version. Won't make this type of assumption (or really: mistake) again!

Thank you all for the replies! Forgot to mention that this is a Windows VCL project (you might have concluded this already of course). Disabling the ASLR options in the project options as DelphiUdIT suggested does make the code work and produce the expected results. But if these options should not be disabled as David is stating, I'd obviously rather correct the code. The original proection solution only has C support, and the header is as follows: LONG pp_lfopen(LPSTR filename, LONG flags, LONG lftype, LPSTR password, LPPPLFHANDLE handle) The LPPPPLFHANDLE is also a pointer to a LONG. Since there are both 32-bit and 64-bit versions of the DLL, I thougth I could get away with a single function definition, but apparently that is wrong. I would expect the compiler to get the right size for the Longint and PLongint for the 32/64 setting and it would match the version of the DLL architecture. Could you help me with the correct definition for the 64-bit version? Or point me to where this is explained?