After my historical look back on the evolution of system-windows window and class extra bytes, I noted that there was one application that expected to be able to modify GWW_CBCLSEXTRA.

It turns out that there are even more applications that expect to be able to modify GWW_CBWNDEXTRA. So many that it wasn’t worth creating an application compatibility exception for them.

So what happens when you modify GWW_CBWNDEXTRA, or its modern equivalent, GWL_CBWNDEXTRA?

The change in window extra bytes takes effect, but not retroactively.

Windows that are created after you change CBWNDEXTRA receive the updated number of extra bytes, but windows that already exist are not modified. They still have the number of extra bytes that were assigned when the window was created.

Specifically to deal with people who change the number of window extra bytes on the fly, the system keeps track of what the number of extra bytes was at the time the window was created, and those are the bytes you get to access from that window. If you try to access the nonexistent bytes, you are told ERROR_INVALID_INDEX.

This does mean that you can get into a strange situation where GetClassLong(hwnd, GCL_CBWNDEXTRA) tells you that you have 8 extra bytes, say, but if you use GetWindowLong(hWnd, 0), which asks for the LONG represented by bytes 0–3, you are told “Sorry, that’s out of range.” As far as you can tell, it is well within range. What you don’t know is that the window was created back when the GCL_CBWNDEXTRA was less than 4.

There is no way to ask a window, “How many extra bytes do you really have?” I mean, why the system go out its your way to improve the lives of people who are abusing it?