A customer, via their customer liaison, reported quite some time ago that their program stopped working on Windows XP. (I told you it was quite some time ago.)
The customer’s investigations revealed that the problem occurred because their window was receiving message 0x0091, and the parameters are wrong. Who is sending this message with the wrong parameters?
Okay, first of all, how do you even know that the parameters are wrong? The message is not listed in winuser.h or in MSDN (as it was then called).
We explained that message 0x0091 is an internal message that they should just pass to DefÂWindowÂProc unchanged. What makes the customer think that the message is being received with the wrong parameters?
The customer said that their program was using that message as a custom message, and now, in addition to getting it when their program sends the message, they are also getting spurious copies of the message with WPARAM and LPARAM values that don’t correspond to any values that the program itself sent.
We informed them that they shouldn’t have been using that message for their own purposes. Those messages are in the system-defined range, which means that they are off-limits to applications. If they want to send a private message, use one in the application space.
It’s like finding an empty closet in an office building and using it to store your bicycle, but now, when you come to work, you find that the closet is filled with other stuff and there’s no room for your bicycle any more. “Why is there stuff in that closet?” Because it wasn’t your closet in the first place.
The liaison took our advice back to the customer, but mentioned that the customer probably won’t like that answer. The message 0x0091 was not the only message they were using. They also used other messages below WM_, and they were all causing problems; they just wanted to start their investigation with 0x0091.
Oh well. But I hope it’s as simple as just changing a macro definition from
#define WM_MYSECRETMESSAGE 0x0091
to
#define WM_MYSECRETMESSAGE (WM_APP + 1020) // or something
Pick a message in the range available to applications for custom use.
@Antonio SPI_GETFLATMENU is true for Luna and false for classic, that and the color is the only menu changes a theme can control on XP. Flat menus are implemented in user32/win32k.
Finally, allow me to quote from the Vista development blog; “Windows XP introduced Visual Styles as a mechanism for providing more visual appeal to windows and controls. Menus, however, were not rendered using visual styles for Windows XP. With Windows Vista menus now are part of the visual schema and are rendered using the visual styles engine.”
Oh hey I can answer this one! Of course you should be using the app or user message ranges, but what is message 0x0091 anyway? I figured this out when I was trying to hack easier ways to get dark mode working for the built in menu bar.
WM_UAHDRAWMENU is what I ended up calling it; it parallels the normal WM_DRAWMENU but draws using the theme!
I documented this here: https://github.com/adzm/win32-custom-menubar-aero-theme/blob/main/UAHMenuBar.h along with a sample usage of that info.
uxtheme.dll and the related draw procedures in the default window proc were indeed in Windows XP, at least in SP2.
Themed menus did not exist in XP? This story must be about Vista.
Windows XP menus are themed, but their design isn't as glaring as that of the window frame or the task bar. In Luna, as you say, menus are white with a flat one pixel gray border, and the menu bar is in the theme's button background color (a yellowish gray for the default blue theme, a blueish one for the gray theme). If you select the Windows Classic "theme" (which, in fact, disables theming), Windows XP falls back to the Windows 95 beveled 3D menus. Windows Vista refreshed their style, adding a separate column for icons and returning to the...
While Visual Styles are new in XP, menus did not get custom styles until Vista. In the default Luna theme on XP, the menu bar is gray while the popup menus have a white background.
I tweaked the code from the GitHub link and ran it on XP SP2, the colors did not change and these messages are not sent.
Theme support and uxtheme.dll were introduced in Windows XP. If those messages are related to themed menus (as Adam Walling points), then Windows XP was the first version to use them. This matches Raymond’s story, too.
>But I hope it’s as simple as just changing a macro definition
If they’re using messages in the system-reserved space then you just know it’s not going to be anywhere near that, there’ll be 0x91’s, 0x92, 0x93… hardcoded all over the code base, except for the places where they’re derived arithmetically from some magic constant so you can’t find them with a grep.
And there will be a companion app that sends these messages, but it will be distributed separately, and clients will have a dizzying array of mismatching versions all over the place.
Even worse. Probably many users wouldn't upgrade the programs because "they worked just fine in Windows 98/2000". In fact, I can almost hear them saying "Microsoft is doing this to break competitors' software". It was the usual way of explaining those incidents back them, when the antitrust trial was all the rage.
Those users are easy to spot, even now. They always use a several year old, unsupported version of Windows. They only upgrade when the "newer" version becomes unsupported. And if they are forced to use the current version, they disable Windows Update with some (unsupported, of course) patch. We...