http://bugs.winehq.org/show_bug.cgi?id=26227
Summary: GetClipboardFormatName() / RegisterWindowsMessage(): thoroughly incompatible implementation Product: Wine Version: 1.3.14 Platform: x86 OS/Version: All Status: NEW Severity: normal Priority: P2 Component: user32 AssignedTo: wine-bugs@winehq.org ReportedBy: andi@rhlx01.fht-esslingen.de
GetClipboardFormatName() / RegisterWindowsMessage() and related APIs are said to map to identical functions (RVAs) in Windows.
In Wine, we have individual USER drivers (winex11.drv etc), and they do their _own_ (even non-ATOM) clipboard format handling. And RegisterWindowsMessage() uses GlobalAddAtom() which is said to be WRONG, too.
"Registered Window Message String", http://www.eggheadcafe.com/software/aspnet/30695961/registered-window-messag... clarifies it: both APIs are _identical_, and they make use of _another_ _internal_ ATOM table. I.e., there's the application-global (NULL HINSTANCE?) atom table, application-local (per-HINSTANCE?), and this _system-internal_ table _common_ to both clipboard/messages.
Conclusion: incompatibilities abound (and that in a situation where Google "RegisterWindowMessage GetClipboardFormatName" shows 1850 results, IOW a very widely known undocumented Windows behaviour).
If correcting the implementation is deemed less urgent, then perhaps it's useful to add a corresponding comment at a prominent place, hinting at these implementation specifics (should probably reference this bug#).
HTH,
Andreas