Suspend/Resume/CloseThread and TThreadId lazarus / 67-Windows ---------------------------------------------------------------------- 440bx · 2024-05-25 13:08 Hello, I just noticed the following definitions in thread.incCode: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i function  SuspendThread (threadHandle : TThreadID) : dword;function  ResumeThread  (threadHandle : TThreadID) : dword;function  CloseThread   (threadHandle : TThreadID) : dword; where TThreadID is defined in sysosh.inc asCode: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i   TThreadID = DWord;I believe this yields an incorrect definition because these thread functions, and many others declared as taking a TThreadID, take a THANDLE which in 64bit is 64 bit wide, not 32 bit. This is important because in 64bit the TThreadId definition can cause the upper 32 bits of the handle to be truncated away. Have I missed something or are these definitions working only due to sheer luck ? Comments welcome. ---------------------------------------------------------------------- Fibonacci · 2024-05-25 14:02 AFAIK its thread ID, not the handle, and these functions you listed actually take the ID not the handle as a param ---------------------------------------------------------------------- ASerge · 2024-05-25 14:10 Quote from: Fibonacci on May 25, 2024, 04:02:32 pmAFAIK its thread ID, not the handle, and these functions you listed actually take the ID not the handle as a param No, it really is. There is a loss of bitness. From systhrd.inc: 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     function  SysSuspendThread (threadHandle : TThreadID) : dword;    begin      SysSuspendThread:=WinSuspendThread(threadHandle); // WinSuspendThread equal kernel SuspendThread    end;Fortunately, this is not essential (so far). In the current implementation of Windows HANDLE is usually an index in the internal table of descriptors. I.e., in reality, even Word is enough. ---------------------------------------------------------------------- Fibonacci · 2024-05-25 14:15 You're right, I just checked and the thread handle is really low number ---------------------------------------------------------------------- 440bx · 2024-05-25 14:42 Quote from: ASerge on May 25, 2024, 04:10:12 pmFortunately, this is not essential (so far). In the current implementation of Windows HANDLE is usually an index in the internal table of descriptors. I.e., in reality, even Word is enough. Yes, basically sheer luck.  If MS were to change how that handle is created, e.g, setting some bits to indicate some characteristics the O/S might want to save in the handle, those definitions may no longer work. This is not a far fetched idea, MS does currently use some bits in some handles to indicate features/properties of the item represented by the handle, e.g, handles returned by LoadLibraryEx (they use the bottom two bits to indicate the mapping format.) ---------------------------------------------------------------------- marcov · 2024-05-25 15:53 sha1: 7957c349407241e8135af138a68621d4cc9ccea3     * change tthreadid to thandle, as the used functions for threadid in systhrd all use HANDLE.     Marco Van de Voort authored just now Please verify your win64 apps with trunk, and then we can maybe still merge it before 3.2.4 ---------------------------------------------------------------------- 440bx · 2024-05-25 16:20 Thank you Marco. I understand that most Windows handles are just indexes into internal tables (as Serge correctly pointed out) but, truncating 32 bits away in 64bit programs isn't a source of comfort. Thank you for the quick response to the issue. ---------------------------------------------------------------------- ASerge · 2024-05-26 02:17 To be more precise, it is not the indexes, but the offsets in the table. Therefore, it is a multiple of 4 bytes. Even for x64. ---------------------------------------------------------------------- 440bx · 2024-05-26 07:40 Quote from: ASerge on May 26, 2024, 04:17:08 amTo be more precise, it is not the indexes, but the offsets in the table. Therefore, it is a multiple of 4 bytes. Even for x64. It depends on the type of handle. For instance, window handles are not multiples of 4, they seem to be multiples of 2.  There is no obvious pattern in their value distribution, such as sequentially increasing values depending on creation time. The bottom line is that it would be unwise to rely on a handle being an index into an internal table because some handles are definitely not direct indexes into some table. In the case of a window handle, it is ok to rely on it being a maximum of 32 bit (even if a 64 bit window handle has the upper dword set to some value - it can be set to zero without any side effects.)  That cannot be said of other handles, particularly module handles that are simply an address in memory (sometimes massaged a little as LoadLibraryEx may do.) ---------------------------------------------------------------------- marcov · 2024-05-26 09:26 GDI handles are probably from the desktop heap, which is limited and can run out of space. I had a run in with it once :-)