Forum > Windows
Suspend/Resume/CloseThread and TThreadId
marcov:
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:
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:
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:
--- Quote from: ASerge on May 26, 2024, 04:17:08 am ---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.
--- End quote ---
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:
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 :-)
Navigation
[0] Message Index
[*] Previous page