WND

The WND (formally tagWND) is the primary representation of a window. It is in some ways a very important structure, certainly to access quickly, and especially for USER32 to read directly in user mode.

Documentation Status

The WND is not documented. Though symbol files for WIN32K.SYS in Windows 8 and higher name the WND in the C++ decorations of internal routines, type information for the structure is present in symbol files for Windows 7 only—not before and not since.

That said, many of Microsoft’s names for both the WND and its members were long known in public from the plain-text output of meta-commands that are implemented in debugger extensions that Microsoft supplied with its debuggers in various kits for both kernel-mode and user-mode programming. See, for instance, USEREXTS.DLL from as far back as the Device Driver Kit (DDK) for Windows NT 3.51. Though the WND structure is not formally documented, Microsoft certainly has understood that knowledge of it may help programmers in the depths of debugging what they’re doing with Windows!

Variability

Perhaps not surprisingly, given its need to be accessible from both kernel-mode and user-mode components, the WND does not vary nearly as much as do other undocumented structures. Almost all of the members that are the most useful to know in practice, e.g., while debugging, have been stable since version 5.1. No member has shifted position since version 6.0. Additions since version 6.2 have all been made by appending to the structure. The following changes of size are known:

Layout

It is well known that the WND is not the whole of its size. Each WND is followed in its allocation by a number of “extra” bytes that is specified as cbWndExtra in the WNDCLASS or WNDCLASSEX when registering the window class that the window is created from.  

HEAD head;

THROBJHEAD head;

THRDESKHEAD head;

WW;

WND *spwndNext;

WND *spwndPrev;

WND *spwndParent;

WND *spwndChild;

WND *spwndOwner;

DESKTOP *spdeskParent;

WND *pwo;

RECT rcWindow;

RECT rcClient;

WNDPROC lpfnWndProc;

CLS *pcls;

INT cbwndExtra;

HRGN hrgnUpdate;

WND *spwndLastActive;

PROPLIST *ppropList;

SBINFO *pSBInfo;

MENU *spmenuSys;

MENU *spmenu;

HRGN hrgnClip;

HRGN hrgnNewFrame;

LARGE_UNICODE_STRING strName;

CHAR bFullScreen;

CHAR cDC;

USHORT fnid;

DWORD dwExpWinVer;

DWORD dwUserData;

HDC hdcOwn;

HRGN hrgnClip;

INT iHungRedraw;

WW;

INT cbwndExtra;

WND *spwndLastActive;

HIMC hImc;

DWORD dwUserData;

ACTIVATION_CONTEXT *pActCtx;

D3DMATRIX *pTransform;

WND *spwndClipboardListenerNext;

union {
    ULONG ExStyle2;
    /* bit fields, follow link */
};

Where its !dw command describes what symbol files later name as pSBInfo, the USEREXTS debugger extension for Windows NT 3.51 uses the name rgwScroll, but what’s pointed to is what’s later known as an SBINFO even if it and its members once had other names.

The spmenu member does a double duty that is not at all suggested by its name but is no surprise from the documented interpretation of the CreateWindow function’s hMenu argument. For a child window, spmenu is not a pointer to a MENU but is instead the window’s ID such as returned by the GetWindowLong function when given the index GWL_ID (-12).

Whatever may have been intended by its Hungarian prefix, the bFullScreen member is not a boolean even in version 3.10. As the FullScreenMode bit field in union with state2 for version 5.0 and higher, it is 3 bits wide.

Appended Since Windows 7

Microsoft’s names for members that have been added to the WND since Windows 7 may never be known. On the plus side, if only for neatness of presentation, new members have been added simply by appending. 

The pointer at offsets 0xC4 and 0x0148 is accessible through the GetWindowLongPtr and SetWindowLongPtr functions, using -2 as the index.

The word at offsets 0xD4 and 0x0168 is the window’s DPI scaling, such as posted in both the low and high 16 bits of the wParam for a WM_DPICHANGED (0x02E0) message.

WW

While the WW is thought to be nested in no other structure, it may as well be presented here. It is nowadays 0x18 or 0x20 bytes in 32-bit and 64-bit Windows, respectively, but is 0x20 bytes before version 5.0.

That said, even if the WW never exists except in a WND, or when copied from one, it evidently is intended to be visible in its own right. In all Windows versions, the address of the nested WW is returned by the GetWindowLong function when given the index -1 (which is conspicuously not among the documented inputs). That the structure is named WW and does not originally begin with the bit fields is obscure. The name seems to be public only in the output of the !dso debugger commands as implemented by the USEREXTS and USERKDX debugger extensions from the DDKs for Windows NT 4.0 and Windows 2000.

union {
    ULONG state;
    /* bit fields, follow link */
};

union {
    ULONG state2;
    /* bit fields, follow link */
};

union {
    ULONG ExStyle;
    /* bit fields, follow link */
};

union {
    ULONG style;
    /* bit fields, follow link */
};

PVOID hModule;

USHORT hMod16;

USHORT fnid;

That some sort of substructure wraps the state, state2 (in applicable versions), ExStyle and style has long been a supportable proposition. Right from the start, WINSRV and then WIN32K has code for accessing these members’ bits by a 16-bit encoding whose high and low bytes are respectively a byte offset from the first member and a byte-wide bit mask. The only known instance of this encoding in WINSRV version 3.10 is 0x0320 for the state bit that symbol files later name bAnsiCreator. Version 3.51, however, has 0x0A10 and 0x0A20 for bits in the style, which puts beyond doubt that these members make a tightly integrated set. Very likely, given the optimisation capability of Microsoft’s compiler even in the early 90s, most of this 16-bit encoding’s use in all versions is more readily visible in the source code than in the binary. By version 4.0, the encoding can be seen more in USER32 than in WIN32K: changes to these flags by USER32 require a transition to WIN32K with the encoding passed as an argument, not interpreted at compile-time and optimised away.

For the output of its !dw command, the USEREXTS debugger extension from the DDK for Windows NT 3.51 has dwExStyle for the extended window styles that symbol files and later versions of that debugger extension present simply as ExStyle. It is here thought that the difference is more of how the debugger extension’s programmer thought of the member, or thought it would better be presented to programmers, than of how it was named in Microsoft’s source code.