| Date: | December 18, 2003 / year-entry #167 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20031218-00/?p=41453 |
| Comments: | 10 |
| Summary: | In the old days, Windows didn't bother enforcing a nesting limit because, well, if you want to nest windows 200 deep, that's your decision. Many window operations are recursive, but since everything happened on the application's stack, it was your own responsibility to make your stack big enough so it didn't overflow. But Windows NT... |
In the old days, Windows didn't bother enforcing a nesting limit because, well, if you want to nest windows 200 deep, that's your decision. Many window operations are recursive, but since everything happened on the application's stack, it was your own responsibility to make your stack big enough so it didn't overflow. But Windows NT moved the window manager off the application stack (first into a separate process, then into kernel mode). So now the OS needs to watch out for stack overflow attacks from people creating too many nested windows. The window nesting limit was set to 100 for the early days of Windows NT. For Windows XP, it dropped to 50 because increased stack usage in some internal functions caused us to overflow at around 75. Dropping to 50 created some breathing room. Disclaimer: I was not personally involved in this issue. I'm just reporting what I was able to figure out from reading checkin logs. |
Comments (10)
Comments are closed. |
I wish *some* checkin logs(e.g. wmgr) were public, would make an interesting read.
Check in to where? Are you using SourceSafe?
I have only know of one, did other people hit this problem?
ianr at bigfoot dot com
AFAIK Microsoft doesn’t use SourceSafe for OS development. They have their own special software.
Last I heard Microsoft used a Perforce derivative. I suppose the problem with publishing some checkin notes is it provides information about the Windows internals which Microsoft may not wish to divulge (particularly mid-development when anything can change, or be dropped)
I can’t imagine any apps needing more than 10 nested windows (and I’m being generous there). Ian, what kind of app ran into this problem so I can stay far, far away from that company?
No idea, asf.
You can find some (limited) information about MS’ source control system (SourceDepot) in a talk that Mark Lucovsky gave at Usenix’s 4th Windows Systems Symposium. You can find the slides at http://www.usenix.org/events/usenix-win2000/invitedtalks/lucovsky.ppt.
Apparently some teams do use SourceSafe, but the OS team is not one of them.
Raymond,
As a test(I’m interested in oditties concerning the window manager, it’s an obsession..) I wrote an app to test the recursion limit. When creating the 48th window, the cardinal checking for DCBAABCD in callwindowproc from keusermodecallback failed. I would guess the top parent could be considered a child of the desktop itself, but the stack is still being eaten before 50 windows are hit(and it seems to be the temp stack put together by keusermodecallback). That’s with the uxtheme hooks enabled though, so it’s possible that the extra stack overhead there is the cause.
Windows 2000 (SP4) also appears to have a limit of 50.