{"id":112196,"date":"2026-04-02T07:00:00","date_gmt":"2026-04-02T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=112196"},"modified":"2026-04-02T07:35:55","modified_gmt":"2026-04-02T14:35:55","slug":"20260402-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20260402-00\/?p=112196","title":{"rendered":"Why doesn’t the system let you declare your own messages to have the same semantics as WM_COPY­DATA<\/CODE>?"},"content":{"rendered":"

In a comment on my discussion on how to return results back from the WM_COPY\u00adDATA<\/code> message<\/a>, Jan Ringo\u0161 observed that it felt wasteful that there was this entire infrastructure for copying blocks of memory via a window message, yet only one message uses it! “I always thought something like EnableWindowMessageDataCopy (HWND, UINT, .)<\/a> after RegisterWindowMessage and ChangeWindowMessageFilterEx to get application’s own private WM_COPYDATA would be a little more secure and convenient, should the programmer didn’t wish to bother with creating shared memory.”<\/p>\n

The infrastructure for copying blocks of memory via a window message is used by far more than just one message! The WM_SET\u00adTEXT<\/code> and WM_GET\u00adTEXT<\/code> message use it for passing string buffers, the WM_HELP<\/code> message uses it for passing the HELPINFO<\/code> structure, the WM_MDICREATE<\/code> message uses it for passing the MDICREATSTRUCT<\/code> structure, and plenty more where those came from. The infrastructure for copying blocks of memory had already existed; it wasn’t created just for the WM_COPY\u00adDATA<\/code> message. adding WM_COPY\u00adDATA<\/code> support was just adding a few lines of code to the common function whose job is to prepare messages to be sent between processes (including copying memory between processes).<\/p>\n

Suppose there were a way for a program to declare that one of its custom messages should have (say) its lParam<\/code> be a pointer to data and its wParam<\/code> be the size of the data. That could be misleading because the only behavior would be copying the memory block and not the data inside it. For example, if the structure contained pointers, the pointers would just be copied as raw values, rather than adding the pointed-to-data to the memory block and adjusting the pointers to point to the copy. It also doesn’t handle the case of sending the message between programs with different pointer or handle sizes, say between a 32-bit program and a 64-bit program.\u00b9 If you need to copy data structures that consists of anything more than scalars (or aggregates of scalars), you’ll have to do your own marshaling to convert your source data structure into a transfer buffer. In practice, this means that sending the message directly with an as-is buffer is unlikely to be the common case; some type of conversion would have to be made anyway.<\/p>\n

Furthermore, the WM_COPY\u00adDATA<\/code> already knew that you wanted to do this, because it left room for it in the COPY\u00adDATA\u00adSTRUCT<\/code>:<\/p>\n

typedef struct tagCOPYDATASTRUCT {\r\n  ULONG_PTR dwData; \/\/ \u2190 here\r\n  DWORD     cbData;\r\n  PVOID     lpData;\r\n} COPYDATASTRUCT, *PCOPYDATASTRUCT;\r\n<\/pre>\n
In addition to describing the memory buffer, there is this extra guy called dwData<\/code>. You can put your “message number” in there, allowing you to multiplex multiple “messages” into a single WM_COPY\u00adDATA<\/code> message.\u00b2<\/p>\n
You don’t need Enable\u00adWindow\u00adMessage\u00adData\u00adCopy<\/code> because you already have it at home. The window manager is more concerned with enabling things that weren’t possible before, rather than making it easier to do things that are already possible. For that, you can use a helper library.<\/p>\n
Bonus chatter<\/b>: In addition to adding complexity to the window manager implementation, allowing programs to customize how messages are marshaled between processes would also make it harder to explain how inter-process marshaling works. Instead of the simple rule “The system marshals messages in the system range, but not messages in the user-defined range,” it would be a much more ambiguous rule: “The system marshals messages in the system range, but not messages in the user-defined range, unless those messages have been customized by a call to Enable\u00adWindow\u00adMessage\u00adData\u00adCopy<\/code>, in which case they marshal by this alternate set of rules.” So now when you look at a message, you can’t tell how it marshals. You’d have to go back to the documentation for the message and hope the person who wrote the documentation remembered to go back and add a section to each page to say whether it follows custom marshaling.<\/p>\n
\u00b9 Or between a 16-bit program and a 32-bit program, which was the more common case back in the days when WM_COPY\u00adDATA<\/code> was designed. In 16-bit code, an int<\/code> is a 16-bit integer, whereas it’s a 32-bit value in 32-bit code.<\/p>\n
\u00b2 If the dwData<\/code> was intended to be a message number, why is it pointer-sized? For the same reason  timer IDs and dialog control IDs are 64-bit values<\/a>: “Pointers are like weeds. Anywhere it’s possible to fit a pointer, a pointer will try to squeeze in there.” In this case, people were putting handles (which are pointer-sized) in the dwData<\/code>, so we had to make it big enough to hold a handle.<\/p>\n","protected":false},"excerpt":{"rendered":"
Tempting but misleading.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-112196","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Tempting but misleading.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/112196","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=112196"}],"version-history":[{"count":1,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/112196\/revisions"}],"predecessor-version":[{"id":112197,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/112196\/revisions\/112197"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=112196"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=112196"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=112196"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}