The Wiert Corner – irregular stream of stuff

The bold messages below inside the main message loop are on my research list because:

• they seem to be undocumented in WinUser.h and other header files
• they are sent to Window handles that have no corresponding VCL TWinControl bound to them
• they are WM_TIMER messages sending to a null hwnd, without the Delphi code registering a window-less timer (note the lParam indicates they have different call back procedures attached to them)

Being inside the message loop, they are either posted or created by Windows.

The hexadecimal value for WM_TIMER is documented: [Archive.is] 0x0113 site:https://docs.microsoft.com/en-us/windows/desktop/winmsg – Google Search.

Neither of the below messages are documented in either of the Undocumented Windows books (yes, there are two; the first – though rare to get – was a slightly earlier published one-person effort; the second was a tiny bit later three-person effort, but much thicker and included a diskette with tools; both books complement each other well; I am listed in both):

• ISBN

  9071996573, 9789071996573

  [Archive.is] Undocumented Windows Beyond the Microsoft Reference: The Developer’s … – Tamura Jones – Google Books

• ISBN

  0201608340, 9780201608342

  [WayBack] Undocumented Windows – Andrew Schulman, David Maxey, Matt Pietrek – Google Books

Messages I am looking for:

• 00000060 – 0x0060 site:https://docs.microsoft.com/en-us/windows/desktop/winmsg – Google Search
• 0000031F – 0x031F site:https://docs.microsoft.com/en-us/windows/desktop/winmsg – Google Search
• 00000737 – 0x0737 site:https://docs.microsoft.com/en-us/windows/desktop/winmsg – Google Search
• 00000738 – 0x0738 site:https://docs.microsoft.com/en-us/windows/desktop/winmsg – Google Search
• 0000B000 – 0xB000 site:https://docs.microsoft.com/en-us/windows/desktop/winmsg – Google Search; it might be the [WayBack] Vcl.Controls.CM_ACTIVATE Constant (relative to the [WayBackControls.CM_BASE Constant)
• 0000B001 – 0xB001 site:https://docs.microsoft.com/en-us/windows/desktop/winmsg – Google Search; it might be the [WayBack] Vcl.Controls.CM_DEACTIVATE Constant

Yes, I know that Windows Messages are usually noted as 4 hexadecimal digits, but since they are UINT, the logging framework logs them as 32-bit hexadecimal values as this was a 32-bit application, see these WM_* constants and message ranges:

• 0x0400: [WayBack] WM_USER – Windows applications | Microsoft Docs
• 0x8000: [WayBack] WM_APP – Windows applications | Microsoft Docs
  

  The WM_APP constant is used to distinguish between message values that are reserved for use by the system and values that can be used by an application to send messages within a private window class. The following are the ranges of message numbers available.

  Start	End	Meaning	Note
  0	WM_USER–1	Messages reserved for use by the system.
  WM_USER	0x7FFF	Integer messages for use by private window classes.	Depends on the one that called RegisterClass, see below.
  WM_APP	0xBFFF	Messages available for use by applications.	Depends on the one that called CreateWindow, see below.
  0xC000	0xFFFF	String messages for use by applications.
  0x10000	0xFFFFFFFF	Reserved by the system.

• 0xC000: MAXINTATOM as per [WayBack] About Atom Tables – Windows applications | Microsoft Docs; see also
  • [WayBack] RegisterWindowMessageW function | Microsoft Docs and
    • [WayBack] RegisterWindowMessageA function | Microsoft Docs; Defines a new window message that is guaranteed to be unique throughout the system. The message value can be used when sending or posting messages.
• 0xFFFF: MAXWORD as per [WayBack] Broadcasting user-defined messages – The Old New Thing (do not broadcast inside WM_USER and WM_APP ranges; for other ranges, be very careful)
• [WayBack] c – WM_USER vs WM_APP – Stack Overflow

Note that [WayBack] Which message numbers belong to whom? – The Old New Thing explains more about CreateWindow and RegisterClass, which are important for the above subranges.

• [WayBack] CreateWindowA macro | Microsoft Docs
• [WayBack] CreateWindowExA function | Microsoft Docs
• [WayBack] RegisterClassA function | Microsoft Docs
• [WayBack] RegisterClassExA function | Microsoft Docs
• [WayBack] GetClassInfoA function | Microsoft Docs
• [WayBack] GetClassInfoW function | Microsoft Docs
• [WayBack] GetClassInfoExA function | Microsoft Docs
• [WayBack] GetClassInfoExW function | Microsoft Docs: Retrieves information about a window class, including a handle to the small icon associated with the window class. The GetClassInfo function does not retrieve a handle to the small icon.

Similarly, the sharing of the ID space for Windows Messages, Atom Names and Clipboard Formats:

• [WayBack] GetClassName function | Microsoft Docs: Retrieves the name of the class to which the specified window belongs.
• [WayBack] sendmessage – Get Name of Message registered by RegisterWindowMessage – Stack Overflow
  • [WayBack] Recover name of message registered with RegisterWindowMessage() | The Linux Page
  • [WayBack] Wie man den Namen einer RegisterWindowMessage bekommt – Martins Blog
  • [WayBack] How to get the string that is used to register a message using RegisterWindowMessage – ntcoder
  • [WayBack] Question about string in RegisterWindowMessage()
  • [WayBack] Reverse RegisterWindowMessage() ?
• [WayBack] RegisterClipboardFormatA function | Microsoft Docs:Registers a new clipboard format. This format can then be used as a valid clipboard format.
• [WayBack] GetClipboardFormatNameA function | Microsoft Docs: Retrieves from the clipboard the name of the specified registered format. The function copies the name to the specified buffer.
• [WayBack] Why do atoms start at 0xC000? – The Old New Thing
• [WayBack] Some other places atoms (and the magical 0xC000) arise – The Old New Thing
• [WayBack] How can I investigate the possibility of a lot of leaked window classes (RegisterClass)? – The Old New Thing
  • [Archive.is] HwndWrapper.cs
  • [WayBack] Don’t forget to unregister your window classes when your DLL shuts down dynamically – The Old New Thing
• [WayBack] How can I investigate the possibility of a lot of leaked window classes (RegisterClass)? – The Old New Thing
• [WayBack] What’s the atom returned by RegisterClass useful for? – The Old New Thing
• [WayBack] Strange uses for window class atoms – The Old New Thing
• [WayBack] What can go wrong when you mismatch the calling convention? – The Old New Thing

It might be that two of the messages are related to an undocumented UserAdapterWindowClass: [WayBack] Windows Creators Update Crashes old C++ Apps – Stack Overflow.

On message handling in general:

• [WayBack] winapi – Moving the mouse blocks WM_TIMER and WM_PAINT – Stack Overflow
• [WayBack] messagesandmessagepumps – jfoscoding

Related (as my WM_TIMER knowledge was rusty when scheduling this blog post):

Read the rest of this entry »

Found it. GetMessageTime defines it as the number of milliseconds since the system was started.

Source: [WayBack] winapi – What format is the time member of a MSG structure? – Stack Overflow.

It is not documented in the MSG/tagMSG documentation: [WayBack] tagMSG | Microsoft Docs Contains message information from a thread’s message queue.

Luckily, The Old New Thing does: [WayBack] What clock do MSG.time and GetMessageTime use? – The Old New Thing

The unit is documented in [WayBack] GetMessageTime function | Microsoft Docs: Retrieves the message time for the last message retrieved by the GetMessage function.

–jeroen