A compatibility note on the abuse of Windows window class extra bytes

The Old New Thing (Raymond Chen) News

Summary

Raymond Chen discusses a historical Windows compatibility issue where some 16-bit programs abused window class extra bytes to store private data, and how Microsoft blocked the loophole for 32-bit and 64-bit programs while maintaining backward compatibility.

<p>During my discussion of <a title="The evolution of Windows window and class extra bytes in Windows" href="https://devblogs.microsoft.com/oldnewthing/20260629-00/?p=112484"> the evolution of system-windows window and class extra bytes</a>, 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.</p> <p>One thing I&#8217;ve learned is that anywhere it&#8217;s possible to hide a pointer, people will hide a pointer there. This is true even for small integers.</p> <p>As I was digging up the history of the extra bytes, I saw a special note in the 16-bit code for <code>Set­Class­Word</code>: It says that there&#8217;s an app that expects to be able to modify the value of <code>GWW_<wbr />CB­CLS­EXTRA</code>.</p> <p>Now, modifying this value has no practical effect because the memory for the class was allocated when you called <code>Register­Class</code>. You can&#8217;t go back in time and change the allocation size.</p> <p>But one program realized that it could use this value as a place to store some private data, so they did. Sure, that&#8217;s not the purpose of the <code>GWW_<wbr />CB­CLS­EXTRA</code>, but that never stopped them.</p> <p>For compatibility, Windows lets 16-bit programs modify <code>GWW_<wbr />CB­CLS­EXTRA</code>. But at least it blocks it for 32-bit and 64-bit programs. One loophole closed. Countless more to go.</p> <p>The post <a href="https://devblogs.microsoft.com/oldnewthing/20260630-00/?p=112488">A compatibility note on the abuse of Windows window class extra bytes</a> appeared first on <a href="https://devblogs.microsoft.com/oldnewthing">The Old New Thing</a>.</p>
Original Article
View Cached Full Text

Cached at: 06/30/26, 05:17 PM

# A compatibility note on the abuse of Windows window class extra bytes - The Old New Thing Source: [https://devblogs.microsoft.com/oldnewthing/20260630-00?p=112488](https://devblogs.microsoft.com/oldnewthing/20260630-00?p=112488) June 30th, 2026 ![like](https://devblogs.microsoft.com/oldnewthing/wp-content/themes/devblogs-evo/images/emojis/like.svg)1 reaction ![](https://devblogs.microsoft.com/oldnewthing/wp-content/uploads/sites/38/2019/02/RaymondChen_5in-150x150.jpg) During my discussion of[the evolution of system\-windows window and class extra bytes](https://devblogs.microsoft.com/oldnewthing/20260629-00/?p=112484), 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\_CB­CLS­EXTRA`\. 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\_CB­CLS­EXTRA`, but that never stopped them\. For compatibility, Windows lets 16\-bit programs modify`GWW\_CB­CLS­EXTRA`\. But at least it blocks it for 32\-bit and 64\-bit programs\. One loophole closed\. Countless more to go\. ### Category ### Topics ## Author ![Raymond Chen](https://devblogs.microsoft.com/oldnewthing/wp-content/uploads/sites/38/2019/02/RaymondChen_5in-150x150.jpg) Raymond has been involved in the evolution of Windows for more than 30 years\. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie\-jeebies\. The Web site spawned a book, coincidentally also titled The Old New Thing \(Addison Wesley 2007\)\. He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information\. ## Read next ## Stay informed Get notified when new posts are published\. Follow this blog - [https://twitter.com/ChenCravat](https://twitter.com/ChenCravat) - [![youtube](https://devblogs.microsoft.com/oldnewthing/wp-content/themes/devblogs-evo/images/social-icons/youtube.svg)](https://www.youtube.com/playlist?list=PLlrxD0HtieHge3_8Dm48C0Ns61I6bHThc) - [https://github.com/oldnewthing](https://github.com/oldnewthing) - [https://devblogs.microsoft.com/oldnewthing/feed/](https://devblogs.microsoft.com/oldnewthing/feed/)

Similar Articles

The evolution of window and class extra bytes in Windows

The Old New Thing (Raymond Chen)

The article traces the evolution of window and class extra bytes in Windows from 16-bit to 32-bit to 64-bit, detailing changes in function names and data sizes as handles and pointers expanded.

Windows stack limit checking retrospective, follow-up

The Old New Thing (Raymond Chen)

Raymond Chen follows up on his previous article about stack limit checking on ARM64, addressing a detail about the unconventional use of the x15 register in stack probe functions and comparing register usage across multiple architectures.

Retrofitting the WM_COPY­DATA message onto Windows 3.1

The Old New Thing (Raymond Chen)

This article explains how the WM_COPYDATA message, introduced for 32-bit Windows, was retrofitted onto 16-bit Windows 3.1 by taking advantage of the shared address space, requiring no changes for inter-16-bit communication.