Are window handles (HWND) unique, or do they ever get reused?
Asked Answered
F

5

8

I am thinking if there are handles of the same value ?

To clarify my question, let's say I open Notepad, type in some text, save it and then close Notepad. If I repeat this a thousand times (or even more), will I ever have a chance to see the same window handle (HWND) value being used for the Notepad main window that was used the first time? If so, why?

Feu answered 14/8, 2011 at 8:47 Comment(3)
I didn't understand any thing can you explain what is your question ???Nosh
Thank you for your post, it's oke if you don't understand, please ignore and read what people post if any brings you any interesting ideas. I am sure you will get hooked up soon :-DFeu
@Serious: "It's oke if you don't understand" ?! No, it's not: If you post a good question on Stack Overflow, that adds value to a great programming resource. If you post a bad or incomprehensible question, on Stack Overflow, that will actually hurt Stack Overflow's usefulness (even if just a little). So please, make an effort to phrase your questions as well as you can, for the sake of the community! (I've edited your question a bit, btw.)Bozo
C
2

By the pigeonhole principal, yes, they can't be unique.

Due to the compatibility with 32-bit processes (WoW64), handles cannot use the entire 64-bits even on 64-bit OS -- think of a 64-bit process passing a handle to a 32-bit child, or getting a handle to a window opened by a 32-bit process. This makes their true space pretty small, and thus reuse very likely.

Castilian answered 14/8, 2011 at 8:56 Comment(10)
Thank ybungalabill, that's exactly what I would like to know.Thumbup!Feu
Only some of this answer is true. Window handles do not retain compatibility with 16-bit Windows. They're pointers, which means that their size is architecture-dependent. On 64-bit versions of Windows, they're 64-bit values. On 32-bit versions of Windows, they're 32-bit values. Check the Windows header files for details.Methacrylate
The HANDLE type is not a typedef for void* anymore; it's been years since that was the case. Parts of the MSDN documentation haven't been updated since then apparently, but that doesn't make the assumption any less incorrect. Moreover, that's not even what the article you linked to says. It only says that there is a limit of 65,536 user handles per session. That doesn't say anything about the data type used to store the handles. You're drawing conclusions that aren't explicitly stated and are quite unjustified.Methacrylate
If you're still using the headers that came with VC 6, you're hopelessly out of date. I'm not sure what else to tell you. It's not defined that way in any modern version of the SDK. I don't really understand what you want from MSDN. You want a link that says MSDN is wrong from MSDN? Sorry, that isn't going to happen. Not every page in the online documentation gets updated regularly, and even when updates do happen, stuff gets missed. Raymond Chen writes an entire blog about that. You provided a link to an irrelevant article about GDI handles, which has nothing to do with HWND values.Methacrylate
And none of that really has anything to do with anything. We aren't talking about GDI tables. The point is that window handles are not backwards-compatible with 16-bit versions of Windows. If you declare the HWND type as a short int, things aren't going to work properly. It's not a 16-bit value.Methacrylate
Hmm, remember that STRICT is defined by default now, and has been for years. You must be looking at the wrong branch of the #if statement. And that article is talking about GDI handles, not window handles. You have to read the whole thing, not just the part of it that suits your argument. I'm not arguing with the fact that the values will be re-used. I'm contesting the specious claim that window handles retain compatibility with 16-bit Windows.Methacrylate
@Cody: excuse me, but I'm not going to argue with you further if you don't do even a minimal effort to go and check that HANDLE is typedefed to a void pointer when STRICT is defined and to an integer otherwise. Unless you do a minimal effort to actually look at the table in the article I linked to where it's written that windows are user objects, and the article is talking about user objects (you just made up that it's "talking about GDI handles").Castilian
Remember, we're not talking about HANDLE. We're talking about HWND. I don't understand why you keep talking about things that are completely irrelevant, like GDI handles and the HANDLE type. The question title very clearly says "window handles". I'm not making this up. And I've already addressed that the table is quite irrelevant to this discussion. And finally, we get to the real heart of your argument, which is completely and totally incorrect. Win16 applications will not work on 64-bit versions of Windows. End of story.Methacrylate
It is mentioned in MSDN: typedef HANDLE HWND;, typedef PVOID HANDLE;, typedef void *PVOID;. And the User Objects article mentions HWND, not GDI Objects. GDI Objects have separate article listed in the navigation. And lastly, a bit reference to the handle table.Saidee
@YakovGalka the type of HANDLE is PVOID, indeed a 64 bit void pointer. This is generic, it can be a 64 bit address or it can be an index into a handle table, or it can be a pseudohandle, depending on the handleTransilluminate
S
7

Yes. There are only a finite number of values a handle can be represented by, so Windows has to reuse them eventually.

Once a handle is closed, it is gone, you can't do anything with it, it doesn't exist, and you shouldn't even look at it.

And if you subsequently open another handle, then it is possible that Windows will reuse the handle value.

Subtropical answered 14/8, 2011 at 8:49 Comment(3)
Thanks, is there a mechanism to deliver handle to open window ? What is that if you could share ?Feu
I would like to know if there is a way to deliver handle value to each open windows ? I have no INTENTION to get the gone window's handle. My knowledge about windows is not good, I make questions.Feu
No - no GUI handle has a reference counter. So there is just one handle value and you can't do something like "DuplicateHandle" Its a design bug in the same way as UNIX uses process id values.Throstle
B
4

theoretically yes. in practice - the probability of this (in contrast to process and thread id, which is frequently reused) is almost zero.

in current implementation low 16 bits of HWND used as index in windows handle table - so currently maximum 64K windows can be created. the next 16 bits used as reuse index. when a cell is used for the first time this index is 1.when this cell is reused, the index is increased by 1. and so on. as result for get the same HWND on window need how minimum 64k windows must be created and destroyed. but this is only in case all this windows will be used the same cell. but we have 64k cells. so real minimum much more higher for this. not exactly 2^32 but big enough.

and even if implementation will changed, i not think that new implementation will make HWND less unique than current.

Beam answered 7/1, 2021 at 18:16 Comment(0)
P
3

Yes, window handles are reused.

Documentation to IsWindow function says:

A thread should not use IsWindow for a window that it did not create because the window could be destroyed after this function was called. Further, because window handles are recycled the handle could even point to a different window.

Phylissphyll answered 5/10, 2015 at 14:14 Comment(1)
My answer is based on the comment by @CodyGray. I just wanted to make this fact more prominent.Phylissphyll
C
2

By the pigeonhole principal, yes, they can't be unique.

Due to the compatibility with 32-bit processes (WoW64), handles cannot use the entire 64-bits even on 64-bit OS -- think of a 64-bit process passing a handle to a 32-bit child, or getting a handle to a window opened by a 32-bit process. This makes their true space pretty small, and thus reuse very likely.

Castilian answered 14/8, 2011 at 8:56 Comment(10)
Thank ybungalabill, that's exactly what I would like to know.Thumbup!Feu
Only some of this answer is true. Window handles do not retain compatibility with 16-bit Windows. They're pointers, which means that their size is architecture-dependent. On 64-bit versions of Windows, they're 64-bit values. On 32-bit versions of Windows, they're 32-bit values. Check the Windows header files for details.Methacrylate
The HANDLE type is not a typedef for void* anymore; it's been years since that was the case. Parts of the MSDN documentation haven't been updated since then apparently, but that doesn't make the assumption any less incorrect. Moreover, that's not even what the article you linked to says. It only says that there is a limit of 65,536 user handles per session. That doesn't say anything about the data type used to store the handles. You're drawing conclusions that aren't explicitly stated and are quite unjustified.Methacrylate
If you're still using the headers that came with VC 6, you're hopelessly out of date. I'm not sure what else to tell you. It's not defined that way in any modern version of the SDK. I don't really understand what you want from MSDN. You want a link that says MSDN is wrong from MSDN? Sorry, that isn't going to happen. Not every page in the online documentation gets updated regularly, and even when updates do happen, stuff gets missed. Raymond Chen writes an entire blog about that. You provided a link to an irrelevant article about GDI handles, which has nothing to do with HWND values.Methacrylate
And none of that really has anything to do with anything. We aren't talking about GDI tables. The point is that window handles are not backwards-compatible with 16-bit versions of Windows. If you declare the HWND type as a short int, things aren't going to work properly. It's not a 16-bit value.Methacrylate
Hmm, remember that STRICT is defined by default now, and has been for years. You must be looking at the wrong branch of the #if statement. And that article is talking about GDI handles, not window handles. You have to read the whole thing, not just the part of it that suits your argument. I'm not arguing with the fact that the values will be re-used. I'm contesting the specious claim that window handles retain compatibility with 16-bit Windows.Methacrylate
@Cody: excuse me, but I'm not going to argue with you further if you don't do even a minimal effort to go and check that HANDLE is typedefed to a void pointer when STRICT is defined and to an integer otherwise. Unless you do a minimal effort to actually look at the table in the article I linked to where it's written that windows are user objects, and the article is talking about user objects (you just made up that it's "talking about GDI handles").Castilian
Remember, we're not talking about HANDLE. We're talking about HWND. I don't understand why you keep talking about things that are completely irrelevant, like GDI handles and the HANDLE type. The question title very clearly says "window handles". I'm not making this up. And I've already addressed that the table is quite irrelevant to this discussion. And finally, we get to the real heart of your argument, which is completely and totally incorrect. Win16 applications will not work on 64-bit versions of Windows. End of story.Methacrylate
It is mentioned in MSDN: typedef HANDLE HWND;, typedef PVOID HANDLE;, typedef void *PVOID;. And the User Objects article mentions HWND, not GDI Objects. GDI Objects have separate article listed in the navigation. And lastly, a bit reference to the handle table.Saidee
@YakovGalka the type of HANDLE is PVOID, indeed a 64 bit void pointer. This is generic, it can be a 64 bit address or it can be an index into a handle table, or it can be a pseudohandle, depending on the handleTransilluminate
B
1

I would advise you to make absolutely no assumptions about handle values.

You shouldn't have to think about concrete handle values for all practical purposes. A handle should be considered an opaque placeholder for something else. You can pass the handle around to refer to something (e.g. a window) without having a reference to the real thing, but you shouldn't ever have to look at the handle itself. The fact that it is a numeric value should be considered an implementation detail, ie. not important (unless maybe you do some kind of low-level systems programming).

That being said, I'd support @jalf's answer: Handle values could get reused. If I had to make any assumption at all about that, I would assume that a handle value could get reused anytime.

Bozo answered 14/8, 2011 at 9:5 Comment(5)
Thank you, your post and his (ybungabol) are very helpful. He posted first so I vote his as accepted answer. My reputation is only 12 at present, I'll upvote you next time if we have a chance to meet again.Feu
@Serious, instead of saying "thumbup" (as with ybungalobill's answer) or "very helpful" (with my answer), just press the up-arrow on the left side of a question!Bozo
You definitely should assume that handle values can be reused. It's not a "potentially" thing. The documentation for the IsWindow() function makes this explicit: "A thread should not use IsWindow for a window that it did not create because the window could be destroyed after this function was called. Further, because window handles are recycled the handle could even point to a different window."Methacrylate
@Cody, you're right, I may perhaps have been too prudent. ;-) I've updated my answer.Bozo
The question is not about representation of a handle, it's about lifetime of thge handle.Throstle

© 2022 - 2024 — McMap. All rights reserved.