{
	"id": "9348a04d-5c7a-49c7-8613-80f228db6836",
	"created_at": "2026-04-06T00:12:03.628592Z",
	"updated_at": "2026-04-10T03:21:56.011515Z",
	"deleted_at": null,
	"sha1_hash": "aa899dfd9fee813bd5b22d6765d4d51bfc7a3d12",
	"title": "About Window Classes - Win32 apps",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 97056,
	"plain_text": "About Window Classes - Win32 apps\r\nBy Karl-Bridge-Microsoft\r\nArchived: 2026-04-05 13:32:00 UTC\r\nEach window class has an associated window procedure shared by all windows of the same class. The window\r\nprocedure processes messages for all windows of that class and therefore controls their behavior and appearance.\r\nFor more information, see Window Procedures.\r\nA process must register a window class before it can create a window of that class. Registering a window class\r\nassociates a window procedure, class styles, and other class attributes with a class name. When a process specifies\r\na class name in the CreateWindow or CreateWindowEx function, the system creates a window with the window\r\nprocedure, styles, and other attributes associated with that class name.\r\nThis section discusses the following topics.\r\nTypes of Window Classes\r\nSystem Classes\r\nApplication Global Classes\r\nApplication Local Classes\r\nHow the System Locates a Window Class\r\nRegistering a Window Class\r\nElements of a Window Class\r\nClass Name\r\nWindow Procedure Address\r\nInstance Handle\r\nClass Cursor\r\nClass Icons\r\nClass Background Brush\r\nClass Menu\r\nClass Styles\r\nExtra Class Memory\r\nExtra Window Memory\r\nTypes of Window Classes\r\nThere are three types of window classes:\r\nSystem Classes\r\nApplication Global Classes\r\nApplication Local Classes\r\nThese types differ in scope and in when and how they are registered and destroyed.\r\nhttps://msdn.microsoft.com/library/windows/desktop/ms633574.aspx\r\nPage 1 of 8\n\nSystem Classes\r\nA system class is a window class registered by the system. Many system classes are available for all processes to\r\nuse, while others are used only internally by the system. Because the system registers these classes, a process\r\ncannot destroy them.\r\nThe system registers the system classes for a process the first time one of its threads calls a User or a Windows\r\nGraphics Device Interface (GDI) function.\r\nEach application receives its own copy of the system classes. All 16-bit Windows-based applications in the same\r\nVDM share system classes, just as they do on 16-bit Windows.\r\nThe following table describes the system classes that are available for use by all processes.\r\nClass Description\r\nButton The class for a button.\r\nComboBox The class for a combo box.\r\nEdit The class for an edit control.\r\nListBox The class for a list box.\r\nMDIClient The class for an MDI client window.\r\nScrollBar The class for a scroll bar.\r\nStatic The class for a static control.\r\nThe following table describes the system classes that are available only for use by the system. They are listed here\r\nfor completeness sake.\r\nClass Description\r\nComboLBox The class for the list box contained in a combo box.\r\nDDEMLEvent The class for Dynamic Data Exchange Management Library (DDEML) events.\r\nMessage The class for a message-only window.\r\n#32768 The class for a menu.\r\n#32769 The class for the desktop window.\r\n#32770 The class for a dialog box.\r\n#32771 The class for the task switch window.\r\n#32772 The class for icon titles.\r\nhttps://msdn.microsoft.com/library/windows/desktop/ms633574.aspx\r\nPage 2 of 8\n\nApplication Global Classes\r\nAn application global class is a window class registered by an executable or DLL that is available to all other\r\nmodules in the process. For example, your .dll can call the RegisterClassEx function to register a window class\r\nthat defines a custom control as an application global class so that a process that loads the .dll can create instances\r\nof the custom control.\r\nTo create a class that can be used in every process, create the window class in a .dll and load the .dll in every\r\nprocess. To load the .dll in every process, add its name to the AppInit_DLLs value in following registry key:\r\nHKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Windows\r\nWhenever a process starts, the system loads the specified .dll in the context of the newly started process before\r\ncalling its entry-point function. The .dll must register the class during its initialization procedure and must specify\r\nthe CS_GLOBALCLASS style. For more information, see Class Styles.\r\nTo remove an application global class and free the storage associated with it, use the UnregisterClass function.\r\nApplication Local Classes\r\nAn application local class is any window class that an executable or .dll registers for its exclusive use. Although\r\nyou can register any number of local classes, it is typical to register only one. This window class supports the\r\nwindow procedure of the application's main window.\r\nThe system destroys a local class when the module that registered it closes. An application can also use the\r\nUnregisterClass function to remove a local class and free the storage associated with it.\r\nHow the System Locates a Window Class\r\nThe system maintains a list of structures for each of the three types of window classes. When an application calls\r\nthe CreateWindow or CreateWindowEx function to create a window with a specified class, the system uses the\r\nfollowing procedure to locate the class.\r\n1. Search the list of application local classes for a class with the specified name whose instance handle\r\nmatches the module's instance handle. (Several modules can use the same name to register local classes in\r\nthe same process.)\r\n2. If the name is not in the application local class list, search the list of application global classes.\r\n3. If the name is not in the application global class list, search the list of system classes.\r\nAll windows created by the application use this procedure, including windows created by the system on the\r\napplication's behalf, such as dialog boxes. It is possible to override system classes without affecting other\r\napplications. That is, an application can register an application local class having the same name as a system class.\r\nThis replaces the system class in the context of the application but does not prevent other applications from using\r\nthe system class.\r\nRegistering a Window Class\r\nhttps://msdn.microsoft.com/library/windows/desktop/ms633574.aspx\r\nPage 3 of 8\n\nA window class defines the attributes of a window, such as its style, icon, cursor, menu, and window procedure.\r\nThe first step in registering a window class is to fill in a WNDCLASSEX structure with the window class\r\ninformation. For more information, see Elements of a Window Class. Next, pass the structure to the\r\nRegisterClassEx function. For more information, see Using Window Classes.\r\nTo register an application global class, specify the CS_GLOBALCLASS style in the style member of the\r\nWNDCLASSEX structure. When registering an application local class, do not specify the CS_GLOBALCLASS\r\nstyle.\r\nIf you register the window class using the ANSI version of RegisterClassEx, RegisterClassExA, the application\r\nrequests that the system pass text parameters of messages to the windows of the created class using the ANSI\r\ncharacter set; if you register the class using the Unicode version of RegisterClassEx, RegisterClassExW, the\r\napplication requests that the system pass text parameters of messages to the windows of the created class using the\r\nUnicode character set. The IsWindowUnicode function enables applications to query the nature of each window.\r\nFor more information on ANSI and Unicode functions, see Conventions for Function Prototypes.\r\nThe executable or DLL that registered the class is the owner of the class. The system determines class ownership\r\nfrom the hInstance member of the WNDCLASSEX structure passed to the RegisterClassEx function when the\r\nclass is registered. For DLLs, the hInstance member must be the handle to the .dll instance.\r\nThe class is not destroyed when the .dll that owns it is unloaded. Therefore, if the system calls the window\r\nprocedure for a window of that class, it will cause an access violation, because the .dll containing the window\r\nprocedure is no longer in memory. The process must destroy all windows using the class before the .dll is\r\nunloaded and call the UnregisterClass function.\r\nElements of a Window Class\r\nThe elements of a window class define the default behavior of windows belonging to the class. The application\r\nthat registers a window class assigns elements to the class by setting appropriate members in a WNDCLASSEX\r\nstructure and passing the structure to the RegisterClassEx function. The GetClassInfoEx and GetClassLong\r\nfunctions retrieve information about a given window class. The SetClassLong function changes elements of a\r\nlocal or global class that the application has already registered.\r\nAlthough a complete window class consists of many elements, the system requires only that an application supply\r\na class name, the window-procedure address, and an instance handle. Use the other elements to define default\r\nattributes for windows of the class, such as the shape of the cursor and the content of the menu for the window.\r\nYou must initialize any unused members of the WNDCLASSEX structure to zero or NULL. The window class\r\nelements are as shown in the following table.\r\nElement Purpose\r\nClass Name Distinguishes the class from other registered classes.\r\nWindow\r\nProcedure\r\nPointer to the function that processes all messages sent to windows in the class and\r\ndefines the behavior of the window.\r\nhttps://msdn.microsoft.com/library/windows/desktop/ms633574.aspx\r\nPage 4 of 8\n\nElement Purpose\r\nAddress\r\nInstance Handle Identifies the application or .dll that registered the class.\r\nClass Cursor Defines the mouse cursor that the system displays for a window of the class.\r\nClass Icons Defines the large icon and the small icon.\r\nClass\r\nBackground\r\nBrush\r\nDefines the color and pattern that fill the client area when the window is opened or\r\npainted.\r\nClass Menu Specifies the default menu for windows that do not explicitly define a menu.\r\nClass Styles\r\nDefines how to update the window after moving or resizing it, how to process double-clicks of the mouse, how to allocate space for the device context, and other aspects of the\r\nwindow.\r\nExtra Class\r\nMemory\r\nSpecifies the amount of extra memory, in bytes, that the system should reserve for the\r\nclass. All windows in the class share the extra memory and can use it for any application-defined purpose. The system initializes this memory to zero.\r\nExtra Window\r\nMemory\r\nSpecifies the amount of extra memory, in bytes, that the system should reserve for each\r\nwindow belonging to the class. The extra memory can be used for any application-defined purpose. The system initializes this memory to zero.\r\nClass Name\r\nEvery window class needs a Class Name to distinguish one class from another. Assign a class name by setting the\r\nlpszClassName member of the WNDCLASSEX structure to the address of a null-terminated string that specifies\r\nthe name. Because window classes are process specific, window class names need to be unique only within the\r\nsame process. Also, because class names occupy space in the system's private atom table, you should keep class\r\nname strings as short as possible.\r\nThe GetClassName function retrieves the name of the class to which a given window belongs.\r\nWindow Procedure Address\r\nEvery class needs a window-procedure address to define the entry point of the window procedure used to process\r\nall messages for windows in the class. The system passes messages to the procedure when it requires the window\r\nto carry out tasks, such as painting its client area or responding to input from the user. A process assigns a window\r\nprocedure to a class by copying its address to the lpfnWndProc member of the WNDCLASSEX structure. For\r\nmore information, see Window Procedures.\r\nInstance Handle\r\nhttps://msdn.microsoft.com/library/windows/desktop/ms633574.aspx\r\nPage 5 of 8\n\nEvery window class requires an instance handle to identify the application or .dll that registered the class. The\r\nsystem requires instance handles to keep track of all of modules. The system assigns a handle to each copy of a\r\nrunning executable or .dll.\r\nThe system passes an instance handle to the entry-point function of each executable (see WinMain) and .dll (see\r\nDllMain). The executable or .dll assigns this instance handle to the class by copying it to the hInstance member\r\nof the WNDCLASSEX structure.\r\nClass Cursor\r\nThe class cursor defines the shape of the cursor when it is in the client area of a window in the class. The system\r\nautomatically sets the cursor to the given shape when the cursor enters the window's client area and ensures it\r\nkeeps that shape while it remains in the client area. To assign a cursor shape to a window class, load a predefined\r\ncursor shape by using the LoadCursor function and then assign the returned cursor handle to the hCursor\r\nmember of the WNDCLASSEX structure. Alternatively, provide a custom cursor resource and use the\r\nLoadCursor function to load it from the application's resources.\r\nThe system does not require a class cursor. If an application sets the hCursor member of the WNDCLASSEX\r\nstructure to NULL, no class cursor is defined. The system assumes the window sets the cursor shape each time the\r\ncursor moves into the window. A window can set the cursor shape by calling the SetCursor function whenever the\r\nwindow receives the WM_MOUSEMOVE message. For more information about cursors, see Cursors.\r\nClass Icons\r\nA class icon is a picture that the system uses to represent a window of a particular class. An application can have\r\ntwo class icons—one large and one small. The system displays a window's large class icon in the task-switch\r\nwindow that appears when the user presses ALT+TAB, and in the large icon views of the task bar and explorer.\r\nThe small class icon appears in a window's title bar and in the small icon views of the task bar and explorer.\r\nTo assign a large and small icon to a window class, specify the handles of the icons in the hIcon and hIconSm\r\nmembers of the WNDCLASSEX structure. The icon dimensions must conform to required dimensions for large\r\nand small class icons. For a large class icon, you can determine the required dimensions by specifying the\r\nSM_CXICON and SM_CYICON values in a call to the GetSystemMetrics function. For a small class icon,\r\nspecify the SM_CXSMICON and SM_CYSMICON values. For information, see Icons.\r\nIf an application sets the hIcon and hIconSm members of the WNDCLASSEX structure to NULL, the system\r\nuses the default application icon as the large and small class icons for the window class. If you specify a large\r\nclass icon but not a small one, the system creates a small class icon based on the large one. However, if you\r\nspecify a small class icon but not a large one, the system uses the default application icon as the large class icon\r\nand the specified icon as the small class icon.\r\nYou can override the large or small class icon for a particular window by using the WM_SETICON message. You\r\ncan retrieve the current large or small class icon by using the WM_GETICON message.\r\nClass Background Brush\r\nhttps://msdn.microsoft.com/library/windows/desktop/ms633574.aspx\r\nPage 6 of 8\n\nA class background brush prepares the client area of a window for subsequent drawing by the application. The\r\nsystem uses the brush to fill the client area with a solid color or pattern, thereby removing all previous images\r\nfrom that location whether they belong to the window or not. The system notifies a window that its background\r\nshould be painted by sending the WM_ERASEBKGND message to the window. For more information, see\r\nBrushes.\r\nTo assign a background brush to a class, create a brush by using the appropriate GDI functions and assign the\r\nreturned brush handle to the hbrBackground member of the WNDCLASSEX structure.\r\nInstead of creating a brush, an application can set the hbrBackground member to one of the standard system\r\ncolor values. For a list of the standard system color values, see SetSysColors.\r\nTo use a standard system color, the application must increase the background-color value by one. For example,\r\nCOLOR_BACKGROUND + 1 is the system background color. Alternatively, you can use the\r\nGetSysColorBrush function to retrieve a handle to a brush that corresponds to a standard system color, and then\r\nspecify the handle in the hbrBackground member of the WNDCLASSEX structure.\r\nThe system does not require that a window class have a class background brush. If this parameter is set to NULL,\r\nthe window must paint its own background whenever it receives the WM_ERASEBKGND message.\r\nA class menu defines the default menu to be used by the windows in the class if no explicit menu is given when\r\nthe windows are created. A menu is a list of commands from which a user can choose actions for the application to\r\ncarry out.\r\nYou can assign a menu to a class by setting the lpszMenuName member of the WNDCLASSEX structure to the\r\naddress of a null-terminated string that specifies the resource name of the menu. The menu is assumed to be a\r\nresource in the given application. The system automatically loads the menu when it is needed. If the menu\r\nresource is identified by an integer and not by a name, the application can set the lpszMenuName member to that\r\ninteger by applying the MAKEINTRESOURCE macro before assigning the value.\r\nThe system does not require a class menu. If an application sets the lpszMenuName member of the\r\nWNDCLASSEX structure to NULL, windows in the class have no menu bars. Even if no class menu is given, an\r\napplication can still define a menu bar for a window when it creates the window.\r\nIf a menu is given for a class and a child window of that class is created, the menu is ignored. For more\r\ninformation, see Menus.\r\nClass Styles\r\nThe class styles define additional elements of the window class. Two or more styles can be combined by using the\r\nbitwise OR (|) operator. To assign a style to a window class, assign the style to the style member of the\r\nWNDCLASSEX structure. For a list of class styles, see Window Class Styles.\r\nClasses and Device Contexts\r\nhttps://msdn.microsoft.com/library/windows/desktop/ms633574.aspx\r\nPage 7 of 8\n\nA device context is a special set of values that applications use for drawing in the client area of their windows. The\r\nsystem requires a device context for each window on the display but allows some flexibility in how the system\r\nstores and treats that device context.\r\nIf no device-context style is explicitly given, the system assumes each window uses a device context retrieved\r\nfrom a pool of contexts maintained by the system. In such cases, each window must retrieve and initialize the\r\ndevice context before painting and free it after painting.\r\nTo avoid retrieving a device context each time it needs to paint inside a window, an application can specify the\r\nCS_OWNDC style for the window class. This class style directs the system to create a private device context—\r\nthat is, to allocate a unique device context for each window in the class. The application need only retrieve the\r\ncontext once and then use it for all subsequent painting.\r\nThe system maintains a WNDCLASSEX structure internally for each window class in the system. When an\r\napplication registers a window class, it can direct the system to allocate and append a number of additional bytes\r\nof memory to the end of the WNDCLASSEX structure. This memory is called extra class memory and is shared\r\nby all windows belonging to the class. Use the extra class memory to store any information pertaining to the class.\r\nBecause extra memory is allocated from the system's local heap, an application should use extra class memory\r\nsparingly. The RegisterClassEx function fails if the amount of extra class memory requested is greater than 40\r\nbytes. If an application requires more than 40 bytes, it should allocate its own memory and store a pointer to the\r\nmemory in the extra class memory.\r\nThe SetClassWord and SetClassLong functions copy a value to the extra class memory. To retrieve a value from\r\nthe extra class memory, use the GetClassWord and GetClassLong functions. The cbClsExtra member of the\r\nWNDCLASSEX structure specifies the amount of extra class memory to allocate. An application that does not\r\nuse extra class memory must initialize the cbClsExtra member to zero.\r\nThe system maintains an internal data structure for each window. When registering a window class, an application\r\ncan specify a number of additional bytes of memory, called extra window memory. When creating a window of the\r\nclass, the system allocates and appends the specified amount of extra window memory to the end of the window's\r\nstructure. An application can use this memory to store window-specific data.\r\nBecause extra memory is allocated from the system's local heap, an application should use extra window memory\r\nsparingly. The RegisterClassEx function fails if the amount of extra window memory requested is greater than 40\r\nbytes. If an application requires more than 40 bytes, it should allocate its own memory and store a pointer to the\r\nmemory in the extra window memory.\r\nThe SetWindowLong function copies a value to the extra memory. The GetWindowLong function retrieves a\r\nvalue from the extra memory. The cbWndExtra member of the WNDCLASSEX structure specifies the amount\r\nof extra window memory to allocate. An application that does not use the memory must initialize cbWndExtra to\r\nzero.\r\nSource: https://msdn.microsoft.com/library/windows/desktop/ms633574.aspx\r\nhttps://msdn.microsoft.com/library/windows/desktop/ms633574.aspx\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://msdn.microsoft.com/library/windows/desktop/ms633574.aspx"
	],
	"report_names": [
		"ms633574.aspx"
	],
	"threat_actors": [],
	"ts_created_at": 1775434323,
	"ts_updated_at": 1775791316,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/aa899dfd9fee813bd5b22d6765d4d51bfc7a3d12.pdf",
		"text": "https://archive.orkl.eu/aa899dfd9fee813bd5b22d6765d4d51bfc7a3d12.txt",
		"img": "https://archive.orkl.eu/aa899dfd9fee813bd5b22d6765d4d51bfc7a3d12.jpg"
	}
}