What's the meaning of dllparam in TDLL_Entry_Hook ? lazarus / 67-Windows ---------------------------------------------------------------------- 440bx · 2019-02-16 11:13 Hello, To receive dll process/thread attach/detach, Borland used a procedure variable DllProc. In Delphi 2 code, I use Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i DllProc := @DllMain; in FPC, I changed that to: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Dll_Process_Detach_Hook := @DllMain;Dll_Thread_Attach_Hook  := @DllMain;     Dll_Thread_Detach_Hook  := @DllMain; thinking that the parameter passed to DllMain is the reason for the call seems logical (thread/process attach/detach) but, that doesn't seem to be the case (at least not for thread attach/detach.) my question is: what does the parameter FPC passes to the hook function mean ? Thank you for your help. PS: FPC v3.0.4 ---------------------------------------------------------------------- ASerge · 2019-02-16 13:49 Quote from: 440bx on February 16, 2019, 12:13:36 pmthinking that the parameter passed to DllMain is the reason for the call seems logical (thread/process attach/detach) but, that doesn't seem to be the case (at least not for thread attach/detach.) my question is: what does the parameter FPC passes to the hook function mean ? As far as I can see from the sources, there are two global variables DLLreason and DLLparam (of course only on Windows platforms, because in other no dll). And DLLparam passed as paramemer. ---------------------------------------------------------------------- Thaddy · 2019-02-16 13:58 BTW it is the same has in later Delphi's (like delphi 3!) ---------------------------------------------------------------------- 440bx · 2019-02-16 14:58 Quote from: ASerge on February 16, 2019, 02:49:30 pmAs far as I can see from the sources, there are two global variables DLLreason and DLLparam (of course only on Windows platforms, because in other no dll). And DLLparam passed as paramemer. Looks like we looked at the same code... this is what I foundCode: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i 90 { Win32 Info } 91   startupinfo : tstartupinfo deprecated;  // Delphi does not have one in interface 92   MainInstance, 93   cmdshow     : longint; 94   DLLreason : dword; public name 'operatingsystem_dllreason'; 95   DLLparam : PtrInt; public name 'operatingsystem_dllparam'; 96   StartupConsoleMode : DWORD; 97 const 98   hprevinst: longint=0; 99  100 type 101   TDLL_Entry_Hook = procedure (dllparam : PtrInt); 102  103 const 104   Dll_Process_Detach_Hook : TDLL_Entry_Hook = nil; 105 Dll_Thread_Attach_Hook : TDLL_Entry_Hook = nil; 106   Dll_Thread_Detach_Hook : TDLL_Entry_Hook = nil;  It's hard to make sense out of that.  Windows passes the instance, the reason and a reserved parameter to the dll.  Obviously the reserved parameter is of little to no use, the values received in dllparam make it clear it's not the dll instance/module, that only leaves the reason as a possible - and useful - parameter value but, that doesn't seem to be it either.  It looks like one of those parameters that should have been named "this_parameter_intentionally_left_useless".  I wonder why the FPC developers deviated from Delphi in this case.  I'm still curious as to what that parameter brings to the table.  For DLLs that need the DllReason, it looks like it is simply not possible to port Delphi code to FPC without making structural changes in the code. ---------------------------------------------------------------------- Thaddy · 2019-02-16 15:02 No. Delphi 3 and higher behave the same as FreePascal. It is just D2 that was not yet compatible with MS API's in the proper way, ---------------------------------------------------------------------- 440bx · 2019-02-16 15:34 Quote from: Thaddy on February 16, 2019, 04:02:29 pmNo. Delphi 3 and higher behave the same as FreePascal. It is just D2 that was not yet compatible with MS API's in the proper way, Your signature is quite accurate, you really can't help it. ---------------------------------------------------------------------- Thaddy · 2019-02-16 16:01 No, that's true. But it is correct.... Delphi2 is the first 32 bit version and did not mature, just like you... I would not rely on comparing D2 "features" to FPC. Start comparing from something like D7. Btw sometimes I still use D2 because it renders smaller executables at the cost of non-fixed compiler bugs. ---------------------------------------------------------------------- 440bx · 2019-02-16 16:07 Quote from: Thaddy on February 16, 2019, 05:01:37 pmNo, that's true. But it is correct.... Delphi2 is the first 32 bit version and did not mature, just like you... I would not rely on comparing D2 "features" to FPC. Start comparing from something like D7 At least you're funny.... that's a plus. ---------------------------------------------------------------------- PascalDragon · 2019-02-18 08:19 The Windows entry point is declared (among others) in rtl\win32\sysinitpas.pp: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i     procedure _FPC_DLLMainCRTStartup(_hinstance : longint;_dllreason : dword;_dllparam:Pointer);stdcall;public name '_DLLMainCRTStartup';    begin      IsConsole:=true;      sysinstance:=_hinstance;      dllreason:=_dllreason;      dllparam:=PtrInt(_dllparam);      SetupEntryInformation;      DLL_Entry(SysInitEntryInformation);    end;      procedure _FPC_DLLWinMainCRTStartup(_hinstance : longint;_dllreason : dword;_dllparam:Pointer);stdcall;public name '_DLLWinMainCRTStartup';    begin      IsConsole:=false;      sysinstance:=_hinstance;      dllreason:=_dllreason;      dllparam:=PtrInt(_dllparam);      SetupEntryInformation;      DLL_Entry(SysInitEntryInformation);    end;So you can see that the global DllParam variable is set to the third parameter of the entry point. Now you can look at MSDN for DllMain where the third parameter is called lpvReserved and indeed has a documentation when it has what kind of value. And as Thaddy said: please don't use Delphi 2 as a point of comparison with FPC for such things. ---------------------------------------------------------------------- 440bx · 2019-02-18 09:43 Quote from: PascalDragon on February 18, 2019, 09:19:08 amNow you can look at MSDN for DllMain where the third parameter is called lpvReserved and indeed has a documentation when it has what kind of value. That doesn't seem to make sense, the lpvReserved is, as its name says, reserved and MS has never documented what the values of that parameter mean.  I don't see getting that parameter value as being very useful. Quote from: PascalDragon on February 18, 2019, 09:19:08 amAnd as Thaddy said: please don't use Delphi 2 as a point of comparison with FPC for such things. Excuse me for stating this but, I really don't put much stock, if any at all, in what Thaddy says. What he stated in this thread Quote from: Thaddy on February 16, 2019, 04:02:29 pmNo. Delphi 3 and higher behave the same as FreePascal. It is just D2 that was not yet compatible with MS API's in the proper way, Is a good reason. As far as comparing with Delphi 2, TTBOMK, much later versions of Delphi still use DllProc, therefore it seems that, in this particular case,  comparing to Delphi 2 or even a much later version of Delphi makes no difference. Again, TTBOMK, no version of Delphi uses the mechanism (Dll_Process_Detach_Hook, Dll_Thread_Attach_Hook, Dll_Thread_Detach_Hook) implemented by FPC.  Because of that, Dll source code requires more than just trivial changes to make it acceptable to Delphi (regardless of version) and FPC. All that said, thank you for making it clear what the meaning of the parameter to the hook procedures mean. I appreciate your clarifying that. ---------------------------------------------------------------------- PascalDragon · 2019-02-19 08:36 Quote from: 440bx on February 18, 2019, 10:43:57 amQuote from: PascalDragon on February 18, 2019, 09:19:08 amNow you can look at MSDN for DllMain where the third parameter is called lpvReserved and indeed has a documentation when it has what kind of value. That doesn't seem to make sense, the lpvReserved is, as its name says, reserved and MS has never documented what the values of that parameter mean.  I don't see getting that parameter value as being very useful. To quote the documentation: Quote from: MSDNpvReserved [in]     If fdwReason is DLL_PROCESS_ATTACH, lpvReserved is NULL for dynamic loads and non-NULL for static loads.     If fdwReason is DLL_PROCESS_DETACH, lpvReserved is NULL if FreeLibrary has been called or the DLL load failed and non-NULL if the process is terminating. It explicitely states when lpvReserved will be NULL and when not. ---------------------------------------------------------------------- 440bx · 2019-02-19 08:47 Quote from: PascalDragon on February 19, 2019, 09:36:59 amTo quote the documentation: Quote from: MSDNpvReserved [in]     If fdwReason is DLL_PROCESS_ATTACH, lpvReserved is NULL for dynamic loads and non-NULL for static loads.     If fdwReason is DLL_PROCESS_DETACH, lpvReserved is NULL if FreeLibrary has been called or the DLL load failed and non-NULL if the process is terminating. It explicitely states when lpvReserved will be NULL and when not. I stand corrected and learned something.  The last time I read the documentation about DllMain was likely over 20 years ago and I could swear MS didn't publish anything about that parameter back then.   Thank you for updating my knowledge and, I can see that parameter being occasionally useful.