3 ms·

At least we can explain it away in terms of backwards compatibility. Here's a quirk that's harder to explain: open a powershell window in windows 10. Hit alt-

At least we can explain it away in terms of backwards compatibility. Here's a quirk that's harder to explain: open a powershell window in windows 10. Hit alt-enter rapidly to switch back-and-forth to full-screen mode while looking at the min/max/close buttons. You can see flashes of windows-vista-era buttons. Is the new look just painted on top of the old one? That's crazy!

JonathonW 8y ago
There's one other place where you'll see Vista-era title bars in Windows 10: in the title bars of MDI subwindows, where the application itself (or, rather, the Windows theming engine) is responsible for drawing the title bar rather than the DWM. For whatever reason, that little bit of the theme was never updated (probably because most users will never see it; AFAIK the only program that ships with Windows that still uses that style of MDI window is MMC). My hunch is that something similar's happening here: when you bring a Windows Console window full-screen, it disables its window decorations and the DWM stops drawing them. Through some quirk of timing, it looks like the console window itself starts attempting to draw its decorations, and, when that happens, you'll see Vista-style decorations very briefly, because that's what the theme tells it to draw. (I suppose it's also possible that console windows always draw their title bars themselves underneath the DWM-provided decorations... they've always been a bit weird in Windows.)
Jasper_ 8y ago
I'll explain it: In the olden Windows days, the application is in charge of painting its titlebar by handling the WM_NCPAINT message. The default window handler for this will paint the Windows Vista-era buttons. During Windows 7's development, the responsibility of painting window frames moved from the application to a separate process known as the Desktop Window Manager, "dwm.exe". DWM tells the app that it should stop drawing its own frame when the application is windowed, and tells it is in charge of drawing "the frame" when fullscreen. This is communicated using an asynchronous protocol (private window messages), thus during the transition it's possible for the window's idea of its frame state to be "out of sync" with the real state because the client hasn't processed all of its messages yet.
- richard_todd 8y ago
  Wow, it's great to be able to finally connect the dots on that one, so thanks for the explanation. I guess either there is a subtle reason why it would be a bad idea to update the old-style handler, or they just never got around to it. Either way, I'm just glad the titlebar isn't being drawn twice at all times.

JonathonW 8y ago

There's one other place where you'll see Vista-era title bars in Windows 10: in the title bars of MDI subwindows, where the application itself (or, rather, the Windows theming engine) is responsible for drawing the title bar rather than the DWM. For whatever reason, that little bit of the theme was never updated (probably because most users will never see it; AFAIK the only program that ships with Windows that still uses that style of MDI window is MMC). My hunch is that something similar's happening here: when you bring a Windows Console window full-screen, it disables its window decorations and the DWM stops drawing them. Through some quirk of timing, it looks like the console window itself starts attempting to draw its decorations, and, when that happens, you'll see Vista-style decorations very briefly, because that's what the theme tells it to draw. (I suppose it's also possible that console windows always draw their title bars themselves underneath the DWM-provided decorations... they've always been a bit weird in Windows.)

Jasper_ 8y ago

I'll explain it: In the olden Windows days, the application is in charge of painting its titlebar by handling the WM_NCPAINT message. The default window handler for this will paint the Windows Vista-era buttons. During Windows 7's development, the responsibility of painting window frames moved from the application to a separate process known as the Desktop Window Manager, "dwm.exe". DWM tells the app that it should stop drawing its own frame when the application is windowed, and tells it is in charge of drawing "the frame" when fullscreen. This is communicated using an asynchronous protocol (private window messages), thus during the transition it's possible for the window's idea of its frame state to be "out of sync" with the real state because the client hasn't processed all of its messages yet.

richard_todd 8y ago
Wow, it's great to be able to finally connect the dots on that one, so thanks for the explanation. I guess either there is a subtle reason why it would be a bad idea to update the old-style handler, or they just never got around to it. Either way, I'm just glad the titlebar isn't being drawn twice at all times.