During my discussion of the evolution of system-windows window and class extra bytes, I noted that even though IDs are typically small integers, people liked to stash pointers there, so we had to expand the ID field to a pointer-sized integer.
One thing I’ve learned is that anywhere it’s possible to hide a pointer, people will hide a pointer there. This is true even for small integers.
As I was digging up the history of the extra bytes, I saw a special note in the 16-bit code for SetÂClassÂWord: It says that there’s an app that expects to be able to modify the value of GWW_.
Now, modifying this value has no practical effect because the memory for the class was allocated when you called RegisterÂClass. You can’t go back in time and change the allocation size.
But one program realized that it could use this value as a place to store some private data, so they did. Sure, that’s not the purpose of the GWW_, but that never stopped them.
For compatibility, Windows lets 16-bit programs modify GWW_. But at least it blocks it for 32-bit and 64-bit programs. One loophole closed. Countless more to go.
There is so many slots where one can place extra bytes, yet, somehow, they always pick places they should really stay away from. What’s wrong with the GWLP_USERDATA range for storing pointer-sized data? Or just adhering to the documented way of doing things in general?
You know; I wouldn’t have been that surprised if it trashed memory in 16 bit Windows when the class was freed.
Whatever program did *that* was just plain old nuts.