[Bug 26227] New: GetClipboardFormatName() / RegisterWindowsMessage(): thoroughly incompatible implementation

[wine-bugs at winehq.org]

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 at winehq.org
        ReportedBy: andi at 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-message-string.aspx
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

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.